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.
If 3DS is required, the payment transitions to redirect_pending with a redirect_data object. Redirect the buyer accordingly. If 3DS is not required, the payment proceeds directly to a final status.
Track the outcome via GET /mobile-pay/{id}/status or a webhook.

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 for the return from 3DS. 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. Follow any redirect_data in that response, or track the payment through the status endpoint and webhooks. Retries and unresolved outcomes work the same as for every pay-in — see Handling errors.

3DS redirect

When 3DS verification is required, the payment reaches redirect_pending. A create response or status response in this state can contain redirect_data; the following example shows the fields used to redirect the buyer:

{
  "status": 200,
  "data": {
    "id": "074be75127e037868",
    "status": "redirect_pending",
    "redirect_data": {
      "type": "3ds",
      "url": "https://pay.example.com/3ds/abc123",
      "method": "GET"
    }
  }
}

Flow

Poll the status endpoint, or query it after a redirect_pending webhook. The webhook itself does not contain redirect_data. If the current status is still redirect_pending, read redirect_data. If it is already final, handle that outcome instead.
Redirect the buyer to redirect_data.url using redirect_data.method. The buyer completes the 3DS challenge on the issuer's page.
After the challenge, an intermediate page waits for the payment to reach a final status.
The buyer is redirected to your success_url or failure_url.

Important. Do not rely on the redirect to your URL as payment confirmation. Always verify the final status via the status endpoint or a webhook.

Payment status

Poll GET /sdk-partner/alternative-mobile-pay/mobile-pay/{id}/status or wait for a webhook. Status values and the response shape are common to every pay-in — see Payment statuses. A Google Pay payment can additionally pass through redirect_pending — see 3DS redirect.

Webhook

Google Pay uses the shared webhook contract, including an intermediate redirect_pending notification. Query GET status after that notification to obtain redirect_data, then follow the 3DS flow. Handle duplicate deliveries idempotently.

Apple Pay

Card payments