Order, account, amount, currency and business rules are established by a trusted backend.
Developer guide
Keep commercial context server-side. Expose only the checkout state the browser needs.
A session-based checkout model lets your backend establish the commercial context, activate a scoped customer-facing session and keep provider-specific credentials and integration details behind the platform boundary.
01Create session
02Activate
03Scope browser state
04Load configuration
05Pay
06Observe outcome
Integration boundary
A controlled boundary between server and browser
A production-proven session pattern uses a server-created session, an activation step and scoped browser access before loading checkout configuration and initiating payment. The reusable design principle is to keep commercial and provider context on the trusted side while exposing only the state required for the customer experience.
A bounded session represents the customer-facing payment journey.
The client receives only the scoped context required to render and continue the checkout.
Eligible payment methods and experience options can be resolved for the active session.
Payment state returns to the broader transaction lifecycle through response, event and state-query patterns.
Proven pattern
Session-based checkout pattern
This structure keeps the storefront or mobile application focused on customer experience while the backend and platform preserve business rules, provider connectivity and transaction identity.
- Create the commercial context from a trusted server-side application.
- Activate a bounded checkout session for the customer journey.
- Expose scoped browser state rather than provider credentials or provider-specific integration details.
- Load the payment experience from the active session and its eligibility context.
- Connect the resulting payment back to the same transaction identity used by downstream systems.
Conceptual session model — not a current API schema
{
"session": {
"id": "checkout-session-id",
"reference": "your-business-reference",
"scope": "customer-checkout"
},
"experience": {
"eligible_methods": ["..."],
"options": ["..."]
},
"transaction": {
"id": "durable-transaction-id",
"state": "..."
}
}Implementation model
Why the boundary matters
These patterns describe integration behavior proven in production systems. They define the technical model, not a promise that the current Zopio API will expose any specific endpoint name, field name or contract shape.
Provider independence
The client application does not need to own every provider-specific credential or implementation detail.
Controlled exposure
Browser-facing state can remain narrower than the commercial and provider context held server-side.
Reusable experience
Web and mobile channels can reuse the same operating concepts without becoming provider-specific applications.
Traceable outcome
The payment created from the session continues into the same observable transaction lifecycle.
Continue exploring
Discuss your integration