Стандартные платежи Google:

Токенизированный ФОП

Обзор

Токенизированный FOP (форма платежа) — это один из видов интеграции платежей в Платежную платформу. Чтобы пользователь мог совершить платеж с помощью этого FOP, Google и интегратор платежей должны выполнить однократный обмен учетными данными учетной записи. Это, в свою очередь, проходит через процесс создания токена, представляющего форму оплаты для этого конкретного пользователя. Этот токен затем можно использовать для оплаты снова и снова. В настоящее время существует 2 версии этих API. Версия 2 поддерживает операторов мобильной связи и поставщиков ссылочных номеров. Все остальные поставщики токенизированных FOP должны реализовать версию 1. Остальная часть этого документа посвящена версии 1.

Google использует два процесса для установления личности и создания токена:

1. Поток аутентификации : идентифицирует и проверяет (аутентифицирует) пользователя.
2. Поток ассоциации : устанавливает токен для пользователя (нового или ранее идентифицированного и аутентифицированного). Этот токен представляет собой определенную форму оплаты конкретным пользователем. Затем токен можно будет использовать в будущих покупках.

Как только токен будет установлен, Google будет использовать его во время процесса покупки для быстрого и удобного оформления заказа для пользователя. Google использует этот токен для представления экземпляра способа оплаты, используемого клиентом. Это еще называют инструментом. Клиент Google может иметь несколько инструментов для оплаты товаров и услуг.

Наконец, все движение денег между банком интегратора и банком Google осуществляется в рамках потока денежных переводов .

1) Пользователь выбирает товар для покупки.

2) Далее выбирают способ оплаты

3) Теперь они добавляют новый способ оплаты.

4) Они перенаправляются для аутентификации

5) Наконец, они прошли аутентификацию и могут совершать покупки.

Эта диаграмма иллюстрирует общий обзор потоков:

Обзор токенизированного ФОП

На высоком уровне добавление вашей услуги в качестве формы оплаты в продукты Google включает в себя следующие этапы:

1. Поток аутентификации
2. Поток ассоциации
3. Поток покупок
4. Поток возврата
5. Поток денежных переводов

Эти потоки описаны более подробно в разделах ниже и еще более подробно в разделе руководств .

Концепции и терминология

