Start your issuer integration

Use Notification mode to let Lume Token make tokenization decisions while your systems receive the events and supporting data. Your integration receives a common notification envelope across schemes; you only need to interpret the native payloads relevant to your card programme.

Your integration at a glance

Paymentology handles	You handle
Scheme connectivity and tokenization request processing	Wallet agreements and the scope of your card programme
Card validation through your configured CMS	A notification endpoint and storage for relevant token events
Configured rules and enabled risk services	Delivery of SMS or email OTPs to your cardholders, if selected
Scheme responses and notification formatting	Cardholder support and updates in your app
Initial rule configuration and requested changes	Testing your integration and reviewing outcomes with the implementations team

1. Agree your programme

Contact your Paymentology account manager to begin implementation. Identify your card scheme, BIN ranges, CMS, wallets or merchants, and whether the programme includes device wallets, e-commerce tokens, or both. Wallet agreements and app requirements are part of this scope.

Choose your scheme guide: Mastercard, Visa, or Jaywan. For a MADA programme, confirm the programme scope with the implementations team.

2. Select activation methods and rules

Start with Paymentology's recommended rule template for your scheme and wallets. Agree which requests to approve, decline, or send for additional authentication. Each step-up rule, including the required default fallback, selects its own activation profiles.

The implementations team applies the configuration and adjusts it on your request. During the project, use test results to understand the flows and request changes. After launch, use your observed outcomes to refine the rules.

If you offer SMS or email OTP, implement delivery through your own messaging service. Paymentology forwards the OTP to you; it does not send messages to cardholders. Agree whether masked contact details are obtained from your CMS or an issuer-hosted contact-data service.

3. Receive notifications

Provide your receiver URL and configure authentication using the notification connection contract. Accept HTTP POST with the tokenization notification envelope:

MESSAGE_TYPE identifies the event.
SUMMARY provides common identifiers and values across schemes.
ADDITIONAL_MESSAGE_DATA contains the eligible scheme payload and results from enabled Lume Token services.

Return HTTP 200 to acknowledge a notification. You do not return an approval or decline decision in Notification mode. Handle OTP delivery and token-state updates according to the event type. Where your own system supplies contact data, implement that separate request/response integration as well.

4. Test the cardholder journey

Use the Token Tester and your agreed test plan to exercise approval, decline, step-up, OTP delivery, and token lifecycle events for your programme. Check both the data you receive and the action your systems take. Complete the applicable wallet and scheme certification activities with the implementations team.

5. Review and improve

Monitor provisioning outcomes, activation completion, and decline reasons. Request changes to rules or methods when the data shows that a specific scenario needs different treatment. Keep the required fallback configured when rules change.

If your own backend needs to make the final tokenization decision, see Advice mode. It is an alternative integration path, not a prerequisite for Notification mode.