How Stripe payment processing works

The Problem Statement

Interviewer: "A user types their card number into your checkout page and clicks Pay. Walk me through every system that card number touches, who authorizes the charge, who actually moves the money, and where Stripe fits in the chain."

This question tests whether you understand the financial plumbing behind online payments. The interviewer is not looking for a Stripe API tutorial. They want to see that you know the six actors in the payment chain, that authorization and settlement are separate steps separated by days, and that you can reason about failure modes at every hop.

Candidates often stumble here because they treat Stripe as a black box. They say "we call the Stripe API and money moves." That answer misses the acquirer, the card network, and the issuer. It also misses the fact that charge.succeeded fires before any money actually moves.

The double-charge problem alone makes this worth understanding deeply. A double charge is one of the worst things that can happen in e-commerce. The customer sees two charges on their statement, calls their bank, files a chargeback, and you lose the revenue plus a $15-$30 chargeback fee. At scale, unhandled double charges lead to elevated chargeback rates, which can get your merchant agreement terminated. This is a business-critical problem, not just a technical curiosity.

Clarifying the Scenario

You: "Great question. Before I walk through the full flow, let me scope this out."

You: "When you say 'every system the card touches,' should I cover the full lifecycle from authorization through settlement, or just the real-time part?"

Interviewer: "The full lifecycle. I want to understand when money actually moves."

You: "Got it. And should I include 3D Secure (the extra verification step), or keep it to a standard card payment?"

Interviewer: "Start with the standard flow, then mention 3D Secure as an extension."

You: "One more thing: should I cover refunds and chargebacks as separate flows?"

Interviewer: "Briefly. I am more interested in the happy path and settlement timing."

You: "OK. I will structure my answer in four parts: the six actors and their roles, the authorization-capture split (the real-time part), settlement and when money moves, and the role of webhooks and eventual consistency in Stripe's event model."

My Approach

I break this into five parts:

1. The six actors: Cardholder, merchant, gateway (Stripe), acquirer, card network, and issuer. Every card transaction passes through all six.
2. Authorization: The real-time "is this card good?" check that happens in under 2 seconds.
3. Capture and settlement: The batch process where money actually moves, typically T+2 business days after the charge.
4. Webhooks and eventual consistency: Why charge.succeeded does not mean money is in your bank, and how to build reliable systems on top of async events.
5. PCI compliance and tokenization: Why the card number never touches your server, and how Stripe's tokenization model keeps you out of PCI scope.

The core insight is this: card payments are not a single operation. They are a two-phase commit spread across six organizations, with the authorization happening in real time and the settlement happening in batch, days later. Most engineers think of payment as "send money," but it is really "reserve funds now, move funds later."

Let me give you the numbers that make this concrete. Stripe processes hundreds of millions of transactions. Network timeouts between your server and Stripe's API happen at a rate of roughly 0.1-0.5% of requests. At 100,000 payments per day, that is 100-500 ambiguous transactions where you do not know if the charge went through. Without idempotency and proper state tracking, each of those could become a double charge or a dropped order.

Every card transaction passes through all six actors. Skip one in your interview answer, and the interviewer will notice.

The Architecture

Here is the full chain from the moment a customer enters their card number through final settlement.

Let me walk through each phase.

Phase 1: Tokenization (client-side). The card number is entered into Stripe Elements or Stripe.js, which runs in the browser. The raw card number goes directly from the browser to Stripe's servers over HTTPS. Your backend never sees the full card number. Stripe returns a one-time token (tok_xxx or pm_xxx) that your backend uses for subsequent API calls.

Phase 2: Authorization (real-time, under 2 seconds). Your backend sends the token to Stripe's /v1/payment_intents endpoint. Stripe forwards this to the acquirer bank (the merchant's bank), which forwards it to the card network (Visa, Mastercard), which forwards it to the issuer (the cardholder's bank). The issuer checks: does the card exist, is it active, is it reported stolen, does the cardholder have sufficient credit or funds? If yes, the issuer places a hold on the amount and returns an authorization code.

Phase 3: Capture. For most Stripe integrations, capture happens automatically at the time of authorization (capture_method: automatic). But hotels, car rentals, and tip-based businesses often separate auth from capture. The hotel authorizes $200 at check-in, then captures $180 at checkout. The remaining $20 hold releases after 7 days.

Phase 4: Settlement (batch, T+1 to T+3). At end of day, the acquirer batches all captured charges and submits them to the card network. The network debits each issuer and credits the acquirer through a net settlement process. The acquirer then credits Stripe, and Stripe deposits funds into the merchant's bank account. This is the actual money movement, and it typically takes 2 business days in the US.

The Authorization-Capture Split

This is the deep dive that separates a surface-level answer from a strong one. Most candidates say "the card gets charged." In reality, authorization and capture are two separate operations, and understanding the split is critical for building correct payment systems.