Transaction Flows - CSMS Developer Guide

Start Triggers by TxStartPoint:

CSMS Implementation Steps:

1. Store the transaction — Create a new transaction record using transactionInfo.transactionId. Record the timestamp, evse.id, evse.connectorId, and seqNo.
2. Validate the IdToken (if present) — Look up the idToken in your authorization system.
3. Respond with TransactionEventResponse containing idTokenInfo with status and groupIdToken if one exists.
4. Track sequence numbers — Store seqNo to verify all messages are received.

Key Requirements:

CSMS Implementation Steps:

1. On StatusNotificationRequest — Update connector status to Occupied. Respond with empty StatusNotificationResponse.
2. On first TransactionEventRequest (Started) — Create transaction record. Note: idToken is NOT present yet. Store chargingState = EVConnected and meter values with context = Transaction.Begin.
3. On Updated (triggerReason=Authorized) — Validate the idToken against your authorization system. Check for reservations if reservationId is present. Respond with idTokenInfo.
4. On Updated (chargingState=Charging) — Update transaction state and store periodic meter values.

Key Requirements:

CSMS Implementation Steps:

1. On Started (triggerReason=Authorized) — idToken IS present in this first message. Validate the token, respond with idTokenInfo. If reservationId is present, link the transaction to the reservation.
2. On Updated (triggerReason=CablePluggedIn) — First time evse.id and evse.connectorId appear. Update transaction with EVSE assignment.
3. Handle EVConnectionTimeout — If the driver does not plug in within EVConnectionTimeOut, the CS may send TransactionEventRequest(eventType=Ended, triggerReason=EVConnectTimeout, stoppedReason=Timeout). CSMS should close the transaction.

Key Requirements:

CSMS Implementation Steps:

1. Accept all queued messages — When offline = true, the CSMS receives messages that may be hours or days old. Process them chronologically.
2. Validate tokens retroactively — The CS authorized locally. The CSMS should still validate the token and include idTokenInfo in responses to update the CS authorization cache.
3. Handle out-of-order delivery — Messages may arrive in a different order. Use seqNo and timestamp to reconstruct the correct sequence.
4. Always respond — The CSMS MUST always respond to TransactionEventRequest, even for offline transactions. Not responding causes the CS to retry (see E13).

Key Requirements:

CSMS Implementation Steps:

1. Validate the IdToken (CRITICAL) — The identifier might have been authorized locally using outdated information. The CSMS MUST verify validity (E05.FR.01).
2. Respond with non-Accepted status when the token is invalid.
3. What happens next depends on CS configuration (not CSMS controlled):

CSMS Implementation Steps:

1. Close the transaction — Mark it as completed with the timestamp from the Ended message.
2. Store final meter values — The meterValue array with context = Transaction.End contains final readings for billing.
3. Calculate and return cost (optional) — Return totalCost in the response. Omit = not free; 0.00 = free.
4. Record stoppedReason — Important for billing disputes and analytics.
5. Validate idToken (if present) — The stopping token may differ from the starting token (same GroupId). Still respond with idTokenInfo.

Key Requirements:

CSMS Implementation Steps:

1. On Updated with triggerReason=StopAuthorized — The stopping idToken may differ from the starting token (they share the same GroupId). Validate the token and respond with idTokenInfo. Note: the CSMS CANNOT prevent a transaction from stopping.
2. On Ended — Close the transaction, store final meter values, optionally return totalCost, respond with idTokenInfo if idToken was included.

Key Requirements:

CSMS Implementation Steps:

1. Process identically to online stop — The transaction end is valid; process meter values and calculate costs.
2. Note the offline = true flag — The stop happened in the past, potentially hours or days ago.
3. Respond normally — Include totalCost if applicable.

Key Requirements:

CSMS Implementation Steps:

1. Close the transaction immediately upon receiving the Ended event.
2. Store meter values — These are the final readings for billing.
3. Return totalCost if applicable.
4. Update connector status when StatusNotificationRequest(Available) arrives.

Key Requirements:

CSMS Implementation Steps:

1. On Updated (SuspendedEV) — Update transaction state to suspended. Do NOT close the transaction. Continue tracking seqNo.
2. On subsequent Updated (Charging, CablePluggedIn) — Transaction resumes. Update state back to active.
3. On Ended — Close the transaction and calculate total cost based on all meter values received during the full transaction.

CSMS Implementation Steps:

1. Detect missing messages — Use seqNo to identify gaps. If you received seqNo 2 and then receive seqNo 5, messages 3 and 4 are missing.
2. Process queued messages — All messages with offline = true should be processed and stored.
3. Use GetTransactionStatus (E14) to check if all messages have been delivered.
4. Validate tokens retroactively — Include idTokenInfo in responses to update the CS authorization cache.

CSMS Implementation Steps:

1. Process the full transaction retroactively — Create the transaction, process all events, close it.
2. All messages will have offline = true — The entire transaction happened while offline.
3. Calculate costs — Based on the meter values provided in the Started and Ended messages.
4. Always respond — Even if the transaction already ended, always respond to allow the CS to clear its queue.

Key Requirements:

CSMS Implementation Steps:

1. If CSMS doesn't respond within the timeout — The CS will retry the message. The CSMS may receive duplicate messages with the same transactionId + seqNo.
2. Handle duplicates gracefully — Use transactionId + seqNo as an idempotency key. If the same pair is received again, respond normally but don't process it twice.
3. Never fail to respond — The outcome of sanity checks SHALL NOT cause the CSMS to not respond. Always send a TransactionEventResponse, even if the data seems invalid. Failing to respond only causes the CS to retry.
4. CALLERROR responses — If the CSMS sends a CALLERROR, the CS should not retry. Use this only for malformed messages that can never be accepted.

CSMS Implementation Steps:

1. When to use — After a connection restoration to check for pending messages; to verify if a specific transaction is still ongoing; to confirm all messages for a completed transaction have been delivered.
2. With transactionId — Check a specific transaction's pending status and whether it's still active.
3. Without transactionId — Check if ANY transaction messages are pending on the CS.

Interrupting Charging (CSMS-initiated):

The charging process ends when:

1. All transaction events are delivered — CSMS has received TransactionEventRequest(eventType=Ended)
2. All messages are delivered — Verified via GetTransactionStatus (messagesInQueue=false)
3. Connector becomes available — CS sends StatusNotificationRequest(Available)

CSMS Finalization Checklist: