Redirect URL Flow

As part of the authentication process, the user will ultimately be redirected to the website of their issuing bank. Once the user has provided sufficient information, they should be redirected back to Google via the integrator. The user should be redirected to the integrator first, which in turn should redirect the user back to Google.

The integrator must redirect the user to callbackUrl, which is part of the authenticate payload. The integrator must implement an HTTPS protocol using GET. The GET parameters, outlined in Redirect Url Response Parameters, will contain information about the completed authentication.

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 Url Response

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

The URL-Ddcoded value of the authenticateRequestId parameter in this example is cmVxdWVzdDE. The URL-decoded value of the paymentIntegratorAccountId parameter in this example is SpeedyPaymentsIndia_INR

The redirectUrlResponse parameter is encrypted and signed using PGP or JWE+JWS before being base64 URL-encoded.

Redirect Url Response Parameters

The HTTPS GET response must have the following query parameters:

authenticateRequestId string

REQUIRED: The requestId sent in the initiating authenticate request. Google will verify this matches the sent requestId, and the authentication flow will fail if it doesn't match.

paymentIntegratorAccountId string

REQUIRED: This is the payment integrator account identifier that identifies contractual constraints around this transaction.

redirectUrlResponse RedirectUrlResponse

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