Fraud Tools

What Fraud Tools protects

Fraud Tools watches every card payment that comes through your payment tools - the virtual terminal, payment links, invoices, recurring billing, your checkout pages, and anything an integration charges through the API. It does not change anything about your in-store terminal activity; this protection is specifically for payments where the card isn't physically present, which is where card fraud actually happens.

You choose the rules; the gateway enforces them automatically on every transaction, around the clock. Find it under Billing Tools → Fraud Tools. The status bar at the top always tells you where you stand: Filter Enabled, Filter Disabled, or Not Configured.

The four actions, in plain words

Every rule you set picks one of four responses when a payment trips it:

1. 1Allow - the payment goes through normally. Use this for results you don't care about.
2. 2Allow, Report - the payment goes through, but it's recorded in your Fraud Activity report so you can watch for patterns.
3. 3Authorize and Hold for Review - the payment is approved but parked in a review queue on this page. You look at it and either approve it or reverse it. If you don't decide within 5 days, it is automatically refunded to the cardholder - a suspicious charge can never quietly keep the money.
4. 4Decline - the charge is refused and the card is never charged. The customer sees a normal decline.

Address checks (AVS)

When a customer pays online, the card networks compare the billing address and ZIP code they typed against what their bank has on file, and report the result. The AVS filter lets you decide what happens for each result.

Example: an e-commerce store that ships goods usually wants to DECLINE when neither the street address nor the ZIP matches (result code N) - that combination is the classic stolen-card signature. A donation page might only Report it, since donors often mistype addresses and there's nothing to ship.

The top table covers general situations (no address sent, the bank doesn't support address checks, the system was down). The bottom table is the match matrix - each row shows exactly what matched and what didn't, in green and red, so you can see what you're acting on.

Security-code checks (CVV)

The CVV is the 3- or 4-digit code on the card itself - someone who stole a card number from a database usually doesn't have it. When the code matches, the payment is always allowed. When it doesn't match, wasn't processed, or the card should have one and none was given, you decide.

Example: to accept nothing except a confirmed CVV match, set every row in this table to Decline. That is the strictest posture and a very effective one for online-only businesses.

Require ZIP and require CVV

Two simple switches: require the billing ZIP code, require the security code. When they're on and a new card is entered without one, the payment is refused before it even reaches the card networks. Cards you've already saved on file aren't affected - a stored card can't carry a security code, by card-network rule.

Spending limits

Set a ceiling and/or a floor for a single transaction. Example: a coffee shop's payment page has no business taking a $2,000 charge - set 'If a single transaction exceeds $500' to Decline. The floor catches the opposite pattern: fraudsters testing stolen cards with $1 charges - set 'less than $2' to Decline and card-testers bounce off.

Velocity rules - stopping rapid-fire abuse

Velocity rules watch how often, and for how much, a single card is used across your payment tools. A legitimate customer might buy twice in a day; a fraudster with a stolen card will hammer it.

Example: 'If the daily attempted transaction count for one card exceeds 5 - Decline' stops a stolen card cold after its fifth try, automatically. 'If the weekly approved amount for one card exceeds $5,000 - Hold for review' lets big spenders through but puts them in front of you first.

Attempted counts every try including declines (best for catching card testing); approved counts only successful charges (best for spending caps). You can stack up to 8 rules across daily, weekly, monthly, and yearly windows.

The same-card-numbers rule watches for many attempts from cards that share their first 6 digits in a day - the signature of a 'BIN attack,' where a fraudster generates card numbers from one bank and tries them in bulk.

IP address rules

Every online payment comes from an internet address. Two patterns are worth watching: one address trying many DIFFERENT cards in a day (someone testing a stolen card list), and one address hammering out transactions.

Example: 'If one IP address uses more than 3 different cards in 24 hours - Decline' shuts down card-testing runs. And the block list refuses specific addresses outright - one per line; end an entry with a dot to block a whole range.

The review queue

Everything your rules held for review sits at the top of the Fraud Tools page: the amount, the card, what triggered the hold, and the date it will auto-refund if you don't act. Approve releases the payment - it settles normally. Reverse refunds the customer now.

The 5-day auto-refund is your safety net: an unreviewed suspicious charge never quietly stays collected.

Reading your Fraud Activity report

The report at the top of the page shows the last 50 payments your rules acted on, with 30-day totals for flagged, held, and declined. Each row says in plain language what triggered it - 'AVS filter: response code N' or 'IP rule: more than 3 different cards used from 203.0.113.7 in 24 hours.'

Remember: this report covers your gateway payments only. Your regular processing reports (batches, deposits, statements) live on their own pages and are unaffected by these rules.

For developers

Everything on this page is also available through the Merchant360 API: read and update your fraud configuration at /v1/fraud-settings with your API key. Filters apply to API charges automatically - a charge refused by your rules returns a decline with a plain-language reason, and a per-request override lets an integration allow or disallow partial approvals on a specific charge.