Category: User Provisioning
Push Provisioning
Also known as: In-App Provisioning, Card Push Provisioning
Simply put
Push provisioning is a process that lets a consumer add a payment card to a digital wallet quickly and securely, typically directly from a bank's or card issuer's app rather than by manually typing in card details. Instead of the wallet 'pulling' the card in, the issuer 'pushes' the card credential into the wallet on the cardholder's behalf. It is used to speed up and simplify card issuance to digital wallets.
Formal definition
In the payments domain, push provisioning is the issuer- or partner-initiated process of provisioning a card's payment credentials to a digital wallet, commonly implemented as in-app provisioning where issuer or partner developers push a customer's digital card into a wallet. In most deployments it is closely associated with digital tokenization, whereby the underlying card credentials are represented by a token supplied to the wallet rather than the raw primary account number, though the exact tokenization mechanics depend on the network and wallet involved. Scope note: this term as used in the cited payments-industry evidence refers specifically to payment-card provisioning to digital wallets and is distinct from IAM identity-lifecycle provisioning (for example SCIM-based account provisioning); the evidence provided does not address the IAM sense, so that meaning is out of scope for this entry.
Why it matters
Push provisioning has become a foundational capability for card issuers and wallet providers because it removes friction from the moment a cardholder wants to use a card in a digital wallet. Rather than asking a consumer to manually key in a primary account number, expiration date, and security code, a process prone to typos, abandonment, and step-up verification failures, the issuer or its partner pushes the card credential directly into the wallet from within a trusted app. This simplifies and accelerates card issuance to digital wallets, which matters for issuers seeking higher activation and top-of-wallet placement, and for wallet providers seeking smoother onboarding.
Who it's relevant to
Card issuers and issuing banks
Issuers use push provisioning to let cardholders add debit or credit cards to digital wallets directly from the issuer's app, simplifying and accelerating card issuance to digital wallets. This is relevant to teams responsible for card programs, digital banking apps, and activation metrics.
Wallet providers
Push provisioning helps wallet providers by streamlining the onboarding of new cards, reducing manual entry and its associated friction. Wallet providers define the specifications that issuer and partner developers integrate against.
Issuer and partner developers
In-app provisioning is the process used by issuer and partner developers to implement push provisioning of a customer's digital card to a digital wallet. These developers integrate with network and wallet APIs and, in most deployments, with digital tokenization mechanisms whose specifics depend on the network and wallet involved.
Payment credential and tokenization service teams
Because push provisioning is commonly associated with digital tokenization, representing card credentials as a token rather than the raw primary account number, teams operating card provisioning and tokenization services (including SaaS-based provisioning offerings) are directly involved in enabling and securing the flow.
Scope note for IAM practitioners
This entry addresses push provisioning strictly in the payments sense of provisioning payment-card credentials to digital wallets. It is distinct from the IAM sense of identity-lifecycle provisioning (for example, SCIM-based account provisioning). The evidence used here does not address the IAM meaning, so that sense is out of scope for this entry.
Inside Push Provisioning
Push model of provisioning
An account-provisioning pattern in which the identity source (typically an identity provider or IGA system) initiates and sends account create, update, and deactivate operations outward to downstream service providers or applications, rather than waiting for the target to request or pull that data.
Provisioning source of authority
The system that holds the authoritative identity lifecycle state and drives push operations. In most IGA deployments this is an HR system, IGA platform, or IdP that determines when a downstream account should be created, changed, or removed.
SCIM as a common transport
The System for Cross-domain Identity Management protocol is frequently used to implement push provisioning, with the source acting as a SCIM client issuing REST operations (for example POST, PATCH, PUT, DELETE) against a SCIM service provider endpoint on the target application. Push provisioning is a pattern, not a single standard, and can also be implemented with vendor-specific connectors.
Target application connector
The integration component on the downstream side that receives pushed operations and applies them to the application's own user store. Its capabilities vary by vendor, and supported attributes or operations depend on the connector and the target's API.
Lifecycle events
The joiner, mover, and leaver triggers that cause push operations, such as onboarding an account, updating attributes or group memberships, and deactivating or deleting an account on separation. This is an identity governance and administration concern, distinct from runtime access enforcement such as token validation at a PDP or PEP.
Common questions
Answers to the questions practitioners most commonly ask about Push Provisioning.
Is push provisioning in IAM just another name for SCIM?
Not exactly. SCIM (System for Cross-domain Identity Management) is a specific standard that defines a REST/JSON protocol and schema for identity lifecycle operations. Push provisioning in the IAM sense describes the general pattern where an authoritative source (typically an identity provider or IGA platform) initiates and sends identity data to downstream target systems, rather than having each target pull or poll for changes. SCIM is one common way to implement push provisioning, but push provisioning can also be realized through vendor-specific connectors, proprietary APIs, or directory synchronization. Treating the two as synonyms conflates a general provisioning pattern with one particular standard that implements it.
Does push provisioning handle authentication or grant users access at runtime?
No. Push provisioning is an identity governance and administration (IGA) lifecycle concern: it creates, updates, deactivates, or deletes accounts and attributes in target systems ahead of or in response to lifecycle events. It does not authenticate a user and does not make runtime authorization decisions. When a provisioned user later signs in, authentication is handled separately (for example via SAML 2.0, OpenID Connect, or the target's own credential mechanism), and authorization is evaluated at access time. Provisioning may populate the roles, group memberships, or attributes that a downstream access decision later relies on, but the enforcement step is distinct from the provisioning step.
How do you decide between push provisioning and pull-based (or just-in-time) provisioning?
The choice typically depends on when accounts must exist and how targets consume identity data. Push provisioning is often preferred when accounts must be present before first login, when deprovisioning must happen promptly for security or compliance reasons, or when the target cannot create accounts on the fly. Just-in-time (JIT) provisioning, by contrast, commonly creates or updates the account during an authentication flow (for example from SAML or OIDC assertions) and can reduce dormant accounts, but it generally cannot remove access on its own and does not act until the user attempts to sign in. Many deployments combine both: push for creation and deprovisioning, JIT for attribute updates at login. The right balance depends on the target's capabilities and your governance requirements.
How is deprovisioning typically handled in a push model?
In most push deployments, a lifecycle event in the authoritative source (such as termination or role change) triggers a provisioning operation against the target. Depending on the target and configuration, this may disable, delete, or modify the account. Behavior varies significantly: some targets support soft-disable, some only support deletion, and some retain data after account removal. Because deprovisioning is often the highest-risk operation from a security and compliance standpoint, teams commonly favor deactivation over hard deletion where reversibility and audit retention matter, and they should verify how each connector maps a deprovisioning action to the target's native semantics.
What should you monitor to ensure push provisioning stays reliable?
Common signals include provisioning job success and failure rates, latency between a source event and the target update, reconciliation results that detect drift between the authoritative source and target state, and error patterns from individual connectors. Because push operations can fail silently at the target (for example due to schema mismatches, rate limits, or permission changes), periodic reconciliation or audit comparison is typically recommended rather than relying solely on the assumption that a sent operation succeeded. Logging each provisioning action also supports access certification and audit evidence.
How do access reviews and segregation of duties relate to push provisioning?
Push provisioning is the mechanism that applies entitlements to target systems, while access reviews (certifications) and segregation-of-duties (SoD) checks are governance controls that determine whether those entitlements should exist. In a well-designed IGA program, SoD policies are typically evaluated before provisioning is executed, so conflicting access is prevented or flagged rather than pushed. Access reviews then periodically confirm that provisioned access remains appropriate, and revocation decisions from a review can trigger downstream deprovisioning through the same push channels. Keeping these as distinct steps, policy evaluation, provisioning, and certification, helps maintain a clear audit trail.
Common misconceptions
Push provisioning and pull provisioning achieve the same result, so the direction does not matter.
The direction determines which system initiates the operation and when downstream state changes. Push is source-driven and typically propagates lifecycle changes proactively, whereas pull is target-driven and depends on the downstream system requesting data. This affects timeliness of deprovisioning, error handling, and where reconciliation logic lives.
Push provisioning is a synonym for SCIM.
SCIM is one commonly used protocol for implementing a push model, but push provisioning is an architectural pattern that can also be realized through vendor-specific APIs or connectors. Conversely, SCIM itself does not mandate a purely push-based flow. Conflating the two overstates what any single standard guarantees.
Push provisioning also handles runtime authorization for the target application.
Push provisioning is an administration and lifecycle function that creates and maintains account and entitlement data in the target. It does not perform runtime access decisions; whether a session is permitted at request time is handled separately by the application's authorization enforcement, independent of how the account was provisioned.
Best practices
Define a single authoritative source for each identity attribute driving push operations, so downstream targets do not receive conflicting create or update instructions from multiple sources.
Prioritize timely deactivation on leaver events, and verify that push deprovisioning actually disables or removes downstream access rather than only updating attributes, since delayed removal leaves orphaned accounts.
Implement reconciliation and drift detection between the source and each target, because push operations can fail silently or be overridden by local changes on the downstream system.
Map and validate the exact attributes and operations each target connector supports before relying on push, since capabilities vary by vendor and connector and unsupported operations may be silently dropped.
Log and monitor push operations with retry and error-handling logic, so failed provisioning or deprovisioning events are surfaced and remediated rather than lost.
Keep push provisioning scope limited to lifecycle and entitlement administration, and confirm that runtime authorization enforcement is handled by the appropriate enforcement components rather than assumed to follow automatically from provisioning.
