Идентификатор учетной записи
Идентификатор учетной записи отправляется обратно с сервера интегратора во время потока ассоциации; он используется, чтобы помочь 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 — это время, когда сервер отправил этот запрос. И уникален для каждой попытки. Это помогает уменьшить возможность повторных атак.
Все межсерверные методы, кроме метода Echo, должны быть идемпотентными. Запросы аутентификации к пользовательскому интерфейсу интегратора (будь то Android или Интернет) не являются идемпотентными.
Примеры идемпотентного поведения см. в справочном документе .
Идентификатор (ID)
Идентификаторы представляют транзакцию или связь между платежным интегратором и Google.
Инструмент
Инструмент представляет собой сохраненный способ оплаты, связанный с одним клиентом Google. Примеры инструментов включают:
- Номер кредитной карты в файле
- Банковский счет и маршрутный номер
Пользователи могут иметь несколько инструментов, связанных с их идентификатором Google.
микро
Денежные значения в этом API представлены в формате, называемом «микро», который является стандартом Google. Micros — это целочисленный формат с фиксированной точностью. Чтобы представить денежное значение в микро, умножьте стандартное значение в валюте на 1 000 000.
Например:
- 1,23 доллара США = 1 230 000 микродолларов США
- 0,01 доллара США = 10000 микродолларов США
Платежный интегратор
Внешний интегратор, обрабатывающий платежи по транзакции пользователя.
Идентификатор аккаунта платежного интегратора
Этот идентификатор представляет собой ограничения по договору между Google и интегратором. Идентификатор учетной записи интегратора создается Google и назначается интегратору во время установки. Обычно это называется «MID». Все запросы и ответы должны включать этот идентификатор. Этот идентификатор непрозрачен и никогда не должен анализироваться. Формат этого идентификатора может не соответствовать всем выпущенным идентификаторам.
Этот идентификатор никогда не меняется в течение всего времени существования транзакции. В случае захвата и возврата используется один и тот же идентификатор.
Ограничения идентификатора учетной записи интегратора определяются самим контрактом. Как правило, ограничения связаны с выставлением счетов. Например, интегратор поддерживает выставление счетов за CAD и 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
Стандарт кодирования, указанный в RFC 4648, раздел 5, Кодировка Base 64 с URL-адресом и безопасным алфавитом имени файла, также иногда называемый кодировкой Base64 или base64url, безопасной для Интернета. (Это то же самое, что и кодировка base64 с URL-адресом и безопасным алфавитом имени файла из RFC 3548, раздел 4.) Все зашифрованные и подписанные значения должны быть закодированы с использованием этого стандарта.