Abstract:
This technical briefing outlines the implementation of Merchant-Initiated Transactions (MITs) within the Google Pay API framework. The update introduces specialized support for recurring billing, deferred payments, and automatic reloads. Key architectural enhancements include the provision of payment tokens that are decoupled from specific customer devices, ensuring payment continuity during hardware upgrades or wallet modifications. The system introduces a "Merchant Token ID" within the encrypted payload, facilitating asynchronous lifecycle notifications. These notifications allow Payment Service Providers (PSPs) to maintain up-to-date credential status. The API update is designed for full backwards compatibility, extending the existing transactionInfo object with new, use-case-specific data structures.
Implementation of Google Pay Merchant-Initiated Transactions (MITs)
0:00 MIT Use Case Expansion: The Google Pay payment sheet now supports three primary merchant-initiated categories: automatic reloads, deferred transactions, and recurring billing.
0:34 Payment Continuity & Device Decoupling: The feature enables the acquisition of payment tokens not bound to a specific consumer device. This architecture prevents service interruptions when users switch devices or update wallet configurations.
1:00 Lifecycle Notification Architecture: Google Pay now issues lifecycle notifications for underlying credential changes. When a user modifies or removes a card, Google sends an update containing the Merchant Token ID to the integrator (typically the PSP).
1:16 Data Flow & Token Exchange: During the initial transaction, the Google Pay sheet returns a DPAN and a Merchant Token ID within an encrypted payload. The PSP must store this ID alongside existing credentials to map future lifecycle events.
2:12 API Payload Schema Updates: The API introduces three new transaction objects: recurringTransactionInfo, deferredTransactionInfo, and automaticReloadTransactionInfo. These sit alongside the standard transactionInfo object.
2:44 Backwards Compatibility: The integration is designed to be backwards compatible; developers select the specific transaction type required for their business model without breaking existing implementations.
3:03 Recurring Transaction Implementation: For subscription models, the recurringTransactionInfo object requires specific parameters: recurrence period (e.g., monthly), period count, descriptive label, and the initial billing timestamp.
3:46 PSP Storage Requirements: Success for MIT scenarios relies on the PSP storing the Merchant Token ID provided in the decrypted payload. This ID serves as the primary key for identifying the correct token when receiving lifecycle management updates.
4:17 Technical Resources: Implementation details and input parameters are documented in the updated API reference, with further technical support available via the Google Pay and Wallet developer community on Discord.