{%, если "стандартные платежи" в динамическом_data.request.path %} {% setvar document_base_path %}/standard-pays{% endsetvar %} {% elif "pay/banking-fop-v2" в динамическом_data.request.path %} {% setvar document_base_path %}/pay/banking-fop-v2{% endsetvar %} {% setvar spec_name %}banking-fop-v2{% endsetvar %} {% elif "pay/card-fop-v1" в динамическом_data.request.path %} {% setvar document_base_path %}/pay/card-fop-v1{% endsetvar %} {% setvar spec_name %}card-fop-v1{% endsetvar %} {% elif "pay/card-management-v1" в динамическом_data.request.path %} {% setvar document_base_path %}/pay/card-management-v1{% endsetvar %} {% setvar spec_name %}card-management-v1{% endsetvar %} {% elif "pay/carriers-v1" в динамическом_data.request.path %} {% setvar document_base_path %}/pay/carriers-v1{% endsetvar %} {% setvar spec_name %}carriers-v1{% endsetvar %} {% elif "pay/carrier-wallets-v1" в динамическом_data.request.path %} {% setvar document_base_path %}/pay/carrier-wallets-v1{% endsetvar %} {% setvar spec_name %}carrier-wallets-v1{% endsetvar %} {% elif "pay/e-wallets-v1" в динамическом_data.request.path %} {% setvar document_base_path %}/pay/e-wallets-v1{% endsetvar %} {% setvar spec_name %}e-wallets-v1{% endsetvar %} {% elif "pay/chargeback-alert-v1" в динамическом_data.request.path %} {% setvar document_base_path %}/pay/chargeback-alert-v1{% endsetvar %} {% setvar spec_name %}chargeback-alert-v1{% endsetvar %} {% elif "pay/golden-fop-v1" в динамическом_data.request.path %} {% setvar document_base_path %}/pay/golden-fop-v1{% endsetvar %} {% setvar spec_name %}golden-fop-v1{% endsetvar %} {% elif "pay/facilitated-transaction-event-v2" в динамическом_data.request.path %} {% setvar document_base_path %}/pay/facilitated-transaction-event-v2{% endsetvar %} {% setvar spec_name %}facilitated-transaction-event-v2{% endsetvar %} {% elif "pay/india-cards-v1" в динамическом_data.request.path %} {% setvar document_base_path %}/pay/india-cards-v1{% endsetvar %} {% setvar spec_name %}india-cards-v1{% endsetvar %} {% elif "pay/issuers/apis/push-provisioning/server" в динамическом_data.request.path %} {% setvar document_base_path %}/pay/issuers/apis/push-provisioning/server {% endsetvar %} {% setvar spec_name %}push-provisioning-v1{% endsetvar %} {% elif "pay/одноразового платежа-код-v1" в динамическом_data.request.path %} {% setvar document_base_path %}/pay/one-time-paying-code-v1{% endsetvar %} {% setvar spec_name %}код-разового платежа-v1{% endsetvar %} {% elif "pay/redirect-fop-v1" в динамическом_data.request.path %} {% setvar document_base_path %}/pay/redirect-fop-v1{% endsetvar %} {% setvar spec_name %}redirect-fop-v1{% endsetvar %} {% elif "pay/redirect-pay-token-v1" в динамическом_data.request.path %} {% setvar document_base_path %}/pay/redirect-pay-token-v1{% endsetvar %} {% setvar spec_name %}redirect-pay-token-v1{% endsetvar %} {% elif "pay/refundable-one-time-paying-code-v1" в динамическом_data.request.path %} {% setvar document_base_path %}/pay/refundable-one-time-paying-code-v1{% endsetvar %} {% setvar spec_name %}возвратный-одноразовый-платеж-код-v1{% endsetvar %} {% elif "pay/refundable-one-time-paying-code-v2" в динамическом_data.request.path %} {% setvar document_base_path %}/pay/refundable-one-time-paying-code-v2{% endsetvar %} {% setvar spec_name %}refundable-одноразовый-код-платежа-v2{% endsetvar %} {% elif "pay/value-on-device-fop-v1" в динамическом_data.request.path %} {% setvar document_base_path %}/pay/value-on-device-fop-v1{% endsetvar %} {% setvar spec_name %}value-on-device-fop-v1{% endsetvar %} {% elif "pay/virtual-cards-v1" в динамическом_data.request.path %} {% setvar document_base_path %}/pay/virtual-cards-v1{% endsetvar %} {% setvar spec_name %}virtual-cards-v1{% endsetvar %} {% конечный %}

Символы и обозначения

Ключевые слова «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ТРЕБУЕТСЯ», «ДОЛЖЕН», «НЕ ДОЛЖЕН», «СЛЕДУЕТ», «НЕ ДОЛЖЕН», «РЕКОМЕНДУЕТСЯ», «МОЖЕТ» и «ДОПОЛНИТЕЛЬНО» в этих документах. интерпретироваться, как описано в RFC 2119 .

Временные метки

Все временные метки представлены в миллисекундах с эпохи Unix (1 января 1970 г.) в формате UTC.

Например:

• 23 апреля 2019 г., 20:23:25 GMT = 1556051005000 миллисекунд
• 16 августа 2018 г., 12:28:35 GMT = 1534422515000 миллисекунд.

Суммы

Денежные значения в этом API представлены в формате «микро», который является стандартом Google. Микро — это целочисленный формат с фиксированной точностью. Чтобы представить денежную стоимость в микромах, умножьте стоимость стандартной валюты на 1 000 000.

Например:

• 1,23 доллара США = 1 230 000 микродолларов США
• 0,01 доллара США = 10 000 микродолларов США

