It’s tempting to put failed transactions and other payment performance problems in the “checkout issues” bucket, but these are post-checkout issues. The customer has checked out just fine, the sale is being lost in the back end. Hence, the payment gateway is often where failures surface and get misdiagnosed.
Gateway decisions carry big implications for merchants, with 47% estimating that up to 5% of legitimate orders get erroneously declined as fraud. This adds up to approximately $50 billion in lost annual revenue.
For teams working to identify and resolve the issues that lead to these costly errors, it doesn’t help that the interlinked and sometimes overlapping functions of the payment processing tech stack can lead to miscommunication and confusion. Depending on who you’re talking to, “payment gateway” might refer to the gateway, the processor, or even the acquirer. Before we can solve our gateway problems, we need to know exactly what a gateway does.
What is a payment gateway?
Payment gateways are technology platforms that connect customers, merchants, payment processors, and banks so they can all seamlessly process electronic payments. Unlike cart abandonment (where a customer leaves before submitting payment), gateway failures happen after payment details are entered. They serve an intermediary role, securely moving data from one step in the process to the next.
Gateways function like the e-commerce equivalent of in-person point-of-sale terminals, accepting payment information through checkout fields that can be integrated into the merchant’s app or website via API, or hosted offsite. Hosted fields and redirect flows can also reduce your PCI scope versus directly collecting card data via API, which typically increases your PCI responsibilities.
The gateway packages the payment authorization request with the information and metadata required by the merchant’s acquiring bank. Later in the process, it receives the responses from payment processors and issuing banks and communicates them to the merchant.
Gateways also provide important security functions, utilizing up-to-date encryption protocols and tokenizing data to reduce potential exposure. Depending on your setup, they may also support optional authentication flows (e.g., 3DS), but authentication isn’t inherent to every gateway integration.
Even when gateways or PSPs run fraud checks or attach risk signals, the issuer’s authorization decision is final, and many false declines originate at the issuer.
Payment gateways vs payment processors vs acquirers: Who does what?
How a payment gateway works
From checkout to settlement, here’s a look at the payment gateway’s involvement in processing a payment:
- The customer submits a payment through a checkout form.
- The gateway, connected to the checkout page either through hosted fields or API integration, captures the data.
- The data is tokenized for protection in the event of a data breach, and risk and context data are attached. Network tokens can reduce expiry-related failures through lifecycle management (where supported), which can help reduce declines.
- The gateway sends an authorization request to the processor and acquirer, who pass it on to the network and issuer. If the request fails before reaching the issuer, it may surface as “transaction declined - gateway rejected.”
- The issuer returns an authorization decision and its corresponding response code.
- The issuer decision is returned via the network, the processor or acquirer, and the gateway relays the result to the merchant.
- The gateway may emit webhooks or events, and the merchant application uses them to finalize order confirmation and post-payment flows.
- If approved, the payment is captured, either immediately or with a delay. Settlement and reconciliation happen later, outside of the real-time events of the checkout.
7 Best practices for payment gateway implementation
1. Design your payment state machine
The payment state machine defines the various stages and transitions that a payment can go through. Define your states end-to-end, for example:
- created → authorized → captured → settled
- failed/declined/unknown
- voided
- refunded
- chargeback
For a consistent approach that protects data integrity, decide on a payments table or object that can function as your single source of truth and determine which systems will have permissions to mutate payment states.
2. Make idempotency non-negotiable
Idempotency refers to operations that can be applied multiple times without altering the result initially generated. In payment terms, this means being able to handle client retries, refreshes, and network timeouts without creating duplicate transaction attempts. You can build this kind of flexibility into your gateway by creating idempotency keys for “create,” “confirm,” “capture,” and “refund,” not just “pay.”
3. Treat webhooks and events as unreliable by design
Webhooks are subject to all kinds of network and data handling issues. Expect to encounter duplicate deliveries (at-least-once behavior), delays, occasional delivery failures, and out-of-order events. To mitigate these issues, you can dedupe by event ID, persist raw events to preserve data integrity, and make processing re-entrant.
4. Capture decline and failure data at full fidelity
Once you have full visibility into the reasons for your declines and failures, you can start getting serious about payment recovery. Capture and store issuer/acquirer response codes, network, BIN, country, amount band, route, timestamp, and internal risk decision. Don’t collapse everything into one “declined” category, as that hinders your ability to diagnose and recover. With clean, structured decline data, teams can even use generative AI to summarize patterns and draft internal incident notes, without changing any payment flow.
The more granular your issuer, network, or processor signals are (raw codes when available), the more precise your recovery logic can be. Gateways often mask raw response codes (such as “05: Do Not Honor” or “51: Insufficient Funds”) with generic “declined” messages.
Some declines are clearly non-retryable (e.g., invalid account), while others are ambiguous and may be recoverable depending on things like the timing and issuer context. “Do Not Honor,” for example, is often an umbrella response that requires disciplined testing rather than automatic exclusion. Where your stack exposes it, also capture network advice codes and any processor “soft” descriptors to improve diagnosis and retry decisions.
5. Separate “integration success” from “revenue success”
You can’t really call a transaction successful until the funds are sitting in your bank account. Track the following metrics to get as clear a picture as possible of where hard-to-detect problems may be costing you revenue:
- Authorization approvals
- Capture success
- Settlement matching
- Refund leakage
- “Paid but no order”
- Timeouts and unknowns
Set alerts for shifts on routing and issuers so you can catch silent revenue drops as swiftly as possible. Segment these metrics by peak vs baseline traffic so you can spot approval-rate drops tied to things like payday cycles and affiliate bursts.
6. Implement a decline recovery lane
With insights from your data about what types of declines are safe to retry, you can define rules that trigger a hold → re-attempt policy → route change → recovery workflow. This can give a second chance at success to orders that might otherwise be lost, with all activity taking place behind the scenes so as not to disrupt the customer experience.
Use this lane to classify and contain retries on your own accounts, then escalate eligible declines to a full-liability recovery provider rather than expanding retry aggression.
Data analytics are essential for informing your recovery rules and keeping them disciplined. Too many uncontrolled retries can hurt a merchant’s standing with banks and card networks. If you have multiple acquirers or MIDs, treat routing as a first-class control. So, think about local vs cross-border acquiring and fallback routes, which can materially change approval rates for the same customer. These controls also give you the data discipline you need to evaluate revenue recovery solutions without guessing what’s actually retryable or what’s just adding noise and risk.
7. Add a full-liability recovery option for eligible declined card payments
If you want to give every payment its best chance of reaching settlement, you can consider adding a recovery layer that takes ownership of the eligible declines you choose to send it. Using a recovery engine, you can pursue incremental approvals without exposing your own merchant accounts to additional risk. That matters because the best recovery approaches often involve timing and routing adjustments that most merchants can’t safely run at scale on their own accounts.
A full-liability recovery lane also helps operationally by turning declines into a recoverable workflow, therefore reducing manual exception handling for finance and support teams. The best solutions systems will retry payments on their own infrastructure, and modern platforms like Paymend can engage in recovery activity without changing any aspect of the checkout UX.
A practical path to higher approval rates
Strong payment performance isn’t just about getting transactions processed. The goal is to turn every payment attempt into settled revenue, and payment gateways sit at the junction where small, resolvable issues can cost you an entire sale.
The best implementations treat declines, timeouts, and edge cases as first-class flows, but even with a fully optimized gateway setup, issuers will still find reasons to decline transactions from legitimate customers. A successful implementation will reduce avoidable failures, but recovery solutions like Paymend can salvage the unavoidable ones.
Paymend is a recovery layer for declined card payments that works alongside your existing gateway. You choose which declined transactions to send, and Paymend retries them on its own infrastructure. Paymend can also decline high-risk traffic you don’t want retried, and it’s no-win, no-fee: you only pay on successfully recovered revenue.
Sign up for a free demo today for an up-close look at how Paymend can recover payments behind the scenes with no checkout changes or extra customer steps.
