Google Pay

Accept payments from Google Pay wallets. Google Pay pay-ins use the same endpoints as Apple Pay — POST /mobile-pay and GET /mobile-pay/{id}/status — with pay_system set to "google". Statuses are described below. Webhooks are shared by all mobile pay-ins.

How it works

Your frontend collects a Google Pay token from the buyer using the Google Pay API.
Your backend sends the token and the buyer's details to POST /sdk-partner/alternative-mobile-pay/mobile-pay with pay_system: "google". The request must include success_url and failure_url.
The System decrypts the token, runs fraud checks, and initiates the payment. The initial response status is pending.
Your backend polls GET /mobile-pay/{id}/status from 5 seconds after the create until the status is final. Webhooks can bring the result sooner.
When a status response carries redirect_data, your frontend sends the buyer to redirect_data.url — see Send the buyer to the payment page. The buyer returns to your success_url or failure_url.

Create the payment

Endpoint: POST /sdk-partner/alternative-mobile-pay/mobile-pay

Set pay_system to google. Take the token string from paymentData.paymentMethodData.tokenizationData.token, Base64-encode it as it is, and send the result as pay_token; the raw JSON string is rejected. Include both success_url and failure_url (HTTPS): the payment page returns the buyer there. Field types, limits, and required buyer details are defined in the endpoint's API Reference.

Request example:

{
  "pay_system": "google",
  "pay_token": "<base64 of the tokenizationData token>",
  "email": "customer@example.com",
  "name": "John Doe",
  "fiat_amount": "100.00",
  "fiat_currency": "EUR",
  "ip": "203.0.113.10",
  "billing_address": {
    "country_code": "DE",
    "street_line_1": "Unter den Linden 1",
    "city": "Berlin",
    "zip_code": "12345",
    "state_code": "BE"
  },
  "location": { "country_code": "DE", "state": "BE" },
  "merchant_transaction_id": "bybit-google-pay-10001",
  "success_url": "https://example.com/checkout/success",
  "failure_url": "https://example.com/checkout/failure"
}

Response:

{
  "status": 200,
  "data": {
    "id": "074be75127e037868",
    "status": "pending"
  }
}

New payments start as pending. Track the payment through the status endpoint and send the buyer wherever redirect_data points. Retries and unresolved outcomes work the same as for every pay-in — see Handling errors.

Send the buyer to the payment page

Poll the status method GET /sdk-partner/alternative-mobile-pay/mobile-pay/{id}/status from 5 seconds after the create, where {id} is data.id from the create response — for example https://pay-in-api.mercuryo.io/sdk-partner/alternative-mobile-pay/mobile-pay/28a3c125a28075453/status (test: https://pay-in-api.mrcr.io/…). When its response carries redirect_data, redirect the buyer's browser to redirect_data.url with redirect_data.method. Until the status is final, keep polling: redirect_data can appear in any non-final response, usually a few seconds after the create.

Response of the status method:

{
  "status": 200,
  "data": {
    "id": "28a3c125a28075453",
    "status": "pending",
    "redirect_data": {
      "type": "3ds",
      "url": "https://pay-in.gateway-provider.com/order/28a3c125a28075453",
      "method": "GET"
    }
  }
}

redirect_data is present while the buyer has a step in the browser, and a repeated create for this payment returns it too. The URL leads to the Mercuryo payment page or, for some 3DS cases, to the provider's 3DS page. The page runs the 3DS device check and, when the issuer asks for it, the 3DS challenge. It then waits for the final status and redirects the buyer to your success_url (paid) or failure_url (order_failed).

Some payments start only after the buyer opens this page. A payment whose buyer does not reach it ends order_failed after 10 minutes. Show the buyer a waiting state on your page until you redirect them or the status is final.

Important. The buyer returning to your success_url is not payment confirmation. Read the final status — see Payment status.

A response can still carry the deprecated redirect_pending instead of pending when the issuer asks for 3DS; redirect_data then holds the 3DS URL. Handle it as pending — redirect the buyer to redirect_data.url.

Payment status

Start polling GET /sdk-partner/alternative-mobile-pay/mobile-pay/{id}/status 5 seconds after the create and continue until the status is final. A webhook can bring the result sooner, but delivery can be delayed: rely on polling. Status values and the response shape are common to every pay-in — see Payment statuses.

Webhook

Google Pay uses the shared webhook contract, including an intermediate redirect_pending notification. Use webhooks to learn the result sooner, alongside polling the status. Handle duplicate deliveries idempotently.

Apple Pay

Guide