Skip to content

Wallet Redirect (Google Pay & Apple Pay)

Overview

Wallet Redirect lets you accept Google Pay and Apple Pay without integrating the wallet SDKs on your own site. Instead of rendering the Google Pay / Apple Pay button yourself and forwarding an encrypted token to the gateway, you select the payment method on your platform and the gateway returns a redirect URL to a PSP that renders the wallet button and authorizes the payment end-to-end.

Payment method type Description
google-pay-redirect Google Pay rendered and authorized by the PSP
apple-pay-redirect Apple Pay rendered and authorized by the PSP

Both are classified as alternative payment methods even though the underlying instrument is a card — the gateway never sees card data, the wallet token, or the decrypted PAN. The PSP returns the transaction outcome and the gateway records it.

When to use Wallet Redirect vs. native Google Pay

Use Wallet Redirect when you want the simplest possible integration and are happy for the wallet UI to be rendered by the PSP after a redirect. If you need the Google Pay button rendered inside your own checkout with no redirect, use the native Google Pay integration instead, which requires you to integrate the Google Pay API and forward the encrypted token.

Integration Methods

Wallet Redirect is available through all three integration types:

Method Effort Notes
Hosted Payment Page None Google Pay / Apple Pay appear automatically on the HPP once enabled on your terminal
Embedded Fields Minimal The gateway exposes a stub script (google-pay-redirect / apple-pay-redirect) that registers a factory; your page renders its own "Pay" button
API Integration Low Send a single authorize request with payment_method.type set to google-pay-redirect or apple-pay-redirect and follow the returned redirect

Activation Prerequisites

Before accepting Wallet Redirect payments:

  1. Request activation of google-pay-redirect and/or apple-pay-redirect on your terminal from your account manager.
  2. No wallet-specific developer credentials (Google merchant ID, Apple Pay merchant ID, domain verification, etc.) are required on your side — the PSP owns those.

Hosted Payment Page

If you are already integrated with the Hosted Payment Page, no additional development is required.

Once google-pay-redirect and/or apple-pay-redirect are enabled on your terminal, they appear as payment options on the HPP alongside cards and other APMs. After the customer selects one, the HPP redirects them to the PSP-hosted wallet page.

sequenceDiagram
    participant Customer
    participant Merchant Frontend
    participant Payment Gateway
    participant PSP

    Customer->>Merchant Frontend: Start checkout
    Merchant Frontend->>Payment Gateway: Create HPP session
    Payment Gateway-->>Merchant Frontend: HPP URL
    Merchant Frontend->>Customer: Redirect to HPP
    Customer->>Payment Gateway: View HPP and select Google Pay / Apple Pay
    Payment Gateway->>PSP: Initiate wallet redirect
    PSP-->>Payment Gateway: Redirect URL
    Payment Gateway-->>Customer: Redirect to PSP wallet page
    Customer->>PSP: Tap Google Pay / Apple Pay and authenticate
    PSP-->>Payment Gateway: Notify payment result
    Payment Gateway-->>Merchant Frontend: Notify result (webhook + return URL)

API Integration

In the Direct API flow the payment method is already selected on your platform — typically because your own checkout rendered a "Google Pay" or "Apple Pay" button. You submit a standard authorize request and the gateway returns a redirect URL that the browser must follow to complete the wallet authorization.

Authorize Request

POST /api/transactions/authorize
Authorization: Bearer <access_token>
Content-Type: application/json

{
  "reference": "ORDER-WR-001",
  "terminal_id": "TERM001",
  "description": "Wallet Redirect payment",
  "currency": "EUR",
  "amount": 1000,
  "transaction_type": "PURCHASE",
  "payment_method": {
    "type": "google-pay-redirect",
    "data": {}
  },
  "customer": {
    "first_name": "John",
    "last_name": "Doe",
    "email": "john.doe@example.com",
    "country": "BA"
  },
  "return_url": "https://merchant.example.com/return",
  "error_url": "https://merchant.example.com/error",
  "cancel_url": "https://merchant.example.com/cancel"
}

For Apple Pay, set payment_method.type to apple-pay-redirect. The payment_method.data object is currently unused for both methods and may be sent as an empty object {}.

Field Value Notes
payment_method.type google-pay-redirect or apple-pay-redirect Required
payment_method.data {} No wallet token, encrypted PAN, or device data is required — the PSP collects it
return_url URL on your site Where the PSP sends the customer after a successful authorization
error_url URL on your site Where the PSP sends the customer after a declined or failed authorization
cancel_url URL on your site Where the PSP sends the customer if they abandon the wallet sheet

Authorize Response

{
  "transaction_id": "txn_01HX...",
  "status": "PENDING",
  "redirect": {
    "transaction_id": "txn_01HX...",
    "url": "https://psp.example.com/wallet/google-pay-redirect/..."
  }
}

Redirect the customer's browser to redirect.url. After the customer completes the wallet sheet at the PSP, they are returned to one of the URLs you supplied (return_url, error_url, or cancel_url) and the gateway emits the standard transaction-processed webhook with the final status.

Flow Diagram

sequenceDiagram
    participant Customer
    participant Merchant Frontend
    participant Merchant Backend
    participant Payment Gateway
    participant PSP

    Customer->>Merchant Frontend: Click Google Pay / Apple Pay
    Merchant Frontend->>Merchant Backend: Place order
    Merchant Backend->>Payment Gateway: POST /api/transactions/authorize<br/>(type = google-pay-redirect | apple-pay-redirect)
    Payment Gateway->>PSP: Initiate wallet session
    PSP-->>Payment Gateway: Redirect URL
    Payment Gateway-->>Merchant Backend: redirect.url
    Merchant Backend-->>Merchant Frontend: redirect.url
    Merchant Frontend->>Customer: Redirect to PSP
    Customer->>PSP: Authenticate in Google Pay / Apple Pay sheet
    PSP-->>Payment Gateway: Final result
    PSP-->>Customer: Redirect to return_url / error_url / cancel_url
    Payment Gateway-->>Merchant Backend: Transaction-processed webhook

Embedded Fields

For Embedded Fields, the gateway exposes a small stub script for each wallet redirect method that registers a factory on window:

Method Script key
google-pay-redirect window['google-pay-redirect'].factory
apple-pay-redirect window['apple-pay-redirect'].factory

The script is intentionally not a wallet SDK — it does not render a Google Pay / Apple Pay button and does not perform the redirect. Your embedded checkout renders its own "Pay" button; when the customer clicks it, the backend authorize response carries the redirect_url and the embedded checkout host performs the navigation.

Limitations

  • No tokenization on your side. The gateway never receives a Google Pay / Apple Pay token. If you need to decrypt tokens yourself or render the wallet button on your own checkout without a redirect, integrate the native Google Pay flow instead.
  • No customer-data passthrough to the wallet. The PSP collects everything it needs inside the wallet sheet; the payment_method.data object is currently unused.
  • One transaction type. Wallet Redirect supports PURCHASE only — AUTHORIZE-then-capture and standalone refunds initiated via the wallet are not available.