Overview

Overview

Google Standard Payments supports redirect-based Forms of Payment (FOPs). A redirect FOP enables users of Google's products or services to pay for these in an external entity's web interface. At a high level, a user who wants to pay for goods is initially redirected to a payment integrator or to an issuer that is available through a payment integrator. If the user is redirected to the integrator, the integrator should forward the user to the issuer's web interface to complete the purchase. Once the payment is completed, the user should be redirected back to Google via the integrator.

Note: The payment integrator and the issuer can be the same entity.

Google uses two main flows to complete a redirect FOP payment:

1. Initiate redirect: There are two different flows that can initiate a redirect payment. The payment integrator should only implement one of these options:
   • Begin Redirect flow: Initiates a payment by redirecting the user to the payment integrator.
   • Generate Redirect Payment Url flow: Google initiates a payment by sending a server-to-server request to the payment integrator to generate a redirect payment URL. Based on the response, Google redirects the user directly to the issuer.
2. Complete Redirect flow: Once the user completes the purchase, the integrator uses this flow to confirm the payment with Google.

Finally, all movement of money between the integrator’s bank and Google’s bank is done in the remittance flow.

Redirect FOP overview

The following figure illustrates a broad overview of the flows:

At a high level, adding your service as a form of payment to Google products involves these flows:

1. Initiate Redirect:
   • Begin Redirect flow
   • Generate Redirect Payment Url flow
2. Complete Redirect flow
3. Refund flow
4. Remittance flow

Concepts and terminology

Symbols & Conventions

The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT," "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in these documents are to be interpreted as described in RFC 2119.

Timestamps

All timestamps are represented as milliseconds since the Unix epoch (Jan 1, 1970) in UTC.

For example:

• April 23, 2019 8:23:25 PM GMT = 1556051005000 milliseconds
• August 16, 2018 12:28:35 PM GMT = 1534422515000 milliseconds

Amounts

Monetary values in this API are in a format called "micros," a standard at Google. Micros are an integer based, fixed precision format. To represent a monetary value in micros, multiply the standard currency value by 1,000,000.

For example:

• USD$1.23 = 1230000 micro USD
• USD$0.01 = 10000 micro USD

Idempotency

All method calls within this API must have idempotent behavior. Google will sporadically retry requests to ensure that transactions are in the same state on both sides. Integrators should not attempt to reprocess any request already successfully processed. The response for the successful processing should be reported instead. All methods have a common RequestHeader which contains a requestId. This requestId is the idempotency key for all calls.

Any non terminal response (a non HTTP 200-success), must not be idempotently processed. So a request that previously got a 400 (bad request/failed precondition), when called a second time, must not idempotently return 400, it must be re-evaluated. At re-evaluation, it could return a 400 or be processed successfully.

For more information on idempotency see this detailed guide.

Integrator

A company who uses Google’s Payment Platform for their business. It could be internal (1P), such as Youtube or AdWords, It can also be an external (3P) business wanting to integrate their service to work with Google’s ecosystem.

FOP

Form of Payment. This is more general than an instrument. Visa, MasterCard, and PayPal are all FOPs.

Instrument

A particular instance of a form of payment by a specific customer. For instance, a user’s credit card, or their PayPal account. A tokenized FOP for a particular customer is also an instrument, because it is an instance of a form of payment for that customer, securely stored on our system.

Token

A representation, on Google’s system, of a specific user’s payment method. Since it contains all the information needed to make a purchase, a token is also an instrument. This may include such information as an account number a user has with their integrator.

Key flows

Begin Redirect flow

The first step in a redirect payment is the Begin Redirect flow. The purpose of the Begin Redirect flow is to redirect the user, via the integrator, to their chosen issuer's web interface so they can authorize a payment. Upon redirect, Google provides basic transaction information to the integrator, which in turn forwards it to the issuer.

For more information, see the Begin Redirect flow section.

Complete Redirect flow

Once the user is in the issuer's web interface, they should perform all the necessary steps to complete a payment (these steps can change depending on the issuer). As part of the Complete Redirect flow, the issuer should redirect the user back to the integrator with information about the successful payment. The integrator will in turn redirect the user back to Google, including payment details as part of the redirect response. Once payment is confirmed, Google will provide the purchased goods or services to the user.

For more information, see the Complete Redirect flow section.