How do you design the payment processing component for an online store?

Direct Answer

Design a PaymentProcessor interface with methods like initiatePayment, verifyPayment, and refundPayment. Implement concrete processors for each payment method: CreditCardProcessor, DebitCardProcessor, UPIProcessor, WalletProcessor. The Payment entity stores paymentId, orderId, method (enum), amount, status (PENDING/SUCCESS/FAILED/REFUNDED), externalTransactionId from gateway, and timestamps. Order class holds a Payment reference. Use the Strategy pattern—OrderService picks the correct processor implementation based on user's selected payment method, keeping payment logic decoupled from Order.

Deep Dive & Architecture

Payment is a stateful record

A Payment keeps the order id, amount, method, gateway reference, idempotency key, and status. Transitions such as PENDING → SUCCEEDED or PENDING → FAILED are validated so a late callback cannot move a refunded payment back to success.

The gateway stays behind an interface

PaymentProcessor implementations translate the application's request into provider-specific calls. For example, a UPI processor may return a pending result while a wallet processor may complete immediately. The order service depends on the interface and stores the provider's external transaction id for later verification.

Retries return the same result

Before charging, the service stores the idempotency key with a uniqueness constraint. Repeating the same request returns the existing payment instead of creating a second charge. Gateway callbacks are authenticated, recorded, and processed idempotently as well. The order becomes paid only after a trusted success result; timeouts remain pending until reconciliation confirms the final state.

Code Example

interface PaymentProcessor {
    PaymentResult initiate(Payment payment);
    PaymentResult verify(String externalTxnId);
    PaymentResult refund(Payment payment);
}

class UpiProcessor implements PaymentProcessor {
    public PaymentResult initiate(Payment p) { /* call UPI gateway */ return PaymentResult.pending(); }
    public PaymentResult verify(String id)   { /* poll gateway */     return PaymentResult.success(); }
    public PaymentResult refund(Payment p)   { return PaymentResult.refunded(); }
}

class PaymentService {
    private final Map<PaymentMethod, PaymentProcessor> processors;
    PaymentResult pay(Order order, PaymentMethod method, String idempotencyKey) {
        // idempotency: same key -> return the existing result, never double-charge
        if (repo.exists(idempotencyKey)) return repo.resultFor(idempotencyKey);
        Payment payment = repo.create(order, method, idempotencyKey);
        return processors.get(method).initiate(payment);
    }
}

The idempotency key makes a retried request safe — the customer is charged at most once.

Common Mistakes & Pitfalls

• No idempotency — a network retry double-charges the customer. Use an idempotency key.
• if-else per payment method — use Strategy; each gateway is a class.
• double for amount — use BigDecimal.
• Assuming synchronous success — gateways are async; model PENDING and verify later via webhook/poll.