Status Reference
Payment intent statuses
Section titled “Payment intent statuses”| Status | Description | Terminal? |
|---|---|---|
requires_payment_method |
No payment method attached | No |
requires_confirmation |
Payment method attached, awaiting confirm | No |
requires_action |
Customer action required (e.g. 3DS) | No |
processing |
Submitted to PSP, awaiting result | No |
succeeded |
Payment completed | Yes |
refunded |
All captured funds have been refunded | Yes |
failed |
Payment declined or errored | Yes |
canceled |
Explicitly canceled | Yes |
See Payment Lifecycle for the transition rules between these states.
Refund statuses
Section titled “Refund statuses”Refunds are separate objects linked to a payment intent.
| Status | Description |
|---|---|
succeeded |
Refund confirmed by PSP |
pending |
Submitted to PSP, awaiting confirmation |
failed |
PSP rejected the refund |
A failed refund does not affect the parent payment intent’s status. To retry, issue a new refund request.
Setup intent statuses
Section titled “Setup intent statuses”Setup intents are used to save a payment method for future use.
| Status | Description | Terminal? |
|---|---|---|
requires_payment_method |
No payment method collected | No |
processing |
Submitted to PSP for verification | No |
succeeded |
Payment method saved | Yes |
failed |
Setup failed | Yes |
canceled |
Explicitly canceled | Yes |
Payment methods
Section titled “Payment methods”Payment methods (pm_xxx) do not have a status field. A payment method either exists (and is usable) or has been deleted. The used flag on the tokenization result indicates whether a single-use token has already been consumed.
Test clock statuses
Section titled “Test clock statuses”Sandbox-only — see Test Clocks.
| Status | Description | Terminal? |
|---|---|---|
created |
Clock created, never advanced | No |
advancing |
An advance is in progress | No |
ready |
Last advance completed; clock can advance again | No |
failed |
An advance failed — delete the clock and recreate it | Yes |