OCPP 2.1 Edition 2 Section C

Authorization Flows - CSMS Developer Guide

Based on OCPP 2.1 Edition 2 Specification (Part 2), Section C (Authorization). This guide covers all authorization flows (C01–C25, D01), including RFID, PIN-code, ISO 15118, remote start, caching, local auth lists, ad hoc payments, and QR code payments from the CSMS perspective using OCPP-J (JSON over WebSocket).

28 Sections

25 Use Cases

C01 – C25, D01

1. Overview

Introduction

The Authorization functional block handles all authorization-related OCPP messaging. From the CSMS perspective, you must handle incoming authorization requests, transaction events, and outgoing remote start/stop and cache management commands.

Key Concepts

Incoming AuthorizeRequest

Messages from Charging Stations requesting authorization. Respond with AuthorizeResponse.

Incoming TransactionEventRequest

Messages containing authorization-related data during transactions. Respond with TransactionEventResponse.

Outgoing Remote Start/Stop

RequestStartTransactionRequest and RequestStopTransactionRequest for CSMS-initiated transactions.

Cache & Local List Management

ClearCacheRequest, GetLocalListVersionRequest, and SendLocalListRequest for managing offline authorization data.

ID Token Types

The IdTokenType is the core authorization identifier. The CSMS must support these type values:

IdToken Type	Description
`Central`	Server-generated token for CSMS-initiated transactions. SHALL NOT be cached.
`eMAID`	Electro-Mobility Account Identifier (ISO 15118 Plug & Charge)
`ISO14443`	RFID UID per ISO 14443 (most common physical RFID)
`ISO15693`	RFID UID per ISO 15693
`KeyCode`	PIN-code entered by user
`Local`	Locally generated identifier (e.g., parking ticket)
`MacAddress`	MAC address based
`NoAuthorization`	No authorization needed (start button chargers)
`DirectPayment`	Ad hoc payment via payment terminal (PspRef as idToken value)

Important: IdToken comparison is case-insensitive on idToken and type fields only. The additionalInfo field is NOT used for comparison.

Authorization Status Values

The CSMS must set idTokenInfo.status to one of the following:

Status	Meaning	CSMS Action
`Accepted`	Token is valid, charging allowed	Allow charging
`Blocked`	Token is blocked	Reject charging
`ConcurrentTx`	Token already in use in another transaction	Reject charging
`Expired`	Token has expired	Reject charging
`Invalid`	Token is unknown/invalid	Reject charging
`NoCredit`	Token valid but account has no credit (prepaid)	Reject charging
`NotAllowedTypeEVSE`	Token valid but not allowed at this EVSE type	Reject charging
`NotAtThisLocation`	Token valid but not at this Charging Station/EVSE	Reject charging
`NotAtThisTime`	Token valid but not at this time	Reject charging
`Unknown`	Token could not be identified at this time	Reject charging

Group ID Tokens

Tokens can be grouped by including a groupIdToken in the IdTokenInfoType. This allows:

Family/business accounts sharing a charging contract
Any token in the group can stop a transaction started by another token in the same group
The groupIdToken.type SHOULD be Central

2. Shared Data Types & Schemas

Reference

AuthorizeRequest Schema

Direction: Charging Station → CSMS

AuthorizeRequest Schema

{
  "idToken": {                    // REQUIRED - IdTokenType
    "idToken": "string (max 255)", // REQUIRED - case insensitive identifier
    "type": "string (max 20)",     // REQUIRED - e.g. "ISO14443", "eMAID", "KeyCode", etc.
    "additionalInfo": [            // OPTIONAL - extra info for authorization
      {
        "additionalIdToken": "string (max 255)", // REQUIRED
        "type": "string (max 50)"                // REQUIRED
      }
    ]
  },
  "certificate": "string (max 10000)",  // OPTIONAL - PEM X.509 cert chain (ISO 15118)
  "iso15118CertificateHashData": [      // OPTIONAL - OCSP data (1-4 items)
    {
      "hashAlgorithm": "SHA256|SHA384|SHA512",  // REQUIRED
      "issuerNameHash": "string (max 128)",      // REQUIRED
      "issuerKeyHash": "string (max 128)",       // REQUIRED
      "serialNumber": "string (max 40)",         // REQUIRED
      "responderURL": "string (max 2000)"        // REQUIRED
    }
  ]
}

AuthorizeResponse Schema

Direction: CSMS → Charging Station

AuthorizeResponse Schema

{
  "idTokenInfo": {                            // REQUIRED - IdTokenInfoType
    "status": "AuthorizationStatusEnumType",  // REQUIRED - see status table above
    "cacheExpiryDateTime": "date-time",       // OPTIONAL - when cache entry expires
    "chargingPriority": "integer (-9..9)",    // OPTIONAL - default 0
    "groupIdToken": {                         // OPTIONAL - IdTokenType for group
      "idToken": "string (max 255)",
      "type": "string (max 20)"
    },
    "language1": "string (max 8)",            // OPTIONAL - RFC 5646 language code
    "language2": "string (max 8)",            // OPTIONAL - must differ from language1
    "evseId": [1, 2],                         // OPTIONAL - restrict to specific EVSEs
    "personalMessage": {                      // OPTIONAL - MessageContentType
      "format": "ASCII|HTML|URI|UTF8|QRCODE", // REQUIRED
      "content": "string (max 1024)",          // REQUIRED
      "language": "string (max 8)"             // OPTIONAL
    }
  },
  "certificateStatus": "Accepted|SignatureError|CertificateExpired|CertificateRevoked|NoCertificateAvailable|CertChainError|ContractCancelled",
  "allowedEnergyTransfer": ["AC_single_phase", "DC", ...],  // OPTIONAL - defaults to charging only
  "tariff": { ... }  // OPTIONAL - TariffType for cost calculation
}

