Operating modes

Notification mode is the recommended starting point. Lume Token decides how to handle tokenization requests and returns the scheme response. You receive the event, its outcome, and the supporting data in the notification envelope.

Notification mode

1. The scheme sends a request to Lume Token.
2. Lume Token validates the card through the configured CMS, applies enabled services, and evaluates your rules.
3. Lume Token responds to the scheme.
4. Your endpoint receives the notification and acknowledges it with HTTP 200.
5. Your systems perform the event-specific action, such as delivering an OTP or updating a token record.

An acknowledgement confirms receipt; it does not change the tokenization decision. A provisioning approval is also not evidence that activation has completed: use lifecycle notifications to track the resulting token state.

Compare modes

Full On-Behalf-Of (OBO)

Lume Token processes requests and responds to the scheme without forwarding the decision-event feed to your backend. Select this when you do not need that feed. If you use SMS or email OTP, your systems still need to receive and deliver the passcode. Other activation methods have their own issuer and wallet integration requirements.

Advice mode

This section is an overview for choosing an operating mode, not a complete Advice API specification. Before implementing Advice, obtain the versioned issuer request/response interface for your programme. It must define the incoming validation indicators, request-to-response correlation, required response fields, and approve, decline, and step-up outcomes. The Notification envelope and its acknowledgement are not that decision interface.

Lume Token forwards the request and enabled-service results to your backend. You return the scheme-specific response, which Lume Token relays to the scheme. You can use Rule Engine recommendations or handle decisioning without the Rule Engine.

Mastercard decision response

The following synthetic AuthorizeService response illustrates an issuer decline. It explains the role of the decision response, not the complete request/response contract. Do not derive required fields or request correlation from this reduced example.

{
  "responseId": "response-example-001",
  "decision": "DECLINED"
}

Use the complete response contract for the MDES version agreed in your integration. Lume Token relays your response to MDES. Do not return this object as the acknowledgement to a Notification-mode TAR.

Card-validation declines

For issuers that do not handle sensitive card data, Paymentology validates it first. If validation fails, the forwarded Mastercard AuthorizeService includes the required decline indication and the reason for the failed check; the issuer still responds. A recognized card reference can remain available when the card is found but CVV or expiry validation fails. Failure to find the card is a separate scenario with a separate decline reason.

If your agreed integration allows you to receive and validate sensitive card data, your systems perform those checks. Discuss that arrangement with the implementations team when defining the interface.

Changing modes

Agree the change with the implementations team. Moving to Advice requires a decision endpoint and scheme-specific response handling. Validate the changed integration before switching traffic. Keep notification receipt, contact-data lookup, and OTP delivery responsibilities explicit in the project scope.