Going live
The pre-flight checklist before you flip Scan to Pay from sandbox to production.
Going live with Scan to Pay is a four-step cutover: tick the checklist, get production credentials issued, swap base URLs, and watch the first live traffic carefully. This page is the gate — work through it before you ask support to enable production.
Pre-flight checklist
The checklist below covers everything we (and most banks doing security review) expect to be done before flipping live. Some items are developer-owned, some operational, some commercial — the role column tells you who typically handles each.
Integration verification (developer-owned)
| ✓ | Item | Why it matters |
|---|---|---|
| ☐ | End-to-end happy path runs cleanly in sandbox — create a code, customer pays, webhook arrives, you record the payment. | This is your baseline. If this isn't solid, nothing else matters. |
| ☐ | Webhook receiver tested under failure conditions — your server returns non-200 and you see the platform retry / reverse correctly. | Webhook errors cause real reversals in production. See Webhooks. |
| ☐ | Refund and reversal flows tested end-to-end. | Different rules apply: reversals are full-amount only; refunds are limited to credit, cheque, and selected debit acquirers. See Refunds and reversals. |
| ☐ | All terminal END_* transaction states are handled in your code, not just SUCCESS. | You'll see bank declines, fraud blocks, customer cancellations on day one. See Transaction states. |
| ☐ | Idempotency on your side — re-running the same merchantReference doesn't duplicate orders. | The platform rejects duplicate references but your retry logic must too. |
| ☐ | Timeouts and polling cadence — if you poll queryRef, no faster than once per 5s; primary verification is via webhook. | Aggressive polling will hit rate limits in production. |
| ☐ | Sensitive data is never logged — no PAN, no PIN, no CVV in your application logs. | PCI DSS requirement. |
| ☐ | Error responses display human-readable copy to your customer, not raw status codes. | See ISO response codes for suggested customer messages. |
Operational readiness (developer + ops)
| ✓ | Item | Why it matters |
|---|---|---|
| ☐ | Notification URL configured in the Scan to Pay Portal against your production merchant profile. | Without this you won't receive webhooks. |
| ☐ | Notification decryption key generated in the portal and stored in your secrets manager. | The production payload is AES/CBC-encrypted with this key. |
| ☐ | Portal sub-users provisioned for everyone on your team who'll log in to monitor. | Don't share the admin login. |
| ☐ | Monitoring and alerting on your side: webhook receiver uptime, transaction success rate, polling failure rate. | You'll be the first to notice problems before us. |
| ☐ | Runbook for common production issues — what your on-call does when webhooks stop arriving, when success rates drop, when an integration breaks. | First incident at 3am is not the time to write this. |
| ☐ | Support contact details distributed to your on-call team — 24/7 phone and email. See Support. | Production support is by phone for P1/P2 incidents. |
Commercial readiness (business / ops)
| ✓ | Item | Why it matters |
|---|---|---|
| ☐ | Scan to Pay merchant ID issued by your acquiring bank to Mastercard and loaded onto the Scan to Pay platform. | Without this, real transactions cannot route to the acquirer. Apply early — this is often the long lead-time item. |
| ☐ | Scan to Pay branding is visible on your checkout page, mobile app, and where applicable USSD menu. | Scheme requirement. |
| ☐ | Scan to Pay terms and conditions linked from your checkout (website and app). | Scheme requirement. |
| ☐ | Customer guidance at checkout — explain that the customer will be prompted to authorise on their phone. | Higher conversion if customers know what's about to happen. |
| ☐ | PCI DSS scope reviewed with your compliance team. | Your liability depends on how you handle card data; Scan to Pay reduces but does not eliminate your scope. |
Production environment
Once support enables production access, swap your sandbox configuration for the live values.
| Sandbox | Production | |
|---|---|---|
| API base URL | https://qa.scantopay.io/pluto | https://scantopay.live/pluto |
| Portal | https://qa.scantopay.io/portal | https://scantopay.live/portal |
| Test cards | Yes — see Sandbox and test cards | No. Real cards only |
| Settlement | Simulated only | Real, per acquirer schedule |
| Card-scheme rules | Relaxed / configurable | Fully enforced |
| Fraud detection | May be disabled | Fully active |
| Webhook signing | Same AES/CBC scheme | Identical to sandbox — your handler works unchanged |
| Support hours | Business hours | 24/7 for P1/P2 incidents |
Only the hostname changes. Both sandbox and production use the/plutopath — you only swap the hostname (qa.scantopay.io↔scantopay.live) on cutover. Store the full base URL as a single configuration value per environment, not as separately hardcoded hostname and path strings.
Requesting production access
When the checklist above is complete, email [email protected] with:
- Your sandbox merchant ID (so we can find your test setup as the reference)
- The acquiring bank merchant ID loaded with Mastercard
- The administrator email for the production merchant profile (this becomes the production portal login)
- The production notification URL you want webhooks delivered to
- Confirmation that you have completed the integration verification checklist (the technical section above)
- Your planned go-live date and time window
You'll receive:
- A link to set the production portal password (expires after 24 hours).
- Your production API username (
merchant-{id}orpsp-{id}, different from your sandbox ID). - Instructions for generating the production API password and notification decryption key from the portal.
If you're integrating via Library Lite SDK, you'll also need a separate Lib Lite token for the production account — generate it from the portal under the email dropdown → Lib Lite Tokens.
If you've chosen JWT Bearer authentication, share your production public key in the same email. See Authentication.
First days live
Treat the first week as a controlled rollout.
Day 0 (cutover):
- Make one small live transaction yourself before opening to customers. The whole point is to verify the credential swap, base URL swap, and notification decryption with real money.
- Watch the support phone line stays answered on your side.
Days 1–7:
- Monitor webhook delivery rate, transaction success rate, refund rate, and time-to-terminal-state on a dashboard. Compare against your sandbox numbers — order-of-magnitude differences usually mean something's misconfigured.
- Keep a rollback plan written and ready (see below).
- Don't push new code to the integration during this window unless necessary.
Ongoing:
- Rotate API passwords on whatever cadence your security policy specifies.
- Test the webhook handler periodically against deliberately bad payloads to confirm error paths still work.
Rollback
If something goes wrong and you need to take Scan to Pay offline at your end:
- Remove Scan to Pay as a payment option from your checkout. New customer flows stop reaching the platform.
- Keep your webhook handler running — in-flight payments will continue to need their notifications acknowledged. If you stop accepting webhooks, those transactions will reverse.
- Process refunds for any orders you can't fulfil through your normal refund flow.
- Call 24/7 production support (+27 10 449 1784) to flag the issue if it's platform-side.
You do not need to suspend the merchant or rotate credentials to do an emergency rollback — just stop sending new traffic.
What's next
- Operational support contacts → Support
- Reference for live transaction states → Transaction states
- Bank decline codes mapped to customer messages → ISO response codes
- Webhook payload format and signing → Webhooks
- Acceptance test pack for sign-off (if required by your PSP relationship) → Onboarding testing
Updated 1 day ago