#2: The Hidden complexity behind 'Payment Successful'

Last week, my card got declined buying a Frozen-themed mug for my little sister. I tried three times before getting frustrated and giving up. I’d made the mistake of hyping up my sister (it was a present for acing an exam) and it was not fun to see her disappointed.

That awkward moment made me realize that I’ve spent years in payments, and yet I can’t easily point to a resource explaining what might have gone wrong. 

So today, we’re fixing that.

Welcome to the issue #2 of DMP - part 1 of a 3 part-series decoding how modern payments actually work. We’ll build a mental model for online payments, explore why they fail, and learn how the best product teams handle them

❗This is a foundational explainer and a longer read. Bookmark it. Reference it. Share it with your team when payments inevitably break.

Let's dive in!  

The Most Important Payment You’ve Never Had Explained To You

I counted last week: 92% of my payments involved typing card numbers into a box. Not swiping, not tapping, but typing. These payments where you enter card details online or over the phone? They're called card-not-present (CNP) payments. 

Every Uber ride, every Amazon order, every Netflix subscription, and that Chinese takeout you ordered last night – all CNP. As the name implies, CNP is when neither the user nor the card is physically present.

To contrast, some other popular forms of payments are card-present payments (where you swipe/tap/insert chip into a machine in-person), bank transfers, digital wallets, buy-now-pay-later i.e. BNPL (Klarna, Afterpay), Crypto, and some local methods. 

Interesting things to know about CNP payments:

• CNP payments account for 70% of all card fraud globally (source)
• Mastercard predicts global CNP losses will hit $28 billion by 2026, marking a 40% jump from 2023.
• CNP fraud is actually very costly. When someone steals $100 through CNP fraud, merchants actually lose $360 (source). I’ll explain why in a future issue!
• Merchants are charged higher fees for CNP payments due to the higher fraud risk & more processing overhead e.g. Stripe charges ~2.9% + $0.03 for a card-not-present payment vs ~2.7% + $0.05 for an in-person (card-present) transaction  

Source   

CNP payments are the foundation of modern ecommerce and SaaS.
They’re also more fragile, expensive, and failure-prone than most builders realize.

That’s why today, we’re going to break down what actually happens when you enter your card info online and click “Pay”. 

Let’s decode it!

Your Payment Is A Rock Climber

We learn best through analogies, and the analogy I want you to keep in mind through this is rock climbing. 

Picture your payment as a speed climber in competition. 

Starting at the bottom, it must scale seven distinct stages to reach the summit. Our goal is to reach the summit and descend safely.  

Only if you reach the top and make it down safely does the system mark the payment as “successful.”

A slip on the way up = decline.

A fumble on the way down = timeout or unknown error.

Either way, you see the same thing: “Payment Failed”

You’ll see it’s kind of a miracle how rarely payments fail.

Stage 0: At the Starting Line

You’re prepping your gear. The climb is about to begin.

You add that hoodie to your cart, type in your card details, and click “Pay Now” 

The merchant collects all the data it needs:

• Your personal details (name, billing address)
• Your card details (number, expiry, CVV)
• Metadata (your IP address, your device fingerprint, the time of the day, and 100+ other data points you never think about etc.)

This data becomes your climbing gear. Miss one piece, and you won't make it past the first ledge.

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

Think of this step as getting your hand firmly on the first solid ledge. You need this ledge to pull yourself off the ground and actually start climbing! 

The merchant itself performs initial risk checks before forwarding your payment to the payment service provider (PSP)

The first obstacle your payment can expect to run into is fraud checks by the merchant app itself. A sketchy dropshipping site might wave you through blindly. But a proper Shopify store? They're running sophisticated checks:

• Velocity: "Why is this customer attempting 5 purchases in 30 seconds?"
• Email + Phone Heuristics:"xyz@tempmail.com? That's a disposable email. Flag it."
• Geographic Mysteries: "Device in Mumbai but billing address in Miami? Suspicious."
• Behavioral patterns: "First-time customer buying $2,000 of electronics at 3am? Let's verify."       

A properly built Shopify store might be even more sophisticated, using either Shopify’s own native ‘indicators’ or leveraging one of the many Fraud Protection aps from Shopify’s marketplace (e.g.), which can have hundreds of pre-defined or custom ‘risk signals’ 

Failure case:

The merchant spots something fishy and either blocks you outright OR triggers 3D Secure – that annoying pop-up asking for a code from your bank.. Basically, it’s the merchant asking your bank ‘Hey, you double check this guy is who he says he is before we let the payment move forward’.  

It would be correct to think of 3DS as the merchant shifting liability to the cardholder’s bank in case of fraud i.e. when merchants use 3D Secure and fraud still happens, the bank eats the cost, not the merchant. But it also increases cart abandonment by 20-30%. Classic payments trade-off.

