OCPP EV Charger With Payment Terminal Integration Guide

An OCPP EV charger with payment terminal combines two technical domains that buyers often treat as one. OCPP manages communication between the charging station and charging management system. Card acceptance requires a terminal, payment application, PSP or gateway, acquirer, merchant configuration, and payment-security controls. A deployable solution needs a tested orchestration layer between them.

This guide helps CPO architects, CSMS providers, charger distributors, EPC contractors, and system integrators specify that boundary. Luxman Energy publishes OCPP 1.6J commercial charger options and POS-related functions on selected models, while exact payment-terminal compatibility and market support depend on the chosen configuration and local partners.

Separate the charging and payment paths

The Open Charge Alliance OCPP overview defines OCPP as the open communication protocol between charging stations and charging management systems. It is not an acquiring protocol and should not be used as an uncontrolled transport path for cardholder data.

A typical system includes these connections:

Connection	Main purpose	Data that should cross
Terminal to PSP or acquirer	Card authorization and financial messages	Protected payment data within the approved payment environment
Charger to CSMS through OCPP	Status, authorization context, transactions, meter values, commands	Charging and non-sensitive correlation data
Orchestrator to payment service	Create, query, capture, reverse, or refund payment	Tokenized or protected payment references and amounts
Orchestrator to charger or CSMS	Start the selected EVSE and track the session	Connector, authorization result, tariff context, session reference
Finance to acquirer and bank	Reconciliation and settlement	Captures, fees, refunds, chargebacks, settlement and bank records

The orchestrator may run in the charging station, a site controller, the CSMS, or a payment gateway. The architecture can vary, but one party must own the state machine and recovery rules.

Understand OCPP version differences

Version selection affects the functions available and the amount of custom integration required.

The Open Charge Alliance states that OCPP 1.6 remains widely used. OCPP 2.0.1 adds improved transaction handling, device management, security, smart charging, ISO 15118 support, and display and messaging functions. OCPP 2.1, released in 2025, adds local cost calculation and explicit support for ad hoc payment using a built-in or stand-alone credit card terminal, along with secure dynamic QR codes and additional transaction options.

OCPP 1.6 and OCPP 2.0.1 are not compatible. A charger described as OCPP compatible therefore needs a version, transport, supported profiles or functions, security settings, and test evidence.

Procurement issue	OCPP 1.6	OCPP 2.0.1	OCPP 2.1
Market position	Widely implemented	Newer standardized architecture	Latest published OCA version
Transaction handling	Established but less detailed	Improved transaction model	Extended transaction options
Payment terminal support	Usually project-specific integration	Can support related UI and transaction orchestration	Explicit ad hoc terminal support described by OCA
Device management	Basic configuration patterns	Expanded device model and monitoring	Builds on 2.0.1 with additions
Migration impact	Existing installed base and CSMS support	Not wire-compatible with 1.6	Application logic designed to build on 2.0.1

Do not choose 2.1 only because it is newer, or 1.6 only because it is familiar. Confirm charger firmware, CSMS implementation, certification status, required functional blocks, payment-terminal integration, cybersecurity, and support lifecycle. The best choice is the version that both sides implement correctly for the project.

Choose an orchestration architecture

Three patterns are common.

Charger local orchestration

The terminal or payment application communicates with logic inside the charger. After approval, the charger starts the selected connector and later sends session records to the CSMS.

This can reduce dependency on a cloud round trip, but it places more integration and lifecycle responsibility in charger firmware. Buyers should confirm how terminal replacements, acquirer changes, payment application updates, and CSMS migration are handled.

CSMS centered orchestration

The terminal or payment gateway sends a tokenized approval to the CSMS, which maps it to an EVSE and sends the appropriate start instruction through OCPP. The CSMS correlates the charging transaction and final payment process.

This gives the operator central control but depends on reliable connectivity and exact identifier mapping. The architecture needs idempotent commands, timeout handling, and a way to query uncertain payment or charging states.

Site controller orchestration

A local controller coordinates one or more terminals and chargers, while communicating with the CSMS and payment services. This can support shared terminals or kiosks and provide controlled local behavior.

It also adds another managed asset, software lifecycle, security boundary, and failure domain. Require monitoring, remote update, redundancy, and a documented mode for controller loss.

No pattern is universally superior. Evaluate latency, offline policy, multi-vendor portability, cybersecurity, service ownership, and expected site scale.

Control connector and payment identifiers

An approved payment must authorize one intended charging point. The integration should preserve a controlled relationship among:

• Site and charging-station identity

• Charge point and EVSE identity

• Connector number and physical label

• Payment terminal and merchant lane identity

• Tariff and currency

• Payment authorization reference

• Charging transaction reference

• Final capture, reversal, or refund reference

• Receipt and settlement record

