Skip to main content
In-page Checkout keeps the buyer on your site. Unlike Redirect Checkout, its supported provider presentation is an overlay or an embedded provider checkout.

In-page capability reference

The Supported SDK mode is the value supplied to CreateOrderOptions. The Public checkout type is returned in PaymentSession::$checkout['type']. It identifies the provider instruction returned by the prepared session; it is not a separate browser-selected setting. The table describes platform capabilities. A gateway/mode pair is usable only when it is currently returned by your backend’s availability() call for the configured domain and selected environment.

1. Prepare an overlay session

Choose a gateway/mode pair returned by availability() with mode: overlay. PayHere, OnePay, and DirectPay currently support Overlay checkout. Persist the returned completionContext with the pending merchant order before sending public checkout instructions to the browser.
The selected method must be an overlay method returned by your server-side availability() result. Do not accept a browser-provided gateway name or mode without that validation.

2. Prepare an embedded session

Embedded checkout currently supports DirectPay only. Use CheckoutMode::Embedded only when DirectPay Embedded is returned by availability(). The same trusted order, customer, URL, and optional configuration values used above apply here.

3. Return only public checkout instructions

The exact checkout object is provider-specific. Return its public fields unchanged to the browser. Set $checkoutSession to the Overlay or Embedded session you just created. Never include completionContext, Vault credentials, project credentials, or internal order data.

4. Launch the provider presentation

Payment Elements is highly recommended for Overlay and Embedded checkout. It handles method rendering and the provider presentation using the public session returned by your backend. It remains optional: the SDK-only integration below is fully supported when you need to integrate each provider’s official browser SDK yourself.
For an SDK-only integration, load and use the selected provider’s official browser SDK according to its documentation, passing only the public fields returned in checkout. Do not create or alter the signed checkout data yourself. In the examples below, publicSession is the exact public session object returned by your backend in the previous step. It must not contain completionContext.

PayHere Overlay — SDK-only

Load PayHere’s official browser script, assign UI-only callbacks, then pass the returned signed fields directly to startPayment().

OnePay Overlay — SDK-only

Install OnePay’s official browser SDK in your frontend build, then initialize it once and pass only the returned OnePay public fields. The SDK event is a UI signal; your server still completes the payment through completePayment().

DirectPay Overlay and Embedded — SDK-only

Load DirectPay’s official V3 script. Use doInAppCheckout() for an Overlay session. Use doInContainerCheckout() for an Embedded session and give DirectPay a dedicated container ID. The signed fields returned by AvraAPI must remain unchanged.
Browser completion events are display signals only. They can show progress, cancellation, or an error, but cannot mark an order paid.

5. Verify server-side completion

Receive the provider callback or return on your backend, load the stored completionContext, and call completePayment() with the gateway-required evidence. DirectPay requires its signed callback body and authorization header; OnePay always verifies its upstream provider status before a payment can succeed. Follow Payment Response & Completion before fulfilment.

Optional: Payment Elements

Payment Elements is optional. It can launch the same returned PayHere, OnePay, and DirectPay public checkout instructions for you. It does not replace the server-side SDK preparation or completion steps on this page. For setup options, safe availability rendering, and browser events, see Payment Elements.
Last modified on October 1, 2026