Введение в стандартные платежи Google для операторов связи

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

Другие формы оплаты также используют токенизацию, поэтому у нас есть общий обзор токенизированных FOP , который в основном относится к выставлению счетов через оператора связи. Потоки аутентификации , ассоциации , покупки и денежного перевода более подробно описаны в этом обзоре. На этой странице представлена ​​более подробная информация в контексте выставления счетов через оператора связи.

Операторы связи присоединяются к стандартным платежам Google путем внедрения API, которые составляют следующие потоки:

Поток Описание Эквивалент спецификации DCB3
Аутентификация Идентифицирует и аутентифицирует учетную запись пользователя в системе Платежного интегратора, которая будет использоваться для осуществления платежей DCB. SMS-MO с GoogleUserToken
Ассоциация Обменяет долгосрочный токен, который, по согласованию Google и Интегратора платежей, можно использовать для совершения платежей с использованием учетной записи Интегратора платежей. обратный вызов Approver с помощью OperationUserToken и GetProvisioning()
Перевод средств Синхронно выводит средства со счета пользователя в Payment Integrator. Передача ответственности платежному интегратору Строки Auth() и CHARGE в файлах пакетных запросов.
Возвращать деньги Синхронно возвращает некоторые или все средства, связанные с предыдущим переводом средств, на счет платежного интегратора пользователя. Переносит ответственность на Google Строки REFUND в файлах пакетных запросов
Денежный перевод Расчеты на основе API, желательно ежедневно Ежемесячный счет в формате PDF, файл с данными ежемесячного счета, файл ежедневной разведки
Обновление ассоциированной учетной записи Информирует Google об изменениях в учетной записи Payment Integrator пользователя (например, лимитах транзакций или статусе обеспечения). Опрос GetProvisioning()
Мошенничество Информирует Google о транзакциях, которые были отменены из-за спора пользователя. Это используется для улучшения механизма управления рисками Google, но не влияет на денежную ответственность. Никто

Общее сравнение со спецификацией DCB3

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

Сравнение технологий стека

Вся связь через API осуществляется с использованием HTTPS POST с зашифрованным PGP и подписанным JSON. Это означает, что Google и Интегратор платежей имеют только один ключ PGP для ротации. Эти технологии также имеют лучшую поддержку, чем SOAP. Более подробно о коммуникационном стеке можно прочитать здесь .

Сравнение философии API

DCB3 в значительной степени полагается на файлы для согласования состояния платежа. В Google Standard Payments нет файлов. Вызовы API повторяются идемпотентно и бесконечно, пока не будет определено окончательное состояние.

Финальные состояния действительно являются окончательными для определенного ключа идемпотентности. Ошибки и неопределенные состояния моделируются не как отклонения, а скорее как HTTP-ответы, отличные от 200. Это позволяет нам быстрее выявлять ошибки и не маскировать их под отказы.

Новые возможности

Стандартные платежи Google поддерживают новые функции, в том числе:

  • Fraud API для информирования системы риска Google о мошенниках
  • Обновите API связанной учетной записи, чтобы информировать Google о предоставлении, лимитах транзакций и изменениях статуса учетной записи.
  • Дополнительная поддержка проверки подлинности во время покупок, например PIN-коды USSD.
  • Ежедневный цикл денежных переводов

Карта терминологии DCB3 и Google Standard Payments

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

  • Перевозчик -> Платежный интегратор

ВНИМАНИЕ: Чтобы избежать путаницы с концепцией интегратора DCB, в этом документе делается попытка использовать термины «интегратор платежей» и «интегратор DCB», а не просто «интегратор». Однако в общей документации Google Standard Payments слово «интегратор» широко используется как сокращение от «Интегратор платежей».

  • Идентификатор соглашения о выставлении счетов -> Идентификатор учетной записи платежного интегратора
  • Операторусертокен (OUT) -> GooglePaymentToken (GPT)
  • корреляция_id -> идентификатор запроса
  • Доля выручки -> комиссия

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

Общий обзор процесса аутентификации для токенизированных FOP см. на этой странице .

Особенности выставления счетов через оператора связи

Для выставления счетов через оператора связи цель процесса аутентификации — доказать, что пользователь контролирует SIM-карту, привязанную к его учетной записи оператора связи. Пользователи Carrier Billing могут пройти аутентификацию с помощью любого из этих трех механизмов:

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

Сравнение с DCB3

Поток аутентификации заменяет обратный вызов approveuser в Google на OUT из спецификации DCB3.

В DCB3 аутентификация и ассоциация были объединены в один поток. В стандартных платежах Google аутентификация не связана с привязкой аккаунта.

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

Общий обзор процесса ассоциации для токенизированных FOP см. на этой странице .

Основное различие между потоком ассоциации , используемым для инструментов выставления счетов операторов связи, и общим потоком токенизированных FOP заключается в том, что доказательство аутентификации, предоставляемое в методе associateAccount , будет варьироваться в зависимости от того, запросил ли интегратор платежей дополнительный запрос пользователя.

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

Атрибуты инструмента

В разделе «Атрибуты инструмента» общего обзора токенизированного FOP обсуждается концепция accountAlias ​​, accountNickname fullAccountNickname .

