사용자가 결제 버튼을 두 번 클릭하면 전자상거래 결제 API가 두 번 호출되지 않는 이유는 무엇인가요?

Introduction

Imagine you’re purchasing a product online. You click the “Pay Now” button, and due to a slow internet connection or impatience, you accidentally click it again.

A common question among developers is:

If two requests are sent, why doesn’t the payment get processed twice?

The answer lies in a combination of frontend protection, backend safeguards, database design, and payment gateway architecture.

In this blog, we’ll explore how modern e-commerce systems prevent duplicate payments and the system design principles behind it.

The Problem

Consider the following sequence:

1. User clicks “Pay Now”
2. Browser sends payment request
3. User clicks again before the first request completes
4. Browser sends another payment request

Without proper handling:

• Customer may be charged twice
• Two orders may be created
• Inventory may be deducted twice
• Refund processes become necessary

This is a critical financial issue that every payment system must prevent.

First Layer: Frontend Protection

The simplest protection happens in the UI.

Disable the Payment Button

After the first click:

const handlePayment = async () => {
  setLoading(true);
  await makePayment();
};

Enter fullscreen mode Exit fullscreen mode

<button disabled={loading}>
  Pay Now
</button>

Enter fullscreen mode Exit fullscreen mode

What Happens?

• User clicks once
• Button becomes disabled
• Additional clicks are ignored

Why This Isn’t Enough

Frontend validation can be bypassed:

• Browser refresh
• Multiple tabs
• Network retries
• Malicious requests
• Mobile app bugs

Therefore, the backend must still assume duplicate requests can arrive.

Second Layer: Idempotency Keys

This is the most important concept in payment systems.

What Is Idempotency?

An operation is idempotent if performing it multiple times produces the same result.

For payments:

Pay ₹100 once
Pay ₹100 again
Pay ₹100 again

Enter fullscreen mode Exit fullscreen mode

Result:

Only one actual payment is processed.

Enter fullscreen mode Exit fullscreen mode

Generating an Idempotency Key

When a payment request is initiated:

payment_id = "PAY_123456"

Enter fullscreen mode Exit fullscreen mode

Request:

{
  "paymentId": "PAY_123456",
  "amount": 1000
}

Enter fullscreen mode Exit fullscreen mode

The backend stores this key.

First Request

PAY_123456
Status: Processing

Enter fullscreen mode Exit fullscreen mode

Payment starts.

Second Request

Backend receives:

PAY_123456

Enter fullscreen mode Exit fullscreen mode

System checks:

SELECT * FROM payments
WHERE payment_id = 'PAY_123456';

Enter fullscreen mode Exit fullscreen mode

Record already exists.

Instead of processing again:

Return existing response

Enter fullscreen mode Exit fullscreen mode

No second payment occurs.

Architecture Flow

User
  |
  v
Frontend
  |
  v
API Gateway
  |
  v
Payment Service
  |
  +---- Check Idempotency Key
  |
  +---- Already Exists?
          |
       YES --> Return Previous Result
          |
       NO
          |
          v
Process Payment
          |
          v
Store Result

Enter fullscreen mode Exit fullscreen mode

This pattern is used by almost every modern payment platform.

Database-Level Protection

Even if two requests reach the server simultaneously, the database provides another safety layer.

Unique Constraint

CREATE TABLE payments (
  payment_id VARCHAR(100) UNIQUE,
  amount DECIMAL(10,2)
);

Enter fullscreen mode Exit fullscreen mode

Suppose two servers receive:

PAY_123456

Enter fullscreen mode Exit fullscreen mode

at exactly the same moment.

The first insert succeeds:

INSERT INTO payments ...

Enter fullscreen mode Exit fullscreen mode

The second insert fails:

Duplicate Key Exception

Enter fullscreen mode Exit fullscreen mode

Thus, duplicate records cannot exist.

Handling Race Conditions

Consider a distributed environment:

Request A --> Server 1
Request B --> Server 2

Enter fullscreen mode Exit fullscreen mode

Both arrive within milliseconds.

Without coordination:

Server 1 -> Process Payment
Server 2 -> Process Payment

Enter fullscreen mode Exit fullscreen mode

Duplicate charge risk.

Distributed Locking

Many systems use Redis locks.

Flow

Acquire Lock
      |
      v
Process Payment
      |
      v
Release Lock

Enter fullscreen mode Exit fullscreen mode

Example:

LOCK:PAY_123456

Enter fullscreen mode Exit fullscreen mode

Server 1:

Lock Acquired

Enter fullscreen mode Exit fullscreen mode

Server 2:

Lock Exists

Enter fullscreen mode Exit fullscreen mode

Server 2 waits or returns existing result.

Payment Gateway Protection

Payment providers also implement idempotency.

Examples include:

• Stripe
• Razorpay
• PayPal

When sending a request:

POST /payments
Idempotency-Key: PAY_123456

Enter fullscreen mode Exit fullscreen mode

Gateway stores:

PAY_123456

Enter fullscreen mode Exit fullscreen mode

If another request arrives:

Same key detected

Enter fullscreen mode Exit fullscreen mode

Gateway returns the original response instead of charging again.

This creates protection even if your application has a bug.

Real-World Payment Architecture

                User
                  |
                  v
         +----------------+
         |  Frontend App  |
         +----------------+
                  |
                  v
         +----------------+
         | API Gateway    |
         +----------------+
                  |
                  v
         +----------------+
         | Payment Service|
         +----------------+
                  |
      +-----------+------------+
      |                        |
      v                        v
 Redis Lock            Payment Database
      |                        |
      +-----------+------------+
                  |
                  v
          Payment Gateway
                  |
                  v
              Bank

Enter fullscreen mode Exit fullscreen mode

Every layer contributes to preventing duplicate transactions.

Why Multiple Protection Layers Are Needed

A common misconception is:

“Disabling the button solves the problem.”

In reality:

Layer Purpose Frontend Disable Prevent accidental clicks API Idempotency Prevent duplicate processing Database Unique Key Prevent duplicate records Redis Lock Prevent race conditions Payment Gateway Idempotency Prevent duplicate charges

Payment systems rely on defense in depth, not a single safeguard.

Interview Perspective

A common System Design interview question is:

How would you prevent duplicate payment processing?

Expected answer:

1. Disable button on frontend
2. Generate unique payment/order ID
3. Use idempotency keys
4. Store payment status in database
5. Add unique constraints
6. Use distributed locking for concurrent requests
7. Leverage payment gateway idempotency support

Discussing all layers demonstrates strong backend and distributed systems knowledge.

Key Takeaways

• Double-clicking a payment button can generate multiple requests.
• Frontend protection alone is insufficient.
• Idempotency keys are the primary mechanism for preventing duplicate payments.
• Databases enforce uniqueness through constraints.
• Redis locks handle concurrent requests across multiple servers.
• Payment gateways provide an additional safety layer.
• Modern payment systems use multiple layers of protection to guarantee that a customer is charged only once.

A successful payment architecture is not about stopping duplicate requests it is about ensuring duplicate requests produce only one financial transaction.