Push provisioning and in-app provisioning are not the same and not opposites. Here is the relationship, the differences, and when to use each.
Search “push provisioning vs in-app provisioning” and the results contradict each other. Visa treats in-app as a type of push. CPI and Mastercard imply they are related but distinct. Others lumps them in with manual entry as parallel options.
The cleaner version is short.
In-app provisioning is push provisioning, delivered through a mobile app. Web push provisioning is push provisioning, delivered through a browser. They are not alternatives, they are channels.
This post sets out the definitions, the comparison, when to use each, and how digital issuance and manual entry sit alongside them.
Push provisioning is the umbrella term. It means the card programme adds a payment card to a digital wallet, such as Apple Pay, Google Pay, or Samsung Pay, on behalf of the cardholder in one tap, without manual card entry. The card is tokenised by the network and the token is delivered to the wallet.
In-app provisioning is push provisioning executed inside the card programme’s mobile app. The cardholder taps “Add to wallet” inside the app and the card flows to the wallet on the same device.
Web push provisioning is push provisioning executed through a browser. The cardholder taps “Add to wallet” on a web page or via a link delivered by email or SMS, on any device.
Manual provisioning sits outside push provisioning. The cardholder types or photographs the card details into the wallet themselves. There is no issuer involvement.
Digital issuance is a separate concept again. It refers to the digital creation of the card itself, such as a virtual card with a number, CVV, and expiry, independent of any wallet.
Push provisioning is what you typically do once a card has been digitally issued.
There are three main reasons.
First, in-app push provisioning came first.
For years, it was the only kind of push provisioning, so the two terms became interchangeable in practice. Web push only emerged as a mainstream method recently, and the language has not caught up.
Second, schemes and providers describe the same flows from their own angles.
Visa frames the work as “in-app provisioning” because its SDK is the integration point. CPI and others frame it as “push provisioning” because their service initiates it.
Both are correct.
Third, “push” gets misread as a contrast to “manual” rather than a contrast to “pull”.
In wallet language, push means the issuer is pushing the card into the wallet. The opposite is the wallet pulling the card via manual entry, not “in-app”.
The result is articles that imply push provisioning and in-app provisioning are competing options.
They are not.
One contains the other.
|
Category |
Manual Entry |
In-App Push Provisioning |
Web Push Provisioning |
|
Who initiates |
Cardholder |
Card programme, in-app |
Card programme, web |
|
Channel |
Wallet app |
Card programme’s mobile app |
Browser, on any device |
|
Cardholder steps |
Type or photograph card and complete step-up |
One tap |
One tap |
|
Card data exposure |
PAN typed into wallet |
Tokenised; PAN never moves through wallet handoff |
Tokenised; PAN never moves through wallet handoff |
|
Multi-device enrolment |
One device only |
One device only |
Yes, multiple devices in one session with Apple |
|
Best fit |
Last-resort fallback |
Mobile-first programmes with strong app adoption |
Programmes without an app, desktop users, email and SMS flows |
|
Apple non-app mandate |
Does not satisfy |
Does not satisfy, because there is no app |
Required for issuers without a mobile app |
The decision is not:
“Push or in-app?”
It is:
“In-app, web, or both, with manual entry as a fallback?”
Your card programme has a native mobile app and your customers actually use it.
The cardholder is already authenticated by the app session, the wallet SDK is embedded, and the activation moment offers the lowest-friction experience in the market.
A meaningful share of your cardholders use desktop or rarely open your app.
Your card programme has no native app at all, such as gift, benefit, prepaid, embedded, or corporate programmes.
You want to convert email and SMS activation prompts on whatever device the recipient uses to read them.
You operate in regions where Apple’s non-app mandate now requires web provisioning.
You want multi-device wallet enrolment so a cardholder can add the card to an iPhone, Apple Watch, and iPad in one session.
Keep manual entry as a documented fallback for the small minority of edge cases where push provisioning fails, such as:
Lost sessions
Unsupported devices
Scheme exceptions
It should not be a primary path.
In practice, most modern card programmes run in-app push and web push together, with manual entry as a tertiary route.
For a deeper view of each method, see:
What Is Push Provisioning
/articles/what-is-push-provisioning (article coming)
Web Push Provisioning Explained
/articles/web-push-provisioning (article coming)
No, but they are closely related.
In-app provisioning is push provisioning that happens through a mobile app. Push provisioning is the umbrella term that also covers web push.
Some industry sources use the terms interchangeably, which is the source of much of the confusion.
Yes.
Web push provisioning is push provisioning delivered through a browser instead of a native app. The underlying tokenisation and network handoff are the same.
Digital issuance is the creation of the card itself, digitally, with a number, CVV, and expiry.
Push provisioning is the act of placing that card into a digital wallet.
They are sequential:
Digitally issue the card → Push provision it into the wallet
Manual provisioning is the cardholder typing or photographing the card into the wallet.
Push provisioning is the card programme pushing the card into the wallet on the cardholder’s behalf, in one tap, with the card replaced by a network token.
Push provisioning is faster, more secure, and lower friction.
If your programme has a strong mobile app, start with in-app push for engaged users.
Add web push to cover:
Desktop users
Non-app users
Email activation flows
SMS activation flows
Most modern card programmes end up running both.
For a deeper decision framework, see the Thredd push provisioning page: /platform/digital-wallets/push-provisioning
Yes.
Thredd supports in-app and web push from a single API, across Visa, Mastercard, and American Express, into:
Apple Pay
Google Pay
Samsung Pay
Speak to our team about what operational readiness looks like for your specific card program.
