Ecommerce

Accept Scan to Pay on your online checkout — choose hosted (Bluebox) for fastest integration, or custom for full UI control.

Two ways to put Scan to Pay on your online checkout. Both end in the same outcome — the customer scans a QR with their bank or wallet app, authorises the payment, and you receive a webhook with the result. The difference is who builds the customer-facing checkout experience.


Pick your integration

PatternWhat you buildWhat we buildBest for
Bluebox hosted checkoutA redirect from your cart to our hosted page, plus a callback handlerThe QR display, the customer instructions, the success/failure UIFastest time-to-live. Small to medium merchants, custom-build is overkill
Custom checkoutThe full checkout UI, including QR rendering and state-pollingJust the API endpointsLarger merchants with strong brand UI requirements

If you're not sure, start with Bluebox. You can always migrate to custom later — the underlying API is the same.


What's the same across both

  • Same code/create endpoint for creating the payment intent
  • Same webhook payload delivered to your notification URL on completion
  • Same merchantReference idempotency model — see Idempotency
  • Same encryption for the webhook body — see Signing and verifying webhooks
  • Same settlement through your existing acquiring bank

What's different

ConcernHosted (Bluebox)Custom
EndpointPOST /bluebox/secure/createTxPOST /code/create
You render the QR?No — we do, on our redirect pageYes — render yourself or use the QR endpoint
Customer leaves your site?Yes, briefly, then returns via callbackNo — entire flow stays on your domain
CallbacksTwo: unencrypted browser redirect (CB1) and encrypted server-to-server webhook (CB2)One: standard encrypted webhook
BrandingScan to Pay branding on the checkout pageYour branding throughout
Time-to-integrateA day or twoA week or two

What's next