Authorize.net Card Testing Attack: Fraud Filter Settings

If your Authorize.net account is being card tested, the fastest fix is in the Merchant Interface. Enable the Advanced Fraud Detection Suite (AFDS). Set its velocity filters (Hourly, Daily and Transaction IP) to a tight limit with the action set to decline or hold. Turn on the Suspicious Transaction Filter. Then put a CAPTCHA in front of your payment form. If you use Authorize.net’s hosted form, Accept Hosted, you can enable a CAPTCHA option on it. Call Authorize.net support while you do this, and afterwards void or refund every approved test charge.

Search for “Authorize.net card testing” and you mostly find sandbox and test-mode pages for developers. This guide is the other kind: what to do when real fraudsters are testing stolen cards through your checkout. Every filter named below appears in Authorize.net’s own help pages, which are linked inline. Menu labels can differ slightly between the classic Merchant Interface and the newer one.

How do I know my Authorize.net account is being card tested?

The signs are the same as on any gateway. In your Authorize.net transaction search or unsettled transactions list you will see:

1. A sudden burst of transactions, often hundreds in an hour, far above your normal volume.
2. Mostly declines, with a few approvals scattered among them.
3. Small amounts, or the minimum your form allows. Donation forms are a favourite target, a point Authorize.net’s card testing article makes too.
4. Strange or repeated billing names and addresses, and a lot of AVS and card code mismatches.

For a general walkthrough that doesn’t depend on your gateway, see card testing attack: what to do.

What is the Advanced Fraud Detection Suite?

AFDS is Authorize.net’s set of rules-based transaction filters and IP tools. Authorize.net describes it as having 13 configurable filters and says the aim is to stop fraudulent transactions before they get as far as authorization. According to Authorize.net’s AFDS support article:

• Only the Account Owner can enable or disable AFDS.
• AFDS carries a monthly fee, shown under Account > Merchant Profile > Fees. The same article says the Daily Velocity Filter is available at no charge.
• You can set up email notifications for suspicious transactions. Each transaction’s detail page shows its AFDS result under Fraud Information.
• The AFDS help pages include a Setup Wizard for configuring the filters.

What actions can a filter take?

Every AFDS filter uses one of four actions, as listed on the Hourly Velocity Filter help page:

1. Process as normal and report filter(s) triggered. The transaction goes through and is flagged. Useful for testing your settings, not during an attack.
2. Authorize and hold for review. The card is authorized and the transaction is held. Authorize.net says held transactions stay in Authorized/Pending Review for 30 days.
3. Do not authorize, but hold for review. The transaction is held before authorization, and you have five days to approve or decline it. Because no authorization is attempted, this avoids authorization fees while you review.
4. Decline the transaction. Authorize.net calls this the most severe action. The transaction is declined before authorization.

If a transaction trips several filters with different actions, the most severe action wins. During an attack, use Decline or Do not authorize, but hold for review. “Authorize and hold” still sends the card to the issuer, and the issuer’s answer is exactly what the tester wants.

Which Authorize.net filters stop card testing?

Authorize.net’s support article groups four filters as card testing settings. Start with these.

Hourly Velocity Filter and Daily Velocity Filter

The Hourly Velocity Filter limits the total number of transactions your account accepts per hour, from any IP address. You enter a Transaction Velocity Threshold, and Authorize.net suggests basing it on your average hourly volume. Several transactions that belong to the same order do not trip it. The Daily Velocity Filter does the same per day, as listed on the Transaction Filters page.

During an attack, set the hourly threshold just above your normal busiest hour and the action to decline. Remember that these limits are account-wide: once the threshold is reached, legitimate customers are caught too. Raise the limits again when the attack is over.

Transaction IP Velocity Filter

This filter limits how many transactions the same IP address can submit per hour. It only works if your website or shopping cart sends the customer’s IP address with each transaction. Authorize.net’s support article names the field (customerIP in the API). Ask your developer or cart vendor whether yours does. Testers often rotate IP addresses, so treat this as one layer, not the whole fix.

Suspicious Transaction Filter

This filter screens transactions against criteria maintained by Authorize.net’s Fraud Management team. You don’t tune the criteria yourself. You only choose the action. Turning it on with a hold or decline action is a low-effort step during an attack.

IP Address Blocking

Under IP Address Administration, IP Address Blocking lets you block specific IP addresses. Like the IP velocity filter, it needs the customer IP. It helps when a handful of addresses are doing most of the damage, and helps less against a botnet. The same section has Authorized API IP Addresses, which accepts API transactions only from the server addresses you list. That is worth turning on if you suspect your API credentials have leaked.

Should I tighten AVS and CCV settings?

Yes. Testers frequently have incomplete or wrong billing data.

• The Enhanced CCV Handling Filter lets you decide what happens to each card code verification result. First make sure your form requires the card code.
• The Enhanced AVS Handling Filter does the same for address verification (AVS) responses. You can decline, hold for review or simply flag each mismatch code.
• The Amount Filter sets lower and upper amount limits. A lower limit is useful against the tiny “test” charges. On a donation form, also raise the minimum the form itself accepts, as Authorize.net recommends.