Идемпотентность

Все вызовы методов в этом API должны иметь идемпотентное поведение. Google будет время от времени повторять запросы, чтобы гарантировать, что транзакции находятся в одном и том же состоянии с обеих сторон. Интеграторам не следует пытаться повторно обработать уже успешно обработанный запрос. Вместо этого следует сообщить ответ об успешной обработке. Все методы имеют общий RequestHeader , который содержит requestId. Этот requestId является ключом идемпотентности для всех вызовов.

Любой нетерминальный ответ (не HTTP 200-успех) не должен обрабатываться идемпотентно. Таким образом, запрос, который ранее получил 400 (неверный запрос/неудачное предварительное условие), при повторном вызове не должен идемпотентно возвращать 400, его необходимо переоценить. При повторной оценке он может вернуть 400 или быть успешно обработан.

Дополнительную информацию об идемпотентности смотрите в этом подробном руководстве .

Интегратор

Компания, которая использует платежную платформу Google для своего бизнеса. Это может быть внутренний (1P), например Youtube или AdWords. Это также может быть внешний (3P) бизнес, желающий интегрировать свой сервис для работы с экосистемой Google.

ФОП

Форма оплаты. Это более общий инструмент, чем инструмент. Visa, MasterCard и PayPal являются ФОПами.

Инструмент

Конкретный экземпляр формы оплаты конкретным клиентом. Например, кредитная карта пользователя или его учетная запись PayPal. Токенизированный FOP для конкретного клиента также является инструментом, поскольку он представляет собой экземпляр формы платежа для этого клиента, надежно хранящийся в нашей системе.

Токен

Представление в системе Google способа оплаты конкретного пользователя. Поскольку токен содержит всю информацию, необходимую для совершения покупки, он также является инструментом. Сюда может входить такая информация, как номер счета пользователя у своего интегратора.

Ключевые потоки

Поток аутентификации

Аутентификация — это первый поток, который должен произойти. Целью потока аутентификации является идентификация и аутентификация пользователя для интегратора. Аутентификация может осуществляться несколькими способами. Токенизированные FOP поддерживают два способа идентификации и аутентификации пользователя:

1. Аутентификация SMS-MT OTP (мобильное завершение SMS, одноразовый пароль)
2. Перенаправление аутентификации

При внедрении интеграторы совместно с Google выбирают механизмы аутентификации, которые лучше всего подходят для их продукта.

Потоки аутентификации можно использовать в двух контекстах: во-первых, для идентификации нового клиента с целью установления связи, и, во-вторых, для запроса у пользователя учетных данных существующего инструмента. Результат потока аутентификации можно использовать в качестве входных данных для нескольких потоков, таких как поток ассоциации , поток обновления токена , поток оспоренной покупки и т. д. Кроме того, поток аутентификации можно использовать в автономном режиме, не привязывая его к какому-либо последующему потоку.

SMS-MT OTP-аутентификация

В этом механизме аутентификации пользователь вводит номер телефона в пользовательском интерфейсе Google. Google отправляет этот номер телефона интегратору (с помощью метода sendOtp ). Интегратор отправляет пользователю одноразовый пароль. Пользователь вводит пароль в пользовательский интерфейс Google, который отправляет его интегратору. Это вызывает успешный ответ Платежного интегратора.

Когда аутентификация SMS-MT OTP используется в автономном режиме, значение OTP отправляется интегратору с помощью verifyOtp . Этот метод проверяет, был ли предоставленный OTP отправлен.

Перенаправление аутентификации

Аутентификация с перенаправлением происходит благодаря тому, что Google перенаправляет пользователя в приложение, принадлежащее интегратору. Это приложение может быть веб-приложением или приложением для Android.

