Cardholder journeys
Understand wallet provisioning, step-up, e-commerce authentication, and lifecycle changes.
The same issuer responsibilities recur across wallets and schemes. Start with the journey, then use your scheme guide for its request names and payload fields.
| Journey | What happens | Your work in Notification mode |
|---|---|---|
| Add a card from a wallet | The cardholder enters or selects a card; Lume Token evaluates the scheme request | Record the provisioning decision and wait for the resulting lifecycle event |
| Add a card from your banking app | Your app initiates push provisioning through the relevant wallet integration | Implement that app integration and monitor provisioning; do not assume every app-initiated request must be approved |
| Complete additional authentication | A step-up rule selects the allowed activation methods | Deliver the selected SMS/email OTP or complete your configured app/contact-centre verification journey |
| Tokenize a merchant-held card | A registered requestor replaces a stored card credential with a network token | Track the token and requestor; device-only signals may not apply |
| Authenticate an existing e-commerce token | The scheme requests authentication for a token that already exists | Distinguish this from initial provisioning and apply the appropriate reason-specific handling |
| Suspend, resume, delete, or update a token | A token lifecycle event is received | Update the affected token record and the cardholder-facing state |
A step-up journey
A yellow decision means more authentication is required. It is not a completed activation. Lume Token returns the methods selected by the matching rule; the wallet presents the options. If the cardholder chooses SMS or email, Paymentology sends you the OTP and you deliver it. Track completion using the subsequent token event.
Card and token identifiers
One funding card can have several network tokens across devices and merchants. Keep the Paymentology card reference separate from the scheme's token reference. A change to one token must not be treated as a change to every token on the funding card.
Follow your scheme
- Mastercard: parallel provisioning calls and RAM-only post-tokenization authentication.
- Visa: separate provisioning and step-up-method requests.
- Jaywan: provisioning, validation methods, and lifecycle events, including co-badged token context.
See all notification types for how these journeys appear in your feed.
Updated 20 days ago