Possible Statuses

Understand the possible statuses of a payment, when each one occurs, and how to handle final, intermediate, and Sandbox behaviors.

Use payment statuses to decide when to wait for processing, finalize an operation, investigate a failure, or update your integration's internal state.

When to use

Refer to this page when handling a payment's return, reconciling the status displayed to the customer, or processing events related to the payment cycle. The status indicates whether the operation is still processing, completed successfully, failed, or was cancelled/refunded.

Statuses and recommended handling

Status	Description	How to handle in the integration
PENDING	Awaiting processing.	Keep the payment as pending and wait for a status update.
BANK_PROCESSING	Sent to the bank.	Indicate that the payment is in bank processing and do not finalize the operation as paid.
PAID	Paid and settled.	Mark the payment as completed and release the flow dependent on the confirmation.
FAILED	Failed — check the reason in the return.	Log the failure, read the returned reason, and guide the user to try again when applicable.
CANCELLED	Payment cancelled before execution.	Stop the execution flow and keep the cancellation history.
REFUNDED	Amount refunded.	Update the payment as refunded and reflect the refund in your internal balance or report.
AWAITING_CHECKOUT_RISK_ANALYSIS_REQUEST	Under analysis.	Treat as an intermediate state: wait for the analysis to finish before confirming or rejecting the payment.

Common status flow

After the payment is created, treat PENDING as an initial waiting state.
When the payment is sent for external processing, treat BANK_PROCESSING as an intermediate state.
Only finalize the flow upon receiving a conclusive status, such as PAID, FAILED, CANCELLED, or REFUNDED.
If you receive AWAITING_CHECKOUT_RISK_ANALYSIS_REQUEST, wait for the analysis before releasing the product, service, or next step of the journey.

PENDING → BANK_PROCESSING → PAID
                         ↘ FAILED
PENDING → CANCELLED
PAID → REFUNDED
AWAITING_CHECKOUT_RISK_ANALYSIS_REQUEST → wait for new update

Important fields and decisions

When processing the response, validate at least the following information:

Information	When to observe	Recommended decision
Payment status	On every update	Use the status as the primary source for updating your internal database.
Failure reason	When the status is `FAILED`	Display an appropriate operational message and log the reason for support.
Environment	During Sandbox testing	Do not use the Sandbox result as evidence of real bank settlement.

Best practices

Do not release access, product, or service while the status is PENDING, BANK_PROCESSING, or AWAITING_CHECKOUT_RISK_ANALYSIS_REQUEST.
Update your database idempotently (the same update may be received more than once and should not duplicate effects).
Log the previous status and the new status to facilitate auditing and support.
For failures, check the returned reason before guiding a retry attempt.

📘
In Sandbox, all payments return FAILED after creation. This is expected, since there is no real bank settlement in the testing environment.

When to use

Statuses and recommended handling

Common status flow

Important fields and decisions

Best practices

Related content