EV CHARGING PAYMENT ORCHESTRATION
The charging-specific payment layer above your PSPs and local acquirers. Connect payment acceptance, session-based capture, refunds and multi-party reconciliation through one API — under your brand.
Sessions · Tariffs · CDRs
Cards · Wallets · Account-to-account
CONTROL FRAMEWORKS / APPLICABILITY BY MARKET
Card-data security & scope
Authentication policy
Entity & responsibility model
Data & charging-payment controls
SCALABLE PAYMENT ARCHITECTURE
New markets introduce new acquiring, authentication and financial-operation requirements. A dedicated orchestration layer separates these changes from your charging product roadmap.
| Requirement | Provider-by-provider integration | CpoPay orchestration model |
|---|---|---|
| Market activation | Separate onboarding and local rules | Reusable onboarding and capability profiles |
| Payment lifecycle | Provider-specific payment states | Session-linked payment state model |
| Financial operations | Separate settlement and refund records | Unified references and reconciliation |
| Governance | Responsibilities across multiple integrations | Explicit merchant, provider and data roles |
CHARGING PAYMENT OPERATIONS
Preauthorize → capture → reverse
For eligible card flows, capture the final session amount and request reversal of unused authorization. Issuer release times vary. QR and wallet flows follow their own pay-first / refund logic.
Eligibility → refund → evidence
Make refund eligibility, limits and timeframes explicit before payment. Preserve session evidence and distinguish card chargebacks from payment-method complaints.
Allocate → reconcile → settle
Create order-level allocations with legal-entity and fee references. Settlement execution and any safeguarded fund arrangements remain provider- and contract-specific.
Market → method → confirmation
Expose familiar local methods with a common API while retaining differences in authentication, expiry, asynchronous confirmation and refunds.
ABOVE THE PAYMENT RAILS
PSPs execute acceptance, authentication and settlement under their supported services. CpoPay coordinates these capabilities with charging-session events, refund policies, allocation rules and audit requirements through one integration layer.
Link consent, payment references and CDR records to support time-bound dispute responses.
Separate merchant ledgers, fees and tax references; keep local tax obligations with the responsible entity.
GLOBAL PAYMENT ECOSYSTEMS
Plan market expansion around local payment preferences, acquiring eligibility and method-level capabilities — with a consistent integration model.
Cards · iDEAL / Wero · Bancontact · BLIK · MB WAY · SEPA …
02Cards · Apple Pay · Google Pay · ACH · Interac · SPEI …
03Pix · Elo · PSE · Webpay · Yape …
04DuitNow QR · PromptPay · GCash · Maya · QRIS · PayNow · MoMo …
05Kaspi QR · UZCARD · HUMO · Click · Payme …
Representative local payment ecosystems. Availability is confirmed per country, provider, merchant entity and use case; listed methods do not imply universal live coverage.
COMPLIANCE CONTROL PLANE
Build the evidence and responsibility model alongside the payment flow. Align platform controls with your provider, merchant entity and local-market requirements.
Use hosted payment fields and token references to reduce card-data exposure. Verify current PCI DSS AOC, assessed entity and service scope; outsourcing does not remove all platform obligations.
Route authentication according to transaction channel and eligible exemptions. Plug & Charge is a charging interaction, not a blanket exemption from payment authentication.
Identify the merchant of record, acquiring entity and settlement recipients. Document who handles refunds, chargebacks and funds; accounting allocation is not a money-transmission licence.
Map public ad-hoc acceptance, payment devices and price disclosure to site power and deployment dates. Software integration alone does not establish site-wide AFIR conformity.
Define controller / processor roles, access rights, retention and deletion. Document international-transfer safeguards, including SCCs where applicable.
Separate legal-entity ledgers, currency, fees and VAT / GST references. Support auditable reporting; tax calculation, filing and invoice obligations depend on jurisdiction and contract.
DEVELOPER EXPERIENCE
A clear integration model. Predictable payment states. Session-linked references. Design your payment flow with the team that understands your use case.
// Illustrative contract · not a live API
POST /example/payments
{
"session_reference": "cs_demo_001",
"market": "DE",
"currency": "EUR",
"amount_minor": 20000,
"method": "card"
}COMMERCIAL MODEL
Platform fee + payment-provider costs at pass-through. No markup on provider costs under the agreed commercial terms. Active-connector definitions, billing period and taxes are specified in your agreement.
+ payment-provider costs
FAQ
CpoPay focuses on payment infrastructure for CPMS providers and CPO businesses. Your CPMS continues to manage chargers, sessions and energy.
The integration pattern can be shared, but payment methods, merchant onboarding, settlement and regulatory requirements vary by market and provider.
A shared session reference links payment events to the CPMS. Your integration should handle asynchronous status updates, duplicate notifications and final reconciliation.
THE NEXT MOVE IS YOURS
Discuss your CPMS architecture, launch markets and commercial model with our team.
CPMS / TECHNICAL & COMMERCIAL
Send your CPMS architecture, target countries and payment priorities. Our team will help scope the integration and commercial model.