Cards
Google Pay
Portofelul Google care utilizează token-uri de rețea de schemă pe Android; oferă biometrie a dispozitivului sau de provocare, considerată SCA conform PSD2.
Google Pay înseamnă: Portofelul Google care utilizează token-uri de rețea de schemă pe Android; oferă biometrie a dispozitivului sau de provocare, considerată SCA conform PSD2.
În operațiunile de plată nu este doar o etichetă; controlează modul în care o tranzacție, o credențială, un eveniment de risc sau o mișcare de fonduri este interpretată de contrapartide. Mecanismul este atașat datelor cardului, credențialelor cardului, procesării emitentului sau standardelor de mesagerie ale schemei.
Afectează modul în care un card este identificat, securizat, stocat, tokenizat, autorizat sau rutat prin rețeaua schemei. Este analizat în mod obișnuit alături de token-ul de rețea, Apple Pay, Autentificarea puternică a clienților, deoarece aceste concepte învecinate determină rezultatul comercial și operațional.
Detaliile practice se găsesc de obicei în jurnalele gateway-ului, rapoartele achizitorului, fișierele schemei, înregistrările serviciului pentru clienți și extrasele de decontare, mai degrabă decât într-un singur tablou de bord.
Echipele ar trebui să înregistreze valoarea, marcajul temporal, contrapartea, moneda, codul de răspuns și orice indicator de scutire sau răspundere atașat evenimentului. O greșeală comună este de a trata Google Pay ca o definiție statică.
În practică, semnificația se poate schimba în funcție de schemă, țară, MCC, produsul cardului, emitent, canalul de tranzacție și dacă plata este inițiată de client sau de comerciant.
De aceea, comercianții cu volum mare documentează în mod normal regulile, monitorizează excepțiile săptămânal și revizuiesc pragurile înainte ca o mică problemă operațională să devină o problemă de Chargeback, finanțare sau conformitate.
Worked example
Un comerciant revizuiește o tranzacție de 75 GBP în care Google Pay este factorul decisiv. Credențialul este identificat, elementele de date ale schemei sunt populate, emitentul își aplică regulile, iar răspunsul este returnat prin achizitor comerciantului.
Costul operațional este modelat la 6 puncte de bază din costul schemei sau al procesării, adică 0,05 GBP, iar acțiunea relevantă trebuie finalizată în timpul autorizării și compensării.
Pasul 1 este de a captura datele cererii originale, inclusiv suma, moneda, țara emitentului, MID și codul de răspuns sau de stare.
Pasul 2 este de a aplica setul de reguli al comerciantului, de exemplu dacă să reîncerce, să conteste, să ramburseze, să elibereze bunuri sau să rețină pentru revizuire.
Pasul 3 este de a reconcilia rezultatul cu raportarea achizitorului, astfel încât departamentul financiar să poată vedea impactul în numerar.
Dacă regula îmbunătățește rezultatul cu chiar și 50 de puncte de bază la 2. 000 de tranzacții lunare similare, comerciantul protejează aproximativ 10 comenzi suplimentare de eșecuri sau pierderi evitabile.
Scheme notes
Visa și Mastercard se bazează ambele pe intervale BIN sau IIN, structuri de mesaje în stil ISO 8583, token-uri de schemă și coduri de răspuns ale emitentului, dar utilizarea câmpurilor și indicatorii de produs nu sunt identici.
Migrația BIN-urilor de opt cifre a crescut necesitatea tabelelor BIN curente, deoarece căutările de șase cifre pot clasifica greșit țara emitentului, tipul de produs sau starea preplătită.
American Express și Discover utilizează propriile reguli de numerotare și de rețea, astfel încât comercianții nu ar trebui să codifice logica cardului doar în jurul Visa și Mastercard.
Why it matters for merchants
Din punct de vedere comercial, acest lucru afectează calitatea autorizării, domeniul de aplicare PCI, ciclul de viață al credențialelor, screening-ul fraudelor și cât de multe date utile ajung la emitent.
Pentru un comerciant care procesează 500. 000 GBP pe lună, o mișcare de 25 de puncte de bază valorează 1. 250 GBP înainte de efecte secundare, cum ar fi Dispute, rezerve, tichete de asistență sau costuri de livrare eșuate.
Impactul este mai mare în modelele cu risc ridicat, abonamente, călătorii, bunuri digitale și transfrontaliere, deoarece deciziile emitentului și monitorizarea schemei se pot compune rapid.
Cardflo poate ajuta prin combinarea accesului la achiziție, rutarea MID, regulile de orchestrare, revizuirea KYB și instrumentele de Chargeback acolo unde este relevant, astfel încât comerciantul să nu depindă de o singură interpretare a procesatorului sau de o singură cale de tranzacție fixă.
Întrebări frecvente
Ce date ar trebui să stocheze un comerciant pentru Google Pay?
Stocați ID-ul tranzacției, MID, achizitorul, suma, moneda, țara emitentului, schema cardului, codul de răspuns sau de stare, marcajul temporal și orice referință 3DS, scutire, rambursare sau dispută.
Pentru tranzacțiile cu cardul, păstrați identificatorii de autorizare și compensare, deoarece întrebările legate de decontare sau Chargeback pot apărea la 30 până la 120 de zile mai târziu.
Pentru fluxurile reglementate, păstrați consimțământul clientului și înregistrările dovezilor pentru cel puțin perioada cerută de legea locală sau de regulile schemei. Înregistrările bune reduc timpul de investigație de la ore la minute atunci când raportarea achizitorului nu se potrivește cu sistemul de comenzi.
Cât de des ar trebui revizuit Google Pay?
Comercianții cu volum mare ar trebui să revizuiască ratele de excepție săptămânal și să urmărească tendința metricii principale lunar, în funcție de schemă, achizitor, țara emitentului, MCC și metoda de plată.
O mișcare de 20 până la 50 de puncte de bază poate fi semnificativă dacă comerciantul procesează mii de comenzi.
Departamentul financiar ar trebui să reconcilieze impactul în numerar la nivel de decontare, în timp ce operațiunile de risc sau de plată ar trebui să analizeze cauza principală. Revizuirea doar a totalurilor combinate ascunde probleme care apar pe un singur interval BIN, regiune sau MID.
Ce prag declanșează de obicei acțiunea pe Google Pay?
Pragul depinde de categorie, dar comercianții ar trebui să investigheze orice modificare bruscă peste o mișcare relativă de 10% sau o mișcare absolută de 25 de puncte de bază.
Pentru Dispute și fraude, pragurile schemei, cum ar fi 0,9% sub monitorizarea Visa sau 1,5% sub Mastercard ECM, pot crea un risc imediat de escaladare.
Pentru elementele de decontare sau de preț, chiar și 5 până la 15 puncte de bază pot justifica rutarea sau revizuirea contractului. Cheia este să setați pragurile înainte de sfârșitul lunii, nu după ce sosește o factură a procesatorului sau o notificare a schemei.
Poate Google Pay să difere între achizitori?
Da. Achizitorii pot mapa codurile de răspuns diferit, pot aplica reguli de risc diferite, pot suporta câmpuri de date diferite și se pot deconta în cicluri diferite.
Un achizitor poate returna un refuz generic, în timp ce altul expune sfaturi ale emitentului care permit o reîncercare sigură. Tratamentul taxelor poate varia, de asemenea, în funcție de contract, în special pentru plăți transfrontaliere, FX, carduri premium și metode de plată alternative.
De aceea, comercianții care utilizează orchestrarea ar trebui să compare performanța în funcție de achizitor și schemă, mai degrabă decât să se bazeze pe o singură cifră de aprobare sau cost combinată.
Care este primul pas de remediere atunci când Google Pay generează pierderi?
Începeți cu un eșantion de 30 de zile și împărțiți-l după schemă, țara emitentului, produsul cardului, metoda de plată, MID și codul de răspuns sau de dispută. Cuantificați valoarea în risc în termeni monetari, nu doar în puncte procentuale.
Apoi decideți dacă soluția este operațională, cum ar fi dovezi mai bune sau comunicare cu clienții, tehnică, cum ar fi date mai bogate sau indicatori 3DS, sau comercială, cum ar fi o rută diferită a achizitorului.
Reverificați aceeași metrică după un ciclu complet de decontare sau dispută pentru a confirma că modificarea a funcționat.
See how Google Pay plays out in practice
Industries and regions where this term drives real acquiring, routing, or dispute decisions.
Termeni asemănători
Un token emis de schemă care înlocuiește PAN-ul end-to-end și este actualizat automat atunci când cardul subiacent este reemis.
Portofelul Apple care utilizează token-uri de rețea DPAN și biometrie a dispozitivului; se califică drept SCA în SEE și poartă echivalente de transfer de răspundere definite de schemă.
Cerință PSD2 conform căreia plățile electronice inițiate de clienți în SEE și Regatul Unit trebuie autentificate cu două dintre următoarele: cunoștințe, posesie, inerență.
Conexe ghiduri.
Gata să-ți îmbunătățești configurația de plăți?
Spuneți-ne despre afacerea dvs. Vă vom potrivi cu partenerii de achiziție potriviți și cu ruta corectă, de obicei în mai puțin de o săptămână.