A shared payment terminal makes this mapping especially important. The terminal must receive current connector availability and reject occupied, reserved, faulted, or unreachable points. If availability changes after payment approval, the system should cancel or reverse the authorization rather than silently apply it to another connector.

Use one identifier register across site labels, charger configuration, CSMS, payment system, asset management, and support. Test replacement scenarios so a new charger or terminal does not inherit incorrect merchant or connector settings.

Define the transaction state machine

The technical specification should describe both normal and exception transitions.

Charging and payment state	Required action
Connector selected	Reserve the intended EVSE for a short controlled period if supported
Tariff displayed	Preserve the version and price components presented to the user
Payment pending	Prevent duplicate starts while allowing safe status query
Payment approved	Send one idempotent start instruction for the selected EVSE
Start accepted	Correlate the OCPP transaction with the payment reference
Start rejected or timed out	Query final charger state and reverse payment if no service began
Charging active	Collect status and meter values and monitor authorization conditions
Session stopped	Validate final meter and stop reason before calculating the charge
Capture pending	Retry or query using the original financial reference without duplication
Capture complete	Produce receipt and include the item in reconciliation
Exception	Hold for controlled investigation with owner and audit trail

Network timeouts create uncertain states. If a CSMS sends a start instruction and loses the response, it should query or observe the charger before issuing another start. If the PSP times out during capture, the payment system should query the original transaction before retrying. Idempotency keys and persistent references are essential on both sides.

Specify OCPP functions rather than a checkbox

An OCPP version name alone does not define how a charger behaves. The RFP should list the functions and evidence needed for the payment journey.

These typically include:

• Charger registration and secure connection to the production CSMS

• Stable EVSE and connector addressing

• Near-real-time status updates

• Remote or centrally authorized start and stop behavior

• Transaction start and stop records

• Meter values and timestamps sufficient for billing

• Stop reasons and fault information

• Local authorization policy where applicable

• Message retry and offline queue behavior

• Clock synchronization

• Remote configuration, diagnostics, and firmware controls

• Display or user-message functions required by the chosen version

• Security profiles, certificates, credentials, and update process

For OCPP 1.6 projects, identify every vendor-specific extension or custom API. A custom data exchange may solve one deployment, but it can increase dependence on the original charger or CSMS supplier. Document ownership, versioning, test cases, and migration support.

Verify certification and implementation scope

The Open Charge Alliance certification program uses approved independent laboratories to test conformance with the OCPP specification. OCA also maintains a list of certified products and indicates certificate types and supported profiles.

Certification can reduce uncertainty, but buyers should check the exact organization, product designation, software version, OCPP version, certificate type, and relevant profiles. A certificate for another firmware release or product family is not automatic evidence for the ordered configuration.

Certification also does not test the complete card-acquiring flow. The project still needs end-to-end tests with the actual terminal, application, PSP, acquirer, merchant, CSMS, charger firmware, network, and tariff.

Ask both charger and CSMS suppliers for an interoperability statement that lists known-tested combinations. Then run project-specific factory and site tests instead of relying only on a historical integration.

Protect the payment environment

The payment terminal should encrypt and route account data through the approved payment architecture. The charging station and CSMS should receive only the references required to authorize and reconcile charging.

PCI Security Standards Council guidance explains that a PTS-approved terminal does not by itself guarantee PCI DSS compliance. Payment applications, terminal management, connected systems, remote access, encryption, inventories, tamper controls, patching, and third-party responsibilities still require review.

Do not place full card numbers, track data, PIN information, or other sensitive authentication data in OCPP fields, custom DataTransfer messages, charger logs, or support tools. Even a vendor-specific field that technically accepts a string is not an appropriate payment-data channel.

Segment charger management and payment networks where the security architecture requires it. Control certificates and credentials separately, record administrative actions, and define how compromises or lost terminals are contained.

Plan communications and offline behavior

The terminal may be online while the charger is offline, or the charger may reach the CSMS while the terminal cannot reach the acquirer. Treat these as separate health states.

Document a policy for each combination:

Terminal path	OCPP path	Decision to define
Online	Online	Normal authorization and charging workflow
Online	Offline	Whether local charger start is possible and how records synchronize
Offline	Online	Whether another payment method is offered or the connector is unavailable for ad hoc use
Offline	Offline	Safe local behavior, risk limits, user message, and recovery

Offline card acceptance depends on terminal, scheme, acquirer, merchant, and risk settings. Offline charger authorization depends on the charger and OCPP implementation. Both must be permitted and tested before deployment.

When connectivity returns, queued records should retain original timestamps and identifiers. Reconciliation must detect duplicates, missing events, and changed final states.

Build an interoperability test matrix

Factory acceptance should use the ordered charger firmware, terminal model and application, CSMS release, and payment test environment. Site acceptance should use the production merchant, acquirer, communications, and physical mapping.

Test at least:

1. Every terminal starts every permitted connector through the production OCPP path.