TransactionEventRequest Schema

Direction: Charging Station → CSMS (authorization-relevant fields)

TransactionEventRequest Schema (Authorization-relevant fields)

{
  "eventType": "Started|Updated|Ended",     // REQUIRED
  "timestamp": "date-time",                  // REQUIRED
  "triggerReason": "TriggerReasonEnumType",  // REQUIRED
  "seqNo": "integer >= 0",                   // REQUIRED
  "transactionInfo": {                        // REQUIRED
    "transactionId": "string (max 36)",       // REQUIRED
    "chargingState": "EVConnected|Charging|SuspendedEV|SuspendedEVSE|Idle",
    "stoppedReason": "ReasonEnumType",
    "remoteStartId": "integer",               // Links to RequestStartTransaction
    "operationMode": "OperationModeEnumType",
    "tariffId": "string (max 60)",
    "transactionLimit": {
      "maxCost": "number",
      "maxEnergy": "number (Wh)",
      "maxTime": "integer (seconds)",
      "maxSoC": "integer (0-100)"
    }
  },
  "idToken": { ... },       // OPTIONAL - IdTokenType
  "evse": {                  // OPTIONAL
    "id": "integer",
    "connectorId": "integer"
  },
  "meterValue": [ ... ],    // OPTIONAL
  "costDetails": { ... },   // OPTIONAL - cost breakdown
  "offline": false           // OPTIONAL - default false
}

TransactionEventResponse Schema

Direction: CSMS → Charging Station

TransactionEventResponse Schema

{
  "totalCost": "number",            // OPTIONAL - running/final cost
  "chargingPriority": "integer",    // OPTIONAL - overrides IdTokenInfo priority
  "idTokenInfo": { ... },           // OPTIONAL - IdTokenInfoType
  "transactionLimit": {             // OPTIONAL
    "maxCost": "number",
    "maxEnergy": "number (Wh)",
    "maxTime": "integer (seconds)",
    "maxSoC": "integer (0-100)"
  },
  "updatedPersonalMessage": { ... },       // OPTIONAL - MessageContentType
  "updatedPersonalMessageExtra": [ ... ]   // OPTIONAL - array of MessageContentType (1-4)
}

Note: The TransactionEventResponse has NO required fields. An empty JSON {} is a valid response.

3. C01 — EV Driver Authorization using RFID

CS-Initiated

Use Case ID	C01
Direction	CS → CSMS (CS initiates)
Trigger	EV Driver presents RFID card at Charging Station
OCPP Messages	AuthorizeRequest / AuthorizeResponse

Flow Diagram

Sequence Diagram (CSMS perspective)

EV Driver              Charging Station                    CSMS
   |                        |                               |
   |--present RFID--------->|                               |
   |                        |--AuthorizeRequest(idToken)--->|
   |                        |                               |-- validate token
   |                        |<--AuthorizeResponse-----------|
   |<--notification---------|                               |

CSMS Handler: AuthorizeRequest

When received, the Charging Station needs to authorize an RFID token. The CSMS must look up the token, determine authorization status, and build the response.

CSMS Processing Logic

Look up the idToken in your user/token database (case-insensitive match on idToken.idToken and idToken.type)
Determine authorization status based on business rules
Build the AuthorizeResponse

Condition	Response
Token valid, allowed on all EVSEs	`status = Accepted, evseId empty/absent`
Token valid, allowed on specific EVSEs only	`status = Accepted, evseId = [1, 2]`
Token valid, NOT allowed at this CS	`status = NotAtThisLocation`
Token valid, NOT allowed on EVSE type (AC/DC)	`status = NotAllowedTypeEVSE`
Token has associated groupIdToken	`Include groupIdToken in response`

Decision Tree

idTokenInfo.status Decision Tree

Is idToken known?
  NO  -> status = "Invalid"
  YES -> Is idToken blocked?
    YES -> status = "Blocked"
    NO  -> Is idToken expired?
      YES -> status = "Expired"
      NO  -> Is idToken already in an active transaction?
        YES -> status = "ConcurrentTx"
        NO  -> Is idToken allowed at this Charging Station?
          NO  -> status = "NotAtThisLocation"
          YES -> Is idToken allowed at the EVSE type?
            NO  -> status = "NotAllowedTypeEVSE"
            YES -> Is idToken allowed at specific EVSEs only?
              YES -> status = "Accepted", evseId = [list]
              NO  -> status = "Accepted" (all EVSEs)

Response Examples

AuthorizeResponse — Accepted

{
  "idTokenInfo": {
    "status": "Accepted",
    "cacheExpiryDateTime": "2025-12-31T23:59:59Z",
    "language1": "en-US",
    "groupIdToken": {
      "idToken": "GROUP-001",
      "type": "Central"
    }
  }
}

AuthorizeResponse — Rejected (Not at this location)

{
  "idTokenInfo": {
    "status": "NotAtThisLocation",
    "personalMessage": {
      "format": "UTF8",
      "content": "This card is not authorized at this charging station.",
      "language": "en-US"
    }
  }
}

AuthorizeResponse — Restricted to specific EVSEs

{
  "idTokenInfo": {
    "status": "Accepted",
    "evseId": [1, 3],
    "language1": "en-US"
  }
}

Language Requirements

If language1 is NOT set, language2 SHALL NOT be set
language1 and language2 MUST be different
Languages SHALL be RFC 5646 tags (e.g., "en-US")
RECOMMENDED: implement English as fallback

4. C02 — Authorization using a Start Button

CS-Initiated

Use Case ID	C02
Direction	CS → CSMS (CS initiates)
Trigger	EV Driver presses start button (no RFID)
OCPP Messages	TransactionEventRequest / TransactionEventResponse

