Skip to content
Documentation Menu

Stop Transaction

Source: OCPP 1.6 Specification — Section 4.10 (Operation), Sections 6.49 / 6.50 (Messages)

Overview

When a transaction is stopped, the Charge Point SHALL send a StopTransaction.req PDU, notifying the Central System that the transaction has stopped.

A StopTransaction.req PDU MAY contain an optional transactionData element to provide more details about transaction usage. The optional transactionData element is a container for any number of MeterValues, using the same data structure as the meterValue elements of the MeterValues.req PDU (see Meter Values).

Upon receipt of a StopTransaction.req PDU, the Central System SHALL respond with a StopTransaction.conf PDU.

NOTE: The Central System cannot prevent a transaction from stopping. It MAY only inform the Charge Point it has received the StopTransaction.req and MAY send information about the idTag used to stop the transaction. This information SHOULD be used to update the Authorization Cache, if implemented.

The idTag in the request PDU MAY be omitted when the Charge Point itself needs to stop the transaction. For instance, when the Charge Point is requested to reset.

If a transaction is ended in a normal way (e.g. EV-driver presented his identification to stop the transaction), the Reason element MAY be omitted and the Reason SHOULD be assumed Local. If the transaction is not ended normally, the Reason SHOULD be set to a correct value. As part of the normal transaction termination, the Charge Point SHALL unlock the cable (if not permanently attached).

The Charge Point MAY unlock the cable (if not permanently attached) when the cable is disconnected at the EV. If supported, this functionality is reported and controlled by the configuration key UnlockConnectorOnEVSideDisconnect.

The Charge Point MAY stop a running transaction when the cable is disconnected at the EV. If supported, this functionality is reported and controlled by the configuration key StopTransactionOnEVSideDisconnect.

If StopTransactionOnEVSideDisconnect is set to false, the transaction SHALL NOT be stopped when the cable is disconnected from the EV. If the EV is reconnected, energy transfer is allowed again. In this case there is no mechanism to prevent other EVs from charging and disconnecting during that same ongoing transaction. With UnlockConnectorOnEVSideDisconnect set to false, the Connector SHALL remain locked at the Charge Point until the user presents the identifier.

By setting StopTransactionOnEVSideDisconnect to true, the transaction SHALL be stopped when the cable is disconnected from the EV. If the EV is reconnected, energy transfer is not allowed until the transaction is stopped and a new transaction is started. If UnlockConnectorOnEVSideDisconnect is set to true, also the Connector on the Charge Point will be unlocked.

NOTE: If StopTransactionOnEVSideDisconnect is set to false, this SHALL have priority over UnlockConnectorOnEVSideDisconnect. In other words: cables always remain locked when the cable is disconnected at EV side when StopTransactionOnEVSideDisconnect is false.

NOTE: Setting StopTransactionOnEVSideDisconnect to true will prevent sabotage acts to stop the energy flow by unplugging not-locked cables on EV side.

It is likely that the Central System applies sanity checks to the data contained in a StopTransaction.req it received. The outcome of such sanity checks SHOULD NOT ever cause the Central System to not respond with a StopTransaction.conf. Failing to respond with a StopTransaction.conf will only cause the Charge Point to try the same message again as specified in Error responses to transaction-related messages.

If the Charge Point has implemented an Authorization Cache, then upon receipt of a StopTransaction.conf PDU the Charge Point SHALL update the cache entry, if the idTag is not in the Local Authorization List, with the IdTagInfo value from the response as described under Authorization Cache.

Sequence Diagram

Figure 21. Sequence Diagram: Stop Transaction

Charge Point  ──── StopTransaction.req ────▶  Central System
                   (idTag?, meterStop, timestamp, transactionId, reason?, transactionData[]?)
Charge Point  ◀─── StopTransaction.conf ────  Central System
                   (idTagInfo?)

Initiator

Charge Point → Central System

Fields

Field NameField TypeCard.Description
idTagIdToken0..1Optional. This contains the identifier which requested to stop the charging. It is optional because a Charge Point may terminate charging without the presence of an idTag, e.g. in case of a reset. A Charge Point SHALL send the idTag if known.
meterStopinteger1..1Required. This contains the meter value in Wh for the connector at end of the transaction.
timestampdateTime1..1Required. This contains the date and time on which the transaction is stopped.
transactionIdinteger1..1Required. This contains the transaction-id as received by the StartTransaction.conf.
reasonReason0..1Optional. This contains the reason why the transaction was stopped. MAY only be omitted when the Reason is Local.
transactionDataMeterValue0..*Optional. This contains transaction usage details relevant for billing purposes.

Reason values

EmergencyStop, EVDisconnected, HardReset, Local, Other, PowerLoss, Reboot, Remote, SoftReset, UnlockCommand, DeAuthorized.

Examples

{
  "idTag": "044943121F1A80",
  "meterStop": 35420,
  "timestamp": "2026-04-27T13:05:42Z",
  "transactionId": 1234,
  "reason": "Local",
  "transactionData": [
    {
      "timestamp": "2026-04-27T13:05:42Z",
      "sampledValue": [
        {
          "value": "35420",
          "context": "Transaction.End",
          "measurand": "Energy.Active.Import.Register",
          "unit": "Wh"
        }
      ]
    }
  ]
}
  • StopTransactionOnEVSideDisconnect
  • UnlockConnectorOnEVSideDisconnect
  • StopTxnAlignedData, StopTxnAlignedDataMaxLength
  • StopTxnSampledData, StopTxnSampledDataMaxLength

Schema

Source: schemas/StopTransaction.json, schemas/StopTransactionResponse.json (OCPP 1.6, JSON Schema draft-04)

Request schema (JSON Schema)
Response schema (JSON Schema)