Payments glossary
Sandbox
A sandbox is a payment provider's test environment - a working replica of the live API with test cards and simulated banks - where developers can build and verify an integration end-to-end without moving real money.
What you can test in a sandbox
Everything except real money. Sandbox test cards are built to trigger specific outcomes on demand - a clean approval, a particular decline code, a 3DS2 challenge - and simulated flows stand in for banks and voucher networks. That makes the sandbox the place to rehearse failure, which is the real point: what your integration does when a payment is declined, a webhook arrives twice, or a customer abandons a challenge matters more than what it does on the happy path. Refunds, webhooks and reconciliation reports can all be exercised the same way.
Going from sandbox to live
Sandbox and production are separated by credentials: the same API, different keys, so promotion is a configuration change rather than a rewrite. The switch deserves a short checklist all the same - webhook endpoints pointed at production URLs, the real statement descriptor in place, error handling proven against the decline scenarios, and secrets stored outside the code. Many merchants finish with one small live transaction, refunded immediately, to confirm the whole chain with real money. Two honest limits: a sandbox cannot reproduce live issuer behaviour or production latency, so approval rates and timing are only truly measurable after go-live. LekkaPay provides sandbox access as part of its standard integration process.
Last updated:
Payments without the jargon.
One integration, every way Africa pays - we'll handle the acronyms.