Idempotent payment intents

Design an idempotent payment-intent flow for a checkout system processing ~2,000 payments/min against an external payment processor (Stripe-like) that itself can be slow or time out. A payment-intent moves through created to requires_action to processing to succeeded/failed. Requirements: a client retry (double-click, network retry, mobile reconnect) must NEVER charge twice; you must reconcile against the processor's async webhook as source of truth; and an in-flight timeout to the processor must not leave money in limbo. Strong consistency on the intent's terminal state is mandatory.