Embedded Components lets you render the SportsPay payment fragment inside your own checkout flow instead of sending the customer away to a full-page redirect. You get the same PCI-safe, server-hosted card capture, delivered as a fragment that visually fits inside your registration platform.

SportsPay still hosts the payment fragment and your platform still never touches card data — you keep the same minimal PCI scope as Customized Checkout and add a smoother, in-place checkout experience.

Under the hood, Embedded Components uses the same StartSession / GetResult / Ack messages as Customized Checkout. The difference is how the customer reaches the payment form: mount it into a <div> on your page using the SportsPay JavaScript Library (coming soon), or embed the returned URL into an <iframe>. Either way, you pass an EMBED= flag on StartSession to tell the gateway which visual components to render. The fragment uses the same brand theming as Customized Checkout — your colours, gradients, and logo carry through.

When to use Embedded Components

Use Embedded Components when you want the payment fragment to appear as part of your existing checkout page — for example, in a modal, a side panel, or a step in a multi-step wizard — rather than redirecting the customer away to a standalone SportsPay page. The fragment seamlessly handles advanced functionality — schedules, CustomerPay, Platform Fees, wallets, and retries — with no additional integration work on your side. Future feature additions are handled inside the fragment too, so your integration doesn't need to change as the platform evolves.

Use Customized Checkout instead when a full-page redirect is acceptable or when you don't need to control the surrounding page chrome.

Choosing between Customized Checkout and Embedded Components

Both methods use the same StartSession, GetResult, and Ack calls — the difference is entirely in how the customer's browser reaches the payment page and how the result returns to your application. Pick one per checkout flow; they are not interchangeable on a per-call basis.

Visual Components and the EMBED= flag

The EMBED= parameter on StartSession is a string of one or more letters. Each letter switches off one visual component of the hosted page so that the fragment blends into your own layout.

Combine letters in any order. For example, EMBED=WCSP strips the wrapper, card, branding, and partner area while leaving the header, info, amount, and buttons in place.

Driving the form from your own buttons (EMBED=B)

Coming soon. A JavaScript bridge that lets your parent checkout page drive the embedded form from its own Pay, Cancel, and language buttons is on the roadmap. Until it ships, leave the built-in buttons in place — omit the B flag from EMBED= — so the customer submits and cancels from inside the embedded fragment. Once the bridge is released, you'll be able to render your own buttons in the surrounding layout and forward their clicks into the iframe.

StartSession, GetResult, and Ack

Embedded Components uses the same three gateway messages as Customized Checkout:

1. StartSession — creates the payment session, returns a SECUREID and a URL you mount into a <div> via the JS library or load directly into an iframe. Pass EMBED= to choose which components render.
2. GetResult — called from your return URL (inside the iframe) after the customer completes payment. Returns the result of the transaction.
3. Ack — confirms and finalizes the transaction. Can be combined with GetResult by passing ACK=Y, or sent separately.

Each request includes the required fields that allow the gateway to validate the request and credit the correct merchant account.

Note: CustomerPay is supported with no additional implementation. The gateway determines whether a merchant is enabled for CustomerPay based on the TERMID, the hosted page auto-calculates USERFEE, and the final amount is returned in the GetResult response.

Payment Sequence

flowchart TD
    A[Customer reaches checkout] --> B[Registration platform sends StartSession with EMBED flags]
    B --> C[Gateway returns SECUREID + Payment URL]
    C --> D[Registration platform renders URL in an iframe on the checkout page]
    D --> E[Customer enters card details in the embedded fragment]
    E --> F[Payment processed by gateway]
    F --> G[Iframe redirected to Success or Failure URL]
    G --> H[Return page calls GetResult server-side]
    H --> I[Return page posts result to parent window]
    I --> J[Parent page closes the iframe and shows the result]
    J --> K{Ack required?}
    K -- Yes --> L[Registration platform sends Ack]
    L --> M[Gateway confirms and closes session]
    K -- No --> N[Session ends]
    M --> O[Registration platform continues user flow]
    N --> O