Stay organized with collections
Save and categorize content based on your preferences.
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 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.
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 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:
Fields
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.
REQUIRED: The RedirectRequest
should be encrypted and signed using PGP or
JWE+JWS. Further, this value should be web-safe
base64 encoded.
All rights reserved. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2024-09-03 UTC.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Missing the information I need","missingTheInformationINeed","thumb-down"],["Too complicated / too many steps","tooComplicatedTooManySteps","thumb-down"],["Out of date","outOfDate","thumb-down"],["Samples / code issue","samplesCodeIssue","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2024-09-03 UTC."],[[["\u003cp\u003eRedirect payments can be initiated in two ways: either the user selects "Redirect payment" and is redirected to the integrator's website to choose a payment method, or the user selects a payment method during the purchase flow and is redirected directly to the issuer's website/app.\u003c/p\u003e\n"],["\u003cp\u003eGoogle redirects the user to the integrator's website without any prior server-to-server communication.\u003c/p\u003e\n"],["\u003cp\u003eIntegrators must implement an HTTPS GET protocol and support URLs up to 2,048 characters long.\u003c/p\u003e\n"],["\u003cp\u003eThe redirect request includes a \u003ccode\u003ecallbackUrl\u003c/code\u003e for redirecting the user after payment completion and a \u003ccode\u003eredirectRequest\u003c/code\u003e containing encrypted payment details.\u003c/p\u003e\n"],["\u003cp\u003eThe \u003ccode\u003eredirectRequest\u003c/code\u003e parameter is encrypted and signed for security and includes details about the requested payment.\u003c/p\u003e\n"]]],["Redirect payments involve users being directed to an integrator's site or an issuer's site/app. If no Form-Of-Payment (FOP) is chosen, the integrator displays available issuers for the user to select; then the user is forwarded to the issuer. If the user selects an FOP, Google populates the `issuerId` and immediately redirects the user to the issuer via the integrator. The integrator receives a GET request with `callbackUrl` and an encrypted, base64-encoded `redirectRequest` parameter. The `callbackUrl` allows for post-payment redirect.\n"],null,["# Begin Redirect Flow\n\nRedirect payments can be initiated in two different ways:\n\n1. When the user selects \"Redirect payment\", they will be redirected to the\n integrator's website to select the Form-Of-Payment (FOP) to use. In this\n case, the `noFopChosen` will be populated in the request. When this happens,\n the integrator will display to the user a list of available issuers. Once\n the user selects one of these, the user will be forwarded to that issuer's\n website/app to complete the purchase.\n\n2. The user will select a FOP (issuer) during the purchase flow. In this case,\n Google will populate the [`issuerId`](/standard-payments/payment-integrator-redirect-fop-api-v1/v1/FormOfPayment#IssuerId)\n parameter in the request and redirect the user to the integrator. When the\n integrator receives this, they should immediately redirect the user to the\n issuer's website/app to complete the purchase.\n\n| **Note:** The payment integrator and the issuer can be the same entity.\n\nIn both of the above cases, Google will redirect the user directly to the\nintegrator's website without any previous server-to-server call from Google.\n\nThe integrator must implement an HTTPS protocol using GET. The GET parameters,\noutlined in [Redirect Request Parameters](#redirect_request_parameters), will\ncontain information about the requested redirect payment.\n\nThe integrator must support URL lengths of 2,048 chars. This includes the\nscheme, host, port, path and parameters. All parameters will be UTF-8 encoded\nprior to being URL-encoded.\n\nRedirect Request\n----------------\n\nHere's an example of the URL to which the user will be redirected as part of the\nBegin Redirect flow (also known as redirect request): \n\n https://www.integratordomain.com/example/redirectEndpoint?callbackUrl=https%3A%2F%2Fexample.google.com%2Freturn%2Furl%3FredirectRequestId%3DcmVxdWVzdDE&redirectRequest=VEhJU19JU19BTl9FTkNSWVBURURfUkVESVJFQ1RfUkVRVUVTVF9QQVlMT0FEX0VYQU1QTEVfVEhBVF9JU19FTkNPREVEX1dJVEhfYmFzZTY0X1VSTC1TQUZFX0VOQ09ESU5H\n\nThe URL-decoded value of the `callbackUrl` parameter in this example is: \n\n https://example.google.com/return/url?redirectRequestId=cmVxdWVzdDE\n\nThe [`redirectRequest`](/standard-payments/payment-integrator-redirect-fop-api-v1/v1/RedirectRequest) parameter is encrypted and signed using `PGP` or `JWE+JWS` before being `base64url`-encoded.\n\n### Redirect Request Parameters\n\nThe HTTPS GET request must have the following query parameters:\n\n| Fields ||\n|-------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| `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. |\n| `redirectRequest` | [RedirectRequest](/standard-payments/payment-integrator-redirect-fop-api-v1/v1/RedirectRequest) **REQUIRED** : The `RedirectRequest` should be encrypted and signed using **PGP** or **JWE+JWS** . Further, this value should be web-safe `base64` encoded. |"]]