Идентификатор аккаунта
Идентификатор учетной записи отправляется обратно с сервера интегратора во время процесса ассоциации; он используется, чтобы помочь Google идентифицировать основную учетную запись двумя способами. Во-первых, выявить несколько инструментов, которые используют одну и ту же учетную запись пользователя, чтобы оценить риск и мошенничество. Во-вторых, это используется агентами службы поддержки клиентов Google для идентификации этой учетной записи. Это значение должно однозначно идентифицировать учетную запись пользователя во всех запросах на ассоциацию, оно должно быть неизменяемым для конкретной учетной записи и должно быть идентифицируемым пользователем.
Например, если интегратор использует адрес электронной почты для идентификации, это может быть адрес электронной почты. Однако если интегратор использует адрес электронной почты для входа в систему, но этот адрес можно изменить, тогда адрес электронной почты является плохим выбором для идентификатора учетной записи. Что бы вы ни выбрали, его значение должно быть одинаковым для нескольких попыток связи с одним и тем же идентификатором пользователя интегратора платежей.
Пакет приложений Android (APK)
Формат файла пакета, используемый операционной системой Android для распространения и установки мобильных приложений.
Управление версиями API
Эта спецификация поддерживает управление версиями. Поддерживаемые версии настраиваются на сервере Google. При переходе с версии N на M (где M — это основная версия, превышающая N) интегратор должен поддерживать как N, так и M, пока Google не проверит, что весь трафик был перенесен в M. Версии идентифицируются по-разному в зависимости от контекста. API Android и API WebRedirect передадут версию API в качестве параметра запроса. Вызовы между серверами передают версию как часть URL-пути.
Версии не фиксируются потоком. Таким образом, во время миграции с N на M интегратор может увидеть захват с версией M и возврат с версией N для одной и той же транзакции. Во время ассоциации интегратор может получить запрос аутентификации версии M с запросом ассоциации версии N.
Идентификатор ассоциации
associationID определяет связь между учетной записью клиента и инструментом Google. associationId очень похож на GPT. Фактически, он имеет тот же срок жизни, что и GPT, и имеет мощность 1:1 по сравнению с GPT. associationId отличается от GPT своей чувствительностью. GPT — это конфиденциальный токен, который используется для платежей. associationId — это общедоступный идентификатор, представляющий ту же связь, но не столь конфиденциальный по своей природе.
associationId передается интегратору платежей во время associateAccount . Это же значение передается при повторной аутентификации интегратору. Это позволяет интегратору иметь представление о том, какая учетная запись должна быть аутентифицирована. Если передается идентификатор ассоциации, необходимо предварительно заполнить и аутентифицировать ту же учетную запись, которая была идентифицирована во время исходной связи.
Ожидается, что платежный интегратор сохранит все идентификаторы ассоциации и свяжет их с определенной учетной записью интегратора на протяжении всего срока действия контракта между интегратором и Google.
Идентификатор запроса аутентификации
Методы refreshToken , associateAccount и (необязательно) capture ссылаются на аутентификацию. Эта ссылка имеет форму requestId конкретной аутентификации, на которую ссылается Google. Это поле должно использоваться платежным интегратором для проверки того, что метод действительно прошел успешную аутентификацию.
Методы захвата могут иметь заполненный requestId аутентификации. Это происходит в двух случаях. Если Google аутентифицирует пользователя непосредственно перед захватом, Google заполняет поле requestId аутентификации. Кроме того, Google часто проверяет подлинность пользователя во время настройки автоматического графика платежей. Google записывает requestId аутентификации в это расписание и отправляет requestId вместе с каждым захватом, связанным с этим конкретным расписанием.
Ожидается, что платежные интеграторы будут хранить все requestIds аутентификации в течение 30 дней. Если интегратор платежей хочет проверить requestIds аутентификации, которые могут присутствовать в запросе на захват, в том числе включенные в графики платежей, тогда интегратор должен хранить все requestId аутентификации на протяжении всего срока действия контракта между интегратором и Google.
Компания
Компания – это концепция, определенная в конфигурации и контракте Google. Компания определяет отношения между интегратором и Google. Ключи PGP и (необязательно) корневые центры сертификации SSL связаны с компанией. Самое главное, что компания связана с одним или несколькими идентификаторами учетных записей платежного интегратора. GPT, созданные внутри компании, в основном работают для всех идентификаторов учетных записей платежных интеграторов внутри компании. Некоторые исключения действительно применяются. Например, если GPT связан со счетом, выраженным в одной валюте (и не поддерживает комиссии за обмен валюты), и пытается совершить покупку по идентификатору счета интегратора платежей в другой валюте.
Форма оплаты (ФОП)
Все транзакции включают одну или несколько форм оплаты (FOP), таких как кредитная карта или электронный денежный перевод, которые используются либо пользователями для оплаты продуктов или услуг Google, либо Google для оплаты пользователям в случае пользователей AdSense и Google. Разработчики игры. Формы оплаты также часто называют Платежными инструментами, Инструментами и Способами оплаты.
Платежный токен Google (GPT)
GPT — это случайное, безопасное для Интернета значение в кодировке Base64, создаваемое сервером Google во время ассоциации и передаваемое на сервер интегратора. GPT – это частный идентификатор, который представляет связь между учетной записью пользователя у интегратора и инструментом Google. GPT — это токен, который заменяет учетные данные пользователя или идентификатор учетной записи. Этот токен используется во время потоков покупок для идентификации счета для пополнения или дебетования и является секретным для обеих сторон. GPT никогда не должен отправляться в виде открытого текста и должен быть зашифрован для обеспечения конфиденциальности.
GPT отличается от associationId , поскольку associationId не защищен и свободно передается общедоступными средствами (URL-адреса, небезопасные соединения). GPT известен только Google и интегратору.
Ожидается, что платежный интегратор будет хранить все GPTS и связывать их с определенной учетной записью интегратора на протяжении всего срока действия контракта между интегратором и Google.
Идемпотентность
Идемпотентную операцию можно применять несколько раз без изменения результата или новых побочных эффектов, помимо первоначального применения операции. Обычно идемпотентность использует «ключ» для идентификации одного и того же запроса. Все запросы, определенные между двумя серверами, используют ключ идемпотентности, определенный в заголовке запроса. Заголовок запроса имеет идентификатор запроса, который используется в качестве ключа идемпотентности. Идентификатор запроса глобально уникален. Идемпотентные запросы должны представлять собой одно и то же тело JSON, за одним исключением. requestTimestamp будет разным для каждого запроса. Это важное различие. requestTimestamp — это время, когда сервер отправил этот запрос. И уникален для каждой попытки. Это помогает снизить вероятность повторных атак. Аналогично, идемпотентный ответ должен представлять собой одно и то же тело JSON, за исключением того, что responseTimestamp будет разной для каждого ответа.
Все межсерверные методы, за исключением метода Echo, должны быть идемпотентными. Запросы аутентификации к пользовательскому интерфейсу интегратора (будь то Android или Интернет) не являются идемпотентными.
Примеры идемпотентного поведения см. в справочном документе .
Идентификатор (ID)
Идентификаторы представляют собой транзакцию или связь между платежным интегратором и Google.
Инструмент
Этот инструмент представляет собой сохраненный способ оплаты, связанный с одним клиентом Google. Примеры инструментов включают в себя:
- Номер кредитной карты в файле
- Банковский счет и маршрутный номер
Пользователи могут иметь несколько инструментов, связанных с их личностью Google.
микро
Денежные значения в этом API представлены в формате «микро», стандарте Google. Микро — это целочисленный формат с фиксированной точностью. Чтобы представить денежную стоимость в микромах, умножьте стоимость стандартной валюты на 1 000 000.
Например:
- 1,23 доллара США = 1 230 000 микродолларов США
- 0,01 доллара США = 10 000 микродолларов США
Платежный интегратор
Внешний интегратор, обрабатывающий платежи по транзакции пользователя.
Идентификатор аккаунта платежного интегратора
Этот идентификатор представляет собой ограничения по контракту между Google и интегратором. Идентификатор учетной записи интегратора генерируется Google и назначается интегратору во время установки. Обычно это называется «MID». Все запросы и ответы должны включать этот идентификатор. Этот идентификатор непрозрачен и никогда не должен анализироваться. Формат этого идентификатора может быть неодинаковым для всех выданных идентификаторов.
Этот идентификатор никогда не меняется на протяжении всего времени транзакции. В случае захвата и возврата используется один и тот же идентификатор.
Ограничения идентификатора учетной записи интегратора определяются самим контрактом. Как правило, ограничения связаны с выставлением счетов. Например, интегратор поддерживает выставление счетов в долларах США и MXN, но требует, чтобы транзакции в евро выставлялись в евро. В этом случае будут использоваться два разных идентификатора аккаунта платежного интегратора: один для выставления счетов в долларах США, а другой — для выставления счетов в евро.
Идентификатор может быть заменен новыми идентификаторами. В случае, если идентификатор устарел, Google прекратит сбор данных по этому идентификатору. Однако интегратор должен осуществлять возврат средств за транзакции, совершенные с этим идентификатором, в течение одного года с момента последней инициации захвата (инициация захвата определяется как метка requestTimestamp , найденная в requestHeader ).
Личные данные
Информация, позволяющая установить личность (PII), — это информация, которая идентифицирует личность человека, а также любые другие данные, которые могут быть разумно связаны с такой информацией Google, например имя пользователя, адрес электронной почты, почтовый адрес или номер телефона, отдельно или в сочетании.
Идентификатор запроса
requestId идентифицирует весь обмен данными между Google и платежным интегратором.
СПИИ
Конфиденциальная информация, позволяющая установить личность (SPII) — это подмножество информации, позволяющей установить личность (PII), которая представляет высокий риск для пользователя в случае ее компрометации или неправильного использования. SPII часто имеет ограничительные требования к обращению и хранению, налагаемые юридическими, нормативными или нормативными органами.
Токен
Токены добавляют дополнительный уровень безопасности при обмене конфиденциальными учетными данными, такими как PII или SPII, между Google и интегратором.
Адрес пользователя
Во время создания инструмента Google проверяет, является ли пользователь клиентом Google Payments. Это не зависит от того, являетесь ли вы клиентом Google. Чтобы стать клиентом Google Payments, нам нужен платежный адрес пользователя. Некоторые регулирующие органы требуют, чтобы мы знали полный адрес пользователя, в то время как другие требуют части этого адреса.
Если у платежного интегратора есть адрес этого пользователя, Google хотел бы получить этот адрес во время процесса связывания, чтобы предварительно заполнить форму адреса для пользователя. Пользователь имеет возможность изменить предварительно заполненный адрес. Предварительное заполнение адреса пользователя уменьшает трудности при добавлении инструмента и увеличивает коэффициент конверсии пользователей, добавляющих эти инструменты.
Если адрес является общим, Google также использует его для расчета в своей модели рисков. Это позволяет механизму управления рисками Google понять адрес, по которому, по словам пользователя, ему выставляются счета, и сравнить его с IP-адресом, по которому в данный момент находится пользователь.
Совместное использование адресов — это чисто оптимизация. Это нормально и ожидается, что некоторые интеграторы не будут иметь платежный адрес для пользователя или не смогут поделиться этим адресом.
Веб-безопасная кодировка Base64
Стандарт кодирования, указанный в разделе 5 RFC 4648, Кодировка Base 64 с безопасным алфавитом URL и имени файла, также иногда называемый «веб-безопасной кодировкой Base64» или «base64url». (Это то же самое, что кодировка base64 с безопасным алфавитом URL и имени файла из раздела 4 RFC 3548.) Все зашифрованные и подписанные значения должны быть закодированы с использованием этого стандарта.