Ställ in Automatiska rabatter

Följ de här anvisningarna för att implementera denna pristoken.

Tokenstruktur

JWT-token innehåller två JSON-objekt: rubrik och nyttolast.

Rubrik

{

"alg": "ES256",

"typ": "JWT"

}

Google-genererade tokenrubriker har två fält:

• alg – använd algoritm, värdet är alltid ES256
• typ – medietyp, värdet är alltid JWT

Token måste avvisas om tokenrubriken innehåller andra fält eller om fältvärden skiljer sig från det som beskrivs ovan.

Nyttolast

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

Nyttolast har följande fält:

• exp – utgångstid som Unix-tid. Token måste avvisas om den har löpt ut.
• o – erbjudande-id används för att kontrollera om målsidan stämmer överens med produkten eller en giltig variant. Om målsidan inte stämmer överens med produkten eller en giltig variant måste den avvisas. En giltig variant kan vara samma skor i en annan storlek.
• m – säljar-id. Om säljar-id:t inte matchar måste token avvisas.
• p – pris för Googles automatiska rabatter (GAD)
• pp – tidigare pris*
  *För EES: Det tidigare priset skickas även med i webbadressen om det visas i Shopping-annonsen. Du kan välja att visa det tidigare priset i onlinebutiken. Det tidigare priset motsvarar det lägsta priset som har visats för användare på Google under de senaste 30 dagarna i följande länder: Kroatien, Lettland, Norge, Polen och Spanien. För alla andra EES-länder återspeglar det tidigare priset det pris som gällde före tillämpningen av flera prissänkningar under de senaste 60 dagarna.
• c – valuta, versaler.

Tokentillämpning

Exakt hur det går till att använda en token beror på vilket bibliotek som används, men på hög nivå finns det tre steg: avkodning och signaturvalidering, fältvalidering och pristillämpning.

Avkodning och signaturvalidering En Base64URL-kodad token skickas i parametern för pv2-webbadressbegäran:

De flesta bibliotek kombinerar avkodning och signaturvalidering till en enda funktion där ”token”, ”ES256” (algoritm) och ”offentlig nyckel” är indata och ”token_body” är utdata:

Offentlig nyckel för validering:

Följande nyckel kan användas av alla som använder automatiska rabatter utan utgångsdatum.

Fältvalidering

Om det valda biblioteket godkänner nyckeln och algoritmen i föregående steg och tvingar användning av dessa trots rubrikalternativen behövs inte ytterligare rubrikkontroller. I annat fall måste rubrikfälten kontrolleras i enlighet med riktlinjerna ovan. Mer information finns i bästa metoderna för JSON-webbtoken.

Oavsett vilket bibliotek som används måste o-, m- och p-fälten valideras mot data på säljarsidan. Om de inte stämmer överens måste token avvisas så att kunder inte kan kopiera token mellan produkter och/eller säljare. Säljaren kan kontrollera fältet exp och avvisa token om den har upphört att gälla, men det är inte obligatoriskt.

Prisanvändning Om alla fält är giltiga och token inte har löpt ut måste säljaren använda priset i p-fältet.

Du kan använda sina befintliga kupongfunktioner för att sänka priset om det uppfyller kraven som anges på den här sidan. I synnerhet måste priset på målsidan stämma överens med priset i token. Det räcker inte att lägga till rabatten på kassasidan.

Testning När integreringen är klar testas den i tre steg:

• Funktionstest (görs av säljaren)
• Nyckelvalidering (görs av säljaren med token från Google)
• Fullständigt test (görs av Google)

Funktionstest Det enklaste sättet att testa under och efter utvecklingen är att generera ett tillfälligt nyckelpar. Det ger dig full kontroll över token. Du kan generera ett giltigt nyckelpar med det här kommandot:

Token kan genereras med jwt.io eller liknande verktyg med ES256 som algoritm.

Nyckelvalidering Signerade token är tillgängliga i Merchant Center under introduktioner (exempeladresser) för att kontrollera att produktionsnycklarna är korrekt konfigurerade.