Best Practices
How to get the most out of PayMongo Protect — from writing effective rules to managing your review queue and calibrating risk thresholds
Best Practices
TLDRWhen using PayMongo Protect:
- Enable Protect before you go live — not after fraud has already hit
- Start with Review rules, not Block rules, to build confidence first
- Use risk scores alongside risk drivers, not scores alone
- Keep rules focused — one rule, one concern
- Review flagged transactions promptly; stale reviews lose context
- Audit your rules regularly and retire ones that no longer apply
Protect is most effective when it's calibrated to how your business actually operates. These best practices cover the four areas where most merchants can make the biggest impact: getting started, writing rules, using risk scores, and managing your review queue and blocked list.
Getting Started
Enable Protect before you go live
Protect is most valuable when it has transaction data from day one. Enabling it after fraud has already occurred means you're reacting instead of preventing. Turn Protect on during testing and keep it active through launch.
Spend the first few weeks observing
When you first enable Protect, avoid blocking transactions immediately. Instead, use the first two to four weeks to observe your score distribution and understand what's normal for your business. This baseline makes it much easier to set thresholds that are accurate — not just aggressive.
Set up webhook notifications for flagged transactions
Connect Protect to your notification workflow via webhooks so your team is alerted when transactions are flagged for review. Waiting to check the dashboard manually means reviews pile up and important decisions get delayed.
Writing Rules
Start with Review rules, then move to Block rules
Blocking a legitimate customer is damaging — it's a lost sale and a damaged relationship. Start by creating rules that flag transactions for review rather than immediately blocking them. Once you've confirmed the pattern is genuinely fraudulent, upgrade the rule to block.
One rule, one concern
Avoid combining multiple conditions into a single rule. Instead, write rules that each address a single, specific concern:
| ✅ Do this | 🚫 Not this |
|---|---|
| "Block transactions with a risk score of 900 or above" | "Block high-score transactions from new devices with a mismatched billing address" |
| "Review transactions from high-risk email domains" | One rule handling score + device + email domain |
Rules are easier to audit, adjust, and retire when they're focused.
Use score thresholds as a starting point — not a final answer
Risk scores work best when combined with other rule attributes. A score of 750 on a ₱50 transaction is very different from a score of 750 on a ₱95,000 transaction. Combine score thresholds with amount, payment method, or other context to reduce false positives.
Suggested starting thresholds:
| Score range | Default behavior | Recommended starting action |
|---|---|---|
| 0–499 | Low risk | Allow |
| 500–799 | Medium risk | Review |
| 800–1000 | High risk | Block |
Adjust these over time based on your dispute rate and false positive feedback.
Test before activating
All new rules start in deactivated (draft) mode by default. Before activating any rule:
- Review how the rule would have applied to recent transactions
- Confirm the rule logic matches your intent
- Activate only when you're confident it won't disrupt legitimate transactions Draft rules have no impact on live transactions.
Audit your rules regularly
Rules written six months ago may not reflect your current transaction patterns. Set a recurring reminder to review your active rules and retire or update any that are stale, overly broad, or no longer serving their original purpose.
Using Risk Scores
Read the score alongside the risk drivers
A score of 850 tells you a transaction is high-risk. The risk drivers tell you why — whether it's a geolocation mismatch, unusual transaction amount, high-risk email domain, or suspicious behavior pattern. Always investigate the drivers before taking action, especially on borderline scores.
Don't set thresholds too aggressively early on
It's tempting to set a low block threshold immediately, but this increases false positives and may block legitimate customers. Start with conservative thresholds, observe your data, and tighten rules gradually.
Use the Scores page to track trends
The Scores page gives you visibility into how risk levels are shifting over time. A sudden spike in medium- or high-risk transactions may signal a coordinated attack. Periodic review of your score distribution helps you catch this early — before disputes start arriving.
Different payment methods carry different baselines
Card transactions typically generate more signals (device, billing address, card origin) than e-wallet or QR Ph transactions. A score of 600 on a card payment carries different weight than the same score on a QR Ph transaction. Calibrate your rules per payment method where appropriate.
Managing Reviews
Review flagged transactions promptly
Reviews are time-sensitive. The longer a transaction sits in the queue, the harder it is to investigate — chargeback windows close, patterns shift, and context fades. Aim to clear your review queue daily.
Use filters to prioritize high-stakes reviews
Not all flagged transactions carry equal risk. Use the filter options in the Reviews tab to surface the highest-priority cases first — such as filtering by transaction amount, risk score, or payment method.
Close every review with a decision
Leaving reviews open without a resolution creates noise and undermines the accuracy of your fraud data over time. Every reviewed transaction should be closed with a clear outcome: approve it or confirm it as fraudulent.
Use review decisions to improve your rules
When you consistently approve or decline transactions with a particular pattern, that's a signal to codify the pattern into a rule. Don't rely on manual reviews for patterns you've already seen repeatedly — automate them.
Managing the Blocked List
Use the blocked list for confirmed fraudsters — not suspects
The blocked list is most effective when used for card numbers, email addresses, or IPs that you have confirmed as fraudulent. Using it as a catch-all for suspected fraud leads to over-blocking and increases false positives.
Understand the scope of each block type
Blocking an email address is broader than blocking a single card. A fraudster can get a new card easily, but email address blocking can catch repeated attempts from the same actor. Use the appropriate block type based on what you've observed.
| Block type | Best used when |
|---|---|
| Card number | A specific card has been confirmed as stolen or used for fraud |
| Email address | A repeat actor is using different cards from the same email |
| IP address | Coordinated attacks are originating from the same IP range |
Review and prune your blocked list periodically
Legitimate customers can sometimes share IPs (corporate networks, shared WiFi) or reuse email addresses from previously blocked accounts. Review your blocked list quarterly to remove entries that may be creating unnecessary friction for good customers.
Updated about 18 hours ago