PaymentIntent lifecycle and idempotency

Design a PaymentIntent object that models the full lifecycle of a single payment (created to requires_action to processing to succeeded/failed) and stays correct under aggressive client and network retries. The same client may call confirm 5 times because of timeouts, a webhook from the bank may arrive before the synchronous response, and a cancel can race a late authorize. ~30,000 confirms/sec at peak. Requirement: a given PaymentIntent must never result in two authorizations or a charge after a successful cancel, and every API call must be safely replayable. How do you model the state, transitions, and concurrency control so the object is the single source of truth?