Choose your integration
Pick the integration path that matches your business and jump straight to the right section.
Scan to Pay supports three integration paths. Pick the one that describes your business.
I'm a merchant or a PSP
You sell something — online, in a physical store, on a bill, or inside your own mobile app — and you want to accept payments.
This is the largest audience and the most common starting point. Most readers of these docs are here.
→ Continue to Merchant / PSP Integrations
I'm a wallet provider, a bank, or a fintech
You operate a consumer wallet or a banking app, and you want to:
- Let users scan and pay QR codes from inside your wallet
- Provision cards into a wallet your bank issues
- Send payment requests between users
- Embed Scan to Pay capability inside your existing super-app
→ Continue to Wallet Provider Integrations
I'm building a mobile app that needs to accept payments
You're a mobile developer adding Scan to Pay payments inside a merchant's Android or iOS app, using the Library Lite SDK. The SDK handles the customer-facing flow; your backend still creates the codes server-to-server.
→ Continue to In-App Payments
Pick your acceptance channel
If you went with Merchant / PSP, you've got a choice of how customers actually reach the payment. Most merchants use more than one over time — start with the channel that matches your immediate use case.
| Channel | Use this when | Go to |
|---|---|---|
| Hosted checkout (Bluebox) | You're selling online and want the fastest integration. Customer redirects to a Scan to Pay-hosted page that displays the QR; you receive a callback when it's done. | Bluebox hosted checkout |
| Custom e-commerce checkout | You're selling online and want full control of the checkout UI. You render the QR on your own page using our API. | Custom checkout |
| Static QR | Small merchant, single printed QR on a counter or poster. Customer types the amount. | Static QR |
| Dynamic QR (POS) | You have a point-of-sale terminal. Each transaction generates a fresh QR with the amount embedded. | Dynamic QR |
| Bill payment | A QR printed on an invoice, statement, utility bill, or parking ticket. | Bill payment |
| App-to-app | Your customers use your own mobile app and you want a "Pay" button that launches the Scan to Pay app on the same device. | App-to-app overview |
| USSD | Your customers use feature phones (no smartphone) and pay via short code. | USSD payment |
Still not sure?
A few patterns that catch people out:
- You're a hybrid org. A fintech that hosts a wallet and sells merchandise integrates as both a Wallet Provider and a Merchant. The two integrations are independent — pick the one for your first project and come back for the other later.
- You're a PSP onboarding merchants. Use the Merchant onboarding API to provision your merchants, then point them at the channel that suits their business.
- You're an acquirer. Acquirer-side integration (Postillion / Base24 / ISO 8583) is handled separately. Contact [email protected] for the acquirer integration pack.
If none of the above describes you, email [email protected] and we'll route you to the right team.
Want to try first, decide later?
Run the Quickstart — it walks through the merchant flow end to end in 15 minutes using sandbox credentials. You can decide on your real integration after you've seen it work.
Updated 1 day ago