StartTransaction

Core CP->CSMS

Sent by the Charge Point when a charging transaction starts.

Quick Reference

Required Fields

connectorId integer

Connector ID where transaction is started (>0)

idTag string(20)

Identifier that started the transaction

meterStart integer

Meter value in Wh at start of transaction

timestamp dateTime

Timestamp when transaction started

Optional Fields

reservationId integer

ID of reservation if transaction started due to reservation

Example Payload

{
  "connectorId": 1,
  "idTag": "AABBCCDD",
  "meterStart": 0,
  "timestamp": "2024-01-15T10:30:00Z"
}

Example Full Frame

[
  2,
  "msg-001",
  "StartTransaction",
  {
    "connectorId": 1,
    "idTag": "AABBCCDD",
    "meterStart": 0,
    "timestamp": "2024-01-15T10:30:00Z"
  }
]

Format: [MessageType, MessageId, Action, Payload]

Open in Builder Go to Validator

Overview

The StartTransaction message notifies the Central System that a charging transaction has begun on a specific connector. This creates a transaction record in the CSMS for billing and monitoring.

When to Send

Immediately after a user is authorized and cable is connected
After RemoteStartTransaction command is executed successfully
When transaction conditions are met (authorization + cable connected + ready to charge)

Expected Response

The CSMS responds with an IdTagInfo object and:

transactionId: Unique ID for this transaction (use in MeterValues and StopTransaction)
Authorization status (may differ from initial Authorize response)

Usage Notes

The meterStart value should be the cumulative energy delivered by this connector
If authorization was not done via Authorize message, the idTag must still be valid
The timestamp should be as accurate as possible for billing purposes
Store the returned transactionId for use in MeterValues and StopTransaction

Best Practices

Accurate timestamps - Use NTP-synchronized time for accurate billing
Meter precision - Ensure meterStart reflects actual energy meter reading in Wh
Authorization check - Even if Authorize was successful, check IdTagInfo in response
Transaction ID storage - Persist transactionId in case of power loss
Reservation handling - Include reservationId if transaction started from a reservation

Testing Tips

Test with valid authorization to verify transaction creation
Test meter value accuracy at start
Test with invalid idTag to verify rejection
Test connector ID validation (0 should be rejected)
Test timestamp format validation

Common Errors

`PropertyConstraintViolation`

Cause: connectorId is 0 or negative

Solution: Use connector ID > 0 (0 is reserved for the Charge Point itself)

`TypeConstraintViolation`

Cause: timestamp not in ISO 8601 format

Solution: Use format: YYYY-MM-DDTHH:MM:SSZ

`GenericError`

Cause: Transaction already active on connector

Solution: Stop existing transaction before starting new one