Google расширяет Google Pay API, чтобы продавцы могли точнее описывать будущие списания при настройке merchant initiated transactions. Изменение важно для подписок, отложенных списаний и автоматических пополнений баланса, потому что эти сценарии зависят от согласия пользователя сегодня на платеж, который может произойти позже.
Что изменилось в Google Pay API#
Google сообщает, что Google Pay API теперь включает новые улучшения для merchant initiated transactions, или MIT. Это платежи, которые продавец запускает позже на основании соглашения, ранее принятого пользователем.
Компания говорит, что Google Pay уже поддерживал MIT. Проблема была не в наличии функции, а в ее форме. Старая спецификация была построена в основном вокруг customer initiated transactions, где пользователь присутствует и платит сразу. Такая модель плохо подходит для будущих списаний, потому что запрос не может полностью выразить, что продавец планирует сделать позже.
Обновленный API добавляет способы описывать будущие условия платежа внутри запроса Google Pay. Это значит, что разработчик может передать структурированную информацию о модели billing, вместо того чтобы оформлять будущий платеж как слабо описанное списание с карты.
Практическая цель не ограничена одним узким checkout-сценарием. Google называет три категории MIT:
- recurring payments, например подписки
- deferred one-time payments, например бронирование отелей или pre-orders
- automatic reloads, когда баланс аккаунта пополняется после падения ниже заданного порога
По словам Google, обновление уже доступно. Разработчикам все равно нужно изучить API reference, чтобы разобраться во всех объектах и свойствах перед внедрением.
Три модели транзакций, которые Google формализует#
Первая модель — recurring payment. Она охватывает подписки и другие случаи, где с пользователя регулярно списываются средства. Google говорит, что продавцы теперь могут указывать такие поля, как introductory periods, billing frequency, fixed или variable amounts, а также duration of the recurrence.
Это полезно, потому что subscription billing часто состоит из нескольких фаз. Пользователь может начать с trial, затем перейти на introductory price, а потом продолжить по обычному monthly или yearly rate. Без структурированного способа описать такой график настройка платежа становится менее прозрачной, а processors или networks сложнее корректно классифицировать платеж.
Вторая модель — deferred one-time payment. Она нужна для случаев, когда платеж авторизуется или согласуется заранее, но списание происходит позже в одной точке. Google приводит в пример бронирование отелей и pre-orders. Новая поддержка в API позволяет продавцам указать точную дату и время будущего списания.
Это важное различие. Deferred payment — не то же самое, что бессрочное recurring agreement. Это одно будущее списание. Если API может отразить это напрямую, user interface и backend processing точнее показывают реальное намерение платежа.
Третья модель — automatic reload. Она применяется к сервисам, где пользователь поддерживает баланс, а продавец пополняет его, когда он падает ниже заданного уровня. Google говорит, что разработчики могут определить minimum balance trigger и reload amount.
Такое часто встречается в wallets, transit-style accounts, prepaid services и usage-based systems. Пользователь не подтверждает каждое пополнение вручную в момент его выполнения. Он подтверждает правило. Новые поля API должны сделать это правило понятнее.
Что могут указывать разработчики#
Google сообщает, что обновление вводит новые объекты для этих MIT-сценариев. В исходном тексте названа поддержка recurring payment schedules, future one-time payments и automatic reload configuration. Один объект указан явно: AutomaticReloadTransactionInfo.
Для recurring payments пример Google показывает объект recurringTransactionInfo с такими полями, как label, transaction ID, recurrence items, management URL и token update URL.
Пример описывает простую monthly subscription. Он включает регулярное списание 9.99, помеченное как final, с recurrence period в один месяц. Также есть management URL, где пользователь может управлять подпиской, и webhook URL для уведомлений о token lifecycle events.
Эти lifecycle notifications — одна из самых практичных частей обновления. Google говорит, что разработчики могут получать уведомления о базовом payment credential, включая обновления срока действия карты. Для recurring payments устаревшие card credentials — частая причина отказов. Если payment token можно обновлять или отслеживать чище, сервисы могут получить меньше предотвратимых перебоев.
Источник также говорит, что обновленная поддержка MIT может помочь Google Pay предоставлять правильный token type для transaction performance и будущих network mandates. Это вопрос compliance и processing, а не только улучшение UI. Payment networks все больше обращают внимание на то, как stored credentials, recurring charges и merchant-initiated payments маркируются и обрабатываются.
Практический вывод#
Для команд, которые уже принимают Google Pay, главный вывод простой: если продукт использует подписки, предзаказы, бронирования, депозиты, автопополнение или любой другой платеж после первичного согласия пользователя, старую интеграцию стоит пересмотреть.
Нужно проверить, можно ли заменить общий checkout-запрос на более точное описание MIT-сценария. Для подписок это означает явно описать schedule, сумму, периодичность, продолжительность, URL управления подпиской и обработку token lifecycle events. Для deferred one-time payments — передать дату и время будущего списания. Для automatic reload — указать порог баланса и сумму пополнения.
Это не просто косметическое изменение. Более точная разметка будущего платежа может снизить риск неправильной классификации транзакции, улучшить обработку токенов, помочь с требованиями платежных сетей и сделать условия понятнее для пользователя. Особенно важно проверить сервисы, где платежи часто падают из-за устаревших карт или где есть спорные сценарии согласия на будущие списания.
Ближайший практический шаг для разработчиков — открыть актуальную Google Pay API reference, найти новые MIT-объекты для своего сценария и обновить request payload в тестовой среде. После этого стоит проверить отображение условий для пользователя, работу management URL, прием token update notifications и поведение платежного процессора при последующих merchant-initiated списаниях.