Preventing Duplicate Payments with Idempotency

A Disabled Pay Button is Just the First Step to Preventing Duplicate Payments

When a user clicks "Pay" and the button disables, many assume the process is finished. They are wrong Disabling the Pay button is a common front-end solution to prevent duplicate payments. It stops the customer from submitting multiple or duplicated payments. But this step is not enough because many scenarios can lead to duplicate charges. The user might refresh the page, experience a network drop, or the app might automatically retry sending the request. If the server isn't equipped to handle these cases, the same payment could be processed multiple times and successful charges occur twice. It's a simple yet crucial distinction. Disabling the button stops double-clicks on the page. Protecting the server stops duplicate payments.

What Idempotency and Key Generation Mean for Safe Payments

Idempotency, simply put, is a property of operations that guarantees the outcome remains the same, regardless of how many times the operation is repeated. It prevents a second request, which logically could be the same as the first, from affecting the payments system. When a user begins a checkout, the client generates a unique, random key for that payment attempt. For example, a key might look like "checkout _8f3c." Any retry of that checkout must send the exact same key. This allows the server to identify and react to the repeated requests. Idempotency serves a few purposes in the payments backend. It detects duplicate requests from the frontend, supplements existing systems like Stripe, and handles retries in a controlled manner. The backend checks the key to see whether it has already processed that payment. If so, it returns the previous results instead of starting another charge. This way, the system ensures that one checkout results in one charge.

The Role of PostgreSQL in Transactional Databases

The backend must store payment attempts in a reliable database to ensure idempotency. Transactional databases like PostgreSQL are ideal for this. Each payment attempt is logged with details including the idempotency key, user ID, amount, and status. The database ensures that only one row can exist for each idempotency key, preventing duplicate charges. If a payment is already in progress, the system will return the current state instead of starting another charge. The unique constraint is crucial to preventing duplicates. It ensures that the database only allows one row for each idempotency key, no matter how many requests come in at the same time. The database then communicates with the payment processor, like Stripe, passing the same idempotency key. This way, even if the backend accidentally sends the request twice, Stripe recognizes that both requests are for the same operation.

Navigating the Webhooks

A critical aspect to consider is the webhook, a call the payment processor makes back to the server upon processing the payment. The server must handle these webhooks with the same idempotency to prevent side effects from duplicate deliveries. It involves verifying the signature, finding the payment record, and updating the status to 'succeeded.' This way, even if the webhook arrives twice, it won't apply the same side effect twice. The process also requires storing the provider's event ID to ensure the system can track and process webhook events correctly. If the webhook arrives and the event ID already exists, the system acknowledges that the event has already been processed and moves on.

Practical guidance for implementing idempotency in payment systems

Without crucial safety measures, duplicate charges can occur when a user refreshes a page, experiences a network drop, or an app automatically retries a payment request. Here’s how to ensure your payment system protects against these scenarios:

• Ensure Unique Key Generation: Generate a unique key for each payment attempt and send it with every retry. This is crucial for differentiating between new and repeated requests.
• Use a Reliable Database: Store payment attempts in a transactional database like PostgreSQL. Ensure the database uses a unique constraint to prevent duplicate rows for the same idempotency key.
• Implement Atomic Writes: Ensure that the database writes are atomic, meaning they either complete successfully or fail entirely. This prevents race conditions where multiple requests might try to create the same row simultaneously.
• Verify Webhooks: When receiving webhooks from payment processors, verify the signature and check the provider's event ID. This ensures that repeated webhook deliveries do not duplicate fulfillment or other side effects.
• Check Payment Status: Before creating a new payment, check if a payment with the same idempotency key already exists. If it does, return the saved result or the current status to prevent duplicate charges.

Idempotency is essential to safeguard payment systems

Idempotency is more than a buzzword. It’s a safeguard ensuring that a payment system is robust and resilient in handling retries and duplicates. By following the guidelines on key generation, database management, and webhook verification, developers can create a payment system that protects both the user and the backend from the chaos of duplicate charges. With idempotency, one checkout indeed results in one charge, ensuring a smooth and secure payment process for all parties involved.