Issuer questions

Do I need to make tokenization decisions in my backend?

Not in Notification mode. Lume Token evaluates the configured rules and responds to the scheme. Your endpoint acknowledges the notification and performs the event-specific work. Use Advice only when your backend must make the final decision.

Does HTTP 200 mean the token is approved?

No. It acknowledges receipt of the notification. Read the outcome in the message and use lifecycle events to track activation.

Who sends OTPs to cardholders?

You do. Paymentology forwards the OTP to your systems, which deliver it through the selected channel. Agree masked contact-data access as part of activation setup.

How do I configure or change rules?

Start with the suggested template. The implementations team configures your programme and applies requested changes. Each step-up rule selects its activation profiles, including the mandatory default fallback.

Can I reuse one rule across schemes?

The business intent can be shared, but rules use scheme-specific endpoints and fields. Configure each rule for your scheme. The common notification summary reduces the amount of scheme-specific parsing your integration needs.

Is the notification payload normalized?

MESSAGE_TYPE and SUMMARY use a common structure. ADDITIONAL_MESSAGE_DATA retains eligible native fields and includes enabled-service enrichment. Card-data protection still applies. See the envelope reference.

Do all notification types apply to my programme?

No. They depend on your scheme, enabled services, requestor, and use case. Implement the events agreed for your programme and distinguish provisioning from post-tokenization authentication.

What if I use another processor's CMS?

Lume Token can be scoped as a standalone integration. Agree CMS validation, card-reference mapping, enabled services, and issuer responsibilities with the implementations team.