Redirect payments can be initiated in two different ways:
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
noFopChosenwill be populated in the request. When this happens, the integrator will display to the user a list of available sub-brands. Once the user selects one of these, the user will be forwarded to that sub-brand's website/app to complete the purchase.
The user will select a FOP (sub-brand) during the purchase flow. In this case, Google will populate the
fopNameparameter in the request and redirect the user to the integrator. When the integrator receives this, they should immediately redirect the user to the sub-brands 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.
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:
redirectRequest parameter is encrypted and signed using
JWE+JWS before being
Redirect Request Parameters
The HTTPS GET request must have the following query parameters:
URL to redirect the user to when a payment is completed. This value is URL encoded.
This URL will include the