Search pages in the SMS Pay documentation.
SMS Pay sits between your backend, your customer checkout, the merchant phone receiving provider SMS, and your webhook endpoint. Your organization does not run the SMS matching infrastructure; you configure and use it from the merchant dashboard.
Loading diagram...
| Component | Merchant-facing purpose |
|---|---|
| Merchant dashboard | Admin portal for receiver accounts, API keys, webhooks, devices, sandbox tests, and operational review. |
| Merchant backend | Your server creates payment intents, redirects customers to checkout, and processes webhooks. |
| Hosted checkout | Customer page that shows payment method, receiver number, amount, short reference, expiry, and TrxID fallback. |
| SMS Pay Android app | Merchant-phone app that forwards trusted provider SMS messages to SMS Pay. |
| Matching and reconciliation | SMS Pay compares SMS evidence with payment intents and decides PAID, REVIEW_REQUIRED, EXPIRED, or REJECTED. |
| Webhooks | Signed server-to-server events sent to your backend when payment status changes. |
Sandbox and live are separate. Sandbox API keys, payment intents, SMS simulator events, webhook tests, and dashboard data do not affect live payments. Live data comes from live API keys and live Android device SMS forwarding.
Use sandbox while integrating. Move to live only after receiver accounts, webhooks, Android device status, and small test payments are verified.
Your system remains the source of truth for orders, invoices, fulfillment, and customer accounts. SMS Pay is the source of truth for SMS-confirmed payment intent status. Link both systems by storing the SMS Pay payment intent id and your own merchantReference on the order.