Error handling and retry requests

HTTP code	Note	Recommended actions
2xx	Transaction status is final (successful, failed)	Use the received transaction status.
2xx	Transaction status is not final (for example, incomplete)	Wait for the webhook notification (more about the notification for cards, more about the notification for APMs), then request the current transaction status by uid (more about the request for cards, more about the request for APMs).
4xx	The request contains invalid data or syntax errors. Do not retry the request without correcting the request parameters.	Fix the request and resend it. If the request included an idempotency key, update it before resending the request.
5xx	A service-side internal error occurred while processing the request. Despite the error response, the transaction may have been created successfully.	Request the transaction status by tracking_id (for cards, for APMs). If the transaction is not found, resend the original request using the same idempotency key. If a retry request is sent without an idempotency key or with a new idempotency key, the API treats it as a new transaction. For transactions that can be performed multiple times (for example, partial refunds), this may result in an additional partial refund.
No response received	timeout or network error	Request the transaction status by tracking_id (for cards, for APMs). If the transaction is not found, resend the original request using the same idempotency key. Do not wait indefinitely for a response. If the request does not complete before the configured timeout expires, terminate the connection and retrieve the current transaction status using the corresponding API. This helps prevent long-lived connections from exhausting client resources and degrading your application's performance. If a retry request is sent without an idempotency key or with a new idempotency key, the API treats it as a new transaction. For transactions that can be performed multiple times (for example, partial refunds), this may result in an unintended additional partial refund.

Warning

In exceptional cases, the acquirer or payment method provider might not return the final transaction result before the request times out.

As a result, transactions that normally receive a final status synchronously (refund, capture, void, recurring, and p2p) can initially return an intermediate status: incomplete for card transactions or pending for APM transactions.

After the final result is received from the acquirer or payment method provider, the merchant will get the webhook notification with the transaction's final status.