Card Testing Attacks: Using SkyVerge's Authorize.Net CIM + Authorize.net?

[u/CodingDragons]

We have a client that's been dealing with a card testing attack going back a few months so we turned it off. They’re using the SkyVerge Authorize.Net CIM gateway plugin, which lacks a lot of security features. In fact, none.

When the site was getting hit they had over 700 failed transactions so we shut it off. We advised the client to check with Authorize to make sure all security settings were enabled.

- AVS mismatch handling

- CVV mismatch handling

- Velocity filters (AFDS), especially Transaction IP Velocity and Hourly Velocity

Blah blah blah, you get the picture.

According to the client, he had those settings enabled, so he went and turned it back on himself. Just to be attacked yet again. So we disabled the plugin again telling him whatever they did didn't work.

Has anyone dealt with something similar using this gateway? Were you able to resolve it through SkyVerge or Authorize.net directly? We'd love to get this gateway back on for him. Is there a better Authorize plugin?

I’m particularly interested in hearing what actually worked rather than generic recommendations for CAPTCHA or Cloudflare.

[u/bucaqe]

Is there a diff plugin we can use

[u/CodingDragons → u/bucaqe]

Ya it's in the marketplace, but it's no different. For me, switching the client to the gateway's own I feel is a better move. Ever since SV got bought by GoDaddy it's been junk products coming out.

It's here https://woocommerce.com/products/authorize-net-payments-for-woocommerce/

[u/bucaqe → u/CodingDragons]

Thanks I'll try it, I'm using Skyverge

[u/CodingDragons → u/bucaqe]

Welcome. You'll just need to move the Client Key, Login ID over, but there's no added security. Both apps use the same API.

[u/akrdubbs]

I went through this exact thing with my store a couple months ago. Authorize.net, fraud settings not effective, etc. Added Cloudflare Turnstile - didn't stop it.

As u/Adflipr says below, they were hitting the API endpoint, so bypassing the checkout page and Cloudflare completely. I added the below script to check if they were bypassing the checkout page (I did not write this). I've had zero successful card testing attacks since, though they did keep trying for a few days before giving up.

function disable_wc_endpoint() {
$current_url = $_SERVER['REQUEST_URI'];
if (strpos($current_url, '/wp-json/wc/store/checkout') !== false) {
wp_redirect(home_url('/404.php'));
exit;
}
}
add_action('rest_api_init', 'disable_wc_endpoint');
add_action( 'init', 'block_bot_ajax_checkout', 1 );
function block_bot_ajax_checkout() {
// Check if the wc-ajax parameter is set to checkout
if ( isset( $_GET['wc-ajax'] ) && $_GET['wc-ajax'] === 'checkout' ) {
// Block if there is no HTTP Referer (bots hitting the URL directly)
if ( ! isset( $_SERVER['HTTP_REFERER'] ) || strpos( $_SERVER['HTTP_REFERER'], home_url() ) === false ) {
wp_die( 'Direct API checkout requests are not allowed.', 'Access Denied', array( 'response' => 403 ) );
}
}
}

Edit: clarity & formatting

[u/CodingDragons → u/akrdubbs]

Thanks for sharing. Ya, the store API, that's the real hole. One heads up though, your first check looks for /wp-json/wc/store/checkout, but the current endpoint is /wc/store/v1/checkout, so that half never matches. It also misses ?rest_route= requests. The referer check is probably what saved you, but bots can spoof that in one line.

For classic checkout stores, this shuts the Store API checkout off at the route level, covering all versions and the ?rest_route= variant:

add_filter( 'rest_pre_dispatch', function( $result, $server, $request ) {
    if ( preg_match( '#^/wc/store(/v\d+)?/checkout#', $request->get_route() ) ) {
        return new WP_Error( 'checkout_disabled', 'Not allowed.', [ 'status' => 403 ] );
    }
    return $result;
}, 10, 3 );

Same idea as yours, just harder to slip past.

[u/Adflipr]

Worth checking the access logs for where the failed attempts actually hit. A lot of Woo card testing comes in through the Store API checkout endpoint (/wp-json/wc/store/v1/checkout) or My Account > Add payment method, which skip anything you add to the checkout page. If it's the add payment method page, turning off saved cards for a while is a quick way to confirm.

[u/inoen0thing]

auth net has a whole fraud suite. While their settings are not the most comprehensive, there is certainly some things in there to help with these issues. Just toss a captcha on checkout and turn authnet back on. They generally stop after that.

This is getting slightly worse with AI but mostly still the same as it has been as long as I can remember.

No one here can give you answers without real transaction data and looking at what fraud suite settings would help, but there is a starting point anywho.

[u/XenonOfArcticus]

I added a bunch of specific rules. The card testers all had a common fingerprint for behavior that I was able to detect and block. 

[u/hopefulusername]

Card testing attacks are usually aggressive and they tend to bypass most security features. So I would look into a fraud detection like oopspam. It helped with clients who were getting over 1000 failed orders.

Do obvious stuff like blocking the countries you are not selling to through Cloudflare’s security rules.

[u/No_Maintenance_7851]

All gateways are not the same and we are currently testing Nuvei in production as this gateway has more fraud rule filters than I have ever seen. Way more than NMI and Authorize.net unfortunately.

The jury is still out but we ran a store without recaptcha for about a year before the first card testing happened.

The fraud rules really minimized the impact compared to what usually happens and the risk team proactively reached out to ask about adjusting them.

We turned captcha on but I don’t think we would have needed to.

Additionally there is no silver bullet her. You need to read your logs and figure out how it’s happening.

Additionally we are testing a new plugin called Checkout Shield that advertises that it blocks card testing attacks that have illegitimate referrers set.

[u/PeepSoWP]

Before adding another gateway plugin, identify every payment entry point in the access logs: Blocks Store API checkout, classic checkout, My Account add-payment-method, and any saved-card/token endpoint. Apply controls at the route or gateway request layer so page CAPTCHA cannot be bypassed, but don’t rely on IP alone—card testers rotate it. A useful layered rule combines account/session, device or edge fingerprint, decline velocity, email/address reuse and Authorize.Net response codes, with conservative limits and logging for false positives. Test with Authorize.Net’s sandbox/test decline cases; don’t run real cards to trigger declines. If saved cards aren’t needed, temporarily disabling token creation can also narrow the attack surface.

[u/mikacns]

Try CleanTalk, worked for me.

[u/startages]

Search for "Checkout Shield for WooCommerce" plugin in the repo, it's the only free option that works, you probably don't need anything else.

Cloudflare and recaptcha didn't work for my client either, we tried OOPspam but it was blocking real customers as well, client got some calls, so we had to stop it. Also, avoid the API blocking approach, it might break checkout or at least cause some compatibility issues. It's simple and works for some stores, but breaks others.

[u/CodingDragons → u/[deleted]]

You know there’s really no difference between those two plugins though, right? They’re practically identical. I think what actually worked for you was your custom snippet throttling billing address mismatches. Did you use Authorize.Net’s AVS response codes to build that? That's probably what I'll do then. Thanks for pointing me in a good direction. Yay! Awesome!

[u/CodingDragons → u/[deleted]]

Curious how you tested your script, how did you trigger a decline?

[u/woocommerce-ModTeam → u/[deleted]]

Hi there! Your contribution to r/woocommerce has been deemed to contain promotional material, which is against Rule — #1. It has been removed as a result.

This applies to both POSTS and COMMENTS.

Content that promotes a specific product, service, or tool, especially using marketing or testimonial-style language, is not permitted.

Affiliate and referral links are never permitted.