Self-Service EV Charging Payment Hosts: What to Define Before Integration

Start with the operating context.

Document what should happen from arrival to charging completion. Identify user authentication or payment needs, the selected charging equipment, the operating platform, connectivity conditions and what happens if a transaction or network event needs support.

Good commercial charging decisions connect vehicle use, site conditions and the operator's intended service. The selected equipment can then be reviewed against the final technical, commercial and destination-market requirements.

Planning checklist.

• Target country and preferred customer payment journey
• Connected-charger topology and controller compatibility
• Network conditions, operating platform and OCPP requirements
• Customer support, exception handling and site supervision

How this applies to a commercial charging project.

For larger unattended sites, Xiaochong can discuss a project-configured self-service host that provides a payment flow and starts charging on connected chargers. The connected charger quantity, payment methods and integration approach are project-specific.

Images and portfolio references are a useful starting point, but final technical data, dimensions, protection rating, certification, payment integration and delivery terms should be confirmed for the selected model and destination market.

Common buyer questions.

Plan for a missing payment result

A driver is waiting, the host has no final payment response, and the team is unsure what message to show. The procurement question is who resolves the original transaction and what evidence permits the next action. Keep an unresolved result distinct from a confirmed decline, cancellation or completed payment.

For a provider-specific example, Adyen's response-handling documentation recommends that an integration check transaction status when a response is missing. Its time-out documentation distinguishes request, processing and device time-outs. A request time-out can leave a transaction able to complete on the terminal. The word “timeout” alone therefore does not establish a final payment outcome. These are Adyen integration details; the contracted provider must confirm the behavior for your terminal, integration mode and software.

Put the unresolved case in the project brief

1. Preserve the observation: record the time and time zone, selected bay or connector, host message and permitted non-sensitive reference to the original payment attempt. Keep the actual provider response separate from the operator's interpretation. If no result has arrived, record that explicitly.
2. Assign the lookup: name the payment partner or authorized integration owner who can resolve the original transaction through the documented status process. Agree how the result reaches the host and support team, including what happens if it remains unresolved.
3. Agree the customer message: define the pending message, contact route and evidence required before a new attempt, cancellation or refund is considered. Follow the provider-approved workflow; do not create a generic “retry payment” instruction from a missing response.
4. Check charging separately: retain the corresponding charging-session and delivered-energy evidence, or explicitly mark them unknown. Payment status does not by itself establish that the selected vehicle received energy.

The Open Charge Alliance defines OCPP communication between charge points and central systems. Keep that interface separate from the provider's transaction-status process. Payment API fields and terminal messages are not universal OCPP fault codes. Official sources checked October 27, 2026; this procurement checklist is an original planning aid, not a provider implementation specification.

Use the readiness score to expose the open decisions

In a fictional ten-device brief, set customer payment journey, offline/failed-payment flow and customer support/refund ownership to Partly; set the other four answers to Yes. The payment-readiness checker gives 79% and four of seven areas fully defined: four Yes answers earn eight points and three Partly answers earn three, making 11 out of 14. The result identifies three open areas; it cannot query a payment, reconcile transactions or approve the site.

If support ownership is subsequently documented, change only that answer to Yes: the score becomes 86% with five areas fully defined. The journey and exception-flow questions remain open. Update an answer because its evidence changed, not because a higher percentage looks better. Keep the case record and agreed acceptance evidence outside the calculator, which does not store transaction records.

Validate this case only through arrangements approved by the payment and charging partners, such as their authorized test environment. Do not repeat customer charges to discover a result, interrupt live equipment, alter payment-security or charging-protection settings, or open energized cabinets. Electrical diagnosis belongs to qualified personnel. Keep card numbers, security codes, credentials, tokens and unnecessary personal data out of this tool and public shares. No universal waiting period, refund time or payment compatibility is implied.

A payment approval is not proof that energy reached the vehicle.

Before buying a kiosk, ask each integration partner to agree how payment status, the requested charger and the charging session will be matched. A driver-facing success message must not hide a charging-start failure. The acceptance checks below are our proposed project worksheet, not an OCPP certification test or a guarantee of compatibility.

Use the readiness score to find missing decisions.

Open the payment and charging-start readiness tool. It covers seven areas: customer journey, controller compatibility, platform responsibilities, exception handling, local requirements, support and security. Mark an area fully defined only when an accountable partner has supplied written evidence.

Worked example: five areas marked Yes, offline handling marked No and support marked Partly produce 79% brief completeness, with five of seven areas fully defined. This is a checklist score, not a payment success rate or a safety approval. Even 100% does not prove the installation works.

