Google today published new enhancements to the Google Pay API that extend support for merchant-initiated transactions (MIT), enabling developers to define recurring charges, deferred payments, and automatic account reloads directly within the payment sheet. The announcement, dated April 15, 2026, comes from Dominik Mengelt, Developer Relations Engineer, Kenneth Tu, Software Engineer, and Kushagra Patel, Senior Product Manager, and was published on the Google for Developers blog alongside a companion video tutorial on the Google for Developers YouTube channel.

The update matters because, according to the announcement, "the existing specification was primarily designed for immediate customer initiated transactions (CIT)," meaning the API lacked a structured way for merchants to signal the nature of future charges at the point of payment. That gap is now closed with three new objects added to the PaymentDataRequest.

What has changed in the API

The Google Pay API previously contained a single TransactionInfo object, which carried fields for total price, currency, and country code. Today's release introduces three additional transaction type objects alongside it: recurringTransactionInfo, deferredTransactionInfo, and automaticReloadTransactionInfo. According to the announcement, the existing TransactionInfo object remains supported, and "all those changes are completely backwards compatible."

Each new object serves a distinct billing scenario. Recurring transactions are intended for subscriptions or any situation where a user is charged at regular intervals. Within recurringTransactionInfo, developers can specify introductoryPeriodInfo for trial pricing, a recurrenceItems array describing one or more billing periods with their own price, status, and duration, a fixed price for the entire recurrence if known in advance, and a managementUrl pointing to a page where users can manage their subscription.

Deferred transactions address situations such as hotel reservations or pre-orders, where payment is authorized upfront but charged at a single point in the future. The new deferredTransactionInfo object allows developers to specify the exact date and time for that future charge, which was not possible under the previous specification.

Automatic reload transactions serve balance-based services - for example, a prepaid account that tops up automatically when it falls below a set threshold. The automaticReloadTransactionInfo object supports defining the minimum balance trigger and the reload amount. The announcement notes that merchants retain responsibility for charging according to the billing agreement and that the API object does not itself initiate the charge.

The merchant token ID and payment continuity

Beyond the three new transaction objects, the update introduces a mechanism for payment continuity across device changes and credential updates. When a user selects a card on the Google Pay sheet and one of the new transaction types is active, the decrypted payload that the payment service provider (PSP) receives contains both a DPAN (Device Primary Account Number) and a merchant token ID. The PSP is expected to store that merchant token ID alongside existing payment credentials.

According to the announcement, with a later release, tokens "not bound to a customer-specific device" will also be available, specifically to ensure continuity when a customer switches devices or modifies their Wallet. This device-agnostic token type is not yet available in today's release but is identified as forthcoming.

The merchant token ID also serves as the anchor for lifecycle notifications. When the underlying payment credential changes - for instance, if a cardholder removes their card from Google Wallet - Google sends an update notification to the integrator containing that merchant token ID. The integrator can then react: one documented use case is notifying the user to update their payment method. The announcement is explicit that "in most cases, lifecycle notifications are received and handled by the payment service providers instead of merchants."

A dedicated tokenUpdateUrl field within recurringTransactionInfo carries the webhook URL where Google sends these token lifecycle event notifications. This mechanism is designed to reduce payment declines caused by outdated or expired credentials, a common problem in subscription billing. According to the announcement, clearly flagging transactions as merchant-initiated, combined with token update mechanisms, "can potentially reduce payment declines."

Technical implementation example

The announcement includes a JSON example for a simple monthly subscription. The recurringTransactionInfo object sits at the top level of PaymentDataRequest, alongside the standard allowedPaymentMethods block. Within it, a recurrenceItems array contains a single entry with a label of "Regular Charge," a price of "9.99," a priceStatus of "FINAL," and a recurrencePeriodwith a unit of "MONTH" and a count of 1. The object also carries a managementUrl and a tokenUpdateUrl:

"recurringTransactionInfo": {
  "label": "Monthly Subscription",
  "transactionId": "SUB12345",
  "recurrenceItems": [
    {
      "label": "Regular Charge",
      "price": "9.99",
      "priceStatus": "FINAL",
      "recurrencePeriod": {
        "unit": "MONTH",
        "count": 1
      }
    }
  ],
  "managementUrl": "https://example.com/subscriptions",
  "tokenUpdateUrl": "https://example.com/api/token-updates"
}