When a Charging Station has a start button instead of RFID, no AuthorizeRequest is sent. The CSMS learns about the transaction via TransactionEventRequest.

Flow Diagram

Sequence Diagram (CSMS perspective)

EV Driver              Charging Station                    CSMS
   |                        |                               |
   |--plug in cable-------->|                               |
   |                        |--TransactionEventRequest----->|
   |                        |  (eventType=Started)          |
   |--press start button--->|                               |
   |                        |  (starts charging)            |
   |                        |--TransactionEventRequest----->|
   |                        |  (eventType=Updated,          |
   |                        |   idToken.type=NoAuthorization)|
   |                        |<--TransactionEventResponse----|
   |                        |   (idTokenInfo.status=Accepted)|

CSMS Handler: TransactionEventRequest with NoAuthorization

When a TransactionEventRequest arrives with an idToken of type = NoAuthorization and the idToken field left empty:

CSMS Processing

Recognize NoAuthorization type — this is a start-button charger
Respond with TransactionEventResponse with idTokenInfo.status = Accepted
Do NOT attempt to cache NoAuthorization tokens

TransactionEventResponse — Example

{
  "idTokenInfo": {
    "status": "Accepted"
  }
}

5. C04 — Authorization using PIN-code

CS-Initiated

Use Case ID	C04
Direction	CS → CSMS (CS initiates)
Trigger	EV Driver enters PIN-code at Charging Station
OCPP Messages	AuthorizeRequest / AuthorizeResponse

Same flow as C01 but with idToken.type = KeyCode.

Flow Diagram

Sequence Diagram (CSMS perspective)

EV Driver              Charging Station                    CSMS
   |                        |                               |
   |--enter PIN "1234"----->|                               |
   |                        |--AuthorizeRequest------------>|
   |                        |  (idToken.id="1234",          |
   |                        |   idToken.type="KeyCode")     |
   |                        |<--AuthorizeResponse-----------|

CSMS Handler: AuthorizeRequest with KeyCode

CSMS Processing

Look up the keyCode against your PIN database
Validate the PIN is allowed at this Charging Station
Return Accepted or Invalid

Security Requirements

The CSMS SHALL NOT log the idToken value (PIN) in any logs — key codes must never appear in logs
RECOMMENDED: implement brute force protection by increasing backoff times after failed attempts

AuthorizeResponse — Valid PIN

{
  "idTokenInfo": {
    "status": "Accepted"
  }
}

AuthorizeResponse — Invalid PIN

{
  "idTokenInfo": {
    "status": "Invalid"
  }
}

6. C05 — Authorization for CSMS Initiated Transactions

CSMS-Initiated

Use Case ID	C05
Direction	CSMS → CS (CSMS initiates remote start)
Trigger	EV Driver uses a mobile app to start charging
OCPP Messages	RequestStartTransactionRequest/Response, TransactionEventRequest/Response

Flow Diagram

Sequence Diagram (CSMS perspective)

EV Driver    APP         Charging Station                    CSMS
   |          |               |                               |
   |--start-->|               |                               |
   |          |--start req--->|                               |
   |          |               |                   determine unique idToken
   |          |               |                   result = "4444", type = Central
   |          |               |<--RequestStartTransactionReq--|
   |          |               |   (evseId=1, idToken.id=4444, |
   |          |               |    idToken.type=Central,       |
   |          |               |    remoteStartId=123)          |
   |          |               |--RequestStartTransactionResp->|
   |          |               |   (status=Accepted)            |
   |          |               |--TransactionEventRequest------>|
   |          |               |  (eventType=Updated,           |
   |          |               |   triggerReason=RemoteStart,    |
   |          |               |   remoteStartId=123)           |
   |          |               |<--TransactionEventResponse-----|

CSMS Outgoing: RequestStartTransactionRequest

RequestStartTransactionRequest Schema

{
  "evseId": 1,                         // OPTIONAL - EVSE number (> 0)
  "idToken": {                          // REQUIRED
    "idToken": "4444",                  // REQUIRED - unique server-generated ID
    "type": "Central"                   // REQUIRED - use "Central" for server-generated
  },
  "remoteStartId": 123,                // REQUIRED - unique ID for this start request
  "groupIdToken": { ... },             // OPTIONAL
  "chargingProfile": { ... }           // OPTIONAL - ChargingProfileType
}

Important Rules for Central Type Tokens

SHALL NOT be cached by the Charging Station
Can be single-use virtual tokens
remoteStartId SHALL be provided at least once in a TransactionEventRequest

Handling RequestStartTransactionResponse

RequestStartTransactionResponse Schema

{
  "status": "Accepted|Rejected",
  "statusInfo": { ... },              // OPTIONAL
  "transactionId": "string (max 36)"  // OPTIONAL - if transaction already started
}

Response Handling

Accepted = Charging Station accepted the request
Rejected = Charging Station rejected (e.g., EVSE not available)
If transactionId is present, a transaction was already started before the remote start

Matching Response to Transaction: When the Charging Station sends TransactionEventRequest after remote start, transactionInfo.remoteStartId will match the remoteStartId you sent. Use this to correlate the app request with the actual transaction.

7. C06 — Authorization using Local ID Type

CS-Initiated

Use Case ID	C06
Direction	CS → CSMS (CS initiates)
Trigger	EV Driver presents a locally generated identifier (e.g., parking ticket)
OCPP Messages	AuthorizeRequest/Response, RequestStopTransactionRequest/Response

Flow Diagram

Sequence Diagram (CSMS perspective)