2. Required cards and wallets produce traceable approvals, declines, and captures.

3. Occupied, reserved, faulted, and unavailable connectors cannot be sold incorrectly.

4. Tariff and any authorization hold appear before payment.

5. An approved payment followed by a rejected charger start produces the agreed reversal.

6. Repeated taps and repeated OCPP commands do not create duplicate sessions or charges.

7. Charger, terminal, CSMS, orchestrator, and network restarts preserve or recover state.

8. Meter values, tariff, final calculation, capture, receipt, and settlement match.

9. Offline and reconnection behavior follows the written policy.

10. Firmware or CSMS update regression tests preserve the payment workflow.

Record protocol traces, non-sensitive financial references, timestamps, screen messages, and final state. A pass or fail checkbox without evidence is weak protection against later vendor disputes.

Plan migration and change control

Payment and charging components change on different schedules. A terminal model may reach end of support while the charger remains serviceable. An acquirer may require a new payment application. A CPO may move to another CSMS or upgrade OCPP versions.

The contract should define:

• Supported charger firmware and OCPP versions

• Terminal and payment application lifecycle dates

• Compatibility testing after security or feature updates

• Notice and approval for component substitutions

• Regression test ownership

• Access to logs, APIs, configurations, and data exports

• Certificate and credential migration

• Rollback and staged deployment process

• Cost and lead time for acquirer or CSMS changes

• Exit support and removal of credentials at contract end

Use a pilot group before fleet-wide updates. Monitor authorization, start success, capture, and reconciliation after every change.

Review Luxman OCPP charger options

Luxman’s commercial EV charger range lists OCPP 1.6J across several AC commercial products and an advertising-display DC model with wireless or POS payment. The page lists AC dual-output options including 2 x 7 kW, 2 x 11 kW, and 2 x 22 kW, and a DC advertising-display model at 60 kW, 80 kW, 120 kW, 160 kW, and 180 kW.

These specifications provide a starting point for integration planning. POS payment is listed for the selected DC advertising-display product, not automatically for every commercial charger on the category page. Buyers should confirm the exact model, firmware, OCPP functions, terminal architecture, PSP and acquirer, connector arrangement, target market, environmental rating, and certification evidence. Availability may vary by model or market.

OCPP payment terminal buyer checklist

Before purchase, confirm:

• Exact OCPP version, transport, functions, security profile, and certification status

• Charger and CSMS software versions tested together

• Terminal model, payment application, PSP, acquirer, schemes, and merchant country

• Orchestration location and accountable integration owner

• Stable EVSE, connector, terminal, payment, session, and receipt identifiers

• Tariff presentation and local cost ownership

• Preauthorization, capture, reversal, refund, and reconciliation rules

• Payment-data boundary and PCI DSS responsibility matrix

• Communications, offline policy, monitoring, and alarms

• FAT, SAT, update regression, service, spare, and migration evidence

Frequently asked questions

Does OCPP include credit card processing?

No. OCPP connects charging stations with charging management systems. Newer versions support payment-related orchestration, but the terminal, PSP, acquirer, card schemes, merchant account, and payment-security environment remain separate.

Can an OCPP 1.6 charger work with a payment terminal?

Yes, when the charger, CSMS, terminal, and integration layer implement and test an agreed workflow. Buyers should document any custom APIs or vendor-specific behavior because OCPP 1.6 does not by itself prove standardized terminal integration.

Does OCPP 2.1 support standalone card terminals?

The Open Charge Alliance lists ad hoc payment using a built-in or stand-alone credit card terminal among OCPP 2.1 authorization options. Both the charger and CSMS still need compatible implementations and project testing.

Is an OCPP certificate enough for interoperability?

It is valuable evidence of conformance for the listed product, software version, protocol version, and certificate scope. It does not replace testing with the project’s CSMS, payment terminal, acquirer, configuration, and network.

Should card data be sent through OCPP?

Sensitive card data should remain within the approved payment environment. The charger and CSMS should use non-sensitive tokens or references needed for charging authorization and reconciliation.

What happens when the CSMS is offline?

Behavior depends on the charger, OCPP implementation, local authorization policy, terminal and acquirer status, and operator risk rules. The exact combinations must be documented and tested.

OCPP EV charger with payment terminal conclusion

An OCPP EV charger with payment terminal is a system integration, not two compatible labels on a datasheet. Buyers need a defined protocol version, orchestration owner, connector mapping, payment-data boundary, state machine, offline policy, certification evidence, and end-to-end acceptance tests.

For a compatibility review, provide Luxman Energy with the charger model and power, connector configuration, CSMS and OCPP version, payment-terminal model, PSP and acquirer, target country, card schemes, tariff and hold rules, communications, security requirements, and test plan. Luxman Energy can then confirm available charger functions and identify where project-specific payment or backend integration is required.