The recurrenceItems field is an array, which means it supports multiple recurring periods within a single object - relevant when a subscription carries an introductory price that transitions to a standard rate. The introductoryPeriodInfo field handles those trial or special-pricing details as a separate sub-object within recurringTransactionInfo.

When the payment sheet is displayed with one of these new transaction types active, Google Pay renders a different UI to the user compared to a standard single payment. According to the tutorial, that modified sheet shows the user "all the important information for your recurring transaction," including billing schedule and amounts, providing transparency before authorization.

What the payment sheet presents to users

The user-facing change is meaningful. Under the previous API structure, a subscription checkout through Google Pay would show a standard payment confirmation without specific reference to the recurring nature of the charge. With recurringTransactionInfo active, the sheet explicitly surfaces the billing frequency, the amount, and - through the managementUrl- a path for users to manage or cancel the arrangement. That shift toward transparency at the point of authorization is consistent with requirements from card networks mandating clearer disclosure for recurring charges.

The announcement describes this as "improved transparency," stating that "users will have a clearer understanding of future payment schedules presented within the Google Pay interface." The deferred and automatic reload types similarly surface their respective charge terms before the user confirms.

Future-proofing and compliance framing

The announcement addresses network mandate compliance directly: "Google Pay facilitates the correct token type to ensure optimal transaction performance and meet future network mandates." This framing reflects ongoing pressure from card networks, particularly Visa and Mastercard, to ensure that MIT flows use appropriate credential types - network tokens or merchant tokens rather than raw PANs - and that intent is properly declared in authorization requests.

The tokenUpdateUrl mechanism connects to broader industry infrastructure. Mastercard's Agent Pay, launched January 11, 2026, established network-token-based infrastructure specifically to address authorization and accountability in non-customer-present transactions. Google's Universal Commerce Protocol, announced the same day, incorporated the Agent Payments Protocol for cryptographic transaction authorization. Today's Google Pay API update sits within that same technical trajectory: extending structured intent and token lifecycle management to the payment sheet itself.

The PSP dependency is worth noting. As the UCP checkout help page published March 2 documented, merchants relying on Google Pay infrastructure need PSPs that support Google Pay tokens. For MIT scenarios specifically, the PSP must be capable of storing the merchant token ID and processing the tokenUpdateUrl webhook. Merchants whose PSPs have not yet integrated these capabilities will need to coordinate an upgrade before the full lifecycle management feature is accessible.

Where this fits in the broader payments picture

Google Pay's MIT expansion connects to a wider pattern visible across the payments industry. Cloudflare's collaboration with Visa and Mastercard, announced October 24, 2025, introduced authentication protocols distinguishing between browsing agents and payment-authorized agents. Visa's tokenized payment infrastructure extended authenticated tokens to agentic commerce scenarios. Today's update addresses the more immediate, commercially active segment: subscription-based and deferred billing by existing merchants using the Google Pay button.

The subscription economy context is significant. Recurring billing is one of the highest-friction areas in digital payments. Card expiries, account changes, and device switches all create involuntary churn. A tokenUpdateUrl that fires a webhook when underlying credentials change gives PSPs and merchants a narrow window to act - either by automatically updating the stored token, or by prompting the user to re-authenticate - before a payment fails. The explicit introduction of this mechanism into the Google Pay API means that subscription businesses integrating directly with Google Pay can now build automated responses to credential changes rather than relying on passive retry logic.

The announcement notes that the three new transaction types are "now available" and points developers to the updated API reference documentation for complete details on the new objects and properties. The Google for Developers video tutorial, published today on the Google for Developers YouTube channel with 2.62 million subscribers, covers the high-level flow and a working implementation example for the recurring case. A second part of the tutorial series will address lifecycle notifications in detail.

Developers seeking support for their implementation can create a support ticket through the Google Pay and Wallet Console, and can join the discussion in the #payments channel on Discord via the Google Pay and Wallet developer community.

How the high-level integration flow works

The full MIT integration involves several distinct phases, and understanding the sequencing helps clarify where the new API objects slot in. First, the user selects a card on the Google Pay payment sheet. At that moment - because the merchant has specified one of the new transaction type objects - Google Pay returns an encrypted payload containing both a DPAN and a merchant token ID. That payload is sent to the PSP, which decrypts it and stores the merchant token ID alongside the payment credentials from that session.

