Fraud controls in EPD Commerce: how the Transact pillar stops card attacks

8 min read Transactagentic commercefraud preventionchargeback protectionpayment security

Fraud controls in EPD Commerce: how the Transact pillar stops card attacks

Card spinning attacks, where bad actors run hundreds of small authorization attempts against a single merchant account, are one of the fastest ways to accumulate chargebacks, trigger processor reviews, and get a merchant account shut down. EPD Commerce Fraud Controls, part of the Transact pillar, give merchants and their account managers a layered, configurable defense they can activate before the damage compounds.

What fraud controls do and why layering matters

Most platforms tell you a fraud event happened. EPD Commerce gives you the controls to stop the next one before it clears.

The system is built in four cooperating layers. Each layer can be configured independently, and together they cover the full surface area of a typical card attack:

  1. Fraud velocity filters: Set count limits on transaction attempts within a time window. EPD Commerce applies these at the “Attempted” transaction type, which catches probing activity before any charge completes. Standard configuration applies count limits only, not dollar-amount thresholds, because volume is the signal in card-spinning scenarios.

  2. Fraud user ban filters: Block specific actors by email address, email domain, credit card number, IP address, or geographic area. Bans are applied indefinitely. The download-and-block workflow lets a team pull a list of fraud-attempted transactions, identify the common fields, and push blocks for all of them in one pass.

  3. CVV verification rules: Decline transactions where the card security code does not match, or where the code should be present but is not indicated. These two conditions (result codes N and S) are the standard configuration applied across accounts during setup.

  4. AVS address verification: Decline when address information for the cardholder is unavailable (result code U). Combined with CVV rules, this closes off the most common card-testing vectors where attackers use generated card numbers without real billing data.

How the ban-list workflow runs in practice

The most operationally important part of Fraud Controls is the ability to act quickly when an attack is already in progress.

The workflow:

  1. Download the transaction list filtered to “fraud attempted” status.
  2. Identify the attack vectors: shared email domain, card number prefix, IP address cluster, or geography.
  3. Apply targeted bans for each identified field. Email domain blocks are especially effective because they stop the entire domain, not just one address.
  4. If the attack volume is high enough, restrict or disable the merchant account at the processor level while the ban list is being built. This pauses all processing for that account and can be reversed once the filters are in place.

Note on IP address blocks: these require more care than other ban types. Some shopping cart integrations, including certain hosted cart environments, route all traffic through shared IP addresses. Blocking an IP in those cases can affect legitimate customers. Email and card-number bans are the safer first response in most attack scenarios.

What does not get set by default

A few controls exist in the system but are not part of standard account setup:

  • Monthly or yearly transaction count limits: these are not typically enabled, because legitimate volume spikes (promotions, seasonal peaks) would trigger false positives.
  • Time-limited user bans: indefinite bans are the standard. There is no documented use case for banning a confirmed fraudulent actor for only a fixed number of days.
  • Dollar-amount velocity thresholds: count limits catch attack patterns earlier and with fewer false positives than amount-based limits.

Who configures these controls

During account setup, EPD Commerce applies a standard fraud control baseline to every merchant account. Velocity filter count limits and the CVV and AVS rule sets described above are part of that baseline.

Merchants with active attack patterns can request immediate changes through their account manager, who can push ban-list updates and processor-level restrictions without waiting for a scheduled review.

FAQ

What are EPD Commerce Fraud Controls?

EPD Commerce Fraud Controls are a set of configurable rules in the Transact pillar that protect merchant accounts from card spinning and other fraud attacks. They include velocity filters, user ban lists, CVV verification, and AVS address verification, applied in layers to stop fraudulent transactions before chargebacks accumulate.

What fields can I block when I download my fraud-attempted transaction list?

You can block by geographic area, email address, email domain, IP address, and credit card number. Domain-level email blocks are particularly effective because they stop all variations of an attacker’s address, not just the specific one used in a given attempt.

Can EPD Commerce pause my entire merchant account if an attack is ongoing?

Yes. The system supports restricting or disabling a merchant account at the processor level, which halts all transaction processing for that account. This is the recommended first step when a high-volume card attack is in progress, while the targeted ban list is being assembled and applied.

What CVV and AVS settings are applied by default?

CVV rules decline transactions where the card security code does not match (result code N) or where the code should be present but is not indicated (result code S). AVS rules decline when cardholder address information is unavailable (result code U). These are the standard settings applied to all accounts during onboarding.

Why should I be careful about blocking IP addresses?

Some shopping cart platforms route all customer transactions through a shared IP address. Blocking that IP would also block legitimate buyers using the same cart. EPD Commerce recommends applying email domain and credit card number bans first, and using IP blocks only when the attack traffic is clearly isolated to specific addresses not shared with legitimate traffic.


EPD Commerce is currently in Beta, with public launch in October. Merchants and developers interested in access can apply at epd.com.

Get early beta access

Request your beta invite

We respond within one business day.

Now in private beta. Powered by Easy Pay Direct.

Now in private beta

EPD Commerce brings your operations, payments, and AI-discoverable products into one connected system.

  • Chat with your data and get instant answers
  • Hands-on onboarding from our commerce team
  • Products made discoverable to AI agents by default
  • Payments, recovery, and analytics in one connected system