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.Documentation Index
Fetch the complete documentation index at: https://docs.y.uno/llms.txt
Use this file to discover all available pages before exploring further.
Workflow
In the following workflow, you can find the different payment statuses and how they can be updated.
status and sub_status as the main reference for the payment’s state. A payment could have different transactions 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.| Status | Substatus | 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. 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