EV Driver   PaymentTerminal  Charging Station               CSMS
   |             |                |                            |
   |--present parking ticket----->|                            |
   |             |                |--AuthorizeRequest--------->|
   |             |                | (idToken.id="1234",        |
   |             |                |  idToken.type="Local")     |
   |             |                |<--AuthorizeResponse--------|
   |             |                |                            |
   ...transaction occurs...
   |             |                |                            |
   |--present parking ticket----->|                            |
   |             |   stop charging|                            |
   |             |                |--RequestStopTransactionReq-|->
   |             |                |  (transactionId="AB1234")  |
   |             |                |<-RequestStopTransactionRes-|

CSMS Handler

Same as C01 — receive AuthorizeRequest, validate the local token, return AuthorizeResponse. The CSMS may also need to send a RequestStopTransactionRequest when the payment terminal signals stop:

RequestStopTransactionRequest

{
  "transactionId": "AB1234"   // REQUIRED - string, max 36 chars
}

RequestStopTransactionResponse

{
  "status": "Accepted|Rejected"
}

8. C07 — Authorization using Contract Certificates (ISO 15118)

CS-Initiated

Use Case ID	C07
Direction	CS → CSMS (CS initiates)
Trigger	Plug & Charge / ISO 15118 contract certificate authorization
OCPP Messages	AuthorizeRequest / AuthorizeResponse

Flow Diagram

Sequence Diagram (CSMS perspective)

EV         Charging Station                    CSMS              (Sub)CA
|               |                               |                  |
|               |--AuthorizeRequest(----------->|                  |
|               |   idToken=<EMAID>,            |                  |
|               |   iso15118CertificateHashData)|                  |
|               |                               |--OCSP request--->|
|               |                               |<--OCSP response--|
|               |                               |                  |
|               |<--AuthorizeResponse-----------|                  |
|               |   (idTokenInfo, certStatus)   |                  |

CSMS Handler: AuthorizeRequest with Certificate Data

When an AuthorizeRequest contains iso15118CertificateHashData (and optionally certificate):

CSMS Processing

Verify signature of GenChallenge (from ISO 15118 layer)
Check certificate validity via OCSP (real-time or cached) — use iso15118CertificateHashData to make OCSP requests to the CA. The responderURL in each hash data entry is the OCSP responder.
Check idToken (eMAID) authorization against your user database
Build response with both idTokenInfo and certificateStatus

AuthorizeResponse — Certificate valid, eMAID accepted

{
  "idTokenInfo": {
    "status": "Accepted",
    "cacheExpiryDateTime": "2025-06-30T23:59:59Z"
  },
  "certificateStatus": "Accepted"
}

AuthorizeResponse — Certificate valid but eMAID blocked

{
  "idTokenInfo": {
    "status": "Blocked"
  },
  "certificateStatus": "ContractCancelled"
}

AuthorizeResponse — Certificate revoked

{
  "idTokenInfo": {
    "status": "Invalid"
  },
  "certificateStatus": "CertificateRevoked"
}

Optional: Handling the certificate field. If the Charging Station cannot validate the contract certificate locally (lacks root cert and CentralContractValidationAllowed = true), it passes the full PEM certificate chain in the certificate field. The CSMS must then validate it.

Decision Matrix

Certificate Valid?	eMAID Accepted?	certificateStatus	idTokenInfo.status
Yes	Yes	`Accepted`	`Accepted`
Yes	No (Blocked)	`ContractCancelled`	`Blocked`
Yes	No (Expired)	`ContractCancelled`	`Expired`
Yes	No (Invalid)	`ContractCancelled`	`Invalid`
Yes	No (Unknown)	`ContractCancelled`	`Unknown`
Expired	N/A	`CertificateExpired`	`Expired`
Revoked	N/A	`CertificateRevoked`	`Invalid`
Cannot verify	N/A	`CertChainError`	`Invalid`

9. C08 — Authorization at EVSE using ISO 15118 EIM

CS-Initiated

Use Case ID	C08
Direction	CS → CSMS (CS initiates)
Trigger	External Identification Means (EIM) via ISO 15118
OCPP Messages	AuthorizeRequest / AuthorizeResponse

External Identification Means (EIM) via ISO 15118. The Charging Station sends an AuthorizeRequest with an idToken containing the External Identification (e.g., RFID used while ISO 15118 communication is active).

CSMS Handler: Same as C01 — standard AuthorizeRequest / AuthorizeResponse flow. The only difference is the availability of ISO 15118 communication between EV and EVSE.

10. C09 — Authorization by GroupId

CS-Initiated

Use Case ID	C09
Direction	CS → CSMS (CS initiates)
Trigger	Two different IdTokens with the same GroupId start/stop the same transaction
OCPP Messages	AuthorizeRequest / AuthorizeResponse

Flow Diagram

Sequence Diagram (CSMS perspective)

EVDriver1  EVDriver2  Charging Station                    CSMS
   |          |             |                               |
   |--present IdToken(001)->|                               |
   |          |             |--AuthorizeRequest(001)------->|
   |          |             |<--AuthorizeResponse-----------|
   |          |             |   (groupIdToken=123, status)  |
   |          |             |                               |
   ...transaction running...
   |          |             |                               |
   |          |--present IdToken(002)-->|                   |
   |          |             |--AuthorizeRequest(002)------->|
   |          |             |<--AuthorizeResponse-----------|
   |          |             |   (groupIdToken=123, status)  |
   |          |             |                               |
   |          |             | (same groupId -> stop allowed)|

CSMS Requirements

When Sending AuthorizeResponse

If the idToken has an associated groupIdToken, the response SHALL include the groupIdToken
The groupIdToken.type SHOULD be Central

When Receiving TransactionEventRequest

If the idToken has a groupIdToken, include groupIdToken in the TransactionEventResponse.

AuthorizeResponse — With GroupId

{
  "idTokenInfo": {
    "status": "Accepted",
    "groupIdToken": {
      "idToken": "FAMILY-ACCOUNT-123",
      "type": "Central"
    }
  }
}