Be careful with strict AVS handling for international customers or customers whose bank returns “AVS not supported.” Look at your filter reports for a few days before you make a strict setting permanent.

Does Authorize.net have a hosted payment form with CAPTCHA?

Yes. Accept Hosted is Authorize.net’s hosted payment form: your site requests a form token and then shows Authorize.net’s page, either by redirecting to it or by embedding it. Authorize.net’s Accept Hosted documentation says the form lets merchants stay at SAQ A level PCI compliance. It also lists a hostedPaymentSecurityOptions setting that turns CAPTCHA on the form on or off. It is off by default, so your developer or cart plugin has to switch it on. (For more on SAQ A and your PCI scope, see which PCI SAQ do I need.)

If you take card details some other way, such as a custom form posting to the API or a shopping cart plugin, add CAPTCHA or a bot challenge on your own page in front of the payment step. Authorize.net’s card testing article also recommends CAPTCHA and a firewall with bot detection.

What should I do during an active Authorize.net card testing attack?

Do these in order:

1. Enable AFDS if it is off. Only the Account Owner can do this.
2. Set the Hourly and Daily Velocity Filters to a tight threshold, with the action set to decline.
3. Turn on the Transaction IP Velocity Filter and the Suspicious Transaction Filter, with decline or do-not-authorize-and-hold as the action.
4. Set the Enhanced CCV and AVS Handling Filters to decline or hold on mismatches, and set an Amount Filter lower limit.
5. Block the worst IP addresses under IP Address Blocking, if your integration sends the customer IP.
6. Turn on CAPTCHA, either in Accept Hosted or on your own form. If the attack still gets through, take the payment form offline for a while.
7. Contact Authorize.net support and your merchant account provider, and keep the case number. Authorize.net itself says there is little you can do once an attack is under way, which is why the filters need to be set up beforehand. It also warns that an acquirer may halt processing until you show a mitigation plan.
8. Clean up. Void approved transactions that haven’t settled and refund the ones that have. Authorize.net’s void vs. refund article explains which applies. Review held transactions and decline the fraudulent ones.
9. Watch for chargebacks over the following months. Authorize.net’s timeline expects them between about day 31 and day 120.

If attackers are reaching Authorize.net without going through your checkout page at all, rotate your API Login ID’s transaction key and turn on Authorized API IP Addresses.

Does CardSecurity protect Authorize.net merchants?

Not yet. CardSecurity card-testing protection is live in pilot for merchants on Payroc. It scores each checkout attempt before it reaches the processor, asks riskier customers to verify, blocks scripted attackers and sends flagged payments to a review queue. Authorize.net support is in sandbox testing and is not available for live merchants. If you process through Authorize.net and want to hear when that changes, tell us your processor. MSPs managing several Authorize.net merchants can also talk to us through the MSP program.

Frequently asked questions

Where are the fraud filters in Authorize.net?

The filters are in the Advanced Fraud Detection Suite section of the Authorize.net Merchant Interface. Only the Account Owner can enable or disable the suite. Each filter, including the velocity, IP, amount and AVS/CCV filters, has its own page where you switch it on, set a threshold and choose an action. Authorize.net also provides a setup wizard. Menu labels can differ between the classic and newer Merchant Interface.

What is the best Authorize.net filter action during a card testing attack?

Use “Decline the transaction” or “Do not authorize, but hold for review.” Both act before the card is sent to the issuer, so the tester learns nothing and you avoid authorization fees on that attempt. “Authorize and hold for review” still authorizes the card, so testers still get their answer. When the attack ends, consider switching less critical filters back to hold or report.

Does the Authorize.net velocity filter block real customers?

It can. The Hourly and Daily Velocity Filters count every transaction on your account, not just suspicious ones, so once you reach the threshold legitimate orders are caught too. Base the threshold on your normal busiest hour plus some headroom, tighten it during an attack, and relax it afterwards. The Transaction IP Velocity Filter is more targeted but depends on the customer IP being sent.

Is CAPTCHA turned on by default in Authorize.net Accept Hosted?

No. Authorize.net’s Accept Hosted documentation lists a CAPTCHA security option in its hostedPaymentSecurityOptions setting, and it defaults to off. Your developer or shopping cart plugin has to turn it on when it requests the form token. If you don’t use Accept Hosted, add a CAPTCHA or bot challenge to your own checkout page before the payment step.

Should I refund card testing charges on Authorize.net?

Yes. If an approved test transaction hasn’t settled yet, void it so it never settles. If it has already settled, refund it. Authorize.net’s support article explains which option applies. Refunding quickly is usually cheaper than fighting chargebacks, since the real cardholders are likely to dispute charges they don’t recognize. Keep a report of the attack window for your records.

To see how CardSecurity scores checkout attempts and stops scripted card testers before they reach the processor, visit CardSecurity card-testing protection.