Begin Redirect Flow

Redirect payments can be initiated in two different ways:

  1. When the user selects "Redirect payment", they will be redirected to the integrator's website to select the Form-Of-Payment (FOP) to use. In this case, the noFopChosen will be populated in the request. When this happens, the integrator will display to the user a list of available issuers. Once the user selects one of these, the user will be forwarded to that issuer's website/app to complete the purchase.

  2. The user will select a FOP (issuer) during the purchase flow. In this case, Google will populate the issuerId parameter in the request and redirect the user to the integrator. When the integrator receives this, they should immediately redirect the user to the issuer's website/app to complete the purchase.

In both of the above cases, Google will redirect the user directly to the integrator's website without any previous server-to-server call from Google.

The integrator must implement an HTTPS protocol using GET. The GET parameters, outlined in Redirect Request Parameters, will contain information about the requested redirect payment.

The integrator must support URL lengths of 2,048 chars. This includes the scheme, host, port, path and parameters. All parameters will be UTF-8 encoded prior to being URL-encoded.

Redirect Request

Here's an example of the URL to which the user will be redirected as part of the Begin Redirect flow (also known as redirect request):

The URL-decoded value of the callbackUrl parameter in this example is:

The redirectRequest parameter is encrypted and signed using PGP or JWE+JWS before being base64url-encoded.

Redirect Request Parameters

The HTTPS GET request must have the following query parameters:

callbackUrl string

URL to redirect the user to when a payment is completed. This value is URL encoded and has a max length of 512 characters.

This URL will include the requestId from the encrypted redirectRequest in the redirectRequestId GET parameter. The vendor should validate that the redirectRequestId from the callbackUrl and the requestId from the encrypted payload are identical to verify that both are related.

redirectRequest RedirectRequest

REQUIRED: The RedirectRequest should be encrypted and signed using PGP or JWE+JWS. Further, this value should be web-safe base64 encoded.