Особенности выставления счетов через оператора связи

  • accountAlias ​​должен быть номером телефона пользователя. Он будет использоваться для идентификации инструмента в случае, если пользователь обратится в службу поддержки Google по поводу своей учетной записи.
  • accountNickname и fullAccountNickname — отображаемые имена, используемые для идентификации инструмента в пользовательском интерфейсе.

Сравнение со спецификацией DCB3

Поток ассоциации заменяет следующие компоненты спецификации DCB3:

  • SOAP-вызов GetProvisioning
  • SOAP-вызов GetSubscriberAddress
  • Выходной сигнал, генерируемый несущей

Большим отличием здесь является тот факт, что Google генерирует платежный токен Google (GPT) во время потока ассоциации , а не оператор связи.

Также важно отметить, что в отличие от DCB3, где OUT привязаны к определенному BillingAgreementId, GPT не привязан к какому-либо конкретному PaymentIntegratorAccountID.

Обновить поток токенов

Общий обзор потока токенов обновления для токенизированных FOP см. на этой странице .

Особенности выставления счетов через оператора связи

Что касается инструментов выставления счетов операторов связи, мы настоятельно не рекомендуем использовать токены Google Payment Token, срок действия которых истекает, поскольку это приводит к отмене заказов на подписку. Вместо того, чтобы истекать срок действия токенов и полагаться на поток токенов обновления для их исправления, ваш вариант использования часто можно реализовать с помощью потока обновления учетной записи, описанного ниже.

Процесс обновления учетной записи

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

  • ежемесячные, дневные лимиты пользователя и лимиты транзакций по каждому элементу
  • статус подготовки учетной записи интегратора пользователя
  • тип учетной записи пользователя-интегратора (предоплата, постоплата, корпоративная и т. д.)
  • «accountAlias», «accountNickname» или «fullAccountNickname» пользователя.
  • установил ли пользователь, удалил или изменил предварительно предоставленный статический PIN-код
  • закрыл ли пользователь свою учетную запись или изменил свой номер телефона, что делает инструмент пользователя недействительным в системе Google.
  • удалить поток токенов

Сравнение со спецификацией DCB3

Процесс обновления учетной записи заменяет следующие компоненты спецификации DCB3:

  • Опрос SOAP-вызова GetProvisioning
  • Периодическая аннулирование токена

Процесс покупки

Общий обзор процесса покупки токенизированных FOP см. на этой странице .

Особенности выставления счетов через оператора связи

Некоторые операторы связи используют USSD или другую технологию для получения PIN-кода от своих пользователей во время каждой покупки. Для этих операторов вместо вызова capture() мы вызываем asynchronousCapture() и даем оператору 30 секунд, чтобы запросить у пользователя PIN-код и завершить захват. Когда окончательное состояние платежа определено, перевозчик сообщает результат Google, вызывая captureResultNotification().

Сравнение со спецификацией DCB3

Здесь есть серьезные изменения.

  • Одиночный синхронный вызов метода — capture() вместо auth() + пакетный файл
  • Никаких пакетных файлов вообще
  • Нет метода cancel() (захват + возврат вместо аутентификации + отмены)
  • Поле user_message в ответе отсутствует. Коды отклонения сопоставляются с сообщениями Google, локализованными на языке учетной записи пользователя.
  • Ключевые изменения терминологии:
    • Идентификатор корреляции → идентификатор запроса
    • BillingAgreementId → PaymentIntegratorAccountId
    • Операторусертокен -> googlePaymentToken

Сложный поток покупок

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

Поток возврата

Общий обзор процесса возврата средств для токенизированных FOP см. на этой странице .

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

Особенности выставления счетов через оператора связи

В процессе возврата средств в инструментах Carrier Billing нет ничего особенного.

Сравнение со спецификацией DCB3

Возврат средств инициируется синхронным вызовом API, а не файлом. Кроме того, для одного исходного платежа можно создать несколько частичных возвратов вместо поддержки только одного возврата полной стоимости.

Поток денежных переводов

Общий обзор потока денежных переводов для токенизированных ФОП можно найти на этой странице .

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

Особенности выставления счетов через оператора связи

remittanceStatementDetails для выставления счетов оператору связи включают дополнительные поля, которые еще не указаны в определениях API потока денежных переводов . К ним относятся:

  • доля доходовКатегория
  • позицияЦена
  • налог
  • временная метка

Для операторов связи, заключивших с Google соглашение о разделении доходов 50/50, сборы, представленные в remittanceStatementDetails , суммируются по revshareCategory , а не представляются по каждому событию.

Сравнение со спецификацией DCB3

Поток денежных переводов заменяет следующие концепции в спецификации DCB3:

  • Ежемесячный отчет о расходах/Отчет о платежах PDF
  • CSV-файл с данными ежемесячного счета.
  • CSV-файлы ежедневной разведки

Основными отличиями здесь являются удаление любых файлов и поддержка ежедневных денежных переводов. Вместо файлов сумма перевода передается через синхронный API, а другой API поддерживает запрос подробной информации о выписке о денежном переводе.

Порядок сообщения о мошенничестве

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

Особенности выставления счетов через оператора связи

В потоке уведомлений об отмене платежа нет ничего особенного в инструментах Carrier Billing.