When a customer reaches the payment step, the module evaluates all active policies against the current cart, customer, delivery address and carrier. Each installed payment gateway receives a SHOW or HIDE decision before options are rendered.

On PrestaShop 8.1 and above, filtering runs through the native actionFilterPaymentOptions hook. On earlier versions, a compatibility layer applies the same logic without breaking your theme.

A policy is a named bundle of conditions plus a set of payment rules. Create as many policies as you need — for example one for B2B bank transfer, one for high-value COD restrictions, one for international cards.

Inside each policy, every installed payment module gets its own rule card. Toggle SHOW or HIDE, set evaluation priority, reorder display position and optionally restrict the rule to a date range.

Policies run in position order. Enable Stop on first match when you want the engine to halt after the first policy that matches the current cart context.

When multiple rules inside one policy target the same payment module, the merge strategy decides the outcome:

• Deny wins — any matching HIDE rule hides the payment.
• Allow wins — any matching SHOW rule shows the payment.
• Priority cascade — the first matching rule by priority decides.
• Weighted score — SHOW adds +1, HIDE subtracts −1; net score determines visibility.
• Unanimous SHOW — all matching rules must be SHOW for the payment to appear.

Set a default merge strategy globally in Settings, then override per policy when a specific scenario needs different conflict resolution.

Sometimes hiding a payment method without explanation frustrates customers. Payment Method Rules lets you write a per-rule, per-language message that appears when a method is blocked.

In Settings, choose between two behaviours: remove hidden methods from the list entirely, or keep them visible as disabled options with your custom message inline on the payment step.

Each rule card includes a multilingual input with a language flag selector — write the explanation once per language, the correct version shows automatically at checkout.

The Simulator tab lets you test rules against real data from your shop. Search and select an active shopping cart, optionally attach a customer, then run the evaluation.

Results show every payment module with its final visibility status, the policies that matched and any unavailable messages that would appear. No test order required. No customer impact.

Use the simulator after every policy change to confirm your rules behave exactly as intended before customers see them.

The Dashboard tab is your visibility control room. KPI cards summarise evaluations, hidden applications and active policies over a selectable period (30, 90, 180 or 365 days).

Chart.js trend charts break down activity daily, weekly or monthly. A per-payment-module table shows which gateways are hidden most often — useful when tuning rules or negotiating with payment providers.

Recent audit entries appear at the bottom of the dashboard for quick access to the latest decisions without leaving the overview.

Every significant event is recorded: visibility evaluations at checkout, order validation blocks, policy create/update/delete, imports, exports, duplicates, settings changes and simulation runs.

The dedicated Audit log admin tab under Payments gives you filters by date, event type and payment module. Click preview on any row to see the full detail payload.

Export the log to CSV when compliance or internal review requires a complete history of who changed what and when.

Download any policy as a portable JSON file from the policy editor or the policies list. Upload JSON to create a new policy on the same shop or a staging environment.

The duplicate action copies the full policy — conditions, rules, merge strategy and multilingual messages — under a new name. Ideal for creating seasonal variants or testing changes safely.

Every import, export and duplicate action is logged in the audit trail.

Rules are enforced twice: at payment option display and again when the order is validated. If a customer somehow reaches a hidden payment module's validation URL, the order is blocked before it is created.

A visibility snapshot is stored on the order record so you can see which payment methods were available at the moment of purchase — directly from the order detail page in the back office.