11. C10 — Store Authorization Data in Authorization Cache

CS-Side

Use Case ID	C10
Mechanism	Charging Station side — CSMS influences via responses
Purpose	Caching authorization data for offline use

This is a Charging Station side mechanism. The CSMS influences it by including idTokenInfo in AuthorizeResponse and TransactionEventResponse messages, and by setting cacheExpiryDateTime to control how long cache entries live.

CSMS Behavior

Cache Control Guidelines

Always include complete idTokenInfo in responses (even for rejected tokens — the CS caches all statuses)
Set cacheExpiryDateTime to control cache duration
If omitted, the cache entry has no expiration (controlled by AuthCacheLifeTime config)
For prepaid accounts: set cacheExpiryDateTime to current time (prevents caching)
Do NOT include additionalInfo of idToken or groupIdToken in responses intended for caching (they are not cached)

How the CS uses the cache: The Charging Station stores idTokenInfo from AuthorizeResponse in its cache, and updates entries from TransactionEventResponse.

12. C11 — Clear Authorization Cache

CSMS-Initiated

Use Case ID	C11
Direction	CSMS → CS (CSMS initiates)
Purpose	Clear the Charging Station's authorization cache
OCPP Messages	ClearCacheRequest / ClearCacheResponse

Flow Diagram

Sequence Diagram (CSMS perspective)

Charging Station                    CSMS
      |                               |
      |<--ClearCacheRequest-----------|
      |                               |
      |--ClearCacheResponse---------->|
      |   (status=Accepted/Rejected)  |

CSMS Outgoing: ClearCacheRequest

ClearCacheRequest

{}

ClearCacheResponse Schema

{
  "status": "Accepted|Rejected",   // REQUIRED
  "statusInfo": {                    // OPTIONAL
    "reasonCode": "string (max 20)", // REQUIRED
    "additionalInfo": "string (max 1024)"  // OPTIONAL
  }
}

Status	Meaning
`Accepted`	Cache was successfully cleared
`Rejected`	Cache not enabled (AuthCacheEnabled = false) or clearing failed

13. C12 — Start Transaction with Cached Id

CS-Initiated

Use Case ID	C12
Direction	CS → CSMS (CS initiates)
Trigger	CS authorizes locally from cache, then sends TransactionEventRequest
OCPP Messages	TransactionEventRequest / TransactionEventResponse

Flow Diagram

Sequence Diagram (CSMS perspective)

EV Driver              Charging Station                    CSMS
   |                        |                               |
   |--plug in cable-------->|                               |
   |                        |--TransactionEventRequest----->|
   |                        |  (eventType=Started)          |
   |                        |<--TransactionEventResponse----|
   |--present IdToken------>|                               |
   |                        | (check cache -> Accepted)     |
   |                        |--TransactionEventRequest----->|
   |                        |  (eventType=Updated,          |
   |                        |   triggerReason=Authorized,    |
   |                        |   idToken=...)                |
   |                        |<--TransactionEventResponse----|

CSMS Handler

[C12.FR.03] When receiving a TransactionEventRequest with an idToken, the CSMS SHALL check the authorization status of the idToken. This is your opportunity to reject a token that was locally accepted but is no longer valid.

Processing

Look up the idToken in your database
If the token is still valid, respond with idTokenInfo.status = Accepted
If the token is no longer valid, respond with the appropriate rejection status
The Charging Station will update its cache with the new idTokenInfo

Response — Token still valid

{
  "idTokenInfo": {
    "status": "Accepted",
    "cacheExpiryDateTime": "2025-12-31T23:59:59Z"
  }
}

Response — Token no longer valid

{
  "idTokenInfo": {
    "status": "Blocked"
  }
}

Note: What the Charging Station does when it receives a non-Accepted status depends on MaxEnergyOnInvalidId and StopTxOnInvalidId configuration variables.

14. C13 — Offline Authorization through Local Authorization List

CSMS-Initiated

Use Case ID	C13
Mechanism	CSMS manages the Local Authorization List on the CS
Purpose	Enable offline authorization using a pre-loaded list
OCPP Messages	GetLocalListVersionRequest/Response, SendLocalListRequest/Response

This is primarily a Charging Station side mechanism used when offline. The CSMS controls it by sending SendLocalListRequest to manage the list.

Query Current List Version

GetLocalListVersionRequest (CSMS → CS)

{}

GetLocalListVersionResponse (CS → CSMS)

{
  "versionNumber": 42   // REQUIRED - current version
}

Send Local List Update

SendLocalListRequest Schema (CSMS → CS)

{
  "versionNumber": 43,              // REQUIRED - new version number
  "updateType": "Full|Differential", // REQUIRED
  "localAuthorizationList": [        // OPTIONAL (required for Full, optional for Diff)
    {
      "idToken": {                   // REQUIRED
        "idToken": "AA12345",
        "type": "ISO14443"
      },
      "idTokenInfo": {               // OPTIONAL (omit to delete entry in Differential)
        "status": "Accepted",
        "cacheExpiryDateTime": "2025-12-31T23:59:59Z",
        "groupIdToken": {
          "idToken": "GROUP-001",
          "type": "Central"
        }
      }
    }
  ]
}

Update Type	Description
`Full`	Complete replacement of the entire list. Must include localAuthorizationList.
`Differential`	Add/update/delete individual entries. Include idTokenInfo to add/update. Omit idTokenInfo to delete.

SendLocalListResponse Schema (CS → CSMS)

{
  "status": "Accepted|Failed|VersionMismatch",  // REQUIRED
  "statusInfo": { ... }                           // OPTIONAL
}

Status	Meaning
`Accepted`	List update applied successfully
`Failed`	Failed to apply the update
`VersionMismatch`	Differential update version doesn't match current version

