> ## Documentation Index
> Fetch the complete documentation index at: https://docs.chargerdojo.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Test a payment terminal

> Test your terminal management system's OCPI Payments interface: register it as a PTP, run the Direct terminal payment journey and read each rule's result.

A payment terminal provider (PTP) runs the terminal management system behind the card terminals
at a charge point. Over OCPI that system starts a paid charging session at a CPO's charge point
and confirms the amount it captured. ChargerDojo plays the CPO against your system and grades
every exchange.

Before you register anything, run the journey free on our sandbox:
[Run a free sandbox payment](https://chargerdojo.com/ocpi-charging-journeys/?template=direct-terminal-payment\&target=sandbox)
opens it on Sandbox PTP, a terminal system we run. It needs no login and leaves your saved endpoint
as it was. [OCPI payment terminal testing](https://chargerdojo.com/ocpi-payment-terminal-testing/)
shows the calls a run makes and the rules it grades.

## Which versions

Payments is defined twice. OCPI 2.2.1 has the Direct Payment extension, a working document the
[EVRoaming Foundation publishes](https://evroaming.org/wp-content/uploads/2024/10/DirectPayment_2_2_1___EVRF_version.pdf#page=21)
on its own. OCPI 2.3.0 has a core
[Payments chapter](https://github.com/ocpi/ocpi/blob/9ed1e39c24f5b84cb1e4008939f47bea838f9b25/mod_payments.asciidoc#mod_payments_payments_module).
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 as `OTHER`.

## Advertise the payments module

Both documents give the module identifier `payments`, 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](https://docs.chargerdojo.com/guide/plans.md)).

1. In ChargerDojo, open **Endpoints**. Under **What do you want to test?** choose **Your PTP
   service**.
2. Choose **Payments**, then **Continue**. **Registration and credentials** runs only the
   credentials handshake and the Credentials checks.
3. 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](https://docs.chargerdojo.com/guide/use-the-connector.md).
4. Enter the registration token (Token A) your system issued for ChargerDojo.
5. **Save endpoint**, then register. ChargerDojo runs the OCPI credentials exchange and a
   read-only check of three requests.

The first run the flow offers is **Direct terminal payment**.

## 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.

ChargerDojo sends its calls on its own, including the terminal activation on 2.3.0. Your calls
come from your system, so someone or something has to act on your side during the run: sending
the Terminal, pulling the Location and Tariff and sending START\_SESSION, then STOP\_SESSION if you
chose that stop path, and the confirmation when the CPO invoices. The run waits up to 300
seconds for each. If one does not arrive in that time, the run records the timeout and moves on.

## 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.

[Read your report](https://docs.chargerdojo.com/guide/read-your-report.md) explains the five verdicts. A report's share link opens
for anyone you send it to, such as the CPO you are about to connect to
([share a report](https://docs.chargerdojo.com/guide/share-a-report.md)).

## What payment terminal testing leaves alone

ChargerDojo connects to your terminal management system's OCPI interface. It does not test the
terminal hardware, settlement with your payment processor or the release of a preauthorization,
which happen outside OCPI. AFIR places the card payment duty on charge point operators, so a report
says nothing about AFIR compliance. The journey is sandbox-tested: it has run against our own
terminal system, not yet against a terminal provider's. A report is a test result, not a
certification.

## Learn the terms

The [glossary](https://docs.chargerdojo.com/guide/glossary.md) defines PTP and the other market roles, and
[run a suite](https://docs.chargerdojo.com/guide/run-a-suite.md) covers the Payments conformance suites.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.