Подлежит уточнению: добавьте краткое описание электронного кошелька (так же, как это было сделано для eMoney).
Будет определено позже: посмотрите демонстрацию работы электронного кошелька после того, как вы подключите свой FoP к объектам Google.
Ниже описаны основные потоки стандартных платежей Google, которые участвуют в транзакциях электронного кошелька.
Поток ассоциации
Стандартные платежи Google позволяют интеграторам создавать поток создания инструментов и поток покупок, чтобы обеспечить быструю и удобную процедуру оплаты для своих пользователей.
У клиента Google есть один или несколько инструментов. Инструмент – это способ оплаты услуг и товаров в различных экосистемах и торговых площадках Google. Чтобы добавить инструмент, пользователь должен связать инструмент с внешними учетными данными и подтвердить подлинность этих учетных данных. Хорошим примером этого является кредитная карта. Кредитная карта имеет номер карты (PAN), который хранится в Google, и проверочный номер карты (CVN), который используется для аутентификации. Пользователь добавляет инструмент, вводя PAN и CVN в пользовательском интерфейсе Google. Google надежно сохраняет PAN после того, как процессор кредитных карт проверит номера PAN и CVN. Аналогичным образом в этой спецификации мы свяжем подтверждение аутентификации с инструментом на стороне Google. Мы называем эту привязку счета к инструменту потоком ассоциации.
Результатом потока ассоциации является обмен платежным токеном Google (GPT), который согласован как Google, так и интегратором. Во время сбора GPT передается интегратору платежей (который владеет учетной записью пользователя) для идентификации учетной записи пользователя, с которой выставляется счет.
Существует множество способов аутентификации пользователя, чтобы доказать право собственности на учетную запись. Имена пользователей и пароли — это один из способов, однако OTP, биометрическая информация и контрольные вопросы также являются жизнеспособными решениями. Google не намерен диктовать, как платежный интегратор проверяет пользователя. Мы считаем, что платежный интегратор делает это лучше всего. Поэтому в рамках этой спецификации Google хочет использовать различные пользовательские интерфейсы платежного интегратора для аутентификации пользователя и просто предоставить Google подтверждение аутентификации. Мы называем это потоком аутентификации.
Выходные данные потока аутентификации являются доказательством аутентификации.
Для потока ассоциации требуется, чтобы Google предоставил подтверждение аутентификации платежного интегратора. Перед потоком ассоциации Google вызывает поток аутентификации для получения этого доказательства.
В приведенном ниже примере показаны шаги, которые должен выполнить пользователь для потока аутентификации и потока ассоциации. В приведенном ниже примере вы познакомитесь с поддельным электронным кошельком под названием InvisiCash.
Примечания к этой схеме:
- На шагах 1 и 3 обратите внимание, что личность пользователя (адрес электронной почты) в Google и InvisiCash различается.
sf@gmail.comиsally@otheremail.comсоответственно. Это нормально и ожидаемо. - Между шагами 3 и 4 приложение InvisiCash (или веб-интерфейс, если у пользователя не установлено приложение) может делать все необходимое для аутентификации пользователя, включая общение с сервером InvisiCash.
Поток покупок
Как только связь будет завершена и у пользователя появится новый инструмент, он сможет использовать его для покупки товаров и услуг через Google. На момент покупки пользователь может находиться в сеансе, а может и не находиться. Все зависит от контекста покупки. Например, при покупке на основе подписки пользователь, скорее всего, не будет в сеансе. Во время покупки Google представит GPT платежному интегратору. Платежный интегратор будет использовать этот GPT для определения правильного счета для дебетования. Это называется потоком покупок.
Пример ниже продолжается после того, как пользователь sf@gmail.com выполнил ассоциацию и инструмент был создан. Теперь пользователь хочет приобрести товар.
Иногда платежный интегратор или Google могут потребовать от пользователя пройти аутентификацию перед совершением покупки. Для этого есть разные причины. Например:
- Система риска Google определяет, что платеж выглядит подозрительно
- Нормативные требования требуют OTP при каждой покупке.
В таких случаях Google объединит процесс аутентификации с процессом покупки. Пользователь будет отправлен в пользовательский интерфейс интегратора для аутентификации. Результатом потока аутентификации является подтверждение личности и аутентификации пользователя. Это подтверждение затем отправляется вместе с информацией о покупке во время процесса покупки.
В приведенном ниже примере пользователь sf@gmail.com выполнил ассоциацию и инструмент был создан. Во время процесса покупки сервер Google желает бросить вызов этому пользователю для защиты от мошенничества:
Обновить поток токенов
Во время процесса связывания платежный интегратор может сообщить Google, что срок действия этого GPT истекает через X месяцев. Хотя Google предпочитает токены с неограниченным сроком действия, он признает, что это не всегда так, и поэтому поддерживает срок действия токена. В случаях, когда срок действия токена подходит к концу, Google отправляет пользователя через поток аутентификации. Пользователь отправляется в пользовательский интерфейс интегратора для аутентификации. Результатом потока аутентификации является подтверждение личности и аутентификации пользователя. Это доказательство затем отправляется интегратору для продления срока действия GPT. Это называется потокомrefreToken.
Пример ниже продолжается после того, как пользователь sf@gmail.com выполнил ассоциацию и инструмент был создан. Срок действия токена пользователя скоро истекает, поэтому Google просит пользователя обновить свой инструмент:
Поток аутентификации используется в двух разных модальностях. Первый — при попытке аутентификации пользователя во время ассоциации. В настоящее время личность пользователя неизвестна, и пользователь должен ввести ее. Идентификация может выглядеть как имя пользователя, адрес электронной почты или номер телефона. Второй метод пытается подтвердить, что пользователь знает учетные данные для существующего инструмента. В этой ситуации пользователь уже добавил инструмент и связал свою учетную запись платежного интегратора. В этом методе мы хотим проверить, что у человека есть учетные данные для определенного идентификатора пользователя. Пользователь не должен иметь возможности изменить личность проверяемой учетной записи. Для этого мы отправляем платежному интегратору идентификатор ассоциации во время ассоциации. Во время аутентификации Google отправляет интегратору тот же идентификатор ассоциации. Интегратор использует идентификатор ассоциации для поиска учетной записи, которую необходимо аутентифицировать.
Поток денежных переводов
Google является учетной системой и ведет учет денежных переводов. Ежедневно Google отправляет отчет о денежном переводе платежному интегратору. В заявлении содержится сводная информация о сумме, которую платежный интегратор должен Google, а также инструкции о том, как платить Google. Чтобы платежный интегратор мог выполнить сверку, он может запросить у Google сведения об уровне транзакции, которые составляют отчет о денежном переводе.
Ниже приведен пример потока: 