Transaction statuses

The status field returned by the V4 Transactions API describes the outcome of the forward payment flow. It is a stable projection and is independent of later refunds, voids, reversals, or disputes.

For example, after a successful payment, the transaction remains capture_succeeded even if a Void, refund, or dispute is created later. Use the Void payment, refund, or chargeback resource to track the corresponding post-payment lifecycle.

Response values

Status	Description	Terminal
processing	The payment is initialized, waiting for buyer action, being processed, or awaiting reconciliation. Continue to query the transaction or wait for a webhook.	No
capture_succeeded	The forward payment completed successfully. The merchant can treat the payment as successful.	Yes
capture_failed	The payment could not be completed. This also represents an initialization error. Check error_code for details when it is present.	Yes
cancelled	The active payment attempt was canceled before completion.	Yes
expired	The active payment attempt expired before completion.	Yes

Do not infer a payment result from HTTP status alone. A successful API request can return a transaction whose status is processing or capture_failed.

State flow

processing ──→ capture_succeeded
    ├────────→ capture_failed
    ├────────→ cancelled
    └────────→ expired

Terminal statuses do not transition back to processing for the same payment attempt.

Transaction list filters

The list endpoint accepts the response values above. For backward compatibility, it also accepts the following more specific filter aliases. Responses are still normalized to one of the five values above.

Filter alias	Matches response status
authorization_pending, capture_pending, buyer_approval_pending, buyer_approval_succeeded	processing
authorization_succeeded, settled	capture_succeeded
authorization_failed, capture_failed, buyer_approval_failed	capture_failed
authorization_void	cancelled
buyer_approval_timeout	expired

Integration guidance

• Fulfill an order only after receiving capture_succeeded.
• Treat processing as non-terminal and make status handling idempotent.
• Read error_code when status is capture_failed; do not retry blindly.
• Track Voids, refunds, and chargebacks separately instead of expecting them to overwrite the transaction's forward-payment status.