Which versions
Payments is defined twice. OCPI 2.2.1 has the Direct Payment extension, a working document the EVRoaming Foundation publishes on its own. OCPI 2.3.0 has a core Payments chapter. ChargerDojo tests both. OCPI 2.1.1 and 2.2 have no payments module. On 2.2.1 the flow runs without terminal activation and deactivation, which only 2.3.0 defines. OCPI’s Role enum has no PTP value, so ChargerDojo registers with your system as a CPO and records yours asOTHER.
Advertise the payments module
Both documents give the module identifierpayments, with the PTP as data owner. ChargerDojo
looks for it in your version details with role SENDER. OCPI 2.3.0 says its Sender interface is
“Typically implemented by market roles like: PTP.” The 2.2.1 extension names no interface roles
at all, so on 2.2.1 the SENDER role is ChargerDojo’s reading, carried over from 2.3.0. The
journey also pushes a Session and a CDR to you, so it needs your Sessions and CDRs RECEIVER
interfaces.
If your system lists Payments under any other identifier, ChargerDojo cannot see it. The Payments
suites mark their checks not applicable, and the journey’s preflight blocks the run and names the
interface it could not find.
Add your endpoint
Testing your own system needs Integrate for the endpoint and Automate for Payments (plans).- In ChargerDojo, open Endpoints. Under What do you want to test? choose Your PTP service.
- Choose Payments, then Continue. Registration and credentials runs only the credentials handshake and the Credentials checks.
- Enter the base URL your versions endpoint hangs off, and pick OCPI 2.2.1 or 2.3.0. Your system needs a public URL: a journey cannot run through the local connector.
- Enter the registration token (Token A) your system issued for ChargerDojo.
- Save endpoint, then register. ChargerDojo runs the OCPI credentials exchange and a read-only check of three requests.
Run the journey
Open Charging Journeys, choose Direct terminal payment and pick your endpoint. Under Payment flow, Configure asks:- Invoice creator. CPO · await payment capture, the default, makes the run wait for your Financial Advice Confirmation. PTP · FAC not applicable expects none.
- Stop path. CPO stops the charge, the default; PTP sends STOP_SESSION, which makes the run wait for your STOP_SESSION; or Preauthorization limit reached.
- Expected Terminal ID, on 2.2.1 only. The 2.2.1 extension has no terminal activation, so enter the Terminal ID your system will send, or leave it blank for an ID made for the run.
- Sandbox capture outcome, on Sandbox PTP only, when the CPO invoices: Successful capture, Partial capture or Failed capture. Against your system the run reads the outcome from your confirmation instead.
Read the report
Eighteen rules, D01 to D18, make up the journey, and a run grades the ones its choices reach. D05 is always reported not applicable. D03 runs only on 2.3.0, and D15 to D17 only at the Adversarial coverage depth. Against your own system the run never grades D11, D13 or D14: D11 needs a capture outcome chosen on Sandbox PTP, and D13 and D14 grade steps only Sandbox PTP takes. Each rule shows the request and response behind it and the section of the specification it reads, and the report labels what kind of result it is. A Conformance requirement is a rule the specification makes mandatory: a required field, a closed value list or a SHALL. Neither payments document uses SHALL, so here it is always a required field or a closed value list. A Business check goes further than OCPI requires. An Observation records behaviour no mandatory rule covers. Some examples:- START_SESSION carries an authorization reference and, when the CPO invoices, the confirmation repeats it (D07).
- On Sandbox PTP with a failed capture chosen, the failure is reported as a payment failure, never as a good CDR (D11).
- When the CPO invoices, the captured total matches the CDR total (D12), a business check.