Migrating to Google UPP

Google is replacing its legacy in-app push provisioning with UPP (Unified Push Provisioning). Google uses UPP for both web and in-app provisioning, and Lithic's Web Push Provisioning integration already runs on it. This page covers what changes in your in-app integration with Lithic.

🚧

Google is ending support for legacy in-app push provisioning at the end of 2026. Every app with an in-app "Add to Google Wallet" button must be migrated before then.

What changes

1. Lithic returns a second payload.

   • Today a Google Pay provision request returns one payload, and it produces a device token so the cardholder can tap to pay.

   • UPP adds a second payload carrying the FPAN (Funding Primary Account Number), which Google saves to the cardholder's Google Account so the card can also be used for online payments.

     Parameter	Produces
     provisioning_payload	The device token used for contactless payments
     google_provisioning_payload	The card saved to the cardholder's Google Account for online payments

2. You call Lithic at a different point in the flow.

   • Today your app requests a payload from Lithic and then hands it to Google.
   • Under UPP your app starts provisioning first, and Google calls back into your app for the payment credentials. Your Lithic request belongs inside that callback.

Where the Lithic call happens

Today your app calls Lithic before it hands anything to Google:

1. Your app calls /cards/{card_token}/provision, sending digital_wallet, client_wallet_account_id, and client_device_id. Lithic returns provisioning_payload.
2. Your app passes that payload to Google's SDK to start provisioning.

Under UPP, provisioning starts first and Google calls back into your app for the payment credentials. Your Lithic call goes inside that callback:

1. Your app starts provisioning through Google's SDK, with no payload.
2. Google calls back into your app for the payment credentials, supplying a session identifier when it wants the FPAN payload.
3. From inside that callback, your app calls /cards/{card_token}/provision with the api-version: 2026-07-01 header, adding server_session_id and google_opc_requested. Lithic returns provisioning_payload and google_provisioning_payload.
4. Your app returns both payloads to Google's SDK.

Lithic API changes

The endpoint and method are unchanged.

POST https://api.lithic.com/v1/cards/{card_token}/provision

Send the api-version: 2026-07-01 header alongside your Authorization header. On this API version, all Google Pay in-app push provisioning uses UPP.

For the full parameter reference see Provision card (Digital Wallet) and the parameter table on In-App Push Provisioning.

Errors

• Sending google_opc_requested as true without server_session_id returns a 400. The request is not downgraded to a response carrying only provisioning_payload.
• If google_provisioning_payload cannot be generated, the whole request fails. There is no partial response to handle.

Testing

Google Pay UPP is not currently available in the sandbox environment.

As with web push provisioning, after your integration is finished Lithic will work with you to complete the required wallet provider launch test cases, then work with the wallet provider to review the testing and schedule a go-live date.

Migration checklist

1. Move your /cards/{card_token}/provision call inside Google's payment credentials callback.
2. Add the api-version: 2026-07-01 header to that request.
3. Send server_session_id and google_opc_requested, using the values Google supplies in the callback.
4. Read google_provisioning_payload from the response and return both payloads to Google's SDK.
5. Handle the 400 returned when google_opc_requested is true and server_session_id is absent.

Google's requirements

Google has its own client-side requirements for UPP, including changes to your app beyond the Lithic request, functional test cases, and a launch approval process. Google distributes its documentation for upgrading to UPP under access control; request access from Google.