When a driver taps an RFID card, the charger thinks for a moment and then either turns the light green or shows red. In that short moment the charger asks the management software, with an Authorize message, "Can this card start charging?" This article explains the Authorize flow, the possible replies and the most common problems in the field.

The Authorize flow

  1. The user taps the card; the charger reads the card ID (UID).
  2. The charger sends this ID to the CSMS as the idTag in an Authorize message.
  3. The CSMS checks whether the card is registered and valid, whether the user is allowed at this station and what their limits are.
  4. The reply comes back with a status inside idTagInfo.
  5. If the status is Accepted, the charger prepares to start charging.

Example:

[2, "3001", "Authorize", {"idTag": "04A2B3C4D5E6F7"}] [3, "3001", {"idTagInfo": {"status": "Accepted", "expiryDate": "2027-01-01T00:00:00Z"}}]

Possible status values

In OCPP 1.6J, idTagInfo.status takes one of these values:

  • Accepted: The card is valid and charging can start.
  • Blocked: The card is blocked (for example after being reported lost).
  • Expired: The card's validity has expired.
  • Invalid: The card is not recognised.
  • ConcurrentTx: This card is already being used in another charging transaction.

The reply can optionally include expiryDate and parentIdTag. parentIdTag is used in scenarios such as cards from the same group being able to stop each other's transactions; see idTag and parentIdTag for details.

In OCPP 2.0.1 and 2.1 the structure is similar, but the fields are called idToken and idTokenInfo. The type of ID (ISO14443, eMAID, KeyCode, Central and so on) is specified separately, and the status list is extended (for example NoCredit, NotAllowedTypeEVSE, NotAtThisLocation, NotAtThisTime).

Is Authorize always required?

No. Authorize can be skipped in some scenarios:

  • Remote start: When the user starts charging from a mobile app, the CSMS sends RemoteStartTransaction. Whether the charger authorises again depends on the AuthorizeRemoteTxRequests setting. See AuthorizeRemoteTxRequests.
  • Local list and cache: If the charger finds the card valid in its local authorisation list or cache, it can, depending on its settings, start charging without asking the CSMS.
  • Free mode: Some private installations can be configured for automatic charging without a card.

What happens offline?

When the internet is down, the charger cannot ask the CSMS. The behaviour then depends on the settings:

  • If LocalAuthorizeOffline = true, the charger can start charging for cards that are valid in the local list or cache.
  • If AllowOfflineTxForUnknownId = true, charging can start even with unrecognised cards (a risky setting).
  • If neither applies, charging cannot start while offline.

See our article on LocalAuthorizeOffline and offline charging for details.

Common problems

  • The card is registered in the dashboard but returns Invalid: The card UID may be read in a different format (reversed byte order, missing leading zeros and so on). The idTag in the charger logs must match the record in the dashboard exactly.
  • The card works and charging starts even though the limit is used up: The limit check must happen during Authorize. In Üreticy, the card of a driver whose limit is used up is rejected at the Authorize stage and the reason is logged.
  • Slow replies: If the mobile connection is slow, the driver waits a few seconds. A local cache reduces this delay.

We cover every aspect of card authorisation in our guide to RFID charging card authorisation in OCPP.

IDs other than cards

Authorize is not limited to RFID cards. In sessions started from a mobile app or a QR code, the CSMS passes a user-specific ID to the charger with the remote start request. In Plug & Charge scenarios the vehicle identifies itself with an ISO 15118 certificate, and in OCPP 2.0.1/2.1 this identity is validated as an idToken of type eMAID. Some chargers also allow PIN entry on their own keypad. Whatever method is used, the rules on the CSMS side should be the same: who can charge, at which station, with which limits. This consistency ensures drivers get the same experience whichever method they choose.

Conclusion

Authorize is the gate that decides who can access the charging network. Correct reply codes, well-designed offline behaviour and consistent card records improve both security and driver satisfaction. Üreticy's OCPP software lets you assign cards to drivers, block them and see every rejected tap with its reason.