; Payments have all the essential information about the order, including customer information, amount, currency, items, shipping info, etc. You can always refer to the transaction details for more details about the order and the payment interactions. ## Workflow In the following workflow, you can find the different payment statuses and how they can be updated.

For every implementation, we recommend taking the payment status and sub\_status as the main reference for the payment's state. A payment could have different [transactions](/reference/transaction) associated with it. By focusing on the payment status / sub\_status, you can have the latest state regardless of how many transactions were made, giving you clear inputs for decision-making. ## Payments status The payments can have the following status and sub status.

Transaction type	Transaction status	Description
		Initial state at the time of creating a payment.
Purchase	Created	Initial state at the time of creating a payment. Waiting for customer action
Authorize	Succeeded	Card authorizations
Purchase	Created	The client has been redirected to the provider and we are waiting for the completion of the payment.
Purchase	Pending	3DS/Second factor
Authorize	Pending	3DS/Second factor for authorization flow
Purchase	Pending	Wating for providers payment confirmation.
Fraud	Pending	Transaction is being analyzed by fraud provider
Purchase	Pending	Initial status upon payment creation
Verify	Succeeded	Zero amount card authorizations
Purchase	Expired	The offline payment method reaches its expiration date.
Authorize	Expired	Authorization expires
Purchase	Rejected	Rejected by Yuno
Capture	Error	Capture rejection by Yuno
Purchase	Declined	Providers rejection
Capture	Declined	Providers capture rejection
Fraud screening	Declined	Declined fraud screening
Purchase	Succeeded	Partial payment (payment with 2 cards)
Purchase	Succeeded	Successful payment
Capture	Succeeded	Successful capture
Capture	Succeeded	Successful partial capture
Refund	Error/Declined	Remains approved due to error in refund / cancellation
Chargeback	Error/Declined	Remains approved due to rejection in chargeback
Refund	Succeeded	Successful partial refund
Chargeback	Succeeded	Successful partial chargeback
Fraud screening	Declined	Fraud screening declined. Can occur before or after provider authorization. Payment succeeded and funds have moved.
Refund	Declined	Transaction was declined and is waiting for retry.
Capture	Declined	Transaction was declined and is waiting for retry.
Capture	Declined	Transaction was declined and retry scheme it's finished.
Refund	Pending	Refund Pending
Refund	Succeeded	Successful refund
Cancel	Pending	Cancel Pending
Cancel	Succeeded	Successful cancelation
Chargeback	Created	Chargeback or Inquiry received. Decision or documentation must be provided
Chargeback	Pending	In\_review
Chargeback	Prevented	Predispute deflected by provider/network. Payment reflects lost funds.
	Example: timeout.



Fraud	Succeeded	Transaction verified by fraud provider during stand alone fraud verification

`PREVENTED` is a transaction status only for `type = CHARGEBACK` when the provider/network reports a [predispute deflection](/docs/chargeback-management). In these scenarios, only the chargeback webhook is sent; no refund webhook is emitted. `REVIEW_WON` is a chargeback transaction status only. When a chargeback is won, the payment returns to its previous status (for example, `SUCCEEDED` / `APPROVED`) and no new payment status is emitted. ### Possible states for sync and async flows Use the diagram that matches your integration type to understand which payment states and transitions to expect. #### Synchronous flow In a synchronous flow, the payment moves from `CREATED` directly to a terminal status — such as `SUCCEEDED`, `DECLINED`, or `REJECTED` — within the same API response. There is no intermediate `PENDING` phase. `ERROR` is transversal and can occur at any point in the flow.

#### Asynchronous flow In an asynchronous flow, the payment passes through a `PENDING` phase after creation before reaching a terminal status. During this phase, substates such as `IN_PROCESS`, `AUTHORIZED`, and `WAITING_ADDITIONAL_STEP` reflect ongoing processing. The final status is delivered via webhook once processing completes. Payments initiated via direct async APMs may also enter a `READY_TO_PAY` state, which can transition to `EXPIRED` if not completed. `ERROR` is transversal and can occur at any point in the flow.