Tokenization rules
Define decisions for your scheme and choose activation methods for step-up.
Your rules tell Lume Token whether to approve, decline, or require additional authentication. In Notification mode, Lume Token uses that result to respond to the scheme and includes decision context in your notification.
Start with Paymentology's recommended template. The implementations team configures it for your scheme and wallets, and applies changes on your request. Use test results and observed activity to refine the configuration.
What a rule contains
| Part | Purpose |
|---|---|
| Scheme and endpoint | The native request to evaluate |
| Wallet or requestor scope | A particular requestor or All Wallets |
| Conditions | Checks on eligible scheme fields or enabled-service results |
| Outcome | Approve, decline, or additional authentication |
| Activation profiles | Methods selected when the rule requires step-up |
| Order | Priority within the applicable evaluation sequence |
Rules are scheme-specific even when the business intent is shared. Native fields and available signals differ by scheme and request type.
Evaluation and fallback
Applicable wallet-specific rules run before All Wallets rules. Agree and test the intended outcome where conditions overlap. A default fallback must always be configured; it usually selects step-up and its own default activation methods.
The Rule Engine is required for Notification and Full OBO. In Advice mode, an issuer can use its recommendations or disable it and implement the decision logic itself.
Continue with building rules, activation profiles, and decision outcomes.
Updated 20 days ago