From that point on, the merchant token ID acts as a stable reference. When the merchant initiates a future charge - whether that is a monthly subscription renewal, a deferred hotel charge, or an automatic top-up - the PSP uses that token to route the transaction. The underlying card network handles the actual authorization. If the card changes between the initial authorization and a future charge, Google sends a lifecycle notification to the tokenUpdateUrl carrying the merchant token ID. The PSP can then resolve the updated credential before the next charge attempt.

This flow differs from the older approach, where PSPs typically stored raw card credentials or relied on network-level card account updater services. The explicit tokenUpdateUrl webhook brings the update notification directly into the application layer, giving PSPs and, in some cases, merchants a programmatic signal they can act on immediately - rather than discovering the credential problem only at the point of a failed charge.

The announcement distinguishes between the current release and an upcoming one. Today, tokens in the payload are still bound to the customer's specific device. A later release will deliver device-agnostic tokens. That distinction matters for subscription services with long billing cycles: a user who gets a new phone and sets it up fresh could trigger a device-bound token to become invalid, even if the underlying card has not changed. Device-agnostic tokens remove that dependency, making payment continuity more robust across the full range of consumer behaviour.

Implications for subscription and deferred payment businesses

For businesses running subscription products, the change addresses two separate problems at once. On the user-facing side, the modified payment sheet provides explicit disclosure of billing terms before authorization. This reduces chargebacks driven by users who claim they did not understand a recurring charge - a persistent problem in subscription billing that card networks have tightened rules around in recent years.

On the operational side, the tokenUpdateUrl reduces passive churn from failed renewals. According to the announcement, by "clearly flagging transactions as merchant-initiated, and with mechanisms for token updates," merchants can "potentially reduce payment declines." The phrasing is careful - this is not a guarantee of reduced declines, because issuer authorization decisions depend on many factors beyond credential validity. But removing stale-credential failures as a cause of decline is a meaningful improvement for businesses where monthly renewal success rates determine revenue predictability.

For deferred payment scenarios, the ability to specify an exact future charge date in deferredTransactionInfo addresses a gap that previously required merchants to handle the timing logic entirely outside the payment API. Hotels, travel operators, and pre-order merchants must currently manage the gap between authorization and capture through their own systems. The new object does not automate the charge itself - the merchant must still initiate the transaction - but it surfaces the expected charge date to the user at the time of authorization, which aligns with card network disclosure rules for deferred transactions.

Automatic reload, the third category, is common in transit, gaming, and digital wallet top-up services. The automaticReloadTransactionInfo object with its minimum balance trigger and reload amount provides a structured way to communicate those parameters to users through the Google Pay interface, rather than relying on separate in-app disclosures. The announcement repeats the merchant's responsibility for executing the actual charge "according to the billing agreement" - the API object defines the terms but does not trigger the payment itself.

Timeline

Summary

Who: Dominik Mengelt (Developer Relations Engineer), Kenneth Tu (Software Engineer), and Kushagra Patel (Senior Product Manager) at Google published the announcement. The primary audience is developers and payment service providers integrating the Google Pay API.

What: Google released new API objects - recurringTransactionInfo, deferredTransactionInfo, and automaticReloadTransactionInfo - within the Google Pay PaymentDataRequest. The update also introduces merchant token IDs in the encrypted payload and a tokenUpdateUrl webhook for receiving lifecycle notifications when underlying payment credentials change. All changes are backwards compatible with the existing TransactionInfo object.

When: The announcement was published on April 15, 2026. The features are described as available immediately. A companion YouTube tutorial was published the same day. A second video covering lifecycle notifications in detail is forthcoming.

Where: The changes affect the Google Pay API, used by developers integrating Google Pay into web and mobile checkout flows globally. Implementation resources are available through the Google Pay and Wallet Console and the updated API reference documentation.

Why: The existing Google Pay API specification was designed primarily for immediate customer-initiated transactions, leaving merchants without a structured way to declare recurring, deferred, or balance-reload intent in the payment request. This gap created transparency limitations for users and made it harder for PSPs to implement compliant MIT flows. The update addresses involuntary churn in subscription billing by adding token lifecycle notification infrastructure, and aligns Google Pay with broader card network mandates requiring explicit MIT declaration.

Share this article
The link has been copied!