For a payment gateway, Relational Databases (e.g., PostgreSQL, MySQL) are the standard choice because ACID compliance is non-negotiable.

The API should be RESTful and must enforce idempotency.

At a high level, the system can be broken down into two core paths:

This path focuses on securely capturing the payment intent and getting real-time approval from the financial network.

This path focuses on updating the merchant and eventually finalizing the movement of funds.

While this implementation technically facilitates a payment, it contains significant architectural "anti-patterns" and missing features (e.g., storing raw credit card numbers, vulnerability to network retries, and dual-write data loss) that prevent us from fulfilling strict financial and compliance requirements.

To meet the requirement of "no double charges," the system needs to handle the reality of dropped network connections and aggressive client retries. Network timeouts are inevitable. If a client doesn't receive the HTTP response, they will retry. We must prevent a second charge.

The initial design implies raw Primary Account Numbers (PANs) flow through the API Gateway and Payment Service. This triggers massive PCI compliance audits for the entire infrastructure. We must isolate this risk. We build a highly restricted, isolated microservice to handle raw card data.

The ultimate source of truth is the actual money moving between banks, not our internal database.