When a driver wants to end charging from the app, when a user's kWh allowance runs out, or when customer support has to close a problematic session, the command used is the same: RemoteStopTransaction. This article explains how the command works and why it sometimes does not produce the expected result.

Command structure

In OCPP 1.6J, RemoteStopTransaction has a single required field: transactionId.

[2, "6001", "RemoteStopTransaction", {"transactionId": 58211}]

The charger replies Accepted or Rejected. As with RemoteStartTransaction, Accepted does not mean the session ended immediately; it means the charger has started the stop process. You know the session actually closed from the StopTransaction message that follows and the reason: "Remote" value inside it.

In OCPP 2.0.1 and 2.1 the equivalent is RequestStopTransaction, which uses the transactionId field; the end of the session is reported with TransactionEvent (Ended).

Why is a transactionId needed?

Using a transaction ID instead of a connector number is a deliberate design choice. It prevents another session from being stopped by mistake. It also assumes the CSMS keeps the transactionId of every open session correctly. A command cannot be sent for a session that was started offline and has not yet been reported to the CSMS.

When is it used?

  • Driver request: The "Stop charging" button in the mobile app.
  • Limit exceeded: Automatic stop when the driver's daily or monthly kWh allowance is used up. See smart charging and kWh limits.
  • Payment issue: When the pre-authorised amount is exceeded.
  • Operational intervention: Closing a session that is stuck or looks faulty.
  • Time limit: Ending sessions that run longer than a set time.

Why does it return Rejected?

  • The charger does not know the transactionId (the session has already ended or the ID is wrong).
  • The charger is in a state where it cannot stop at that moment.
  • The charger has restarted and lost the session.

When you get Rejected, first check whether the session is really still open on the charger side. If the charger restarted, it may have sent the missing StopTransaction.

If the cable stays locked after stopping

On some chargers the cable remains locked after the session stops until the user taps their card. In remotely stopped sessions this can leave the driver stuck. The fix is usually one of two things:

  • Configuring the charger to unlock automatically after a remote stop,
  • Sending an UnlockConnector command if needed.

See our article on UnlockConnector for details.

The difference from smart charging

If you only want to reduce power rather than end the session completely, use charging profiles instead of RemoteStopTransaction. For example, when a building's total power limit is exceeded, reducing the power of sessions gives a much better user experience than closing them. See limiting power with SetChargingProfile.

Care in automation

In systems that stop sessions automatically when a limit is reached, always track the result of the command. If the charger rejects the command or never replies, this should appear as a separate alert. Üreticy stops the session of a driver whose limit is used up remotely; if the charger does not accept the command, it records this as a separate alert in the dashboard.

Quick checklist

  • Before sending the command, confirm that the session is open in the dashboard and the transactionId is filled in.
  • After an Accepted reply, expect a StopTransaction within a few minutes at most.
  • Check that the reason field in StopTransaction is "Remote".
  • If the cable stays locked, send the unlock command without keeping the driver waiting.
  • Report repeated Rejected replies by charger model.

Informing the user

In a remotely stopped session it is important to tell the driver why. A short notification such as "Your daily kWh allowance is used up, charging has stopped" or "The session was ended by customer support" greatly reduces complaints. This notification should be sent together with the session summary after StopTransaction arrives.

Conclusion

RemoteStopTransaction ends a charging session safely by targeting it by its ID. Telling Accepted apart from the actual end, keeping the transactionId accurate and configuring details such as the cable lock in advance are the keys to smooth operations. Üreticy's OCPP software records the result of every command, including remote stops.