Unified payment intent is a single object representing a customer's intention to pay a specific amount, tracking every attempt, method and provider used until the payment succeeds or is abandoned. The merchant creates one intent per order, and cards, wallets and retries attach to it as child records instead of separate charges. Stripe popularized the pattern with its PaymentIntents API in 2019, largely to handle extra steps introduced by SCA. The intent moves through defined statuses, from awaiting a payment method through requiring action to succeeded or canceled, each emitted as a webhook, and its idempotency key prevents double payments. In orchestration layers one intent spans several providers, whose own references still drive refunds and disputes.
What is unified payment intent, compared with a charge
The older model created a charge for each attempt. A customer whose card was declined, who then succeeded with a wallet, left two records, and the merchant had to work out which one belonged to the order. The intent model separates the goal (collect EUR 80 for order 5521) from the attempts, which become child records. Stripe popularized the pattern with its PaymentIntents API in 2019, largely to handle the extra steps SCA introduced.
How does unified payment intent work
The intent moves through a defined set of statuses. A typical sequence: created and awaiting a payment method, awaiting confirmation, requiring action (for example a 3DS challenge or a bank redirect), processing, authorized and awaiting capture, then succeeded or canceled. Each state change is emitted as a webhook, and the merchant's order system listens for the terminal state rather than parsing individual API responses.
Because the intent has one ID and is created with an idempotency key, a double-click on "Pay" or a network retry cannot produce two payments for the same order.
Payment intent orchestration explained
In a multi-provider setup, the unified intent lives in the orchestration layer rather than at one PSP. Payment orchestration platforms create their own intent and then open attempts at different providers underneath it: first acquirer A, then acquirer B after a soft decline, then a local payment method if the customer switches. The merchant sees one intent and one final status, while the platform stores which provider actually captured the money.
A numeric example
A retailer sees 10,000 checkout sessions a day, with an average of 1.3 payment attempts per completed order. Under a charge-per-attempt model that is 13,000 records to reconcile, of which about 3,000 are failures that must be excluded. Under the intent model it reconciles 10,000 intents and inspects attempts only when a status looks wrong.
Limits of the model
An intent is only unified within the system that created it. Refunds, disputes and payouts often still reference the underlying provider's transaction ID, so the orchestration layer must keep a clean mapping between its intent ID and each provider's references for reconciliation and dispute handling to work.