Troubleshooting

Use this page to troubleshoot common issues in Protect, Policies, and Analytics.

Protect

Protect requires account configuration before use.
If the Reviews, Blocked, Scores, and Rules sections are empty or inaccessible, your account may not have Protect enabled yet.
Contact [email protected] to request access.

Confirm your account has Protect enabled (see above).
Check that the rule is active and not paused or in draft.
Verify the rule conditions match the transaction attributes you're testing against — for example, card_country_id only matches the card's issuing country, not the billing country.
Check rule order. Rules are evaluated from lowest to highest order number. A higher-priority allow rule may be matching before your block or review rule gets evaluated.
Remember: rules only apply to future transactions. Existing processed payments are not retroactively evaluated.

Check if an allow rule with a lower order number matched first. Allow rules prevent subsequent block or review rules from applying.
Verify the rule condition is correct — for example, ensure the country code is a valid 2-letter ISO code and formatted as a list where required (e.g., ['NG'] not 'NG').
Confirm the payment method is supported by Protect. Currently only card transactions are evaluated. E-wallets and QR Ph support is coming soon.

Your block rules may be too broad. To reduce false positives:

Use AND logic to combine conditions — for example, require both a high risk score and a specific card country rather than either condition alone.
Switch from a block rule to a review rule for that condition while you gather more signal.
Check the blocked list for the customer's transaction and inspect which rule triggered the block and what the risk score was.

Add a more targeted review rule to narrow what gets flagged — for example, restrict reviews to high-risk transactions above a certain payment amount.
Add an allow rule for clearly low-risk segments (e.g., allow if risk_score_lte: 300) to prevent them from reaching the queue.
Use filters in the Reviews section to prioritize by risk score or date.

Scores reflect the signals available at the time of the transaction. Unusual scores are often explained by the risk drivers shown in the dashboard — check which factors contributed most.
If you're seeing a pattern of unexpectedly high scores on legitimate transactions, review the risk driver breakdown and consider creating a targeted allow rule for that segment.
If scores are missing entirely, confirm Protect is enabled on your account.

Policies troubleshooting — content to be added by the fraud team.

Confirm you have transactions on your account. The dashboard reflects actual payment activity — test mode and live mode data are separate.
Check whether you are in live mode or test mode in the dashboard. Switch to the correct mode for the data you expect to see.
If you recently went live, allow a short processing window for data to appear.

Check the date range filter. The default view may not cover the period you're looking at.
Confirm which payment statuses are included. Pending or failed transactions may be excluded from certain views.
If you're comparing against an external report, check whether both are using the same timezone. Analytics timestamps are in UTC.

Check your date filters — a narrow or misaligned date range is the most common cause.
Verify column and table names against the Data Reference. Column names are case-sensitive.
Check the table's freshness indicator to confirm data has arrived for the period you're querying.
If filtering by status, confirm the exact status string (e.g., 'paid' not 'Paid').

Narrow the date range — queries spanning many months over large tables are the most common cause of timeouts.
Reduce the number of columns selected — only pull what you need.
Add aggregations earlier in the query rather than returning raw rows.
Add a LIMIT clause to preview results before running the full query.

Add or lower your LIMIT.
Aggregate the data in the query before exporting — for example, group by day instead of returning individual transactions.
Split the export by date range into smaller batches.

Confirm the schedule is active and wasn't paused or deleted.
Check the recipient email address is correct and check spam/junk folders.
Verify the query itself runs successfully when executed manually — a query error will silently prevent the scheduled export from sending.
Note that export download links are temporary. If the email arrived but the link expired, rerun the query to regenerate.

Ask your account Admin to confirm your Prism role and access level.
Some fields may be masked depending on your account plan. If a column returns no data or an access error, it may be restricted for your role.

This is expected. Prism is a read-only query tool. It cannot insert, update, or delete data.