Merchant Initiated Transactions (MITs)

Overview of MIT Support

Merchant Initiated Transactions (MITs) are transactions processed without the user being actively in session. This update to the Google Pay Online API provides enhanced visibility for these transaction types, improved user experience through dedicated billing detail UX, and better payment continuity.

Key Use Cases

  • Recurring Payments: Digital streaming services, memberships, or utilities.
  • Deferred Payments: Hotel reservations, pre-orders, or no-show fees.
  • Automatic Reloads: Stored value top-ups for transit or gift cards.

MIT API Implementation

The MIT API is an extension of the existing loadPaymentData API. Integrators must include exactly one *TransactionInfo object to specify billing intent. Google provides 3 options depending on the type of Merchant Initiated Transaction:

Transaction Type Object Name Description
Recurring RecurringTransactionInfo Used for fixed-frequency charges. Supports trials, pre-paid, and post-paid billing.
Deferred DeferredTransactionInfo Used for a single charge at a predetermined future time.
Automatic Reload AutomaticReloadTransactionInfo Used for reloading a stored-value account when a balance falls below a minimum threshold.

Integration Steps

  1. Documentation: Access the DevSite during the Early Access Program. The three new object definitions are located in the Object Reference section, and are directly linked in the preceding list.
  2. Implementation: Use the relevant *TransactionInfo object(s) for your system in your API request.
    • Note that only one object can be passed per request to the API. Determining which object to use and populating the fields is up to the individual merchant.
  3. Testing: Use the TEST environment to validate that billing details render correctly in the paysheet.
  4. Launch: Go live once parameters are verified.

Token Lifecycle Management (TLM)

Token Lifecycle Management ensures payment continuity by providing real-time notifications when secure payment tokens are updated or deactivated. For full details, see the Token Lifecycle Management documentation .

Key Token Events

  • Deactivation/Deletion: Notifies when a token is no longer usable.
  • FPAN Suffix Updates: Occurs when the underlying Funding Primary Account Number is updated.

Server Setup Requirements

Direct Merchants and Payment Service Providers (PSPs) must establish a system to receive, decrypt, and process these messages.

Requirement Description
Endpoint Secure HTTPS endpoint to receive POST calls.
Authentication Must handle signature validation and message decryption.
Response Return SUCCESS to continue notifications, or TOKEN_NOT_FOUND/TOKEN_NOT_IN_USE to stop them.
Merchant Notification PSPs will need to communicate the token status to their merchants.

Implementation Notes

The tokenUpdateUrl endpoint must be passed in with the transaction in order to receive updates for the token. For PSPs, determining how merchants will receive and populate this URL in the relevant *TransactionInfo object is the responsibility of the PSP to define.

Also note that the encrypted payload will return an additional optional field, merchantTokenId, for MITs. For specific details, see the Payment Data Cryptography documentation (for Merchants) or Payload Structure documentation (for PSPs).