Payment statuses
Endpoint: GET /sdk-partner/alternative-mobile-pay/mobile-pay/{id}/status
Use the current payment status to decide whether to wait or process a final result. A browser redirect is not payment confirmation. New payments start as pending; a repeated create request returns the current state of the existing payment.
Start polling 5 seconds after the create and continue until the status is final. Webhooks can bring the result sooner, but delivery can be delayed: rely on polling.
| Status | Action |
|---|---|
paid |
Payment completed. This is a final payment outcome. |
order_failed |
Payment failed. This is a final payment outcome. |
refunded |
A partial or full refund has been confirmed. Use refunded_amount to determine how much was returned; this status does not imply a full refund. |
pending |
Processing is ongoing. If the response carries redirect_data, send the buyer to redirect_data.url. Keep polling. |
order_scheduled |
Deprecated. Replaced by pending; handle it as pending. |
redirect_pending |
Deprecated. Google Pay; replaced by pending; handle it as pending. |
The API Reference contains response schemas and examples. See the payment page step for Apple Pay and Google Pay and Refunds for the separate refund operation and its statuses.
Unknown status or timeout
If you receive a status you do not recognize, keep the result unresolved: do not treat it as success or failure. Poll at a reasonable interval and set an overall timeout on your side.
If the result remains unresolved past that timeout, stop automated polling and contact support with the payment id. Your timeout does not cancel the payment or prove that it failed. Keep the operation available for reconciliation and continue accepting late webhooks; do not create a replacement payment merely because the original timed out.
