Skip to main content
This page documents the current behavior of the Checkout Embed SDK (window.Shoppex): the full API, data attributes, events, security model, and troubleshooting.

Script and integration modes

Global object:
The SDK auto-binds clickable elements matching:
  • [data-shoppex-product-id]
  • [data-shoppex-group-id]
  • [data-shoppex-checkout]
Simple button:
Multiple items with JSON:
Group button:

Data attributes

* Required unless data-shoppex-items contains at least one valid item. ** Required when you want to open a group instead of a product checkout. data-shoppex-metadata example:

JavaScript API

Shoppex.init(config?)

Initializes bindings and keyboard handlers.
Notes:
  • This call is usually optional because the script initializes automatically.
  • It is safe to call multiple times. The first call wins.

Shoppex.open(options)

Opens modal checkout.
Important behavior:
  • items must contain at least one valid productId, unless groupId is provided.
  • groupId opens a group picker first, then forwards the buyer into the normal product checkout page.
  • If more than one item is passed, the current modal flow uses the first valid item.
  • Calling open() while a modal is open closes the old modal first.

Shoppex.close()

Closes the modal programmatically.

Events

Listen on document.
Event payloads: Internal iframe events used by the SDK:
  • shoppex:ready
  • shoppex:resize
  • shoppex:close
Practical example

URL mapping and runtime behavior

The SDK resolves checkout iframe URLs to:
Supported query params sent by the SDK:
  • quantity
  • variantId
  • theme (only when not auto)
  • flow
  • shopId
  • returnUrl
  • email
  • couponCode
  • affiliateCode
  • metadata[key]=value
Runtime behavior:
  • The modal uses Shadow DOM (mode: closed) for style isolation.
  • Escape, a backdrop click, and the close button all close the modal.
  • Dynamically inserted buttons are auto-bound through a MutationObserver.
  • Message handling accepts only trusted checkout origins.

Security

The SDK protects modal message handling by validating the iframe origin before it processes events. It accepts messages only from trusted origins, so a forged postMessage event from a random origin is ignored.
Trusted origins:
  • https://checkout.shoppex.io
  • the local development origin for the checkout app

CSP setup

If you enforce a Content Security Policy and omit the required frame-src and script-src rules, the checkout iframe is blocked entirely. Customers see a blank modal or a browser console error instead of the payment form. Always test your CSP in production, not only locally.
If you run a strict CSP, allow the checkout iframe and script, and pass a nonce to Shoppex.init. Example policy:
SDK init with nonce:
Why this matters:
  • The SDK injects styles into its shadow root.
  • The nonce lets those injected styles run under a strict CSP.

Return URL safety

Never pass unvalidated user input as returnUrl. An attacker can exploit this as an open redirect, sending customers to a phishing page after checkout completes. Always use a hardcoded or server-validated URL.
Use a trusted application URL for returnUrl.
Avoid sending unvalidated user input directly as returnUrl.

Production checklist

1

Use HTTPS everywhere

The embed modal runs inside a cross-origin iframe. Most browsers block mixed content, so your host page must be served over HTTPS.
2

Load the embed script from the correct origin

Always load from https://checkout.shoppex.io/embed/embed.iife.js. Never self-host or proxy the script, because it must match the iframe origin.
3

Bind event handlers

Listen for shoppex:success and shoppex:error events so your app knows when a payment completed or failed. Without these, your UI has no feedback loop.
4

Track conversions

Fire your analytics conversion event inside the shoppex:success handler. This is the only reliable moment to attribute a sale to your funnel.
5

Validate product and variant IDs

Double-check that data-shoppex-product-id and data-shoppex-variant-id values match real products. Invalid IDs silently fail to open the modal.
6

Test dark mode and mobile viewports

The modal adapts to prefers-color-scheme and small screens. Test both to catch layout issues before your customers do.
7

Validate CSP in production

Your local dev server likely has no CSP. Test your Content Security Policy on the real production domain, because CSP violations only surface there.

Troubleshooting

Checklist:
  • The script is loaded.
  • The element has a valid data-shoppex-product-id, data-shoppex-group-id, or data-shoppex-items.
  • items contains at least one non-empty productId, unless you pass a valid groupId.
  • No JavaScript error runs before the click handler.

Wrong product opens

Cause: multiple items currently resolve to the first valid item in the modal flow. Fix: pass one item per checkout open until multi-item modal support lands.

Event listeners do not fire

Checklist:
  • Listen on document, not only on the button element.
  • Make sure that checkout completed successfully for shoppex:success.
  • Verify that browser extensions or policies do not block cross-origin frames.
Use low-risk defaults:
  • Avoid custom overlays with extreme z-index values.
  • Test with your cookie or privacy banners and support widgets.

Dynamic content buttons do not open checkout

The SDK auto-observes DOM changes, but make sure that:
  • New nodes actually include data-shoppex-product-id, data-shoppex-group-id, or data-shoppex-checkout.
  • Your frontend does not stop propagation on click before the SDK handler runs.

Debug helpers

Simple runtime checks:

Integration patterns and framework snippets

Next.js, React, WordPress, and Webflow snippets, plus the hybrid product-cards pattern.