Configure your services
Understand the services Paymentology configures and how to request changes for your programme.
Paymentology configures these services for your programme during onboarding and makes configuration changes on your request. The default configurations comply with all applicable wallet and card-scheme requirements and mandates.
Use this section to understand what each service does and how its configuration affects your tokenization flows. You do not need to configure the services yourself. If you want to change the default behavior, describe the scenario and desired outcome to the implementations team so they can assess the request against the applicable requirements and configure the change.
In Notification mode, Lume Token uses the Rule Engine to decide and sends the eligible scheme data plus service results in the notification envelope.
| Service | What it contributes | Configuration to discuss with Paymentology |
|---|---|---|
| CMS validation | Card identification, status and credential checks | Your CMS and card-reference mapping |
| Rule Engine | Approve, decline, or require additional authentication | Scheme/requestor rules and a mandatory fallback |
| Activation profiles | Methods selected for step-up | Supported channels and methods per rule |
| Velocity Check | Signals about repeated declined provisioning | Monitoring scope, thresholds and cooldowns |
| TokenGuard | Known compromised-device intelligence | Participation and rules that consume the result |
| Card Gateway | Card references in place of sensitive card data | The card-reference integration |
| Notification formatting | Common message type and summary around the enriched payload | Notification delivery and event handling |
Not every service applies to every method. A lifecycle update or passcode delivery does not need a fresh provisioning decision. See scheme requests for the relevant context.
Updated 20 days ago