Require three separate acceptance gates.

1. Payment authorization evidence: record the provider result and a non-sensitive reference. An approved authorization or account hold does not prove that the charger accepted a start request.
2. Charging-start evidence: match the requested bay, charger, connector and session identifier, then confirm that the charger reports a started transaction or the agreed project-specific equivalent. A command acknowledgement alone is not proof of energy delivery.
3. First delivered-energy evidence: confirm the agreed meter or session evidence after start, with timestamp and unit. This is an integration acceptance checkpoint—not a metrology or billing certification.

Put the three timestamps and responsible systems on one test record. If a gate is missing, the driver message, support owner and payment-provider action must follow the approved project workflow. Do not infer a universal timeout, refund period or cancellation rule.

Agree these acceptance scenarios before public operation.

• Payment approved, no charging start: agree the time limit, driver message, support owner and payment-provider process for a hold, cancellation or refund. Do not invent a universal refund time.
• Wrong bay or connector selected: test that the displayed charger identity matches the intended parking space before energy transfer.
• Repeated start request: agree how partners recognize a retry, avoid unintended duplicate billing and reconcile the final session.
• Connection lost: record what each component can and cannot do offline; test recovery only through the approved commissioning plan, without disabling safety controls.
• Session ends or delivers no energy: compare the charging record, applicable tariff and payment-provider record. Assign someone to resolve discrepancies and explain the result to the driver.

Keep the support record useful and safe.

Record the timestamp and time zone, charger and connector identifiers, non-sensitive session reference, exact customer-visible message and each partner's status. Do not put card numbers, security codes, passwords, access tokens or personal identity documents into a public post or a tool brief. Electrical fault diagnosis remains work for qualified personnel.

Architecture reference: the Open Charge Alliance integration whitepaper describes POS, charging-management and local-controller integration approaches. Rechecked September 16, 2026. The OCA paper distinguishes a start-command flow, charging-station notification and periodic energy-consumption updates; our three-gate worksheet is a buyer acceptance method, not an OCA certification test. Exact payment APIs, OCPP version, selected equipment, provider rules and local requirements must be confirmed separately. Xiaochong Energy can discuss the equipment scope; payment-provider acceptance and site approval are not implied.

86% complete can still leave refund ownership undefined.

For a fictional project brief, mark six areas Yes and customer support/refund ownership No in the payment-readiness tool. It gives 86% because each Yes earns two points, Partly earns one and No earns zero, out of fourteen possible points. Change that one No to Partly and the rounded score rises to 93%. Neither result closes the missing decision.

This arithmetic measures the answers entered, not the quality of evidence or the probability of a successful payment. A supplier's verbal assurance is not a completed acceptance record. The tool now keeps both examples in review and lists the unresolved area; even seven Yes answers and 100% remain subject to evidence and integration review.

Turn one unresolved area into an accountable handoff.

1. Describe the exact case: for example, a driver sees payment approval but the agreed charging-start evidence is absent. Record the approved customer message, non-sensitive references and timestamps, without assuming whether money was captured.
2. Name the responsible parties: identify who handles the driver contact, who checks the charging session, and who can investigate the payment-provider record. Specify the handoff between them, not just a generic support email.
3. Record the agreed evidence: the project team should document the applicable authorization, capture, cancellation or refund workflow with its payment provider. Keep actual observed results separate from planned actions; do not promise a universal release or refund time.
4. Close with verification: a designated project owner reviews the approved commissioning evidence and unresolved exceptions. Changing a dropdown to Yes does not establish that a test ran or a customer case was resolved.

This is our original procurement worksheet, not an OCPP certification procedure, legal advice or permission to launch. OCA's integration whitepaper explains alternative POS, controller and charging-management arrangements. Its payment-terminal example is illustrative, not a preferred universal implementation. Rechecked September 30, 2026; the score and workflow above are not OCA requirements.

Keep card numbers, security codes, credentials and unnecessary personal data out of this tool and public support posts. Tests belong in the approved commissioning process with the responsible partners; never disable charging safety controls. Editing an answer clears the previous result, so rerun the check after each change.

A pilot passed. Does the same evidence cover the rollout?

Changing the device count is not an acceptance test. In our payment-readiness checker, a fictional two-device brief with all seven answers set to Yes scores 100%. Change the count to 24 and leave the answers unchanged: it still scores 100%. The score uses only the seven answers, not the device count, software versions, topology or test records. Neither example demonstrates supported capacity or a successful transaction.

