The shopper-facing status read used by the native mobile SDK. A provider confirmation succeeding on the device is not proof that RezolvePay recorded the payment — the webhook-updated status is — so the SDK polls here until the status is terminal.

This is not GET /api/v1/payments/{payment_id}. It is authenticated by the payment_client_token rather than merchant credentials, and returns exactly three fields. Card brand and last4, customer email, provider IDs and payout/fee figures are never exposed to a credential held on a shopper's device. Merchant credentials are not accepted here.

Path parameters:

Polling: status follows the open vocabulary above. A native client sees pending, then confirmed or rejected. Treat any other value as "not yet terminal" and keep polling. Rate limited to 120 requests/minute.

Why a separate token: The token is signed and carries its own payment_id, so it cannot be re-pointed at another payment and payment IDs cannot be enumerated — a valid token for another payment learns nothing about this one. A 15-minute expiry bounds replay, and a distinct type plus a secret separate from the console session secret keeps this token and an operator session from ever being forged from one another.