Best Practice: For Differential updates, first query current version with GetLocalListVersionRequest, then send an update with versionNumber = current + 1.

15. C14 — Online Authorization through Local Authorization List

CS-Side

Use Case ID	C14
Mechanism	CS pre-authorizes locally when online, CSMS can override via TransactionEventResponse
Prerequisite	LocalPreAuthorize = true and idToken found in Local Authorization List with status Accepted

When the Charging Station is online and the idToken is found in the Local Authorization List with status Accepted, it may authorize locally without sending an AuthorizeRequest to the CSMS (if LocalPreAuthorize = true).

CSMS Involvement: Same as C12 (Start Transaction - Cached Id). You receive TransactionEventRequest and can override the local authorization in the response by returning a different idTokenInfo.status.

16. C15 — Unknown Offline Authorization

CS-Initiated

Use Case ID	C15
Direction	CS → CSMS (CS sends queued messages after reconnect)
Prerequisite	OfflineTxForUnknownIdEnabled = true
Purpose	Handle transactions started offline with unknown IdTokens

When offline and OfflineTxForUnknownIdEnabled = true, a Charging Station may accept unknown IdTokens. When it comes back online, it sends the queued TransactionEventRequest messages.

CSMS Handler

When receiving TransactionEventRequest for an offline-authorized transaction:

The offline flag will be true
Validate the idToken
If NOT accepted, respond with rejection status

CS Behavior After Rejection

Condition	Charging Station Behavior
StopTxOnInvalidId = true AND TxStopPoint contains Authorized/PowerPathClosed/EnergyTransfer	CS stops transaction, sends TransactionEventRequest(Ended, stoppedReason=DeAuthorized)
StopTxOnInvalidId = true AND TxStopPoint does NOT contain those values	CS stops energy, sends TransactionEventRequest(Updated, triggerReason=Deauthorized, chargingState=SuspendedEVSE)
StopTxOnInvalidId = false AND MaxEnergyOnInvalidId set	CS allows energy up to the MaxEnergy limit
StopTxOnInvalidId = false AND MaxEnergyOnInvalidId not set or exceeded	CS stops energy, suspends EVSE

17. C16 — Stop Transaction with a Master Pass

CS-Initiated

Use Case ID	C16
Direction	CS → CSMS (CS initiates)
Trigger	A Master Pass IdToken is presented at the Charging Station
OCPP Messages	AuthorizeRequest/Response, TransactionEventRequest/Response

A Master Pass is a special IdToken whose GroupId equals the configured MasterPassGroupId. It allows stopping selected ongoing transactions (e.g., for law enforcement).

Flow Diagram

Sequence Diagram (CSMS perspective)

User                Charging Station                    CSMS
  |                      |                               |
  |--present MasterPass->|                               |
  |                      |--AuthorizeRequest------------>|
  |                      |<--AuthorizeResponse-----------|
  |                      |   (groupId = MasterPassGroupId)|
  |<--select tx to stop--|                               |
  |--select tx---------->|                               |
  |                      |  (stop selected transactions)  |
  |                      |--TransactionEventRequest----->|
  |                      |  (eventType=Ended,             |
  |                      |   stopReason=MasterPass)       |
  |                      |<--TransactionEventResponse----|

CSMS Handler

AuthorizeRequest for MasterPass

Validate the idToken as usual
If valid, include groupIdToken with the value of MasterPassGroupId in the response
The CS will recognize this as a MasterPass and show UI to select transactions to stop (or stop all if no UI)

AuthorizeResponse — MasterPass Accepted

{
  "idTokenInfo": {
    "status": "Accepted",
    "groupIdToken": {
      "idToken": "MASTER-PASS-GROUP",
      "type": "Central"
    }
  }
}

TransactionEventRequest with stoppedReason=MasterPass

Process as a normal transaction end. The stoppedReason = MasterPass indicates the transaction was stopped by a MasterPass holder.

Important: IdTokens with groupId equal to MasterPassGroupId SHALL NOT be allowed to start a transaction.

18. C17 — Authorization with Prepaid Card

CS-Initiated

Use Case ID	C17
Direction	CS → CSMS (CS initiates)
Trigger	Prepaid card presented for authorization
OCPP Messages	AuthorizeRequest/Response, TransactionEventRequest/Response

CSMS Handler: AuthorizeRequest for Prepaid Account

Condition	Response
Card invalid	`status = Invalid`
Card valid, balance <= 0	`status = NoCredit, cacheExpiryDateTime = current time`
Card valid, balance > 0	`status = Accepted, cacheExpiryDateTime = current time`

Critical: Set cacheExpiryDateTime to the current time so the prepaid token is NOT retained in the authorization cache. This ensures the Charging Station always sends an AuthorizeRequest to check the current balance.

AuthorizeResponse — Valid prepaid with balance

{
  "idTokenInfo": {
    "status": "Accepted",
    "cacheExpiryDateTime": "2025-02-16T14:30:00Z"
  }
}

Transaction Limit for Prepaid

When a TransactionEventRequest with eventType = Started comes in for a prepaid token, respond with transactionLimit.maxCost set to the remaining balance. Only include this the first time.

TransactionEventResponse — Prepaid Transaction Started

{
  "idTokenInfo": {
    "status": "Accepted",
    "cacheExpiryDateTime": "2025-02-16T14:30:00Z"
  },
  "transactionLimit": {
    "maxCost": 12.34
  }
}

19. C18 — Authorization using Locally Connected Payment Terminal

CS-Initiated

Use Case ID	C18
Direction	CS → CSMS (CS initiates)
Trigger	Ad hoc (direct) payment via integrated payment terminal
OCPP Messages	AuthorizeRequest/Response, VatNumberValidationRequest/Response

