What this prompt does
This prompt casts the AI as a senior systems architect designing a payment processing system for a [business_type] platform handling [tps] transactions per second at peak. It moves through six steps: functional and non-functional requirements (including [payment_methods], [currency_count] currencies, [availability] SLA, and [max_latency]), a service-level architecture, the database and event-sourcing schema on [primary_database], a real-time fraud pipeline, settlement and reconciliation, and a PCI DSS compliance plus disaster-recovery plan.
The structure works because payment systems fail in specific, expensive ways, and each step targets one. Idempotency keys in [cache_layer] stop duplicate charges when a client retries; a double-entry ledger keeps the books provably balanced and makes discrepancies detectable; event sourcing makes the payment state machine auditable after the fact. The fraud step uses concrete thresholds — auto-approve below [auto_approve_score], auto-decline above [auto_decline_score], manual review in between — so scoring policy is explicit rather than hand-waved. Reconciling against [payment_processor] statements closes the loop between your ledger and the money that actually moved, which is where silent settlement bugs usually hide.
When to use it
- You're scoping a payment platform and need the full lifecycle before touching a processor integration
- You want a defensible architecture for idempotency, ledgering, and fraud in one document
- You need to reason about multi-currency support and recurring billing up front
- You're preparing for a PCI DSS conversation and need tokenization and audit-logging covered
- You're sizing infrastructure for a high-
[tps]workload with a strict[availability]SLA - You want settlement, payouts, and reconciliation designed alongside the happy path
- You need marketplace disbursements or split payments handled, not just single charges
Example output
Expect an architecture document: a service interaction diagram for a full payment lifecycle across the gateway, ledger, fraud, currency, and notification services, a ledger schema with the pending→authorized→captured→settled→refunded→disputed state machine and event sourcing, the fraud-scoring feature list with the configured [auto_approve_score] and [auto_decline_score] thresholds, a settlement and reconciliation flow against [payment_processor] with fee deductions and payouts, and a compliance section covering tokenization, encryption at rest and in transit, audit logging, and regional failover with zero transaction loss. It's a written design walkthrough, not runnable code.
Pro tips
- Set
[tps]to your real peak; it drives the database, sharding, and cache decisions more than any other variable - Keep
[auto_approve_score]and[auto_decline_score]apart enough to leave a sensible manual-review band in the middle - Treat
[availability]honestly — five nines implies multi-region failover that materially raises cost and complexity - Match
[primary_database]to a system with strong ACID guarantees, since the ledger is the part you can't get wrong - Use
[cache_layer]strictly for idempotency keys here; conflating it with general caching invites duplicate-charge bugs - This is a design aid — any real implementation still needs a security review and the actual
[payment_processor]API constraints
