Payment System Design at Scale

Source: Dev.to

What really happens when Maria taps “Confirm Ride”?

Maria has an important meeting in 15 minutes.
She doesn’t have cash.
She opens Uber, requests a ride, gets dropped off.

The payment? Invisible. Instant. Effortless.

But behind that single tap is one of the most complex distributed systems in modern software.

Today we’re breaking it down – not just “how to charge a card,” but how to build a secure, reliable, scalable payment system that can process millions of rides per day.

The Illusion of Simplicity

From the user’s perspective:

Trip ends → $20 charged → Done

From the backend’s perspective:

• Securely collect payment details
• Avoid storing sensitive card data
• Prevent fraud
• Handle bank outages
• Split money across multiple parties
• Maintain financial correctness
• Reconcile mismatches
• Survive retries and timeouts
• Support global scale

This is not a feature. This is infrastructure.

1️⃣ The First Problem: You Can’t Store Card Data

When a user enters:

• Card number
• CVV
• Expiry

Storing it directly means:

• Heavy PCI‑DSS compliance
• Massive breach risk
• Legal exposure

Solution: Tokenization

1. The mobile app integrates a payment‑provider SDK (Stripe, Adyen, etc.).
2. The SDK sends card data directly to the provider.
3. The provider returns a token.
4. You store only that token.

The token is a reusable, scoped permission to charge the card. If it’s stolen, it’s useless outside your merchant account. Security solved (mostly).

2️⃣ Authorization vs. Capture (Where Things Get Subtle)

When the ride ends you don’t just “charge.” You typically:

1. Authorize – check if the card has funds and lock the amount.
2. Capture – actually move the money.

Why split it?

• The ride price may change.
• You may need to adjust the final fare.
• You don’t want unpaid rides.

Large systems often authorize early (estimated fare) and capture later (final fare). A small detail with massive architectural impact.

3️⃣ The Money Doesn’t Go Rider → Driver

The rider does NOT pay the driver directly. Instead:

Rider → Uber Merchant Account → Split →
    → Driver
    → Uber Commission
    → Taxes
    → Fees

Why?

• Commission control
• Tax handling
• Dispute handling
• Fraud protection

Direct peer‑to‑peer payments would break accounting.

4️⃣ The Hidden Hero: Internal Ledger System

You cannot rely on your payment provider as the source of truth. Build your own ledger service.

A simplified double‑entry example:

Every movement is recorded. Double‑entry ensures money cannot disappear. If debits ≠ credits → something is broken. At scale, this is the difference between “works fine” and “lost $3 M silently.”

5️⃣ Reliability: External Systems Will Fail

Your payment system depends on:

• Banks
• Card networks
• Payment providers
• Network calls

All of them can fail. A common nightmare:

1. Authorization succeeds.
2. Capture request times out.
3. You retry.
4. Customer gets double‑charged.

Solution: Idempotency keys

• Each payment attempt includes a unique key (e.g., ride_id).
• If retried, the provider recognizes the key and avoids duplicate processing.

Without idempotency you’ll double‑charge users and lose trust.

6️⃣ Smart Retries (Not Blind Retries)

Blind retries create chaos. Intelligent retries create resilience.

7️⃣ Fraud Layer (Before Money Moves)

Before charging, run:

• Velocity checks
• Device fingerprinting
• Location mismatch detection
• Behavioral anomaly detection

If something looks suspicious, trigger:

• 3‑D Secure
• OTP verification
• Manual review

Payment systems are also fraud systems. Ignoring this will let chargebacks destroy margins.

8️⃣ Refunds Aren’t Simple

Refunding isn’t just “reverse the transaction.” It requires:

1. Updating the internal ledger
2. Issuing a refund request to the provider
3. Adjusting the driver’s balance
4. Handling payouts that may have already been completed

Sometimes the platform absorbs a temporary loss. Complexity compounds over time.

9️⃣ Driver Payouts: A Different System

Charging cards is one system. Paying drivers is another.

Typical flow:

• Aggregate earnings daily
• Settle weekly (or offer instant payout for a fee)

Uses bank rails like ACH, SEPA, etc., which are completely different from card networks. Two financial systems under one product.

🔟 Reconciliation (Where Adults Work)

Every night:

1. Pull reports from the payment provider.
2. Compare with the internal ledger.
3. Identify mismatches.

If a mismatch is found:

• Flag for review
• Trigger investigation

Without reconciliation, small inconsistencies compound into millions.

1️⃣1️⃣ Scaling to Millions of Rides

At high scale:

• 1 M+ rides/day
• 1 000+ transactions per second at peak

You need:

• Stateless payment services
• Event‑driven architecture
• Message queues (Kafka, Pub/Sub, etc.)
• Horizontal scaling

Instead of a synchronous “Ride → Immediate Charge,” use a decoupled flow:

RideCompleted Event → Payment Queue → Worker → Provider

Decoupling prevents cascading failures.

1️⃣2️⃣ Multi‑Provider Strategy

Never depend on a single payment provider. Implement:

• Primary provider
• Secondary fallback

With an abstraction layer:

def charge(amount, token):
    # routing logic decides which provider to use
    ...

Outages happen; a fallback keeps the platform alive.

“if.”
They are “when.”

What Looks Simple Is Actually Distributed Finance

A ride‑payment system is not:

• Just API calls
• Just token storage
• Just Stripe integration

It is:

• Distributed systems
• Financial accounting
• Legal compliance
• Fault tolerance
• Fraud modeling
• Bank integrations
• Event‑driven infrastructure

That’s why payment infrastructure is one of the hardest backend domains in the world.

Final Thought

When Maria stepped out of that taxi in Prague, she didn’t think about:

• Idempotency keys
• Double‑entry accounting
• Multi‑provider failover
• Fraud scoring
• Reconciliation pipelines

She just walked into her meeting.

That’s the goal. Great engineering makes complexity invisible.

If you’re building systems

Don’t just design features. Design for:

• Failure
• Scale
• Auditability
• Correctness

Because money systems don’t forgive mistakes.