What this prompt does
This prompt has the AI design a payment processing system tightly enough to build, with concrete contracts rather than vague intent. You set the [product_type], the [provider], the [currencies], and the [compliance_scope]. It returns an idempotency-key API design with a dedupe storage model, a per-payment state machine with legal transitions, provider webhook handling with signature verification and retry/backoff, reconciliation that flags drift across currencies, compliance minimisation via tokenization, and fraud hooks plus an immutable audit trail.
The structure works because payments are where a missing idempotency key turns a retry into a real double-charge and a chargeback. Forcing the state machine to be explicit catches impossible transitions, and treating the provider as the source of truth makes reconciliation reliable. [provider] shapes the webhook verification and reconciliation, [currencies] widens the reconciliation scope, [compliance_scope] drives what data never touches your servers, and [product_type] frames the audit trail.
When to use it
- You're designing billing or checkout and want double-charges structurally impossible.
- You need an explicit payment state machine with only legal transitions.
- You're integrating a provider's webhooks and need signature verification and retries.
- You want reconciliation that compares your records against the provider and flags drift.
- You must minimise compliance exposure by keeping card data off your servers.
- You need an immutable audit trail and fraud hooks designed in.
Example output
You get the design with the state diagram, the webhook flow, and the idempotency contract: an API using idempotency keys so retries never double-charge, with the dedupe storage model; a per-payment state machine (created, authorized, captured, failed, refunded) and its legal transitions; webhook handling for [provider] covering signature verification, retry/backoff, and out-of-order delivery; reconciliation comparing internal records against [provider] and flagging drift across [currencies]; [compliance_scope] minimisation via tokenization and what never touches your servers; and fraud hooks plus observability and an immutable audit trail for [product_type].
Pro tips
- Treat the
[provider]as the source of truth and reconcile relentlessly; your internal records can drift, so the reconciliation step is what catches it across[currencies]. - Make the idempotency key contract explicit, including the dedupe storage model, since a missing key turns an innocent retry into a real double-charge.
- Force the state machine to enumerate legal transitions only — listing the impossible ones (like captured back to created) catches bugs before they reach production.
- Always verify the webhook signature for
[provider]and handle out-of-order delivery, because webhooks arrive late, duplicated, and occasionally spoofed. - Use
[compliance_scope]to push card data to the provider via tokenization so it never touches your servers, shrinking what you must secure and audit. - Keep the audit trail immutable; for a
[product_type]like a marketplace, an append-only record is what lets you resolve disputes after the fact.
