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 2 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 than described above, the token must be rejected.

Payload

{
"exp": 1571673600,
"o": "tddy123uk",
"m": "140301646",
"p": 21.99,
"pp": 15.00,
"c": "USD"
}

Payload has the following fields:

• exp - expiration time as Unix time. If the token is expired, it must be rejected.
• o - offer ID, used to check if the landing page matches the product or a valid variant. If the landing page doesn't match the product or valid variant, it must be rejected. A valid variant can be a different size of the same shoes.
• m - merchant ID. If the merchant ID doesn't match, the token must be rejected.
• p - Google Automated Discounts (GAD) price
• pp - Prior price *
  *For EEA: The prior price will also be passed in the URL if shown on the Shopping ad. You may choose to display the prior price on your online store. 

  The prior price represents the lowest price displayed to users on Google in the past 30 days in the following countries: Croatia, Latvia, Norway, Poland, Spain. 

  For all other EEA countries, the prior price represents the lowest price displayed to users on Google in the past 30 days, except where there is an application of consecutive price reductions (e.g., 10% off, then 20% off, then 50% off) within the past 60 days. In that case, the prior price will be the price that was applied before the first price reduction.

  Example: Consider the product price changes e.g. Day 1: 100€, Day 7: 90€, Day 14: 80€, Day 21: 70€, the prior price on Day 22 for Croatia, Latvia, Norway, Poland, Spain would be 80€ and 100€ for all other EEA countries

• 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 3 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 to 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 discounts 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 what 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's 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 their existing coupon functionality to discount the price if it fulfills 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 3 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 the Merchant Center during on-boardings (sample URLs).