Your site shows Cloudflare "Error 1020: Access denied"
The page says "Error 1020 Ray ID: ... Access denied. This website is using a security service to protect itself from online attacks." On your own site this is not Cloudflare being down. A firewall rule in your Cloudflare account matched the visitor and blocked them. Usually it is a rule written to stop bots or one country that also catches real customers, payment callbacks, or you. Here is how to find the exact rule and narrow it.
What the visitor sees
https://maplewoodflorist.example/checkout/
What the checks found
Find the rule that blocked them
Get the Ray ID from the error page (bottom line, like 8a1f2c3d4e5f6789). Ask the customer for a screenshot if it was them.
Open Cloudflare > your domain > Security > Events and add the filter Ray ID equals that value. The event names the service (Custom rules, IP Access rules, Rate limiting, Zone lockdown, User agent blocking) and the exact rule.
Read what matched: the event shows the country, the IP and its network (ASN), the user agent and the path. That tells you why a real person fit a rule meant for bots.
No Ray ID? Filter Events by Action = Block and the last 24 hours. A rule blocking many visitors from one country, one mobile network, or one path like /wp-admin/admin-ajax.php stands out quickly.
Is it really your account? If the domain is not in your Cloudflare dashboard at all, the 1020 comes from the owner of the site you are visiting, and only they can change it.
The fixes, by rule
A country block catching customers: travellers, people near a border, and mobile networks or VPNs that route through another country hit it. Change the action from Block to Managed Challenge, so a person passes a quick check and a script does not.
A block on /wp-admin or wp-login.php that also matches admin-ajax.php: many front-end features (cart, forms, filters) call admin-ajax, so they break for everyone. Add and not http.request.uri.path eq "/wp-admin/admin-ajax.php" to the rule, or limit it to wp-login.php only.
A block that catches payment or shipping callbacks (Stripe, PayPal, Square, WooCommerce webhooks): orders stay "pending" while the card was charged. Add a Skip rule above it for those paths, or for the provider's published IP ranges.
An IP Access rule blocking a whole network (ASN): one bad IP led to blocking a provider that real visitors share. Remove the ASN entry and block the single IP, or use a Managed Challenge on the ASN.
A user-agent or "known bots" rule that blocks Googlebot or your uptime monitor: exclude cf.client.bot (verified bots) from the rule so search engines can still crawl the site.
You blocked yourself: add your own IP as Allow under Security > WAF > Tools (IP Access rules), then fix the rule that matched you.
What you see, what it means, what it needs
What you see
What it means
Usual fix
Only visitors abroad or on one mobile network get 1020
A country or ASN block matches them
Managed Challenge instead of Block
Cart, forms or filters fail; the page itself loads
A /wp-admin block also covers admin-ajax.php
Exclude admin-ajax.php from the rule
Card charged but order stays pending
The payment webhook is blocked
Skip rule for the callback path
Search Console says pages are blocked
A bot rule blocks Googlebot too
Exclude verified bots
You see it on your own site
Your IP matches one of the rules
Allow your IP, then narrow the rule
What not to do
Do not turn off all the rules or pause Cloudflare to make it go away. The rules usually exist because of a real attack, and turning them all off brings the attack back.
Do not tell customers to "use a VPN". A VPN often makes it worse, and most will simply leave.
Do not guess which rule it was. The Ray ID names it exactly in Security > Events, and changing the wrong rule leaves the block in place.
After any change, test from a phone on mobile data and place a test order, so you know the checkout and its callbacks work.