How Lume Token works

How Lume Token sits between card-scheme TSPs and issuer systems, and how a token request flows through the platform.

At its core, Lume Token is a smart middleware layer — an Issuer TSP (I-TSP) — that sits between the card schemes' tokenization services and the issuer's systems. It receives token requests from the schemes, enriches and evaluates them through a set of modular services, and returns a decision.


High-level architecture

Lume Token connects in two directions:

  • Westbound — to the Token Service Providers (TSPs) of each scheme: Visa's VTS issuer API, Mastercard's MDES API, the MADA Tokenization Service, and the Jaywan TSP interface.
  • Eastbound — to the services that process each request and communicate with the issuer's systems.

Architecture overview


How a token request flows

A request is "piloted" through the enabled modules, each performing a separate task:

Request processing flow

  1. Incoming token request — the scheme's TSP receives a digitization request from the Token Requestor and sends a token request (for example, a Mastercard AuthorizeService request) to Lume Token, because Paymentology acts as the issuer's I-TSP. The request carries sensitive PCI card data, wallet risk data, and scheme risk data.
  2. Request routing — the request reaches the Lume Token core for processing through the services enabled for the issuer.
  3. Paymentology Card Management System — validates the financial account: that the PAN exists, is not suspended, and that the expiry date, CVV, and cardholder name match.

    NOTE: If an issuer processes their card transactions "in-house" or another 3rd party processor is used, the Lume Token platform can integrate with it and be provided as a standalone product.

  4. ​Velocity Check — detects repeated or abnormal declined token provisioning attempts for the same PAN or Token Requestor ID, and applies a temporary cooldown when thresholds are exceeded.
  5. Token Guard — provides device-risk results for the issuer's configured rules. TokenGuard and Velocity results do not independently force a decline; the rules choose the outcome.
  6. Rule Engine — evaluates the request and added value application flags (Velocity, Token Guard) against the issuer's configured rules and produces a decision: Approve, Decline, or ID&V required.

    For ID&V, each step-up rule selects the activation methods appropriate to the token requestor and scenario.

  7. Card Gateway — replaces sensitive PCI card data with a card reference (from Lume, Lume, Voucher Engine, or any other issuer CMS) so the issuer-facing message identifies the card without exposing its sensitive card data.
  8. Response — depends on the operating mode:
    • Notification — Lume Token responds to the scheme and forwards the request to the issuer as a notification, enriched with the rule engine's decisioning advice so the issuer has visibility into the decision.
    • Advice — Lume Token forwards the request and applicable service results to the issuer for a decision, then relays the issuer's response to the scheme. Where Paymentology performs card validation, failed validation is indicated to the issuer as requiring a decline.
    • Full OBO — Lume Token responds Approve / Decline / ID&V required to the scheme on the issuer's behalf without the issuer decision-event feed. Issuer OTP delivery is still required when SMS or email OTP is used.
📘

Recommended path for go-live

Implement the Notification mode for the best balance around information and control. After tokenization go-live evaluate the need for moving to Advice mode - agree and validate the changed integration with the implementations team.

If you do not need the decision-event feed, consider Full OBO. Agree the issuer work needed for your selected activation methods.


Schema-agnostic by design

Lume Token uses a common rule model across schemes. Define the business intent — for example "step up high-risk provisioning" — then configure the rule for the relevant scheme, endpoint, and wallet using that scheme's fields.

Rather than renaming every scheme's fields into a single unified API, Lume Token keeps the original request and field names from each card scheme and uses a common notification envelope around the eligible native payload and enriched data. A rule references the native fields directly, so the value a field carries is never lost or distorted in translation.

For example, Mastercard sends a phone-number suffix in mobileNumberSuffix, while Visa uses its own device and contact fields. The same verification intent is configured separately against each scheme's native payload.

📘

What this means for you

  • Faster support for new scheme features — onboarded fields can be used in configuration, allowing the implementations team to adapt and test rules for your programme.
  • A shared language across teams — because rules describe business intent, your teams, scheme-support and Paymentology's implementation teams talk about the same use case, which speeds up scoping and reduces miscommunication on projects.
  • Less field translation — native fields retain their scheme-specific meaning. The implementations team assesses and tests changes for the affected scheme and programme.

Where to next


Did this page help you?