Overview
This article describes every fraud module available in USAePay's consoles, listed alphabetically. Each entry explains what the module is used to combat, common use cases, console-specific naming differences, and the error message a merchant will see when the module blocks a transaction. Use this article alongside How to Add and Manage Fraud Modules in USAePay for setup steps, and Troubleshooting Fraud Module Errors for resolving errored transactions.
Module names sometimes differ slightly between Console 1 (Legacy Console) and Console 2. Both names are noted where they differ.
Advanced Transaction Filter
Used primarily to combat: custom fraud patterns not covered by another module (bad invoice formats, disallowed email domains, out-of-range totals, etc.)
The Advanced Transaction Filter lets a merchant build custom rules against transaction fields (Invoice, Email, Billing/Shipping fields, Subtotal, Tax, Tip, and more), using tests like Equals, Contains, Starts With, Is Greater Than, and In List. Up to 100 rules can be added, and rules are not case-sensitive.
Common uses:
- Blocking specific email domains not covered by the Email Blocker
- Rejecting transactions with subtotal, tax, or tip amounts outside expected ranges
Error message: If no custom message is entered, the default is: The value of field "[Name of Field]" was blocked.
As a best practice, entering "Error" in the Optional Custom Error field helps avoid revealing which validation failed, making it more difficult for fraudsters to determine what information or field needs to be changed.
Console 1
Console 2
AVS Response
Used primarily to combat: stolen card use where the billing address doesn't match the card on file.
The Address Verification System (AVS) module checks the billing street and zip code the customer enters against what the card's issuing bank has on file. The merchant selects which AVS result codes to accept; all others are errored.
Common uses:
- Blocking card-not-present transactions where the address doesn't match
- Reducing chargebacks tied to stolen card numbers
Error message: Your billing information does not match your credit card. Please check with your bank. (34)
ℹ️ AVS Pre-Check : AVS Pre-Check checks the AVS result before requesting authorization, so a transaction rejected by this module won't create a pending authorization on the customer's account. Without Pre-Check, the bank may still approve and hold funds even though the gateway errors the transaction. Pre-Check requires processor and issuing bank support, and is not available for Retail (Swipe) merchants.
Common uses:
- Rejects transactions when the billing address entered by the customer does not match the billing address on file with the card issuer.
Console 1
Console 2
Bin Ranges (Console 1: "Bin Range Blocker")
Used primarily to combat: known bad card ranges, prepaid/gift cards, or cards issued in specific countries.
This module blocks transactions based on the first six digits of the card number (the BIN), which identifies the issuing bank. Merchants enter each BIN range to block on its own line.
Common uses:
- Blocking gift or reward cards
- Blocking cards issued by a specific bank or in a specific country
Error message: Card issuer blocked, please try a different card.
Console 1
Console 2
Bin Type Blocker
Used primarily to combat: unwanted card types (e.g., debit-only fraud, or unsupported card brands).
This module accepts or blocks cards by a combination of card issuer (Visa, MasterCard, American Express, Discover) and card type (Credit, Debit, Prepaid, Unknown).
Common uses:
- Accepting only debit transactions
- Blocking all Amex/Discover transactions for a merchant that doesn't support them
Error message: Card not accepted by merchant, please try a different card (or a custom message if one is set)
Console 1
Console 2
Block by Card Country
Used primarily to combat: transactions from cards issued in high-risk or unsupported countries.
This module accepts or blocks transactions based on the credit card's country of origin, determined by the card's BIN — not the customer's IP address. Merchants choose either "Accept All Except" or "Deny All Except," then build a country list.
Common uses:
- Restricting a merchant to only accept domestically issued cards
- Blocking cards issued from a small list of high-risk countries
Error message: Merchant does not accept this card due to its country of origin : (Country)
Console 1
Console 2
Block by Host or IP (Console 1: "Block By Host or IP Address")
Used primarily to combat: known fraudulent IP addresses, hosts, or domains submitting transactions.
This module blocks transactions based on a single IP, a range of IPs, a host address, or an entire domain/subdomain/TLD. It requires the merchant's shopping cart or software to pass the customer's Client IP to the gateway.
Common uses:
- Blocking a specific IP address flagged for repeated fraud attempts
- Blocking an entire suspicious domain or country-code TLD
Error message: IP (XXXXX) blocked by fraud stopper. (c)
⚠️ Blocking by host or domain name (rather than IP) is discouraged, since the lookup adds processing time to every transaction.
Console 1
Console 2
Card ID Checker
Used primarily to combat: stolen card numbers used without the physical card (no CVV match).
This module accepts or errors transactions based on the CVV2/CID result returned by the issuing bank.
Common uses:
- Requiring a valid CVV match for all card-not-present transactions
- Reducing approvals on stolen card numbers being tested without a CVV
Error message: Unable to verify card ID number.
Note: Like AVS Response, a transaction rejected by this module may still generate a pending authorization on the customer's account if the issuing bank approved it before the CVV check. See the Troubleshooting Fraud Module Errors article for resolution steps.
Console 1 - Simple
Console 1 - Advanced
Console 2 - Simple
Console 2 - Advanced
Card Level Results (Console 1: "Card Level Result")
Used primarily to combat: unwanted transactions on specific card categories (e.g., corporate, rewards, or healthcare cards).
This module accepts or errors transactions based on the card level result returned by the issuing bank (Traditional, Business, Healthcare, Rewards, Corporate, etc.).
Common uses:
- Restricting acceptance to standard consumer cards only
- Blocking corporate or purchasing cards if the merchant's processing agreement doesn't support them
Error message: Card not accepted by merchant, please try a different card.
Console 1
Console 2
Card Type (Console 1: "Card Types")
Used primarily to combat: acceptance of card brands the merchant isn't set up to process.
This module accepts or blocks transactions by card brand (Visa, MasterCard, Discover, American Express).
Common uses:
- Blocking card brands the merchant's processor doesn't support
- Limiting acceptance to one or two card brands by merchant preference
Error message: Merchant does not accept card type.
⚠️ This module does not control the merchant's actual processing capabilities. Even if a card type is "allowed" here, it will still be declined by the processor if the merchant's account isn't set up to accept it.
Console 1
Console 2
Country Blocker
Used primarily to combat: transactions originating from high-risk or unsupported countries, based on the customer's location.
Unlike Block by Card Country, this module determines country using the customer's IP address (GeoIP) rather than the card's BIN. It requires the merchant's software to pass the Client IP to the gateway.
Common uses:
- Blocking traffic from countries with no legitimate customer base
- Restricting a merchant to only accept orders placed from within their home country
Error message: Merchant does not accept transactions from (XXXX)
Console 1
Console 2
Credit Card Blocker
Used primarily to combat: known stolen or bad credit card numbers.
This module checks the card number against the gateway's system-maintained list of known bad cards, a merchant's custom block list, or both.
Common uses:
- Blocking a specific card number after a confirmed fraud incident
- Applying the system-wide bad card list to reduce repeat fraud attempts
Error message: Merchant does not accept this card, try a different card. (or a custom message if one is set)
Console 1
Console 2
Duplicate Detection
Used primarily to combat: accidental double charges, not intentional fraud.
This module detects and blocks duplicate transactions using the last 4 digits of the card number, the transaction amount, and (optionally) the invoice number, within a merchant-defined time window (up to 2880 minutes / 48 hours).
Common uses:
- Preventing double charges from a customer double-clicking an order button
- Preventing duplicate charges when a customer clicks "Back" on a payment form
Error message: Duplicate Transaction, wait at least (XX) minutes before trying again.
⚠️ Do not enable this module alongside a source key's own Duplicate Transaction Handling setting — combining the two can cause a system error.
Console 1
Console 2
Email Blocker
Used primarily to combat: disposable/free webmail fraud and specific known-bad email addresses.
This module blocks or allows transactions based on the customer's email address or domain (e.g., Yahoo, Hotmail).
Common uses:
- Blocking free webmail domains commonly used in fraud attempts
- Allowing a specific list of trusted email domains only
Error message: Email address (XXXX) blocked by merchant. Please use a different email address.
Console 1
Console 2
Fraud Profiler
Used primarily to combat: broad, pattern-based fraud (unusual transaction volume, sudden spikes, geographic anomalies).
This module runs a real-time fraud risk score against every transaction using automated and behavioral pattern analysis. Transactions scoring above the merchant's threshold are blocked.
Common uses:
- Catching fraud patterns that don't fit a single rule (sudden volume spikes, unusual decline rates)
- Adjusting sensitivity or the decline message without disabling baseline protection
Error message: Transaction declined (fp).
ℹ️ A baseline version of Fraud Profiler is applied automatically to all merchants at a threshold designed to prevent large-scale abuse without affecting normal transaction patterns. Merchants only need to add this module themselves if they want to change the decline message or adjust the sensitivity threshold.
Console 1
Console 2
Multiple Credit Cards
Used primarily to combat: stolen card number testing (card cracking/carding).
This module blocks transactions once a merchant-defined number of unique cards or declines occur within a time period, grouped by Invoice #, Order ID, or Client IP.
Common uses:
- Stopping repeated card-testing attempts from the same customer or IP
- Limiting how many different cards can be tried against a single order
Error message: You have tried too many card numbers, please contact merchant.
Console 1
Console 2
Required Fields
Used primarily to combat: incomplete or missing transaction data that makes other fraud checks (like AVS) less effective.
This module requires specific fields (Invoice, Description, Card Holder, AVS Street, AVS Zip, etc.) to be completed before a transaction can process.
Common uses:
- Ensuring every transaction has billing address data available for AVS checks
- Requiring an invoice number for internal tracking
Error message: The required fields (XXX) are missing.
⚠️ Confirm the required field is actually available on every source it's applied to. For example, requiring Shipping Street on a source that doesn't collect shipping data (like Simple Charge) will cause every transaction on that source to fail.
Console 1
Console 2
Transaction Amount
Used primarily to combat: unusually large or small transaction amounts that fall outside a merchant's normal order size.
This module rejects transactions outside a defined minimum and/or maximum dollar amount. Entering * in either field leaves that side unrestricted.
Common uses:
- Blocking unusually large test transactions
- Preventing $0 or near-$0 transactions used to validate stolen cards
Error message: The (minimum/maximum) order amount is $(XXX).
Console 1
Console 2
Zip Code Verifier
Used primarily to combat: fake or inconsistent address data used to bypass basic checks.
This module verifies that the billing and/or shipping zip code is valid and consistent with the State, City, and/or Area Code entered — it does not confirm the address belongs to the cardholder.
Common uses:
- Catching obviously fake billing/shipping addresses
- Ensuring shipping zip codes match the shipping state/city entered
Error message: one of:
- (Billing/Shipping) (state/city/area code) does not match (billing/shipping) zip code.
- Invalid shipping zip code.
- Invalid billing zip code.
Console 1
Console 2
Common Questions
Q: Why do some modules have different names in Console 1 vs. Console 2?
A: The consoles were built at different times, and several module names were updated for clarity in Console 2. The functionality of each module is the same; only the label changed. See the naming notes above for each module.
Q: Which module should I use to block a country — Country Blocker or Block by Card Country?
A: Country Blocker uses the customer's IP address (requires the merchant's software to pass Client IP). Block by Card Country uses the card's BIN instead, so it works even if IP data isn't available.
Q: Can I combine multiple fraud modules?
A: Yes. Merchants can use several modules together (for example, AVS Response + Card ID Checker + Duplicate Detection) for layered protection.