What Systems Decide Whether a Payment Is Approved or Declined

No single system makes every decision

The decision is distributed, and that's the first thing to accept when you're chasing an unexplained decline. A payment passes through a chain where each link holds veto power, but only one link holds approval power for card transactions. Your gateway can reject a malformed request. Your fraud vendor can hold an order that never reaches the network. The issuer alone returns the approval code.

That split matters because the decline data you see in your dashboard is a mix of decisions made in different places by different logic. Response code 05, "do not honor," came from the issuer. A pre-auth fraud block came from a system you configured yourself.

Card-not-present authorization rates sit around 80% against roughly 98% for card-present transactions, according to industry benchmarks compiled by Subrevival. That 18-point gap is the accumulation of every additional check that a remote transaction triggers, which means fixing it requires knowing which check fired.

Which systems participate in authorization?

Six components touch a card authorization, and only two of them can say yes. The merchant's checkout and gateway build and route the message. The acquirer forwards it. The card network validates and switches it. The issuer's authorization platform decides. Fraud tools on either side advise or block, without ever approving anything.

Separating the routers from the deciders is the diagnostic move most teams skip. A system that only routes will still produce a failure, and that failure looks identical in a summary report to a genuine issuer refusal.

Mastercard's Decision Intelligence scores fraud risk across 125 billion transactions per year at roughly 50 milliseconds each. It evaluates over 500 data points before the message reaches the issuer. So the network is doing substantive analytical work in the middle of your latency budget. When you model authorization timing, treat network-side scoring as a real processing stage rather than transport overhead.

Authorization engines execute decision logic

The authorization engine is the component that turns inputs into an outcome code. It validates message format and mandatory fields and pulls the account record, then calls out to fraud scoring and sanctions screening. It applies the institution's own business rules and collapses everything into approve or decline, with refer and step up to authentication as the other results.

Engines vary in how much they parallelize those calls. A well-built one fires fraud scoring and balance checks concurrently, because card networks enforce response deadlines and a slow issuer gets pushed into stand-in. Enfuce's documentation lists response code 96 as "system malfunction", returned when internal errors or breached scheme response-time limits stop processing.

Which tells you something uncomfortable. Your own timeout is a decline reason with its own code, so latency in a downstream fraud vendor becomes a lost sale attributed to your platform.

Fraud systems assess transaction risk

Fraud systems produce a score and a recommendation. They combine deterministic rules with machine-learning models fed by device fingerprints and behavioral history plus geolocation and velocity counters, then compare the output to thresholds you set.

Those thresholds are where the money leaks. Blocking aggressively feels safe until you measure what it costs on the other side. Datos Insights estimated global lost e-commerce revenue from false declines at $174.38 billion in 2024 and projected $201 billion in 2025.

Compare that against card-not-present fraud losses, which run an order of magnitude smaller, and the tuning question inverts. For most catalogs, the expected loss from a slightly loose threshold is smaller than the expected loss from a tight one. That argues for reviewing your block band quarterly against actual chargeback outcomes rather than treating it as a fixed security setting.

Core banking verifies account conditions

Core banking answers one question: can this account fund this amount right now, and is it allowed to? The check covers available balance net of existing holds and account status. Per-transaction and daily limits apply too, as does overdraft policy together with any legal or internal restriction sitting on the ledger.

Existing authorization holds are the part that surprises merchants. Each open hold reduces available funds, so a customer with money in the account still fails the balance check if earlier holds haven't released. Visa releases card-present holds after 5 calendar days and card-not-present cardholder-initiated holds after 10, while Mastercard runs 7 days for final authorizations and 30 for preauthorizations.

That difference has a practical consequence for anyone running estimated authorizations. A 30-day Mastercard preauth on a rental or hotel booking suppresses the cardholder's spending power for a month, which makes their next purchase with you more likely to fail on funds.

Decision rules follow a defined hierarchy

Authorization logic resolves in a fixed order that starts with mandatory blocks and then account conditions before risk scoring, with authentication used to resolve anything in the middle. Approval happens only when nothing in that sequence objects.

The order isn't arbitrary. Compliance blocks sit at the top because they aren't negotiable against a risk score. A payment matching a sanctions list gets stopped regardless of how clean the fraud model says it is, and US financial institutions must report blocked transactions within 10 business days to the Office of Foreign Assets Control (OFAC).

That reporting duty explains why the hierarchy exists in the shape it does. A regulator-facing obligation with a statutory clock can't be weighed against a probabilistic score, so it gets evaluated first and exits the flow immediately. When you design an engine, model those checks as short-circuit gates rather than weighted inputs, because a scoring architecture that averages compliance signals with risk signals will eventually let something through that it shouldn't have.

Hard rules create immediate declines

Hard rules end the transaction with no path to recovery on the same credential.

They fire on conditions that no amount of authentication or retry will change:

• A closed or frozen account

• An expired card or invalid card verification value

• A transaction type the account is barred from, such as gambling or cross-border spend on a restricted product

• A breached credit line or daily limit that hasn't reset

Retry logic treats these badly. Recurly's research found recovery rates above 45% on the three most common decline messages, but that number is carried almost entirely by insufficient-funds cases, where the best retry window is 2 to 7 days.

So a dunning process that retries every failure on the same schedule is spending its retry budget on credentials that are structurally dead. Split your retry queue by code class before you tune timing, or you'll optimize a window that only helps one bucket.

Risk thresholds create conditional outcomes

Risk scores produce bands, and the middle band is where design choices show up. Below the lower boundary, the payment clears without friction. Above the upper one, it's refused. Between them, the engine either sends the transaction to manual review or steps it up to authentication.

