A breakdown of how automated payment-to-wallet crediting works for SMS aggregators and resellers: which gateways are supported, how webhook signature verification and idempotency prevent double-crediting, how reseller merchant-credential isolation works, and what still requires manual operational discipline.
Table of Contents
- The Short Answer
- TL;DR
- What Auto Wallet Credit Actually Automates
- Webhook Verification and Idempotency: Why Wallets Don’t Get Double-Credited
- Reseller Merchant Credential Isolation
- Reconciliation: Matching Settlements to Ledger Entries
- Gateway Coverage by Region
- What Still Needs Manual Operational Discipline
- Next Steps
- FAQs
The Short Answer
Payment gateway integration on an SMS platform automates one specific handoff: turning a confirmed payment into a posted wallet balance without a human touching the transaction. A customer picks a credit pack, pays through a supported gateway, a webhook callback confirms the payment with a verified signature, and the platform posts credits, any configured bonus, and tax treatment to the account automatically. Resellers can run this with their own merchant credentials so settlement lands in their own bank account, isolated from other tenants on the same platform.
What it doesn’t automate is everything downstream of that moment: refund handling, chargeback disputes, tax-rate accuracy across jurisdictions, and the regulatory obligations that come with actually holding or moving customer money. Those stay manual, or get handled by the payment gateway itself rather than the messaging platform.
TL;DR
- Auto wallet credit connects a payment gateway’s webhook or IPN callback to the platform’s credit ledger, so SMS, WhatsApp, and RCS balances update automatically on confirmed payment, with no manual recharge processing.
- Supported gateways span India (Razorpay, PayU, CCAvenue, Paytm, Cashfree, PhonePe, Instamojo), US/UK/EU (Stripe, PayPal, Braintree, Authorize.net, Adyen, Mollie, 2Checkout), and Africa/GCC processors, plus any gateway that offers a checkout URL with a signed webhook or IPN.
- Duplicate webhook deliveries don’t double-credit a wallet: the same payment reference is rejected on retry, and pending, failed, or duplicate callbacks are ignored or logged rather than acted on.
- Resellers configure their own gateway keys per tenant, so a downline customer’s payment settles directly to the reseller’s own account under the reseller’s own branding, not through the platform operator’s account.
- Pricing for the integration runs $100 to $1,000+ one-time per gateway depending on that gateway’s own API and reconciliation requirements, available on every plan tier.
- Reconciliation, refund workflows, tax-rate accuracy, and credential rotation remain operational responsibilities the aggregator or reseller has to own; the automation stops at “credit the wallet on a confirmed payment.”
What Auto Wallet Credit Actually Automates
The mechanism is straightforward once you see the whole loop. A customer or downline user opens the panel, selects a credit pack denominated in SMS, WhatsApp, or RCS message volume, and is handed off to whichever payment gateway is configured for that account. The gateway processes the transaction through whatever local payment method it supports (UPI, cards, net banking, mobile wallets, depending on region and gateway). Once the gateway confirms the payment, it fires a webhook or IPN callback back to the platform. That callback carries a signature the platform verifies before it trusts the payload. Only after that verification does the platform post the purchased credits, any configured bonus, and the applicable tax treatment to the wallet.
That sequencing matters more than it looks. The credit never posts on the strength of the customer clicking “pay” or the checkout page redirecting back with a success parameter in the URL, both of which are trivial for anyone to spoof. It posts on the gateway’s own server-to-server confirmation, verified cryptographically. That’s the actual automation: removing the manual step where someone on the operations team checks a bank statement or a gateway dashboard, matches it to a customer, and credits an account by hand. For a reseller running any real transaction volume, that manual step is the bottleneck this integration removes, not customer-facing convenience.
Configuration sits at four points: the credit packs themselves (SMS/WhatsApp/RCS quantities with optional bonus tiers), pricing and tax display (GST or VAT treatment, currency), the gateway credentials (merchant ID, API key, webhook secret, held per tenant), and the success rule that only a confirmed payment event triggers a credit. Every transaction, successful or not, gets logged with a payment reference, amount, pack, and resulting balance, which is what makes reconciliation possible later (more on that below).
Reseller note: subscription customers bill through the platform operator’s own commercial relationship, while perpetual-license operators (see the perpetual license vs subscription breakeven analysis) run their own infrastructure and, if they resell downstream, need this kind of self-service wallet billing to avoid manually invoicing every downline account.
Webhook Verification and Idempotency: Why Wallets Don’t Get Double-Credited
The single biggest operational risk in any payment-to-credit automation is a webhook arriving twice for the same payment and crediting the wallet twice. Payment gateways retry webhook delivery when they don’t get a fast, successful response; that’s standard behavior, not a gateway malfunction. Stripe’s own webhook documentation, for example, states plainly that it retries failed deliveries for up to three days with exponential backoff in live mode, and that event IDs, not timestamps, are the correct way to detect a duplicate, since two events can share a timestamp and events aren’t guaranteed to arrive in the order they were generated.
The platform’s stated safeguard against this is that the same payment ID cannot credit a wallet twice on webhook retry, and that pending, failed, or duplicate callbacks are either ignored or logged rather than acted on. Combined with signature verification on every inbound callback, that covers the two failure modes that actually matter: a forged callback that never happened, and a real callback that arrived more than once.
Signature verification itself follows the same shape across virtually every serious gateway, whether or not the specific vendor is named here: the gateway signs the webhook payload with a secret only it and the receiving server know (commonly an HMAC over the raw request body), and the receiving server recomputes that signature before trusting anything in the payload. Stripe’s implementation, again as a generic industry reference rather than a claim about how any given gateway configured here behaves, also includes a timestamp in the signed payload specifically to block replay attacks, where an old, legitimate signature gets re-sent later. Whichever gateway a given deployment uses, this class of protection is table stakes, not an SMPPCenter-specific feature; the gateway itself owns the signature scheme, the platform owns the verification and the idempotency check on its own side of that handshake.
The webhook endpoint’s own exact contract (request shape, retry-handling response codes it expects, per-gateway configuration screens) isn’t published outside the app. That’s consistent with how the rest of the platform’s API surface works: it’s shown inside the panel to a customer with a live deployment, scoped to that deployment’s own domain, rather than published as a generic public reference the way a payment gateway’s own docs are. If a deployment needs that detail to finish a gateway integration, it comes from inside the account, not from a public spec.
Reseller Merchant Credential Isolation
The reseller model here is structurally different from a typical SaaS billing setup, and it’s worth being precise about why. A reseller adds their own merchant credentials, their own Razorpay keys or their own Stripe account, rather than routing customer payments through the platform operator’s gateway account. Those credentials stay isolated per tenant. When a downline customer pays, the checkout page carries the reseller’s own branding, and settlement flows to the reseller’s own bank account, not to the platform operator’s. This can run alongside an operator’s own master gateway configuration for the operator’s direct customers, on the same platform.
There’s a regulatory reason this structure is worth understanding, not just a technical one, for any reseller operating in India. Under the Reserve Bank of India’s payment aggregator framework (the master directions most recently overhauled in 2025), an entity that aggregates customer payments across channels and settles funds to merchants out of its own account is a payment aggregator, and non-bank payment aggregators are required to hold merchant settlement funds in escrow accounts with a scheduled commercial bank, with day-end balances that can’t fall below what’s owed but not yet paid out. The framework does contemplate a payment aggregator settling to a third party on a merchant’s specific direction, but that provision is scoped to cases above a turnover threshold and still routes through the aggregator’s own regulated escrow structure.
A reseller using their own merchant credentials on their own gateway account sits outside that picture in a meaningful way: the messaging platform isn’t the one collecting, holding, or aggregating the customer’s payment, since the money never touches an account the platform controls. The reseller’s own relationship with their own gateway, and whatever merchant or sub-merchant obligations that gateway imposes on them directly, is what governs their compliance position, not the messaging platform’s status. This is regulatory background to understand the shape of the obligation, not legal advice, and a reseller with real transaction volume should confirm their specific position with their own gateway agreement and, where warranted, counsel, rather than treat this as a substitute for that review. It sits alongside a separate regulatory surface entirely, the RBI’s rules on messaging compliance for banks and NBFCs, which govern the SMS content and delivery side (OTP handling, DLT template validation) rather than payment settlement, and the two shouldn’t be conflated when a bank or NBFC is evaluating both.
The practical upside of credential isolation, separate from the regulatory framing, is straightforward: one reseller’s compromised or misconfigured gateway key can’t expose another reseller’s transactions or settlement, and a reseller can rotate their own credentials without coordinating with the platform operator or with any other tenant on the same install.
Reconciliation: Matching Settlements to Ledger Entries
Automated crediting removes the manual step of matching a payment to an account, but it doesn’t remove the need to periodically confirm that what the gateway actually settled matches what the platform’s ledger says it credited. The stated mechanism here is that gateway settlements are matched against the panel’s own credit logs, each of which records a payment reference, amount, credit pack, and resulting balance, for accounting purposes.
That log is what makes reconciliation tractable, but running it is still an operational task, not something that happens on its own. A gateway’s settlement report and a platform’s credit log are two independently generated records, and the routine discipline that keeps them aligned, checking that every settled payment has a matching credit event and every credit event has a matching settlement, sits with whoever runs finance for that deployment, whether that’s the platform operator or a reseller running their own books.
There’s a separate, lower-friction benefit worth noting on the security side of this same design. Because the integration works against gateways that use a hosted checkout URL, the customer’s card details are entered on the gateway’s own page, not on the messaging platform’s servers. That pattern, keeping cardholder data off a merchant’s own infrastructure entirely, is the standard way vendors reduce their PCI DSS compliance scope: a merchant that never receives, transmits, or stores card data directly typically qualifies for a much lighter self-assessment questionnaire than one that touches card data at any point. Whether that applies to a specific deployment depends on exactly how that deployment’s checkout flow is configured and on the gateway’s own compliance posture, not something the messaging platform can certify on a merchant’s behalf, but the architecture itself (redirect to gateway, verify webhook, never touch the card number) is the right shape for keeping PCI scope narrow.
Gateway Coverage by Region
| Region | Supported gateways |
|---|---|
| India | Razorpay, PayU, CCAvenue, Paytm, Cashfree, PhonePe, Instamojo |
| US / UK / EU | Stripe, PayPal, Braintree, Authorize.net, Adyen, Mollie, 2Checkout |
| Africa / GCC | Paystack, Flutterwave, plus regional processors covering Kenya, South Africa, Nigeria, and the UAE |
| Anywhere else | Any gateway offering a checkout URL plus a signed webhook or IPN callback |
That last row does most of the practical work. Rather than a fixed list that needs a new integration built for every new market, the requirement is a specific, common shape: a hosted or redirect checkout, and a server-to-server confirmation the platform can verify. Most payment processors operating anywhere in the world meet that shape, which is why the named list above reads as “these are confirmed working” rather than “these are the only options.”
Pricing for setting up a given gateway runs $100 to $1,000 or more, one-time, per gateway, on every plan tier, with the exact figure depending on that specific gateway’s own API, webhook, and reconciliation requirements. A reseller supporting three regional gateways for three different customer bases is pricing three separate one-time setups, not one flat fee, and final pricing is confirmed after scoping the specific gateway.
What Still Needs Manual Operational Discipline
Automated crediting is a narrow, well-bounded piece of the billing lifecycle, and it’s worth being clear about where that boundary sits so a deployment doesn’t assume more coverage than exists.
Refunds and chargebacks aren’t part of the crediting loop described here; a refund happens on the gateway side, and reversing the corresponding wallet credit, or deciding whether to reverse it at all if messages have already been sent against those credits, is a judgment call and a manual process a reseller has to define for their own operation. The same is true of partial payments or failed-then-retried transactions that leave a customer in an ambiguous state; the safeguard against double-crediting handles the technical risk, but deciding what to tell a customer whose payment shows as failed on their bank statement and pending in the panel is a support workflow, not something the webhook logic resolves for you.
Tax and currency configuration is exposed as a setting, GST or VAT treatment and display currency, but keeping that setting accurate as rates change in a given jurisdiction, or as a reseller expands into a new one, is a maintenance task with no stated automatic update mechanism. And credential hygiene, rotating gateway API keys and webhook secrets on a schedule or after any suspected exposure, the way Stripe’s own guidance recommends doing periodically for its own webhook secrets, is a routine an operator or reseller has to run themselves; nothing in the stated feature set prompts or enforces that rotation on its own.
None of this makes the automation less useful for what it does. It just means the honest way to plan a deployment is to treat “payment confirmed to wallet credited” as the automated segment, and everything upstream (gateway selection and compliance posture) and downstream (refunds, tax accuracy, credential hygiene, reconciliation cadence) as work that still needs an owner on the aggregator’s or reseller’s side.
Next Steps
Pricing for setting up a specific gateway, and which plan tiers a given configuration fits, is confirmed after scoping on the pricing page. For a reseller weighing whether to route settlement through their own merchant account versus an operator’s master gateway, the reseller and white-label documentation covers the broader account-tier and credit-management mechanics this integration plugs into.
FAQs
Does auto wallet credit support recurring or subscription-style billing, or only one-time top-ups?
The described flow is a credit-pack purchase model: a customer selects a pack and pays for it once, and the wallet is credited on that confirmed payment. Recurring auto-debit billing isn’t part of the stated feature; if a deployment wants that pattern, it would need to be built on top using a gateway that supports recurring mandates, with the platform’s wallet crediting still triggered per individual successful charge.
If a webhook delivery fails or is delayed, does the customer’s payment get lost?
No; the payment itself lives on the gateway’s side regardless of webhook delivery, and gateways retry failed webhook deliveries automatically. The practical risk is a delay between payment and credit appearing in the panel, which is what the payment reference in the credit log is for: support staff can look up a specific transaction on the gateway’s own dashboard and cross-check it against the platform’s log if a customer reports a gap.
Do resellers need their own PCI DSS certification?
That depends on their own merchant agreement with their own gateway, not on the messaging platform. Since the integration works through a hosted checkout redirect, cardholder data doesn’t pass through the reseller’s own systems in that flow, which typically keeps a merchant’s own PCI scope narrow, but the specific compliance requirement is set by the gateway the reseller signed up with, and by their own transaction volume and business type under that gateway’s terms.
Can a customer in one country pay in a different currency than the reseller’s default?
Currency is one of the configurable elements alongside pricing and tax display, but multi-currency checkout behavior depends on what the specific gateway supports for that market; a gateway configured for Indian rupee settlement, for example, isn’t necessarily going to accept a checkout in a different currency without a separate gateway configuration for that market.
Is there a way to see which payments failed signature verification, as opposed to ones that simply never arrived?
Failed or duplicate callbacks are logged rather than silently dropped, which is what makes that distinction checkable after the fact, but the level of detail in that log for a specific deployment is something to confirm inside the account rather than something documented publicly.
Recent Articles
- SFTP Bulk SMS Campaigns: An Operations Runbook for File-Drop Messaging at Scale
- Telegram Bulk Messaging for Business: What the Platform Actually Allows
- MCP Server Integration for SMS Platforms: Connecting an AI Agent to SMPPCenter
- Message Encryption, IP Whitelisting and VPN Protection: The SMS Security Layer Most Platforms Skip
- Reseller Architecture Explained: How Multi-Tenant SMPP Platforms Actually Work
