Five Fraud Detection Mistakes in Payment Flows

Payment fraud rules usually get written in a panic: a chargeback lands, someone adds a rule, and it sits in production for two years. The damage is quiet — genuine customers declined, an ops team reviewing the same queue every morning, and the transactions you actually wanted to catch sailing through because nobody can tell which rule fired. If you handle payments for an Indian SMB or mid-market B2B company, these are the five mistakes that cost the most, and what to do instead.

Mistake 1: Blocking on a single signal

A rule that fires on one attribute will always be either too loose to stop fraud or too aggressive to keep customers. A new device, a billing pincode that differs from the delivery city, a first order from an unfamiliar GSTIN — each is completely normal on its own, especially in B2B where a new buyer's first purchase is routine. The fix is to combine weak signals and require more than one before you act:

• New device plus a first-time payment method plus an order value above your 90th percentile: queue for review.
• New device on its own: score it, don't block it.
• A failed attempt followed by a success on a different card from the same device: that pattern is worth a block.

Mistake 2: Getting velocity windows wrong

Velocity rules fail when the counting window is longer than the attack and shorter than a customer's normal behaviour. Card testing happens in minutes, so a 24-hour counter of attempts per card will not catch it — count per 10 minutes on the VPA, device fingerprint and phone number, not just the card. But a tight window can also hammer a legitimate subscription with retries or a COD-heavy repeat buyer. Count on the keys an attacker cannot cheaply rotate, and give each key its own threshold. If hand-tuned thresholds keep breaking, a scoring layer built on your own labelled history is usually cheaper than a bigger rules engine — AI and automation work of that kind can start from a spreadsheet of last quarter's chargebacks.

Mistake 3: Running reviews with no audit trail

If a reviewer can approve or reject a flagged payment without leaving a record, your rules can never improve. Every decision needs the rule ID, threshold version, reviewer, timestamp and the eventual outcome — a chargeback, a refund, or a clean settlement 90 days later. That outcome is the label telling you whether a rule is earning its place. Keep it in the same database as the order, not in a spreadsheet someone updates on Fridays. If you already reconcile captured payments against issued GST invoices, extend that reconciliation to attach chargeback outcomes to the original invoice line — the GST billing automation most teams already run is a sensible place to hang it.

Mistake 4: Shipping thresholds you never tested

A threshold is a hypothesis, and it should be tested against your own last 90 days before it goes live. Replay historical transactions through the candidate rule and count what it would have caught versus what it would have wrongly blocked. Here is an illustrative example for a B2B portal doing about 40,000 transactions a month at an average order value of INR 18,000. A rule blocking any order where device and billing pincode disagree might fire on 1.5% of traffic — 600 orders. If nine in ten of those are genuine, you have blocked roughly INR 97 lakh of legitimate GMV (about INR 21 lakh of margin at 22%) to prevent around INR 10.8 lakh of fraud. That is a bad trade, and you would only know it from the replay.

Mistake 5: Sending every alert to a human

A rule that pings a person for every hit teaches that person to ignore the queue. Split outcomes into three buckets: auto-approve, auto-block (only for patterns with almost no false positives, such as a card already reported stolen), and review. Size the review queue deliberately — one reviewer can handle roughly 30-60 cases a day with real attention, so tune thresholds until the queue fits the person, not the other way round. Give the queue one named owner, send a daily digest instead of real-time pings, and re-check the rule set monthly against recorded outcomes. If you are scoping an internal build, the pricing page shows typical ranges for that kind of work.

Where to start

Pick the rule that fires most often, replay your last quarter against it, and write down what it would have wrongly blocked. That single exercise usually pays for the whole cleanup. If you would rather not do it alone, Maysan Labs builds dashboards, portals and internal tools — including the review queues and reconciliation layers that sit behind payment rules — for SMBs and mid-market teams in Gurgaon, Cardiff and beyond.