How Does Stripe Avoid Charging You Twice?

Imagine you're paying for an online order.

You click Pay.

• The loading spinner keeps spinning.
• So you refresh the page and try again.
• A few seconds later... Your payment succeeds.

But thankfully, you're only charged once.

How?

A simplified payment flow looks like this:

1. 💳 You click Pay.
2. 🔑 The application generates a unique Idempotency Key for that payment request.
3. 🌐 The payment request reaches the payment service.
4. ⚡ The payment is processed.
5. 📡 Before the response reaches your browser, your connection briefly drops.

Your browser retries the request. Instead of processing the payment again...

The payment service recognizes the same idempotency key.

It returns the original result instead of creating a second charge.

• No duplicate payment.
• No duplicate order.
• No financial inconsistency.

That's one of my favorite examples of good system design. The user sees one payment. The system may have received multiple requests.

One lesson that's changed how I think about distributed systems: Retries improve reliability. Idempotency protects consistency.

You almost always need both.

Without retries, temporary failures frustrate users. Without idempotency, retries can create even bigger problems.

That's why payment systems are designed around trust before speed.