In-App Push Provisioning

Let cardholders add a card to Apple Pay or Google Wallet by tapping a button in your app, rather than typing their card details.

In-app push provisioning lets a cardholder add a card to their wallet by tapping a button in your app, instead of typing card details. It converts far better than manual entry and removes the step where cardholders mistype a PAN.

It is the one provisioning method that requires integration work: with the wallet provider’s SDK, and with Synctera to obtain the payload that SDK expects.

Before you build, your program needs push provisioning entitlements from Apple and Google, and must pass their UX reviews. See Program Setup.

Apple Pay

Shell

curl -X POST "$baseurl/v2/cards/{CARD_ID}/digital_wallet_tokens/applepay" \
  -H "Authorization: Bearer $apikey" \
  -H 'Content-Type: application/json' \
  --data-binary '{
    "device_type": "MOBILE_PHONE",
    "provisioning_app_version": "2.13.7",
    "certificates": [
      "MIIEPDCCA+KgAwIBAgICEAAwCQYHKoZIzj...",
      "MIIDZjCCAw2gAwIBAgIJAJx22AGaEPSgMA..."
    ],
    "nonce": "vXWJaBidcTLaJJCF",
    "nonce_signature": "jD4Aphu+93N2wbBn"
  }'

The certificates, nonce, and nonce_signature come from Apple’s SDK. The response returns encrypted_pass_data, activation_data, and ephemeral_public_key to pass back to it.

See Create Digital Wallet Token for Apple Pay.

Google Wallet

Google is replacing its legacy push provisioning APIs with Unified Push Provisioning (UPP) and has announced it will deprecate the legacy APIs by the end of 2026. UPP also saves the card to the cardholder’s Google Account, so it can be added on their other Google devices.

Synctera offers a separate endpoint for each. Use googlepay_upp with Google’s UPP SDK, and googlepay with the legacy SDK. An app uses one or the other.

	Legacy	Unified Push Provisioning
Endpoint	/cards/{card_id}/digital_wallet_tokens/googlepay	/cards/{card_id}/digital_wallet_tokens/googlepay_upp
Google SDK	Legacy TapAndPay push provisioning	Unified Android push provisioning
Returns	opaque_payment_card	opaque_payment_card, and google_opaque_payment_card when requested

Before you start

UPP requires a Google business profile for the card issuer, set up in Google’s Issuer Console and linked to your processor’s profile. The issuer of record for your program sets this up, not Synctera. Follow Google’s onboarding guidance, and confirm with your sponsor bank and your Implementation & Onboarding manager who holds it. googlepay_upp needs it in place.

Unified Push Provisioning

Shell

curl -X POST "$baseurl/v2/cards/{CARD_ID}/digital_wallet_tokens/googlepay_upp" \
  -H "Authorization: Bearer $apikey" \
  -H 'Content-Type: application/json' \
  --data-binary '{
    "device_type": "MOBILE_PHONE",
    "provisioning_app_version": "2.13.3",
    "wallet_account_id": "ae25OGhjZTk2dsr452dgsr51",
    "device_id": "W85OGhjZTk2dsr452dgsr51j",
    "server_session_id": "123e4567-e89b-12d3-a456-426614174000"
  }'

The request takes the same fields as the legacy endpoint, plus two optional ones:

Field	Description
server_session_id	The session ID from Google’s SDK, as a UUID. Send it only when Google asks for the Google Opaque Payment Card (OPC). Without it, google_opaque_payment_card is not returned.
token_requestor_id	Required when tokenizing a Visa card to a Fitbit device. The request fails without it.

See Create Digital Wallet Token for Google Pay (UPP).

The response returns two payloads for Google’s SDK:

• push_tokenize_request_data.opaque_payment_card: the OPC used to create the device token.
• google_opaque_payment_card: the OPC that saves the card to the cardholder’s Google Account. Returned only when you sent server_session_id.

How it fits Google’s SDK

Google’s SDK calls a generator you provide when it needs the payloads. In that callback, call your backend, which calls Synctera, and hand the results back to the SDK.

1. Set a payment credentials generator on the push tokenize request in your app.
2. When Google calls it, send your backend the IDs from Google’s request (the wallet, device and session IDs) together with the card ID.
3. Your backend calls googlepay_upp. Include server_session_id only if Google requested the Google OPC.
4. Return opaque_payment_card and, if present, google_opaque_payment_card to the SDK.

Two other changes in your app:

• Show Add to Google Wallet when the cardholder has an eligible device to tokenize to, not only when the card isn’t already tokenized.
• Supply the cardholder’s address to Google in the push request. Synctera does not return it.

Like the legacy endpoint, googlepay_upp works only in production. See Tokenization Overview.

googlepay_upp is not yet available for every card program. For cards that don’t support it, the request fails with IN_APP_PROVISIONING_NOT_SUPPORTED. Keep using googlepay for those cards until your Implementation & Onboarding manager confirms support.

Migrating from the legacy endpoint

The legacy googlepay endpoint keeps working. To migrate, release an app version built on Google’s UPP SDK and switch its backend to googlepay_upp.

Both endpoints require the same permissions, return 404 for an unknown card, and apply the same card checks. The card must be active, and its card product must have in-app provisioning enabled.

Legacy

Google has announced it will deprecate this API by the end of 2026. New integrations should use Unified Push Provisioning.

Shell

curl -X POST "$baseurl/v2/cards/{CARD_ID}/digital_wallet_tokens/googlepay" \
  -H "Authorization: Bearer $apikey" \
  -H 'Content-Type: application/json' \
  --data-binary '{
    "device_type": "MOBILE_PHONE",
    "provisioning_app_version": "2.13.3",
    "wallet_account_id": "ae25OGhjZTk2dsr452dgsr51",
    "device_id": "W85OGhjZTk2dsr452dgsr51j"
  }'

The response returns push_tokenize_request_data for Google’s SDK.

See Create Digital Wallet Token for Google Pay.

Next Steps

Token Lifecycle Management

What happens to the token once it exists.

Provisioning Decisions

Why a provisioning attempt is challenged or refused.