CSMS Handler: AuthorizeRequest for Direct Payment

When PaymentCtrlr.AuthorizeDirectPayment = true, the Charging Station sends an AuthorizeRequest with:

idToken.idToken = <PspRef> (payment reference from PSP)
idToken.type = DirectPayment
additionalInfo containing payment details (e.g., CardBin, CardLast4Digits)

CSMS Processing

Validate the payment reference
Optionally return a tariff (if not using default)
Respond with Accepted or rejection

AuthorizeResponse — With tariff

{
  "idTokenInfo": {
    "status": "Accepted"
  },
  "tariff": {
    "tariffId": "ADHOC-001",
    "currency": "EUR",
    "energy": {
      "prices": [{ "priceKwh": 0.35 }]
    },
    "fixedFee": {
      "prices": [{ "priceFixed": 1.00 }]
    }
  }
}

When PaymentCtrlr.AuthorizeDirectPayment = false, no AuthorizeRequest is sent. The CSMS first learns about the transaction via TransactionEventRequest.

VAT Number Validation

The Charging Station may send a VatNumberValidationRequest for ad hoc payments:

VatNumberValidationRequest (CS → CSMS)

{
  "vatNumber": "string",
  "evseId": 1
}

VatNumberValidationResponse (CSMS → CS)

{
  "status": "Accepted|Rejected",
  "vatNumber": "string",
  "evseId": 1,
  "company": "string"  // OPTIONAL - company name if validated
}

20. C19 — Cancellation Prior to Transaction

CS-Initiated

Use Case ID	C19
Direction	CS → CSMS (CS initiates)
Trigger	EV Driver cancels before a transaction starts
OCPP Messages	NotifySettlementRequest / NotifySettlementResponse

The EV Driver cancels before a transaction starts (before TransactionEventRequest is sent).

CSMS Handler: NotifySettlementRequest (Cancelled)

When PaymentCtrlr.AuthorizeDirectPayment = true, the Charging Station sends a NotifySettlementRequest with status = Cancelled.

Record that the payment for this PspRef/idToken has been cancelled
No charging or settlement is needed
Respond with NotifySettlementResponse

21. C20 — Cancellation After Start of Transaction

CS-Initiated

Use Case ID	C20
Direction	CS → CSMS (CS initiates)
Trigger	Transaction started but no energy delivered, payment cancelled
OCPP Messages	TransactionEventRequest/Response, NotifySettlementRequest/Response

CSMS Handler

Receive TransactionEventRequest with eventType = Ended and triggerReason = StopAuthorized or EVConnectTimeout
Respond with TransactionEventResponse with totalCost = 0
Receive NotifySettlementRequest with status = Cancelled
Record the cancellation

TransactionEventResponse — Cancelled Transaction

{
  "totalCost": 0
}

22. C21 — Settlement at End of Transaction

CS-Initiated

Use Case ID	C21
Direction	CS → CSMS (CS initiates)
Trigger	Ad hoc payment transaction ends, final cost must be settled
OCPP Messages	NotifySettlementRequest / NotifySettlementResponse

CSMS Handler: NotifySettlementRequest (Settled)

The Charging Station sends a NotifySettlementRequest with:

transactionId — the OCPP transaction ID
pspRef — the idToken value (PspRef)
status = Settled
settlementAmount — the final settled amount
settlementTime — when settlement occurred
Optionally vatNumber, vatCompany

ReceiptByCSMS	CSMS Action
`true`	Generate receipt, respond with receiptUrl in NotifySettlementResponse
`false`	Acknowledge the settlement, no receipt URL needed

When SettlementByCSMS = true

The CSMS handles settlement directly with the PSP (instead of the payment terminal):

Receive TransactionEventRequest(Ended) with costDetails
Settle with PSP using the PspRef
PSP returns receipt data
Respond to NotifySettlementRequest with receiptUrl

23. C22 — Settlement is Rejected or Fails

CS-Initiated

Use Case ID	C22
Direction	CS → CSMS (CS initiates)
Trigger	Settlement is rejected by PSP or fails due to technical error
OCPP Messages	NotifySettlementRequest / NotifySettlementResponse

CSMS Handler: NotifySettlementRequest (Rejected/Failed)

The Charging Station sends a NotifySettlementRequest with:

status = Rejected (PSP rejected settlement) or Failed (technical failure)
Includes transactionId, pspRef, settlementAmount, settlementTime

CSMS Processing

Record the failed/rejected settlement
CSO may need to manually capture the amount by contacting the PSP directly using the PspRef (which is the idToken value)
Respond with NotifySettlementResponse

24. C23 — Increasing Authorization Amount

CS-Initiated

Use Case ID	C23
Direction	CS → CSMS (CS initiates)
Trigger	Costs exceed initial authorization amount during a transaction
OCPP Messages	TransactionEventRequest / TransactionEventResponse

During a transaction, costs may exceed the initial authorization amount. The Charging Station handles incremental authorization with the payment terminal and notifies the CSMS.

CSMS Handler

When receiving a TransactionEventRequest with triggerReason = LimitSet and an updated transactionLimit.maxCost:

Record the new transaction limit
This is informational — the Charging Station has already increased the authorization with the payment terminal
Respond with TransactionEventResponse

25. C24 — Ad Hoc Payment via Stand-alone Payment Terminal

CSMS-Initiated

Use Case ID	C24
Direction	CSMS → CS (CSMS sends remote start after payment kiosk authorization)
Trigger	Separate payment kiosk communicates with PSP, then CSMS
OCPP Messages	RequestStartTransactionRequest/Response, TransactionEventRequest/Response

CSMS Outgoing: RequestStartTransactionRequest

When the CSMS receives payment authorization from the Payment Kiosk (outside OCPP):

RequestStartTransactionRequest — Ad Hoc Payment

