The customer cannot check out. She tries again. It fails again. She sends a screenshot of a grey page with a number on it.
You forward it to the payment gateway, who reply that it is not them. They suggest the bank. The bank has nothing to report, because as far as the bank is concerned no transaction was ever attempted. Everyone in the chain is being honest and nobody is being useful.
If you run an online shop, you have been in this meeting.
What error 1015 actually is
Error 1015 is not a payment error. It has nothing to do with cards, funds, fraud scoring or your merchant account. It is a Cloudflare response, and it means you are being rate limited.
Cloudflare’s own documentation puts it plainly. The site “has received too many requests and has temporarily blocked you from accessing it”, because “the website owner has configured rate limiting rules that restrict how many requests a visitor can make to their site in a given time period”.
That is the whole message. Too many requests, too fast, from one address. It says nothing about whether the payment would have succeeded.
The error you are shown belongs to the layer that noticed. Not necessarily to the layer that failed.
The bit that tells you where to look
The giveaway is in the URL on that grey page.
If the blocked request is hitting a path containing ThreeDSecure/V2_1_0/CReq, you are not looking at your shop or your gateway. You are looking at card authentication.
3-D Secure is the verification step that happens after the card details go in, when the bank asks the shopper to confirm it is really them, usually with a prompt in the banking app or a one-time PIN. Visa calls its version Visa Secure, which many people still know by its old name, Verified by Visa. Mastercard calls its version Identity Check.
CReq is short for Challenge Request, the message that carries that challenge to the cardholder.
CardinalCommerce is one of the services that runs this step. It sits between the shop’s payment gateway and the issuing bank. Gateways are usually explicit that this is not their job: CardPointe’s documentation, for one, states that “The CardPointe Gateway does not provide a mechanism for cardholder authentication.”
So the anatomy of a checkout looks like this:
- The shop takes the order.
- The payment gateway takes the card.
- The 3-D Secure provider takes the verification to the bank.
- The bank approves or declines.
- In front of all of it, a security and performance layer decides who is even allowed to knock.
A 1015 on a CReq URL means the block happened at layer five, in front of layer three. That locates the blocking. It does not yet tell you what caused the flood of requests that triggered it, and those are two different questions.
Why it looks random to the customer
Rate limits are cumulative and time-boxed.
Something fails once for an ordinary reason: a mistyped digit, a slow banking app, a dropped connection. The shopper retries. Then retries again. Each attempt counts against the limit. A few attempts in quick succession and the limit trips, after which everything fails, including the attempts that would have worked.
The shopper reasonably concludes that your shop is broken. She leaves, and she tells a friend your shop is broken.
To your monitoring, this looks like nothing at all. The site is up, the gateway reports no declines, and there is no failed transaction to investigate, because nothing ever reached anything capable of failing it. Your analytics cannot see an abandoned checkout that was never allowed to begin.
The question that actually splits the diagnosis
Here is where most people stop too early, ourselves included on a first pass.
“The customer retried too many times” is the comfortable answer. It is often correct. It is also the answer that costs you nothing, which is exactly why it deserves a second look.
The thing that separates a customer retrying from a system misbehaving is the timestamps.
Ask the shopper to check her banking app and tell you the times on the verification prompts. If ten prompts arrived over four minutes, that is a person clicking. If ten prompts arrived inside the same second, no human did that. Something upstream sent the same authentication request over and over, and that flood is what tripped the limit.
Same symptom. Same error page. Completely different fix, and only one of them is yours to make.
That single detail, the second on the clock, is worth more than a week of everyone reassuring each other that it is not their side.
The diagnosis order
Work through it in this sequence.
1. Confirm it is a rate limit, not an outage. Wait fifteen to sixty minutes, then retry from a different network. Mobile data instead of office wifi is the fastest test. If it works from the second network, you have a rate limit.
2. Get the timestamps. As above. This is the highest-value question in the whole process and almost nobody asks it.
3. Establish whether it is one shopper or many. One shopper, once, after several rapid retries is the system working as designed. Many shoppers, repeatedly, means something structural.
4. Look for a duplicate submission. A plugin, a payment extension, a theme conflict or a piece of custom JavaScript firing the same verification request several times per click will trip a limit no human could. From the shopper’s side it looks like one click.
5. Ask the gateway for the request count. This is the one people skip, and it settles the argument. Ask your provider for their transaction log for that merchant profile, showing how many 3-D Secure authentication requests were initiated per checkout session, with timestamps. One request per session means the duplication is happening downstream of them. More than one means it is not.
6. Check for shared IP addresses. If a meaningful share of your customers sit behind one corporate network, one mobile carrier, one school or one VPN, then to a firewall they are all the same visitor. Individually reasonable behaviour becomes collectively suspicious.
The wider point
A modern checkout has four or five independent layers, each run by a different company, each with its own error vocabulary.
When something goes wrong, the message you get is written by whichever layer noticed. Not necessarily by whichever layer failed. That is why “the payment gateway is broken” is so often wrong, and why a blame meeting can run for a week without anyone being dishonest.
It also means the first plausible explanation is not the same thing as the correct one. On an eCommerce site that distinction is worth real money, because the orders you lose to this never appear in a single report.
It sounds technical. It isn’t. Not really. It is knowing who is in the room, and asking one of them for a timestamp.
If your checkout is doing something strange and nobody can tell you why, that is a diagnosable problem, and usually a smaller one than it feels like at 11pm. Our WordPress and WooCommerce concierge service exists for the layers you did not know you owned.
