Define and change rules

Work with the implementations team to configure your rules. Describe the customer scenario and intended outcome first, then agree the scheme fields and conditions that identify it.

Start with a template

Paymentology configures the default template for your scheme and wallets. The default configuration complies with all applicable wallet and card-scheme requirements and mandates. Confirm the supported activation methods and the mandatory fallback. Test the expected approval, decline, and step-up paths before asking for refinements.

Specify a change

Provide the scheme, endpoint, wallet/requestor scope, conditions, desired outcome, and activation profiles when step-up is required. Explain which conditions must hold together and which represent alternative scenarios so the implementations team can configure and test the intended logic.

For example, an issuer might restrict activation methods for requests carrying a particular device-risk signal. Agree the native field or enrichment field for that signal and the methods the cardholder can actually complete. Do not copy a condition from another scheme without checking its meaning and availability.

Order and fallback

Evaluate the applicable wallet-specific rules in their configured order.
If none match, evaluate All Wallets rules.
Use the required default fallback when no earlier rule determines the result.

Review restrictive and permissive rules together within the appropriate scope. Test overlapping conditions explicitly, including requests that meet both wallet-specific and All Wallets conditions.

A fallback that selects step-up has its own activation profiles. For endpoints that obtain methods separately, configure the corresponding method-selection flow as well. Agree a valid fallback for the request type and wallet requirements.

Validate and tune

Test the changed scenario, nearby cases that should remain unchanged, and the fallback. Review notification outcomes after the change. Your programme's rule configuration should evolve from observed data, such as avoidable declines or higher-risk requestor activity.

See rule reference for condition operators and testing for issuer checks.