Skip to main content
Each session type moves through its own set of status values over its lifecycle. The diagram, states, and transitions are described below for each session type.

​
One Time and First In Series Payment Sessions

Both are customer-initiated, customer-present flows: the customer is present and completes payment via a hosted Checkout page.
The session remains in an active state while the customer is interacting with the Checkout page via the session_url.In the event of a failed payment, the session remains in an active state to allow the customer to make another payment attempt, as long as further attempts are still permitted.In the event of a successful payment, the session transitions into a completed state.While the session is active, the payment outcome (payment_outcome) is always one of: not_started (no attempt has been made yet), pending (an attempt is in flight), or unpaid (the most recent attempt failed, and another attempt is still permitted).
The session has completed. This does not necessarily mean the payment was successful. The outcome must be verified by interrogating the payment outcome (payment_outcome).A completed session’s payment outcome (payment_outcome) is one of: reserved (an auth-only hold was placed and is awaiting capture), paid (the payment was captured and the session closed successfully), unpaid (the session closed without payment because all permitted attempts were exhausted), or payment_method_verified (the payment method was saved via an amount: 0 verification flow).If the outcome is paid, reserved, or payment_method_verified, the payment_id field represents the associated payment; reserved and payment_method_verified both execute a payment without moving funds.
The session expired due to inactivity or a timeout. The customer did not complete the checkout process in time.An expired session’s payment outcome (payment_outcome) is either not_started (the session timed out before any payment attempt was made) or unpaid (the session timed out after a payment attempt had already failed).
The session was explicitly cancelled by the customer or merchant before the payment completed.A cancelled session’s payment outcome (payment_outcome) is either not_started (cancelled before any payment attempt was made) or unpaid (cancelled after a payment attempt had already failed).
The table below is the complete reference: every status and payment_outcome combination that can occur for a one_time or first_in_series session.

​
Next In Series Payment Sessions

A merchant-initiated, customer-absent flow: the customer is not present, and the payment is processed programmatically against an existing mandate.
The session is briefly in an active state while the payment is processed without customer interaction, using a saved payment method.In the event of either a successful or a failed payment, the session transitions into a completed state.While the session is active, the payment outcome (payment_outcome) is always one of: not_started (no attempt has been made yet) or pending (an attempt is in flight).
The session has completed, though this doesn’t necessarily mean the payment succeeded; check payment_outcome.It is one of: paid (captured successfully), unpaid (the payment failed), or reserved (auth-only hold, capture pending). payment_method_verified never applies, since payment method verification isn’t available on next_in_series sessions.If the outcome is paid or reserved, the payment_id field represents the associated payment.
The table below is the complete reference: every status and payment_outcome combination that can occur for a next_in_series session.
payment_status is deprecated in favour of payment_outcome.The new field supersedes the old and adds not_started, reserved, and payment_method_verified values.The deprecated field is still populated with paid, unpaid, or pending for backwards compatibility.