Now assume the expanded scope needs fresh controller, platform and offline-flow evidence. Set those three answers to Partly and keep the other four Yes: the result is 79%, with four of seven areas marked fully defined. This is a desk-planning example, not a real deployment or a prescribed risk threshold. The existing up-to-30-device planning reference is not an OCA limit, compatibility approval or proof that one host will serve the rollout.

Make evidence transfer an explicit decision.

1. Freeze the pilot baseline: record the dated scope and revision, device identifiers, charger/controller/terminal software, charging backend, payment partner and network arrangement. Keep the approved acceptance records tied to that baseline.
2. List the rollout differences: identify added devices or sites, changed versions, revised routing and payment/support responsibilities. Assign an owner to decide which evidence remains applicable and which checks need repeating. An unchanged dropdown is not that decision.
3. Check the intended device mapping: use the partners' approved commissioning plan to establish that the selected bay/connector, charging-session reference and permitted payment reference belong together. Agree the expected customer message and support handoff for exceptions; never infer delivery from payment approval alone.
4. Keep three evidence gates separate: record payment authorization, charging-session start and first delivered-energy evidence for the agreed scope. Record expected versus observed results and unresolved exceptions, with the responsible reviewer and date. Acceptance coverage and launch approval belong to the project parties, not this calculator.

Use only authorized, provider-approved test arrangements; discuss a sandbox with the payment partner before planning test payments. This worksheet performs no payment or equipment operation. Do not disconnect live equipment to simulate failures, open energized cabinets or bypass charging protections. Leave electrical diagnosis to qualified personnel. Keep card numbers, security codes, credentials, tokens and unnecessary personal data out of this tool and public posts.

Source and scope: reviewed October 9, 2026 against the Open Charge Alliance Integrating OCPP chargers at filling stations whitepaper, version 1.0 (May 2022), especially section 5.4 of the official PDF. It separates station/backend communication from payment arrangements and illustrates different integration responsibilities. Our scope-change worksheet and numerical examples are original planning aids, not OCA certification requirements, current legal guidance or a preferred universal payment architecture.

Define which connection is offline

“Works offline” is incomplete procurement language. Ask which component has lost which connection, at what point in the customer journey. A payment-terminal connection, a charger-to-backend connection and a local host-to-controller connection are different paths. Evidence about one does not establish the behavior of the others.

Use separate cases in the planning brief

• Payment path unavailable: ask the payment partner which terminal, integration mode and payment methods the documented behavior covers. Distinguish a request not yet received from a transaction already in progress; do not assume that every interruption has the same outcome.
• Charging backend path unavailable: ask the charger and platform partners what the exact configuration permits for new sessions, existing sessions and later reporting. A payment result alone does not answer those questions.
• Local control path unavailable: identify how the selected bay and connector are mapped through the host and controller. Record the agreed customer message, support owner and unresolved session status if that path cannot be confirmed.

For each case, attach the topology revision, affected component and endpoints, journey phase, expected behavior, evidence source and responsible reviewer. Keep “unknown” distinct from an observed failure. Where paths share a network, record that dependency rather than assuming failures are independent. This is our desk-review checklist, not a universal fault diagnosis or a commissioning procedure.

A single partial answer can contain several open cases

Fictional tool example: use 10 connected devices, set the six other areas to Yes and set offline/failed-payment flow to Partly. The payment-readiness checker shows 93% and six of seven areas fully defined. The offline answer earns one point, so the calculation is 13 divided by 14, rounded to a percentage. It neither counts the three cases above nor measures the chance of service continuing. Keep the individual cases in the project brief; do not turn the answer to Yes solely to improve the score.

Provider-specific example: Adyen's offline-payment documentation distinguishes integration types and interruption timing. For its cloud-connected terminals, the documented offline case depends on the terminal having already received the payment request before internet access is lost. Its store-and-forward option does not cover an outage of the Adyen payment platform. These are Adyen-specific limits, not evidence of support on a Xiaochong host, another provider or an unspecified terminal. Ask the contracted provider to confirm the actual arrangement; this guide does not recommend enabling offline processing or changing payment risk settings.

The Open Charge Alliance protocol overview defines OCPP communication between charge points and central systems. Treat that scope separately from a provider's payment capability. Both official pages were checked October 18, 2026. Earlier whitepaper review dates above remain historical; the checklist and score example are our own planning aids, not OCA certification requirements.

Agree any validation with the responsible partners in their approved test environment. Do not cut a live connection to create a failure, repeat customer charges, alter protection or payment-security settings, or open energized equipment. Keep card numbers, security codes, tokens and personal data out of this tool and public posts. Electrical diagnosis belongs to qualified personnel. No offline operation, recovery time, refund outcome or launch approval is promised by this worksheet.