{
  "evseId": 1,
  "idToken": {
    "idToken": "4444",
    "type": "DirectPayment"
  },
  "remoteStartId": 123
}

Note: Include additionalInfo elements for payment details (cardBin, cardLast4Digits) as needed.

When the Charging Station confirms the transaction started, respond with the payment card authorization amount:

TransactionEventResponse — Transaction Limit

{
  "transactionLimit": {
    "maxCost": 100.00
  }
}

Settlement

After the transaction ends:

Receive TransactionEventRequest(Ended) with costDetails (if local cost calculation) or without (if central)
Settle with PSP or Payment Kiosk based on implementation
Optionally send SetDisplayMessageRequest with receipt URL

26. C25 — Ad Hoc Payment via QR Code

CSMS-Initiated

Use Case ID	C25
Direction	CSMS → CS (CSMS initiates remote start after QR-based payment)
Trigger	EV Driver scans QR code on Charging Station display
OCPP Messages	NotifyWebPaymentStartedRequest/Response, RequestStartTransactionRequest/Response, TransactionEventRequest/Response

Flow Diagram (Dynamic QR Code)

Sequence Diagram (CSMS perspective)

EV Driver       Charging Station       CSMS              PSP
   |                  |                   |                 |
   |--scan QR code--->|                   |                 |
   |  (URL with TOTP) |                   |                 |
   |--visit URL-------|------------------>|                 |
   |                  |                   |--validate TOTP  |
   |                  |                   |--decode URL     |
   |                  |<--NotifyWebPaymentStartedReq--------|
   |                  |--NotifyWebPaymentStartedResp------->|
   |                  |                   |--forward to PSP>|
   |--enter payment---|---credentials---->|---------------->|
   |                  |                   |<--PspRef, details|
   |                  |<--RequestStartTransactionReq--------|
   |                  |--RequestStartTransactionResp------->|
   |                  |--TransactionEventRequest----------->|
   |                  |<--TransactionEventResponse----------|

TOTP Validation

URL Validation [C25.FR.07]

Decode the URL parameters (chargingstationid, evse, totp, version)
Validate the TOTP using the shared secret and validity time configured for that Charging Station
Compare against current time interval AND adjacent intervals (previous/next) to handle clock skew
If invalid, do NOT start a transaction

TOTP Algorithm

Uses HMAC-SHA256 with shared secret
Base62 encoding (0-9, a-z, A-Z)
Must check current time interval plus previous and next intervals

After Successful URL Validation [C25.FR.09, C25.FR.20]

Decode URL parameters (charging station identity, optional EVSE number)
Accept query parameters: maxenergy, maxtime, maxcost [C25.FR.59]
Forward EV Driver to PSP web page for payment

Optional: NotifyWebPaymentStartedRequest [C25.FR.21]

Send to the Charging Station to indicate a web payment is in progress. Includes evseId and timeout (seconds to lock the EVSE).

After Payment Authorization

Send RequestStartTransactionRequest with idToken.type = DirectPayment
Include transactionLimit in the TransactionEventResponse based on any limits from the URL parameters

Settlement

Same as C24 — settle with PSP after transaction ends.

27. D01 — Send Local Authorization List

Referenced

Referenced here because it is critical to authorization functionality. The full implementation is in Section D (Local Authorization List Management).

CSMS Responsibilities

Query current list version: Send GetLocalListVersionRequest, receive version number
Full update: Send SendLocalListRequest with updateType = Full and complete list
Differential update: Send SendLocalListRequest with updateType = Differential:
- Include idTokenInfo to add/update entries
- Omit idTokenInfo (only provide idToken) to delete entries

Configuration Variables

Managed via SetVariablesRequest:

Variable	Description
`LocalAuthListEnabled`	Enable/disable the Local Authorization List
`LocalAuthListEntries`	Max number of entries supported
`LocalAuthListAvailable`	Whether the CS supports this feature
`ItemsPerMessageSendLocalList`	Max entries per message
`BytesPerMessageSendLocalList`	Max bytes per message

28. Message Direction Summary

Reference

Incoming to CSMS (Charging Station → CSMS)

Message	CSMS Must Respond With	Use Cases
`AuthorizeRequest`	AuthorizeResponse	`C01, C04, C06, C07, C08, C09, C16, C17, C18`
`TransactionEventRequest`	TransactionEventResponse	`C02, C05, C06, C12, C15, C17, C18–C25`
`ClearCacheResponse`	(response to CSMS request)	`C11`
`GetLocalListVersionResponse`	(response to CSMS request)	`C13, C14`
`SendLocalListResponse`	(response to CSMS request)	`C13, C14`
`RequestStartTransactionResponse`	(response to CSMS request)	`C05, C24, C25`
`RequestStopTransactionResponse`	(response to CSMS request)	`C06`
`NotifySettlementRequest`	NotifySettlementResponse	`C19, C20, C21, C22`
`NotifyWebPaymentStartedResponse`	(response to CSMS request)	`C25`
`VatNumberValidationRequest`	VatNumberValidationResponse	`C18`

Outgoing from CSMS (CSMS → Charging Station)

Message	When to Send	Use Cases
`RequestStartTransactionRequest`	CSMS wants to start a remote transaction	`C05, C24, C25`
`RequestStopTransactionRequest`	CSMS wants to stop a transaction	`C06`
`ClearCacheRequest`	Clear the CS authorization cache	`C11`
`GetLocalListVersionRequest`	Query Local Auth List version	`C13, C14`
`SendLocalListRequest`	Update Local Authorization List	`C13, C14`
`NotifyWebPaymentStartedRequest`	Notify CS about QR code payment in progress	`C25`
`SetDisplayMessageRequest`	Show receipt URL on CS display	`C24, C25`