It shows up in the payment-failure emails first. Then in the logs: one guest cart ID, hit hundreds of times, a different card each attempt, IPs rotating every few tries.
Your reCAPTCHA is on. Your AVS and CVV checks are on. Braintree's fraud tools are on.
The attempts keep coming.
This is a carding attack. On Magento 2 it is routine — and the reason your defenses miss it is that they guard the wrong part of the request.
What the attacker wants
Not your products. A way to sort live stolen cards from dead ones.
Your checkout does that for free: submit a card, read the response, learn whether it is live.
The authorization result is the product. Whether an order is fulfilled never matters to them.
Two paths into your checkout
Front door. A real browser walks the genuine flow, swapping cards on each decline. Often manual, rotating IP every few attempts to stay under your limits.
Back door — the one that matters. Magento's checkout is API-driven. An attacker reads the cart ID straight out of your page's AJAX calls, then scripts requests directly to the payment endpoint, never loading your checkout again:
POST /rest/<store>/V1/guest-carts/{cartId}/payment-information
The GraphQL placeOrder mutation is equivalent.
The signature is simple: one cart, many cards.
Why your current stack misses it
reCAPTCHA guards the form. The API path never renders the form, so the challenge never fires. A v2 checkbox is cheap to solve anyway.
IP rate limits lose to rotation and the slow manual cadence.
AVS and CVV are the ones you asked about. The short version:
- They are advisory codes from the issuer, not gates.
- Braintree only declines if you set a rule and the issuer returns a true mismatch.
- International and many debit cards return "unavailable" or "not supported" — not a mismatch, so nothing fires.
- "Validating globally" means sending AVS, not declining on it.
The core point: AVS tells you the address did not match. It does not tell you the card is stolen.
The attacker already got what they came for — an approved authorization proving the card is live.
Yes, bots can order through your APIs
The guest-cart REST endpoints and GraphQL accept scripted orders with no browser involved.
Guest orders have even been placed via the API with guest checkout disabled. Swagger is enabled by default.
Lock the API path down:
- Rate-limit and challenge
*/guest-carts/*/payment-informationand/graphqlat the edge — not the checkout URL. - Ban IPs posting to that endpoint faster than a human (fail2ban).
- Require a valid origin and referer; reject calls without them.
- Disable Swagger in production.
- Cap distinct cards per cart, per session, and per IP.
The defense that maps to the attack
Ordered by impact.
1. 3D Secure 2 — the control that ends it. The issuer authenticates the cardholder before the transaction completes. A script cannot satisfy that, so the authorization the attacker is fishing for never resolves. Set it to always-request during an attack. In the EEA it is required anyway, as PSD2 Strong Customer Authentication.
2. Score, don't guess. Use Braintree Advanced Fraud Protection. Keep CVV rejection on. Use AVS for review, never auto-decline "unavailable" or "not supported".
3. Defend the API surface — the edge rules above.
4. Correlate weak signals. The manual, IP-rotating attack beats every single rule. Many cards on one cart, a spread of unrelated BINs, payment calls with no page load, one device fingerprint behind rotating IPs — together they are unmistakable. That is the async, log-based layer's job.
Keep patching to the latest 2.4.6 security release. Necessary — but it will not close a configuration gap.
If you are under attack right now
- Turn on always-request 3D Secure.
- Add an edge challenge and fail2ban on
payment-informationand/graphql. - Cap cards per cart and per IP.
- Enable Advanced Fraud Protection; switch AVS to review.
- Watch one-cart-many-cards as your live signal.
Are you being carded?
- One guest cart, many payment POSTs, different cards
- Bursts of small authorizations, mostly declined
- Payment calls with no page views in the session
- A wide spread of card BINs from a few carts
- Attempts continuing despite reCAPTCHA
Two or more, and your checkout is a card-testing oracle right now.
FAQ
Why isn't reCAPTCHA stopping it?
It guards the form. The attack hits the API beneath it.
Why did AVS pass an obvious mismatch?
AVS is advisory and often not run by the issuer. A decline needs a configured rule — and the attacker only needed the authorization.
Can bots order through the API?
Yes, directly, with no browser.
The single most effective control?
Always-on 3D Secure 2.
Get a free carding exposure report
We will map the automated traffic reaching your Magento checkout, cart, and API endpoints, and show which controls are firing in the wrong place. Request it here.