Set up automated discounts

Follow these instructions for implementing the price token.

Token structure

JWT tokens contain two JSON objects: header and payload.

Header

---

{

"alg": "ES256",

"typ": "JWT"

}

---

Google-generated token headers have two fields:

• alg – used algorithm, value is always 'ES256'
• typ – media type, value is always 'JWT'

If the token header contains any other fields, or field values are different from described above, the token must be rejected.

Payload

---

{

"exp": 1571673600,

"o": "tddy123uk",

"m": "140301646",

"p": 21.99,

"c": "USD"

}

---

Payload has the following fields:

• exp – expiry time as Unix time. If the token has expired, it must be rejected.
• o – offer ID, which can be used to check that the landing page matches the product. If there's a mismatch, the token must be rejected.
• m – Merchant ID. If the Merchant ID doesn't match, the token must be rejected.
• p – discounted price
• c – currency, upper case

Consuming token

The exact details around consuming the token depend on the used library, but at a high level, there are three steps: decoding and signature validation, field validation and consuming price.

Decoding and signature validation
The Base64URL-encoded token is passed in pv2 URL request parameter:

Most of the libraries combine decoding and signature validation into a single function, where 'token', 'ES256' (algorithm) and 'public key' are inputs and 'token_body' is the output:

Public key for validation:

The following key is meant to be used by all automated discount users without expiry.

Field validation

In case the selected library accepts key and algorithm in the previous step and forces their use despite header options, there's no need for additional header checks. Otherwise, the header fields need to be checked according to the guidelines above. For more information, review the JSON web token best current practices.

No matter which library is used, the o, m and p fields must be validated against merchant-side data. If they don't match, then the token must be rejected so that customers can't copy tokens across products and/or merchants. The merchant may check the exp field and reject the token if it has expired, but this isn't mandatory.

Consuming price
If all the fields are valid and the token isn't expired, the merchant must use the price provided in the p field.

You can use the existing coupon functionality to discount the price if it fulfils the requirements listed on this page. In particular, the price on the landing page must match the price in the token. Just adding the discount on the checkout page doesn't suffice.

Testing
After the integration is completed, it will be tested in three steps:

• Functional testing (done by merchant)
• Key validation (done by merchant with Google-provided token)
• Full end-to-end test (done by Google)

Functional testing
The easiest way to test during and after development is to generate a temporary key pair. This gives you full control over the tokens. A valid key pair can be generated with this command:

Tokens can be generated with jwt.io or similar tools using ES256 as an algorithm.

Key validation
In order to validate that production keys are correctly configured, signed tokens are available in Merchant Center during onboardings (sample URLs).