Success case:

You pass the sniff test. Your payment data gets bundled and sent to the Payment Service Provider (PSP).

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

You’ve got a solid grip on the wall. The first obstacle is behind you. 

You now scan the path upward, and decide which ledge you’re going to climb onto next. There’s more than one route, and choosing the wrong one could mean a slip, a stall, or a total failure. 

The merchant passes your payment to the Payment Service Provider (PSP), think Stripe, Adyen, or Checkout.com, who then routes it to the merchant’s bank.

The PSP takes your payment and decides how to send it forward to your merchant’s bank (called the acquirer). Your payment can take dozens of different paths to approval. The PSP is playing 4D chess in milliseconds:

• Route through Bank A or B?
• Stay domestic or go cross-border?
• Use the expensive reliable route or risk the cheap one?
• Is this a high-risk transaction that needs extra screening and metadata?

📡 This is called routing — and it’s one of the biggest hidden levers in payments.

Routing hides much more complexity than you’d think, and is often ignored until a business hits scale, international markets, or unexpected decline rates: 

A good route means faster processing, higher approval odds, and lower fees. A bad one? Delays, declines, or silent drop-off. A 1% approval rate improvement = $100K+ monthly revenue for a mid-size brand. At Amazon scale? Routing optimization is worth tens of millions annually. There are entire product teams whose only job is tweaking routing logic!

Routing is based on:

• Card type (Amex, Visa, debit, corporate)
• Geography (local acquirers improve approval rates)
• Past performance (ML models trained to select faster or more reliable bank for that card)
• Cost or risk (some paths carry higher decline rates or fees)
• A/B testing across routing paths over time

Tools like Adyen’s RevenueAccelerate and Stripe’s Adaptive Acceptance are designed specifically to allow merchants to customize payment routing.

Failure case:

PSP selects a suboptimal route. Maybe they send your US card through a European processor (higher decline rates). Maybe the bank they chose is having a slow day. You get "Payment Failed" and probably abandon that cart forever.

Success case:

Optimal route selected. Your payment flows smoothly to the merchant's bank, ready for the technical climb ahead.. No delays and higher chances of approval.  

Stage 3: The Technical Traverse (Merchant’s Bank → Network → Cardholder’s Bank)

You’ve made it past the risky scramble from the base, and are now climbing to the summit. This is the most technical part of the climb. Every move matters.

You will need to climb a sequence of tight, unforgiving ledges. Staying nimble, staying precise, and moving fast while carefully navigating each ledge.

Your transaction moves between three massive institutions in under a second. The merchant’s bank (sometimes also called the acquirer) passes your payment to your bank (called the issuer) via an appropriate card network (e.g. Visa, Mastercard, Amex) for the issuer to make a final approve or deny decision.  

First Stop: The Merchant's Bank (Acquirer)

After receiving the payment from the PSP, the merchant’s bank (acquirer) basically acts as a translator + quality control officer preparing the payment to move across standardized rails. The acquirer:

1. Formats and validates the payment (e.g. right structure, required fields, ISO 8583 etc.)
2. Adds IDs & Metadata like merchant info, fraud scores, or 3DS results
3. Performs Sanity Checks (e.g. is the merchant account active? are limits exceeded?)
4. Logs the Transaction for traceability and reconciliation in their system

Second Stop: The Network (Visa/Mastercard/Amex)

After getting the properly formatted and validated payment from the merchant’s bank, the network:

1. Identifies your bank using your card’s first 6-8 digits (called the BIN)
2. Formats and forwards the request to the correct cardholder bank (i.e. issuer)
3. Applies scheme rules (e.g., merchant category restrictions, velocity/risk checks)
4. Logs the transaction for traceability and future reconciliation

Think of it as a bullet train system: tickets validated, correct track selected, full speed to destination.

Failure case:

Network hiccup. Timeout. Misrouted transaction. Your payment never even reaches your bank for a decision. Lost in the void.

Success case:

Clean handoffs. Your payment arrives at your bank's doorstep, properly formatted and ready for judgment.

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

You’ve reached the summit ledge. This is the moment of truth. The judge takes a hard look at you, evaluating you and your climb.

This is where your bank receives the payment request and has 400 milliseconds to evaluate 100+ signals to make the final call: approve or decline.

Your bank considers:

• Authentication: Is this card valid and active?
• Authorization: Is there enough credit or balance?
• Fraud Detection: Does this transaction match the customer’s behavior?
• Risk Modeling: Does this transaction look similar to past fraud attempts?

Banks use internal models, customer behavior history, and often external data (device fingerprint, 3DS results, geo-location, etc.).

