Cards
Google Pay
Портфейл на Google, използващ токени на схемата на мрежата на Android; предоставя биометрични данни за устройство или предизвикателство, отчитани като SCA съгласно PSD2.
Google Pay означава: Портфейл на Google, използващ токени на схемата на мрежата на Android; предоставя биометрични данни за устройство или предизвикателство, отчитани като SCA съгласно PSD2.
При платежните операции това не е просто етикет; той контролира как транзакция, идентификационни данни, рисково събитие или движение на средства се тълкуват от контрагентите. Механизмът е свързан с данни за картата, идентификационни данни за картата, обработка от издателя или стандарти за съобщения на схемата.
Той влияе върху това как картата се идентифицира, защитава, съхранява, токенизира, оторизира или маршрутизира през мрежата на схемата. Обикновено се анализира заедно с мрежов токен, Apple Pay, силно удостоверяване на клиента, тъй като тези съседни концепции определят търговския и оперативен резултат.
Практическите детайли обикновено се намират в регистрационните файлове на шлюза, отчетите на придобиващия, файловете на схемата, записите за обслужване на клиенти и извлеченията за сетълмент, а не в едно табло за управление.
Екипите трябва да записват стойността, времевия печат, контрагента, валутата, кода за отговор и всеки индикатор за изключение или отговорност, свързан със събитието. Често срещана грешка е да се третира Google Pay като статична дефиниция.
На практика значението може да се променя според схемата, държавата, MCC, продукта на картата, издателя, канала на транзакцията и дали плащането е инициирано от клиента или от търговеца.
Ето защо търговците с голям обем обикновено документират правила, наблюдават изключенията ежеседмично и преглеждат праговете, преди малък оперативен проблем да се превърне в проблем с обратно плащане, финансиране или съответствие.
Worked example
Търговец преглежда транзакция от £75, където Google Pay е решаващият фактор. Идентификационните данни се идентифицират, елементите на данните на схемата се попълват, издателят прилага своите правила и отговорът се връща чрез придобиващия към търговеца.
Оперативните разходи се моделират на 6 базисни точки от схемата или разходите за обработка, или £0,05, и съответното действие трябва да приключи по време на оторизация и клиринг.
Стъпка 1 е да се заснемат оригиналните данни на заявката, включително сума, валута, държава на издателя, MID и код за отговор или статус.
Стъпка 2 е да се приложи наборът от правила на търговеца, например дали да се опита отново, да се оспори, да се възстанови сумата, да се освободят стоки или да се задържат за преглед.
Стъпка 3 е да се съгласува резултатът с отчитането на придобиващия, така че финансовият отдел да може да види паричния ефект.
Ако правилото подобри резултата дори с 50 базисни точки при 2000 подобни месечни транзакции, търговецът защитава приблизително 10 допълнителни поръчки от избегната повреда или загуба.
Scheme notes
Visa и Mastercard разчитат на BIN или IIN диапазони, структури на съобщения в стил ISO 8583, токени на схемата и кодове за отговор на издателя, но използването на полета и продуктовите индикатори не са идентични.
Миграцията на осемцифрени BIN увеличи нуждата от текущи BIN таблици, тъй като шестцифрените търсения могат да класифицират погрешно държавата на издателя, типа продукт или предплатения статус.
American Express и Discover използват свои собствени номерации и мрежови правила, така че търговците не трябва да кодират твърдо логиката на картата само около Visa и Mastercard.
Why it matters for merchants
В търговски план това засяга качеството на оторизацията, обхвата на PCI, жизнения цикъл на идентификационните данни, проверката за измами и колко полезни данни достигат до издателя.
За търговец, обработващ £500 000 на месец, движение от 25 базисни точки струва £1250 преди вторични ефекти като спорове, резерви, билети за поддръжка или разходи за неуспешна доставка.
Въздействието е по-голямо при високорискови, абонаментни, туристически, дигитални стоки и трансгранични модели, тъй като решенията на издателя и мониторингът на схемата могат да се натрупват бързо.
Cardflo може да помогне, като комбинира достъп до придобиване, маршрутизиране на MID, правила за оркестрация, преглед на KYB и инструменти за обратно плащане, където е уместно, така че търговецът да не зависи от едно тълкуване на процесора или един фиксиран път на транзакция.
Често задавани
Какви данни трябва да съхранява търговецът за Google Pay?
Съхранявайте ID на транзакцията, MID, придобиващия, сумата, валутата, държавата на издателя, схемата на картата, кода за отговор или статус, времевия печат и всякакви препратки към 3DS, изключения, възстановявания или спорове.
За картови транзакции запазете идентификаторите за оторизация и клиринг, тъй като въпроси за сетълмент или обратно плащане могат да възникнат 30 до 120 дни по-късно.
За регулирани потоци запазете съгласието на клиента и записите за доказателства за поне периода, изискван от местното законодателство или правилата на схемата. Добрите записи намаляват времето за разследване от часове до минути, когато отчитането на придобиващия не съвпада със системата за поръчки.
Колко често трябва да се преглежда Google Pay?
Търговците с голям обем трябва да преглеждат нивата на изключенията ежеседмично и да проследяват основния показател ежемесечно по схема, придобиващ, държава на издателя, MCC и метод на плащане. Движение от 20 до 50 базисни точки може да бъде съществено, ако търговецът обработва хиляди поръчки.
Финансовият отдел трябва да съгласува паричния ефект на ниво сетълмент, докато операциите по риск или плащания трябва да анализират основната причина. Прегледът само на общите суми скрива проблеми, които се появяват в един BIN диапазон, регион или MID.
Какъв праг обикновено задейства действие при Google Pay?
Прагът зависи от категорията, но търговците трябва да разследват всяка внезапна промяна над 10% относително движение или 25 базисни точки абсолютно движение.
За спорове и измами, праговете на схемата като 0,9% при мониторинг на Visa или 1,5% при Mastercard ECM могат да създадат незабавен риск от ескалация. За сетълмент или ценови елементи, дори 5 до 15 базисни точки могат да оправдаят маршрутизиране или преглед на договора.
Ключът е да се зададат прагове преди края на месеца, а не след като пристигне фактура от процесор или известие от схемата.
Може ли Google Pay да се различава между придобиващите?
Да. Придобиващите могат да картографират кодовете за отговор по различен начин, да прилагат различни правила за риск, да поддържат различни полета за данни и да се уреждат по различни цикли.
Един придобиващ може да върне общо отхвърляне, докато друг разкрива съвет от издателя, който позволява безопасно повторно опитване. Третирането на таксите също може да варира според договора, особено за трансгранични, FX, премиум карти и алтернативни методи на плащане.
Ето защо търговците, използващи оркестрация, трябва да сравняват производителността по придобиващ и схема, вместо да разчитат на една обща цифра за одобрение или разходи.
Коя е първата стъпка за отстраняване, когато Google Pay създава загуби?
Започнете с 30-дневна извадка и я разделете по схема, държава на издателя, продукт на картата, метод на плащане, MID и код за отговор или спор. Количествено определете стойността на риска в парично изражение, а не само в процентни пунктове.
След това решете дали корекцията е оперативна, като по-добри доказателства или комуникация с клиенти, техническа, като по-богати данни или 3DS индикатори, или търговска, като различен маршрут на придобиващия.
Проверете отново същия показател след един пълен цикъл на сетълмент или спор, за да потвърдите, че промяната е проработила.
See how Google Pay plays out in practice
Industries and regions where this term drives real acquiring, routing, or dispute decisions.
Свързани термини
Токен, издаден от схема, който замества PAN от край до край и се актуализира автоматично, когато основната карта бъде преиздадена.
Портфейлът на Apple, използващ мрежови токени DPAN и биометрични данни на устройството; квалифицира се като SCA в ЕИП и носи еквиваленти на прехвърляне на отговорност, определени от схемата.
Изискване на PSD2, че инициираните от клиента електронни плащания в ЕИП и Обединеното кралство трябва да бъдат удостоверени с два от следните фактори: знание, притежание, присъщност.
Свързани ръководства.
Готови ли сте да подобрите настройките за плащанията си?
Разкажете ни за вашия бизнес. Ние ще ви свържем с правилните банки акцептанти и правилния маршрут, обикновено в рамките на една седмица.