13 min read

[#3] The Payment Obstacle Course: Six Stages Where Your Money Gets Stuck Before You Know It (2/3)

[#3] The Payment Obstacle Course: Six Stages Where Your Money Gets Stuck Before You Know It (2/3)

Last week, we broke down the full wall-climbing race that is a modern online payment, from the customer’s first click to the merchant finally getting paid.


If you missed it, check out the handy visual below which maps out all 6 stages a payment climbs through: from merchant-side checks to authorization, settlement, and final reconciliation.

Visual flow of an online transaction

Such a smooth flow, right? Your money gliding effortlessly across six stages from 'Buy Now' to 'Order Confirmed'.

Yeah, this is the fairy tale version.

Today, we’re flipping this map on its head. Because every one of those six stages? It can and does break. Spectacularly.

And when it does, you don't get a helpful error message.
You get silence. Or worse: a lie. (“Payment Successful” with no product delivered.)

Here's the kicker: the vast majority of payment failures happen invisibly. And they're deadly:

  • 5-10% of online payments fail globally, costing merchants billions in lost revenue (source)
  • 15% of valid payments get flagged as fraud, causing 32% of customers stopping to abandon the brand completely (source)
  • 22% of payments drop off during 3DS authentication due to poor UX and time-outs (source)
  • 70% of corporations are frustrated with their payment failure rate (source)

Translation: your "seamless" checkout is probably hemorrhaging money.

You click pay, see "Something went wrong," and have zero clue whether the problem was your bank, the merchant's fraud system, or a network hiccup somewhere in the middle. 

The payment died, but where? And why? 

Time to find out.


Stage 1: The First Ledge (Merchant’s Risk Checks)

Blocked at the Gate: Your Payment Dies Before It Even Starts

Your payment is blocked by the merchant’s own fraud logic and gets rejected before it even leaves their website. Sometimes this is justified but often, it’s overkill. Kinda like an overzealous bouncer.

What’s Actually Happening

Before your payment data even touches the PSP (e.g. Stripe or Adyen), it goes through the merchant’s fraud detection system. Recall from Part 1 that this comprises:

  • Rules engines checking if you're buying too fast, from the wrong place, or acting "weird"
  • Third-party fraud tools (Sift, Signifyd, or whatever Shopify cooked up this week)
  • ML models trying to predict if you're a criminal mastermind 

They're all asking one question: "Is this person trying to steal from us?"

But in their eagerness to block the bad guys, they often shut out real customers too. This is a massive problem for online businesses. Recent studies show that more than half of US customers have experienced false declines, and 43% of retailers consider it a major issue. In 2023, false declines cost US online retailers an estimated $81 billion in lost sales. In many cases, revenue losses exceed those from actual fraud!

⚠️ How it breaks

  • False Positives: Legit customers flagged for behavior that resembles fraud
  • Bad integrations: Third-party tools aren’t integrated properly and don’t provide correct risk signals back to the merchant
  • Overly sensitive thresholds: Blocking based on normal-but-rare behavior (e.g., high cart value on first visit)
  • 3DS overload: Merchant always uses 3D Secure and the friction leads to lower conversion. Customers give up and shop elsewhere

A Personal Example

My brother found a great deal on a gaming laptop (he plays a LOT of Fortnite) from a U.S.-based Shopify store. He then used my credit card to buy it and have it shipped to me in New York, but the transaction just wouldn’t go through.

See in this case, the merchant’s fraud engine saw:

  • First-time user, and that too from Pakistan
  • IP & billing address mismatch
  • High-value electronics
  • Different shipping country

Boom. Blocked outright. He kept seeing a useless "Transaction failed" message. No explanation. No recourse. Ultimately, he went on Amazon and bought the same laptop in 30 seconds.

That Shopify merchant spent thousands on ads to acquire a customer, sweetened the deal with a non-trivial discount, and then had their own fraud system block him out at checkout 🤦.

🛠️ Quick Fixes

  • Avoid hard declines. Use 3DS as a fallback when unsure (but don’t always use 3DS! It can kill conversion by anywhere from 3-15+% - source1, source2)
  • Actually review who you’re blocking (spoiler: it can totally be some of your best customers!)
  • Update fraud logic with post-transaction labels (i.e. was this fraud or not?)
  • Log and monitor fraud tool outages just like payment outages

🧗‍♀️ The Climb Continues...

Congratulations, you passed the paranoid bouncer. Your payment now heads to the Payment Service Provider (PSP), who has to figure out where to send it next (spoiler: this, too, can go wrong).


Stage 2: The Route Selection (Payment Service Provider → Merchant's Bank)

Smart Payment, Dumb Route: When PSPs Pick the Scenic Path to Failure

Your payment clears the merchant’s checks and reaches the PSP (Stripe, Adyen, Checkout.com). But now it fails on the way to the card networks because of suboptimal routing decisions or acquirer-level issues. Think of this like your GPS routing you through a closed road to save 2 minutes.

What’s Actually Happening

Once the PSP gets your payment data, they need to route it to an acquirer. See Part 1 for a refresher on routing intricacies.

The problem is that sometimes PSPs optimize for their own margins, not for payment success. It’s not malicious, it’s just that optimizing for margin is simpler and higher leverage for them unless you explicitly push for payment success optimization. 

A lot of merchants are on default settings (and don’t even know routing is customizable!), and real-time conditions (e.g., latency, traffic) shift faster than routing logic updates, especially with static routing. 

⚠️ How it breaks

  • Geographic mismatch: US Visa card routed through European acquirer (spoiler: usually fails)
  • Stale performance data: PSP routes to an acquirer that worked great last month but is struggling today
  • Missing metadata: CVV or 3DS data is lost in transit, causing declines downstream
  • Cost over success: PSP saves 0.05% but your payment fails 15% more often

🛠️ Quick Fixes

  • Monitor decline rates by route, card type, and region. Trust me - you'll be shocked at the variance!
  • Ask your PSP about routing logic and push for performance-based routing over cost-based
  • Ensure smart routing features (Stripe Adaptive Acceptance, Adyen RevenueAccelerate) are turned on if your PSP offers them
  • Consider multi-PSP setups for critical transactions

This is one of the most misunderstood points of failure because technically, nothing was broken. The PSP just chose a suboptimal route. But in payments, suboptimal = silent failure.

🧗‍♀️ The Climb Continues...

If routing succeeds, your payment reaches the acquirer. Now it needs to navigate through the card networks to your issuing bank. This is where the technical complexity really ramps up.


Stage 3 The Technical Traverse (Acquirer → Network → Issuer)

Lost in Transit: When Your Payment Disappears Into the Card Networks

Your PSP routes the payment correctly but somewhere between the acquirer, the card network, and your bank, it just… vanishes. No decline, no approval. Just a silent drop-off into the ether. You’re left scratching your head at a useless “Something went wrong” message, with no clue wtf happened.

What’s Actually Happening

Welcome to the actual plumbing of global payments. This step is all about structured handoffs between giant, high-speed, high-stakes systems:

  1. The acquirer (often Stripe or Adyen themselves in most modern setups) formats and sends your payment
  2. The card network (Visa, Mastercard, Amex) validates and routes it to your bank
  3. Your bank (issuer) receives it and makes a final decision

It’s like a high speed relay race with zero room for error and lots of places to fail.

⚠️ How it breaks

  • Data missing: Missing 3DS status, incomplete metadata, or forgotten fraud flags cause the issuer to reject or time out
  • Data formatting: Acquirer formats data incorrectly (bad currency codes, missing fields, invalid merchant category codes (MCCs)). Network rejects it before your bank even sees it
  • Network rules violation: Certain merchants or card types aren’t allowed to interact (e.g., using a corporate card on a gambling website, trying to use a pre-paid transportation debit card to buy groceries)
  • Network issue: Visa or Mastercard have bad days too. Rare, but when they have even a second of downtime, thousands of payments vanish

The worst part? Many of these failures never show up in your analytics. Your PSP might log them as "network error" or "issuer unavailable," when in reality, your payment never even made it to the issuer in the first place.

💥
One Second. 30,000 Failures

Visa handles 250 billion payments per year which means up to 30,000 payments per second at peak speed.

If the network blips for just one second, that’s 30,000 payments gone.No decline code. No response. Just… vanished.

Your customer sees: “Something went wrong.”You lose the sale.And that’s just Visa.

A Personal Example

I was trying to buy tickets for my parents from a small Saudi-based airline with a somewhat shitty website (the best harbinger of impending payment failure…). My Chase Sapphire failed twice with ‘Payment could not be processed’. I call Chase and they tell me they never received any payment request.

My guess? The payment was failing somewhere in the network path from the PSP to Chase via Visa. I tried my Wells Fargo card, which uses the Mastercard network, and it worked instantly. Same merchant, same amount, different network path. 

🛠️ Quick Fixes

  • Demand raw network response codes from your PSP, not just pretty error messages (most don’t expose raw network-level logs by default, but they totally can!).
    • In a similar vein, push for access to scheme-level response codes (i.e. the actual Visa/Mastercard errors, not just issuer codes).
  • Monitor the percentage of failures tagged as "No response" or "Processing error". These are hiding network-level drops.
  • If you’re big enough and/or your transactions are critical enough, consider implementing a backup PSP with different network routes.

🧗‍♀️ The Climb Continues...Congratulations, your payment survived the network gauntlet and actually reached your bank. Your bank should always know and approve when it’s actually you…right?


Stage 4: The Summit Decision (Your Bank Says Yes or No)

The Final Boss: When Your Own Bank Pulls an ‘Et Tu Brute?’ on you

Your payment made it through merchant checks, PSP routing, and network transit. It's literally at your bank's doorstep. And then in just a few hundred milliseconds, your own bank, holding your own money, says no. They sometimes do this for good reasons, often for stupid ones, and almost always with zero useful explanation 🤦

What's Actually Happening

Your issuing bank (Chase, Bank of America, that local credit union you thought was cool) receives the authorization request and in under ~400 milliseconds decides: approve or decline?

The bank evaluates a massive set of signals:

  • Account & Fund checks: Do you have money? Is your card active? Are you over your limit?
  • Risk analysis: Is this transaction normal for you? (Amount, location, merchant type, time of day)
  • Business rules: Daily limits, international blocks, merchant category restrictions
  • Technical validation: Is all the data correct? Does everything match?

Sounds reasonable, right? Except banks are notoriously conservative and their systems are often older than your favorite old school movie.

⚠️ How it breaks

  • Overzealous fraud detection: Your bank sees a slightly odd purchase pattern and flags it as suspicious (e.g. first time buying from a merchant, International transaction, large purchase etc.).
  • Outdated cardholder data: You moved but your bank thinks you're still in Ohio.
  • Random bank preferences: Weird merchant name (the issues I’ve seen unicode characters cause…), misformatted 3DS info, or higher decline rates for cross–border online transactions.

A Personal Example: My Three-country Card Chaos

At one point, my US credit card was being used by me in Pakistan, my brother in Qatar, and my parents in Saudi, all at the same time. 

Apple Pay, physical card, different devices, different countries.

Naturally, Chase freaked out with random declines almost daily 😂The last straw? Getting declined trying to buy some piping hot samosas.

Finally called Chase, spent 20 minutes explaining that my family is scattered across the Middle East, not running an international fraud ring. They finally added a note to my account.

No failures since 🤞 ...but I'm still bitter about that samosa.

🛠️ Quick Fixes

  • Track decline codes to spot patterns (issuers send descriptive decline codes but merchants show generic ‘Payment Failed’ - easy UX win to be had) (see Part 1 for some common decline codes!)
  • Track decline rates by Bank Identification Number i.e. BIN (first 6 to 8 digits of a credit, debit, or prepaid card number) to identify problematic issuers
  • Build retry capabilities so you don’t lose the transaction. Both issuer-specific retry logic and "try another card" flow as a backup
  • For high-value transactions or international users, consider pre-auth flows or friendly failure message alongside priority support if payment fails

Here's the thing: you can optimize every other step, but if issuers keep declining legitimate transactions, you're stuck. The best merchants know this and have built entire strategies around issuer psychology.

🧗‍♀️  The Climb Continues...

If the bank says yes, you’re not done yet. The funds are still in limbo, and the payment has to travel all the way back through the same chain in reverse. Even then, things can still go wrong…


Stage 5: The Descent (Response Journeys Back)

Payment Approved… But Where’s My Confirmation?

Your bank says yes. Victory, right? Wrong.Before the merchant sees that glorious “Payment Successful” message, the approval needs to boomerang back through the entire chain: Issuer → Network → Acquirer → PSP → Merchant App → You.

And if any link in this chain breaks, you get the worst of both worlds: payment approved but unconfirmed, money on hold but no order confirmation, and both the merchant and customer wondering what just happened.

What’s Actually Happening

Once your bank approves:

  • It places an authorization hold (money reserved, not moved)
  • A response is generated and sent backward through the same chain
  • Each system needs to receive, process, and pass it along
  • The merchant receives this success signal and updates the UI (“Your order is confirmed!”)
  • You, the customer, breathe a sigh of relief

Except this return journey is just as fragile as the original climb.

⚠️ How it breaks

  • Timeout on the return trip: The bank approves, but the response times out before reaching the merchant because some step(s) took too long. Your funds are on hold, but the merchant thinks the payment failed.
  • Merchant system error: The merchant’s frontend or backend crashes. They never receive the success message or don’t parse or log it properly. The transaction was approved, but the customer sees “try again later.”
  • Duplicate/ambiguous state: Merchant shows failure, then gets a delayed success message. Now they’re unsure whether to fulfill the order or not.

A Personal Example

Last year, I was booking a last-minute hotel at 2 AM (classic poor planning). My card was approved & I saw the charge hit my pending transactions), but the booking page crashed right after I hit pay.No confirmation email. No booking ID. Just a useless “There was an error” message.

Called the hotel & they had no record. Called Chase & the funds were authorized and on hold. I had to book a different hotel while my money sat frozen for 5 days until the auth expired.

The payment worked. The response didn't. I paid for a ghost room.

💡
The Authorization Trap

Just because funds are on hold doesn't mean:

- The merchant knows about it
- You'll get what you ordered
- The transaction will complete

This zombie state (‘approved but unconfirmed’) is the most frustrating failure mode in payments.

🛠️ Quick Fixes

  • Use webhooks with retries: Don’t rely only on synchronous responses (i.e. use async confirmation with retries)
  • Design for ambiguity: Say “We’re confirming your payment…” not “Payment failed.” when unsure. Avoid lying to the user.
  • Build reconciliation systems to match authorizations with actual orders
  • Set up alerts for mismatches between auth approvals and frontend confirmations. This is especially critical during sales spikes or outages

🧗‍♀️ The Climb Continues...

If the response makes it back cleanly, the merchant knows you’ve paid.. But that money still isn’t theirs. Not until they capture it and the settlement flow begins, where a whole new set of failures await…


Stage 6: Claiming The Prize (Capture & Settlement i.e. funds actually move)

‘Payment Successful’... but nobody got paid yet

Your screen says “Payment Successful.” The merchant starts packing your order.
But here’s the twist: no money has moved.
Until the merchant explicitly ‘captures’ the payment and it settles through the banking system, the funds are just floating in limbo. 
If something breaks now, nobody gets paid (and yes, this happens more often that you’d think)

What’s Actually Happening

Let’s recap:

  • Your bank approved the transaction and placed a hold
  • The success message made it back
  • You see ‘Order Confirmed’

But that’s just a promise to pay. Now, the merchant needs to:

  1. Send a capture request ("I want my money now")
  2. Your bank removes the hold and initiates the transfer
  3. Wait for settlement (typically 1-3 business days)
  4. Funds travel via the card network from your bank to the acquirer
  5. Acquirer sends them to the merchant’s bank

See, when you click Pay and see “Payment Successful”, it's like giving the merchant an IOU not cash. Usually that IOU gets cashed. But sometimes…it doesn’t.

⚠️ How it breaks

  • Capture never sent: Yes, this happens. Merchant forgets or their system never triggers the capture request.
  • Capture job errors: The merchant’s systems could error out during batch capture. Especially common in systems that queue captures for later processing (e.g. after shipping)
  • Amount mismatch: Merchant tries to capture more/less than what was authorized amount. Rejected. Happens a lot with tips, taxes or currency conversions.
  • Capture delay → auth expires: Holds expire in 7 - 30 days. If you wait too long, the funds unlock and you lose the right to collect.

And since the customer thinks the payment went through (and likely already has the product), you're out of both the item and the money.

Stage 6 errors are rarer than failures in routing, network transit, or issuer logic, but when they do happen, they can quietly cost merchants big. They are more likely to happen around high-traffic operational spikes. And they are especially dangerous because most never monitor for these thinking “everything already succeeded.”

🛠️ Quick Fixes

  • Use automatic capture on fulfillment if your model allows e.g. digital goods, subscriptions
  • Set up alerts for uncaptured authorizations nearing expiry
  • Build daily reconciliation jobs to match captures against authorizations
  • Log and monitor capture failure rates, especially during high volume spikes

🧗‍♀️ The Climb Concludes... For Now.

The funds finally moved. The merchant is paid. You got your stuff!


The Plot Twist: You Can Actually Fix This

Let’s be real: this entire Rube Goldberg machine succeeded despite its complexity, not because of its elegance. 

Every step is a potential point of failure, held together by decades-old infrastructure and hope.

Most businesses treat payments like plumbing. Invisible infrastructure you only think about when it breaks. But the smartest ones? They treat it like a growth engine.

They know that every percentage point improvement in payment success rates drops straight to the bottom line. They know that customers who hit payment friction once are 70% less likely to complete future purchases. And they know that while their competitors are losing millions to invisible failures, they're capturing every dollar.

The best part? Most of these fixes aren't rocket science. They're just rarely talked about.

So buckle up for Part 3. We're about to turn you into the person who actually knows where payments break and more importantly, how to fix them before they cost you another sale.

Until then, may your payments be swift and your declines be... well, non-existent. 🚀