Unmasking the Double Charge Dilemma: The Intricate Technology Behind Preventing Duplicate Transactions.

The Birth of Stripe:
How Two Brothers Tackled the Double Payment Problem with Idempotent APIs :

Back in 2010, in the sunny state of California, two entrepreneurial brothers aspired to launch their own business. They soon discovered the complexities of setting up online payments, a challenge that seemed insurmountable at the time. Instead of giving up, they pivoted their focus and created an online payment service that we now know as Stripe.

As Stripe gained popularity, the issue of double payments surfaced. Users were sometimes charged twice for the same transaction, leading to frustration and mistrust. To address this, the brothers turned to a sophisticated solution: idempotent APIs. These clever mechanisms ensure that a transaction is processed only once, even if the request is repeated. As the number of users soared, this innovation became crucial in maintaining Stripe's reliability and user satisfaction.

What is Double Payment Problem ?

• Imagine you’re buying something online.
• You click “Pay Now,” but nothing seems to happen.
• So, you click again, just to be sure.
• Later, you find out that you were charged twice for the same purchase.
• This is the double payment problem.

 Why Does It Happen?

1. Slow Responses or Server Issues: Sometimes, the payment system takes a while to respond, making you think the payment didn't go through.

2. Network Issues: If the connection drops or slows down, you might resend the payment request, leading to multiple charges.

3. System Glitches: Errors in the payment processing system can accidentally process the same payment request more than once.

They aimed to resolve the double payment problem as efficiently as possible. Often, the simplest solution proves to be the most effective. Thus, they developed an idempotent API.

What are Idempotent API's ?

Imagine Your Favorite Ice Cream Truck

Picture your favorite ice cream truck driving through your neighborhood. You run up and ask for your favorite ice cream, and the ice cream man nods and starts making it. But then, you get worried that he didn't hear you, so you ask again, "Can I have my ice cream?"

The Ice Cream Man's Magic Notebook

Now, this ice cream man has a special magic notebook. Whenever he gets an order, he writes it down. If someone asks for the same thing again, he looks at his notebook and says, "Ah, I already wrote that down! I won't make it twice." So, no matter how many times you ask for your ice cream, you only get one.

Idempotent API is Like the Magic Notebook

In the world of computers, an idempotent API works just like that magic notebook. When you make a request to do something (like ordering ice cream or making a payment), the computer writes it down. If you ask again, it checks its list and says, "I already did that!" This way, you won't get charged twice or get two ice creams when you only wanted one.

So, idempotent APIs help computers remember what they’ve already done, making sure they don’t do the same thing more than once, just like the ice cream man with his magic notebook!

How Stripe Implements Idempotent APIs:

1. Idempotency Keys

Stripe ensures that each request is processed only once by using idempotency keys. 

Here’s how they do it:

1. Unique Identification: For each request, Stripe generates a unique string called a UUID, which acts as the idempotency key.
2. HTTP Headers: This key is sent along with each request in the HTTP header.
3. Tracking Changes: A new UUID is created whenever the request payload changes, ensuring that even similar requests are treated individually.

Imagine the idempotency key as a unique fingerprint that helps Stripe identify if a request has already been processed.

2. Preventing Double Payments with Idempotency Keys

1. In-Memory Database: Stripe stores idempotency keys in an in-memory database on the server side.
2. Caching Responses: After successfully processing a request, Stripe caches the server response.
3. Querying the Database: When a request is received, the in-memory database is queried to check if it has been processed before.
4. Processing New Requests: If the request is new, it’s processed, and the idempotency key is stored in the database.
5. Returning Cached Responses: If the request has been processed earlier, the cached response is returned, avoiding double processing.
6. Transaction Rollback: In case of a server error, transactions are rolled back using the ACID database properties.
7. Key Expiry: Idempotency keys are removed from the in-memory database after 24 hours to reduce storage costs and allow time to retry failed requests.

In essence, an idempotency key can be reused after 24 hours, ensuring efficient and accurate request processing.

So, next time you tap "Pay Now" or "Order," keep in mind the influence of idempotent APIs—the behind-the-scenes magic that ensures our digital encounters remain smooth and our online purchases accurate.