Quick Definition
A payment gateway is the technology that processes credit card and digital payment transactions between your application and the financial networks. It authorizes (or declines) charges in real time, acting as the intermediary between your SaaS, the card networks (Visa, Mastercard), and the customer's issuing bank.
For subscription businesses, the payment gateway is the system that either collects your revenue or tells you why it could not. The response codes it returns, the retry logic it supports, and the way it handles failures all directly affect your payment failure rate and recovery rate.
If you are on Stripe: Stripe acts as both your payment gateway and payment processor. This means your gateway responses, retry behavior, and failure handling all happen within Stripe's ecosystem.
How a Payment Gateway Works
When a customer's card is charged for a subscription renewal, here is what happens in roughly 1-3 seconds:
- Your application sends a charge request to the payment gateway (amount, currency, card token).
- The gateway encrypts the data and forwards it to the acquiring bank (your bank).
- The acquiring bank routes the request through the card network (Visa, Mastercard) to the issuing bank (customer's bank).
- The issuing bank approves or declines based on available balance, fraud rules, card status, and spending limits.
- The response travels back through the same chain: issuing bank to card network to acquiring bank to gateway to your app.
- The gateway returns a response code telling you what happened.
The key players
| Role | What They Do | Example |
|---|---|---|
| Payment Gateway | Routes and processes the transaction | Stripe, Braintree, Adyen |
| Acquiring Bank | Your bank, receives the funds | Stripe (acts as acquirer too) |
| Card Network | Routes between banks, sets rules | Visa, Mastercard, Amex |
| Issuing Bank | Customer's bank, approves/declines | Chase, Barclays, Revolut |
Gateway Response Codes That Matter
The response code your gateway returns after a failed payment dictates your entire recovery strategy. Not all declines are the same, and the gateway is where you learn the difference.
Soft Decline Codes
These indicate temporary problems. The card is still valid, and a retry may succeed.
| Code | Meaning | Recommended Action |
|---|---|---|
insufficient_funds |
Balance too low | Retry in 2-5 days |
processing_error |
Temporary network issue | Retry in a few hours |
try_again_later |
Bank system issue | Retry next day |
do_not_honor |
Generic bank decline | Retry once in 3-5 days |
withdrawal_count_exceeded |
Daily limit hit | Retry next day |
See Soft Decline for a deeper breakdown.
Hard Decline Codes
These indicate permanent problems. Retrying will not help.
| Code | Meaning | Recommended Action |
|---|---|---|
expired_card |
Card past expiration date | Request new card |
lost_card / stolen_card |
Card reported lost/stolen | Request new card |
card_not_supported |
Card type not accepted | Request different method |
invalid_account |
Account closed or invalid | Request new card |
pickup_card |
Bank wants the card returned | Request new card |
See Hard Decline for the full list.
Why this distinction matters
Retrying a hard decline wastes your retry budget, can trigger fraud monitoring on the card network side, and delays the real solution (asking the customer to update their payment method). Your gateway response code is the data point that tells you which path to take.
Stripe as a Payment Gateway
Most SaaS companies reading this are on Stripe, so it is worth understanding what Stripe does differently as a gateway:
Built-in smart retries
Stripe's Smart Retries use machine learning to determine the best time to retry a failed payment. They analyze patterns across millions of transactions to pick optimal retry windows. Compare Smart Retries to dedicated dunning tools.
Tokenized card storage
Stripe stores card details as tokens, so you never handle raw card numbers. When a card is updated through Account Updater or by the customer, the token automatically points to the new credentials.
Radar fraud detection
Stripe's fraud system (Radar) runs on every transaction. Legitimate charges blocked by Radar show up as a specific decline type. This is a gateway-level decision, not a bank-level one.
Webhook-driven failure notifications
When a payment fails, Stripe fires an invoice.payment_failed webhook. This is how tools like Rekko detect failures in real time and trigger dunning sequences within seconds.
How Gateway Choice Affects Recovery
Your gateway influences recovery rates in several ways:
Retry intelligence
| Gateway Approach | Description | Recovery Impact |
|---|---|---|
| Fixed retry schedule | Retry at set intervals regardless of failure type | Baseline |
| Smart retries | ML-based retry timing | +10-15% recovery |
| Custom retry logic | You control timing based on decline codes | Varies |
Decline code granularity
Some gateways return detailed decline codes (Stripe gives you decline_code with 30+ specific reasons). Others return a generic "declined" with no detail. More granular codes = better recovery decisions.
Multi-acquirer routing
Enterprise gateways like Adyen and Checkout.com can route transactions through different acquiring banks. If one acquirer declines, the transaction is automatically attempted through another. This can improve authorization rates by 2-5%.
Network tokens
Modern gateways support network-level tokenization (as opposed to gateway-level tokens). Network tokens tend to have higher authorization rates because the card networks can keep them updated even when the underlying card changes.
Common Gateway Errors vs. Bank Errors
Not every failure is a bank decline. Some failures happen at the gateway level before the transaction even reaches the card network:
| Error Type | Source | Example | Action |
|---|---|---|---|
| Gateway timeout | Gateway/network | Connection dropped | Retry immediately |
| Invalid request | Your integration | Bad amount, missing field | Fix the code |
| Rate limit | Gateway | Too many requests | Slow down, retry later |
| Authentication failure | Gateway | Bad API key | Fix credentials |
| Card network unavailable | Network | Visa down temporarily | Retry in 30 minutes |
Gateway-level errors are almost always recoverable. They are not about the customer's card at all.
Gateway Metrics to Monitor
| Metric | What It Tells You | Healthy Range |
|---|---|---|
| Authorization rate | % of attempted charges approved | 92-97% |
| Soft decline rate | % of failures that are temporary | 60-70% of failures |
| Hard decline rate | % of failures that are permanent | 30-40% of failures |
| Gateway error rate | % of charges that fail at gateway level | < 0.5% |
| Retry success rate | % of retried charges that succeed | 30-50% |
If your authorization rate drops below 90%, something is wrong at the gateway, integration, or card-portfolio level. Investigate.
Best Practices for Gateway-Optimized Recovery
1. Route by decline code
Build your retry logic around specific decline codes, not generic "failed" status. Soft declines get retries. Hard declines get dunning emails immediately.
2. Monitor authorization rates over time
A sudden drop in authorization rate could indicate a gateway issue, a change in card network rules, or a problem with your Stripe integration. Track it weekly.
3. Pair gateway retries with customer outreach
Gateway retries happen silently. Dunning emails happen in parallel. The best recovery comes from doing both: retry the card while also notifying the customer to update if the retry fails.
4. Test with real decline scenarios
Use Stripe's test card numbers (4000000000000002 for generic decline, 4000000000009995 for insufficient funds, etc.) to verify your integration handles each decline type correctly.
Key Takeaways
- The payment gateway is where transaction success or failure is determined. It sits between your app and the banking system.
- Decline codes from your gateway dictate recovery strategy. Soft declines get retries. Hard declines need customer action.
- Stripe acts as gateway and processor, with built-in smart retries and detailed decline codes.
- Gateway-level errors are different from bank declines and are almost always immediately recoverable.
- Authorization rate is the metric to watch. Anything below 92% warrants investigation.
Turn Gateway Declines into Recovered Revenue with Rekko
When Stripe returns a decline, Rekko takes over:
- Real-time webhook detection of every failed payment
- Decline-code-aware dunning that adapts messaging to the failure type
- Email + SMS sequences that run alongside Stripe's smart retries
- Pre-authenticated payment links for quick card updates