Перенаправления Android и Web ведут себя одинаково. Google перенаправляет пользователя в приложение интегратора. Интегратор идентифицирует и аутентифицирует пользователя в той форме, которая наиболее естественна для этого интегратора. После аутентификации интегратор перенаправляет пользователя обратно в пользовательский интерфейс Google, чтобы завершить привязку. При перенаправлении Google предоставляет requestId для идентификации этого сеанса аутентификации. Этот идентификатор затем используется в качестве подтверждения личности во время ассоциации.

Интеграторы, выбирающие этот процесс, должны предоставить URL-адрес веб-аутентификации, поскольку это наиболее распространенный знаменатель для всех поверхностей (настольных или мобильных устройств). Тем не менее, настоятельно рекомендуется использовать аутентификацию Android, чтобы обеспечить наилучшее взаимодействие с пользователем на мобильных устройствах.

В зависимости от контекста устройства и установленных приложений пользовательский интерфейс Google выберет перенаправление через Интернет или через приложение Android.

Этот механизм аутентификации предоставляет интегратору максимальную свободу. Существует множество способов аутентификации и идентификации пользователя. Имя пользователя + пароль или биометрическая информация и контрольные вопросы являются жизнеспособными решениями. Google не намерен диктовать, как интегратор проверяет пользователя. Интегратор заботится об аутентификации пользователя. Таким образом, Google намерен использовать различные пользовательские интерфейсы интегратора для аутентификации пользователя и просто предоставить Google подтверждение аутентификации.

Примечание. Если интегратор собирается использовать SMS-MT OTP во время перенаправления, Google настоятельно рекомендует использовать вышеупомянутую аутентификацию SMS-MT OTP. Это обеспечивает пользователю более удобный опыт работы со свойствами Google.

Дополнительную информацию об аутентификации смотрите в этом подробном руководстве .

Ассоциативный поток

После прохождения аутентификации посредством одного из упомянутых выше механизмов пользователь перемещается по потоку ассоциации. Целью потока ассоциации является создание платежного токена Google ( GPT ) для создания инструмента. Этот поток выполняет следующие действия:

1. Согласовывает идентификатор, называемый токеном, для представления этого пользователя.
2. Предоставляет информацию об учетной записи для информирования системы рисков Google.
3. Собирает необходимую информацию о первоначальной настройке для создания и установки GPT .

В результате установленный GPT согласовывается как Google, так и интегратором.

Два пользователя Google могут использовать одну и ту же учетную запись пользователя у интегратора. В этом случае у каждого пользователя будет свой инструмент. Для каждого инструмента существует независимый поток ассоциации и, следовательно, уникальный GPT .

Эта иллюстрация познакомит вас с поддельным токенизированным ФОП под названием InvisiCash. Это демонстрирует шаги, которые пользователь должен выполнить для потока аутентификации и потока ассоциации .

Обзор потока ассоциации

1. Пользователь Google с адресом электронной почты [e-mail] хочет добавить свою учетную запись InvisiCash в Google Play Store, чтобы использовать ее для покупок.
2. В магазине Google Play открывается приложение InvisiCash для аутентификации.

3. Пользователь входит в свою учетную запись InvisiCash, используя адрес электронной почты [e-mail]. Возможно, она использует свой адрес электронной почты Gmail для обоих случаев, если это ее логин для ее учетной записи InvisiCash.

   Примечание. Существуют и другие способы аутентификации. Это только один пример. Это можно даже сделать через Интернет, а не через приложение.

4. Приложение InvisiCash отправляет идентификатор аутентификации обратно в магазин Google Play.

5. Магазин Google Play отправляет идентификатор аутентификации на серверы Google.

6. Сервер Google отправляет сообщение серверу InvisiCash для связывания учетной записи. Эта ассоциация включает идентификатор аутентификации, GPT (платежный токен Google) и идентификатор ассоциации.

7. Серверы InvisiCash хранят платежный токен Google ( GPT ) и идентификатор ассоциации. Оба теперь связаны с учетной записью Салли InvisiCash.

8. InvisiCash одобряет эту ассоциацию. Затем серверы Google создают инструмент, который можно использовать для будущих покупок.