They return a simple answer: Approved or Declined, along with a response code.

Issuer decline codes are interesting. They don’t just say ‘no’ but rather return a decline code, which is a short numeric or alphanumeric reason code that tells the merchant (or PSP) what went wrong e.g.

• 05: ‘Do Not Honor’ (generic decline, could be anything)
• 14: ‘Invalid Card Number’ (typo, fake, or expired)
• 51: ‘Insufficient Funds’ (not enough money)
• 07: ‘Pick Up Card’ (OH SHIT IT’S STOLEN)

These codes are meant for machines, not humans. Meaning a customer will only see a generic ‘Transaction failed’, even if the reason was low balance or an expired card. Personally, I’ve always felt there’s an opportunity for product teams to increase transparency on the causes of failures and yield lower cart abandonment rates…

Failure case:

Declined. You see ‘payment failed’, and maybe abandon the checkout entirely. Could be no money, expired card, or just their ML model having a bad feeling about this specific transaction pattern.

Success case:

Approved! Your bank places a hold on the funds. But we're not done yet…

Stage 5: The Descent (Response Journeys Back)

You’ve reached the summit & the judge has given you the nod! But you still need to climb back down safely, and claim your medal. 

Just like your medal is reserved for you but not yet claimed by you, the funds are now on hold, but not yet sent to the merchant.

Your bank places an authorization hold on the money (basically setting them aside) and sends the approval response back through the same chain (Issuer → Network → Acquirer → PSP → Merchant → Your Screen). You see ‘Payment Successful’ and the merchant fulfills the order, but they haven’t actually been paid yet.

Once a payment is approved:

• The issuer creates an auth hold (e.g., $100 is reserved, and your available balance is reduced by $100)
• A response is sent back down the chain:
  • Issuer → Network → Acquirer → PSP → Merchant App → Your Screen
• The merchant receives confirmation and updates the UI (e.g., “Payment Successful”)
• The funds are not yet moved

This hold typically lasts 7–30 days, but the merchant will usually capture (settle) the funds within 1–2 days (see step 6!)

Failure case:

Things can still go wrong! If one of the parties in the return path experience a delay or error (e.g., timeout at PSP or the merchant app fails to parse the response), we could see a situation where your money is frozen in limbo (and your available balance is reduced) but the merchant never gets a confirmation and doesn’t fulfill the order. You refresh frantically. Support tickets are filed. Transaction Lost. Trust eroded.

Note in such cases, the hold would remain on the your card until it expires or is manually released

Success case:

Clean descent. You see "Payment Successful!" The merchant starts packing your order. But here's the twist – no money has actually moved yet.

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

You walk up to the podium and finally grab your medal! 

After the payment is authorized, the merchant must explicitly ‘capture’ the payment (usually after order confirmation or fulfillment).
Once captured, the customer’s bank sends the funds to the merchant’s bank account.
This is settlement i.e. when the money actually moves.

Authorization only holds the funds but the money isn’t moved until the merchant sends an explicit “capture” request to finalize the transaction. Capture requests are often batched at end-of-day or triggered post-fulfillment.

Settlement begins after capture:

• Your bank deducts the money from your account
• Money flows through the card network
• Money is lands in the merchant’s bank account 1-3 days later (minus fees)

In modern PSPs (like Stripe), the capture is often automated, but it’s still a separate API call or step under the hood!

Failure case:

Merchant forgets to capture (yes, this happens). Your authorization expires after 7-30 days. Money was locked for nothing. Nobody gets paid.

Success case:

Capture → Settlement → Everyone gets paid. The beautiful machine works.

The One Thing to Remember

Every online payment climbs through 7 stages in under 2 seconds.
One stumble = decline.
The miracle isn't that payments fail, it's that they ever work at all!

So that declined mug payment? Could've failed at any of these seven stages. Most likely: My bank's fraud model flagged that I was transacting from Pakistan, when I live in the US. Or the mug store’s backend system garbled the routing. Or, and this happens more than you'd think, someone typed my card number wrong 🤦

What's Next

Next week, we'll dive deep into why these failures happen and what the best product teams do about it. Spoiler: It's not what most builders think.

Before you go:

• Forward this to someone who doesn’t understand why payments are "so complicated"
• What's your CNP vs other payment ratio? (Mine was 92% CNP last month)
• Ever had a payment mysteriously fail? Now you know why!

See you next week for Part 2: The Hidden Failure Points That Kill Your Conversion. Subscribe to get it in your inbox!

Building something in payments? Hit reply. Always happy to chat payments puzzles!

P.S. That mug payment never went through but I took her to watch the live-action How To Tame Your Dragon. Great movie. And then my card declined when paying the parking fee. Payments, man.