Manual review has quietly shrunk as models improved. Datos Insights reported that 35% of US merchants now manually review just 1% to 9% of card-not-present transactions, though 31% still route 10% to 19% into a queue.

Look at what that spread implies. Two merchants with similar fraud exposure are making review decisions that differ by a factor of ten, which means the band width is a business policy far more than a technical constraint. If you're in the 10-to-19% group, the question worth asking is whether your reviewers are overturning enough of those holds to justify the delay you're adding to legitimate orders.

External responses can override local approval

A merchant-side approval has no authority over an issuer decline, and the asymmetry runs one direction only. Your fraud stack can kill a payment before it leaves your infrastructure. It cannot resurrect one the issuer refused.

The exemption mechanism under Strong Customer Authentication shows the boundary. Only the acquirer can request an exemption from a challenge, and the issuer remains the final arbiter. It can reject the exemption with a soft decline that tells you to step up to a full 3DS challenge, as described in Worldpay's exemption engine documentation.

Read that as a negotiation with a fixed winner. You get to propose, and the issuer disposes. The only leverage you hold is the quality of the data you send with the proposal. Richer transaction context raises the frictionless rate, which is the one lever on your side of the wire that measurably shifts issuer behavior without touching their rules.

Payment rails use different approval models

"Approved" means different things on different rails, and conflating them is how reconciliation breaks. Card authorization is a real-time promise from the issuer that funds are reserved. An ACH acceptance is an acknowledgment that a file was received in good order, with no funds guarantee attached.

Instant payment rails sit at the third pole. Payments over the FedNow Service are final and irrevocable once settled, per the Federal Reserve Board's 2020 service details notice, with interbank settlement occurring in seconds.

So the three rails distribute risk in incompatible ways. Cards give you a reversible promise and ACH gives you an unreliable acceptance you can claw back, while instant payments give you certainty you can never undo. Any platform supporting more than one rail needs separate post-approval handling per rail, because a single "payment succeeded" event abstracts away the exact property your finance team depends on.

Card payments receive real-time authorization

A card authorization travels from the merchant through the gateway and acquirer to the network and issuer, then back, in under a second. The issuer returns an approval code and places a hold against available funds. Nothing has moved yet.

Declines split into two classes that demand opposite responses. Hard declines like lost card or closed account are permanent. Soft declines are temporary, and the same card can succeed on a fresh attempt. Recurly found smart retries alone recover roughly 53% of soft declines.

Half your soft declines are recoverable revenue that most systems throw away because the response code never gets parsed past "failed." If you're logging declines as a single boolean, you've discarded the only field that distinguishes a customer who'll pay in three days from one who never will. Store the raw code.

Account payments follow rail-specific rules

Account-based rails replace real-time issuer authorization with consent, and each rail defines consent differently. Under the UK Open Banking specification, a payment initiation service provider creates a payment-order consent at the account provider and redirects the customer to authenticate. It then calls a separate funds confirmation endpoint for one-off payments.

ACH does none of that. The debit is submitted on the strength of a stored authorization, and rejection arrives days later as a return code. Unauthorized return codes R05 and R07 are in the cap along with R10 and R29, and R51 is in it as well. Nacha caps the unauthorized return rate at 0.5% of debits originated, and a 15% ceiling applies to overall returns.

That threshold is an operational constraint disguised as a compliance rule. Since returns land after you've delivered goods, an ACH program needs its own pre-submission screening to keep the ratio under control, which is a fraud function you'd otherwise assume the rail provided.

Real scenarios reveal the deciding system

Match the symptom to the system, and most mystery declines stop being mysteries.

Here's how the common ones resolve:

• Insufficient funds returns code 51 from the issuer's core banking layer, and the balance check failed after existing holds were deducted.

• Suspicious cross-border spending gets stopped by issuer fraud scoring or network-side analytics before any balance is checked.

• A 3DS soft decline is the issuer refusing an SCA exemption request.

• An ACH debit accepted on day one and returned on day four was never approved by anything, because acceptance and authorization aren't the same event on that rail.

Issuer outages produce the strangest case. Visa converts response codes 91 and 96 to code N0 under forced single-request Stand-In Processing, so the network decides using issuer-configured parameters rather than live account data.

Which means a stand-in approval can exceed a balance the network couldn't see. Treat N0 traffic as a distinct risk population in your reconciliation, because those authorizations were made against stale limits.

Approval does not guarantee settlement

Authorization confirms permission at a single moment. It doesn't move money, and four later stages can still stop you from keeping it, from capture and clearing through settlement to the dispute window that stays open for months.

Miss the capture window and the authorization expires. Most card networks require clearing within roughly 7 days of authorization, after which the hold releases and the transaction fails to clear even though the customer saw a pending charge.

Disputes are the longer tail. Mastercard and Datos Insights project global chargeback volume rising from 261 million in 2025 to 324 million by 2028, with North America growing 16% across that span.

Set against a card approval rate near 80% on card-not-present traffic, that dispute growth reframes what authorization optimization is worth. Squeezing another point of approvals delivers nothing if those marginal transactions come back as disputes six months later. Measure net retained revenue by cohort.

Build stronger payment decisioning with EGS

Fixing a decline problem starts with instrumenting the handoffs between the systems described above, because that's where attribution is lost. EGS builds and modernizes the components in that chain: authorization engines and core banking integrations, plus fraud controls and hardware security module (HSM) supported cryptographic infrastructure for multi-rail financial platforms.

The work begins with a specific question rather than a full rebuild. Which system produced last quarter's declines. Whether your engine can parallelize risk and balance checks inside the network's response window. How to run card and account rails through one decisioning layer without collapsing their different guarantees into a single misleading status.

Book a call with the EGS team to walk through your current authorization flow and identify where the logic can be improved.