Square Risk Manager and Zen Cart Stores Print

A recommended starter ruleset and setup guide

Last reviewed: August 2026

Who this is for

Owners and developers of a typical Zen Cart storefront taking card payments through Square — a single online store, modest order volume, a physical product catalog, mostly domestic customers with some international orders, and no dedicated fraud analyst on staff.

If that describes your store, you can implement everything here in about twenty minutes.

1. Before you write a single rule

Know which Square module you're running

The one thing that will bite you: 3D Secure

Square's Risk Manager offers a 3D Secure (3DS) authentication action. It is genuinely the best tool on the menu — the customer authenticates with their issuing bank, and liability for fraudulent chargebacks shifts from you to the issuer.

But it does not work by itself. Risk Manager decides when 3DS is required; your storefront has to actually perform it. In the Web Payments SDK that means passing verificationDetails to card.tokenize() (the older verifyBuyer() method still works but is deprecated).

If a 3DS rule fires and your checkout never runs the authentication step, Square does not silently skip it — the payment is declined with CARD_DECLINED_VERIFICATION_REQUIRED. The customer sees a failed order and no explanation.

The Zen Cart Square WebPay documentation does not currently document 3DS/SCA support. Assume your store does not support it until you have proven otherwise.

How to prove it — do this before enabling any 3DS rule:

1. Enable one 3DS rule with the narrowest possible condition (for example, payment amount over a very high number you can hit deliberately).
2. Place a real test order that trips it.
3. If you see a bank authentication step and the order completes → your module supports 3DS. Proceed.
4. If the order is declined with a verification error → your module does not. Deactivate the rule immediately and use blocks and alerts instead.

Everything in the Tier 1 and Tier 2 rulesets below works regardless of 3DS support.

Know what Square can actually see

Rules can only act on signals your checkout sends. For a standard Zen Cart + Square WebPay setup:

• Billing address (AVS) and CVV come from the Square card form — generally available.
• Buyer IP address and card origin are determined by Square.
• Shipping ZIP comes from the Zen Cart order.
• Risk evaluation is Square's own model score — available on every payment, and it is the single most useful signal you have.

2. The recommended ruleset

Build it in tiers. Tier 1 on day one; add Tier 2 after a couple of weeks once you can see what your alert volume actually looks like.

Tier 1 — Start here (four rules)

That's roughly 80% of the available protection, with a very low false-decline cost.

Tier 2 — Add after two weeks

Tier 3 — Only if you confirmed 3DS support

Note that Square restricts which conditions can be paired with the 3DS action. Only these four are available: card origin, card purchases per day, payment amount, and risk evaluation. Billing address, CVV, payment method, buyer IP, and shipping ZIP cannot trigger 3DS.

3. Rules to avoid

These are the mistakes that show up over and over in real Square accounts.

Don't block on billing address mismatch alone

This is the single most common self-inflicted wound. AVS is largely a US/UK/Canada system — most non-US issuers simply don't participate and return a mismatch or "unavailable" by default. Domestically it also fires on typos, missing apartment numbers, work addresses, customers who recently moved, and any order shipped as a gift.

For a typical Zen Cart store — niche or hobbyist catalogs where gift purchases and international customers are normal — blocking on AVS alone rejects a meaningful amount of real revenue.

Always pair it with the risk score, as in the Tier 2 rule above.

Don't block on "billing address is unavailable"

Same reasoning, worse. "Unavailable" usually means the issuer doesn't support the check at all — it tells you nothing about the buyer.

Don't confuse "CVV is invalid" with "CVV is unavailable"

Invalid means the code was actually wrong — block it. Unavailable means the check didn't run — that's common for legitimate reasons and should not block.

Don't blanket-block prepaid cards

Prepaid cards are harder to trace, but plenty of legitimate customers pay with gift cards — especially around the holidays, which for most Zen Cart retailers is peak season. Qualify the rule (prepaid and something else) rather than banning the payment type.

Don't write compound rules that duplicate simple ones

If you already block on high risk, then a rule that blocks on "invalid CVV and high risk and address mismatch" can never fire — the first rule catches every one of those payments. These accumulate over the years and make your ruleset impossible to reason about.

Test: for each compound rule, ask whether any single condition inside it is already blocked on its own. If yes, the compound rule is dead weight.

Don't set an alert on something you already block

The payment is rejected either way; all you get is a noisier queue.

Don't scope rules to payment sources you don't use

Square offers Online, eGift card, Invoice, Subscription, Virtual Terminal, and Appointments. A standard Zen Cart store is Online — add eGift card only if you actually sell Square eGift cards. Leaving Virtual Terminal checked means a rule can block a card you're keying in by hand over the phone.

4. How to create a rule in Square Risk Manager

Getting there

1. Sign in to the Square Dashboard.
2. Open the left navigation → Risk Manager → Rules.

You'll see Active rules, and below them recommended rules ("Based on businesses similar to yours") that Square suggests. You can activate a recommended rule in one click, but read its conditions first — the suggestions are generic, and some overlap with rules you already have.

Creating one

1. Click Create rule (top right of the Active rules list).

2. Rule name — replace the default "Rule 1". Use a name that states what the rule does, like Block: Invalid CVV. You will thank yourself in two years.

3. Action — pick one:

   • Send an alert for a payment — payment proceeds, you're notified
   • Block a payment — payment is declined
   • Authenticate payment with 3D Secure (3DS) — buyer is challenged by their bank

4. Payment source — tick Online (and eGift card if relevant). Leave the rest unchecked.

5. Condition — choose a signal and then its specific value. Available conditions:

   Condition	Values
   Billing address	does not match / is unavailable
   Buyer IP address	is out of the country
   Card origin	is out of the country
   Card purchases per day	more than N
   CVV	invalid / is unavailable
   Payment amount	more than X
   Payment method	is prepaid
   Risk evaluation	is high / is moderate
   Shipping ZIP code	does not match billing

6. Click Add condition to combine signals. Maximum of three conditions per rule, joined by AND.

7. Read the Rule summary box at the bottom. Square writes out the rule in plain English — this is your last chance to catch a mistake, so actually read it.

8. Click Activate rule.

The rule goes live within a minute or two.

Editing a rule — an important limitation

Clicking Edit rule on an existing rule lets you change only the location(s). The name, action, payment source, and conditions are locked.

To change any of those, you must:

1. Create the replacement rule first (so you're never unprotected), then
2. Deactivate the old one.

Deactivating is permanent — you cannot undo it, though you can recreate the same rule later. Deactivated rules remain in your historical reports.

5. If you run more than one location

Rules are scoped per location, and Square's Settings page has a per-location enrollment toggle (Risk Manager → Settings → Locations).

⚠️ Enroll one location at a time

When you enroll a location, Square offers to apply your existing rules to it. That dialog rewrites each rule's entire location list rather than adding to it, using whatever data it loaded when the page rendered.

Enroll several locations back-to-back without reloading and each one silently drops the previous one's assignment. Every toggle and success message looks correct — only the Rules list reveals the problem.

Safe procedure: enroll one location → reload the page → enroll the next → when finished, open Rules and confirm each rule lists every location you expect.

If assignments were already lost, don't re-run the enrollments. Fix it on each rule directly: Edit rule → Location → select all → Save changes.

Also worth knowing: setting a rule's location to All locations means it automatically covers any location you enroll later.

6. Notifications

Alert delivery is controlled by a single account-wide toggle at Risk Manager → Settings → Notifications. It is not configurable per rule — you cannot have one rule email you and another log quietly.

Plan accordingly: if you write several alert rules across several locations, all of them land in the same inbox. An alert queue nobody reads is the same as having no alerts, so keep the number of alert rules small and meaningful.

7. Rolling out safely

1. Write Tier 1. Four rules, one sitting.
2. Wait two weeks. Check Risk Manager → Alerts and Blocked payments.
3. Read your blocks. Every blocked payment is either prevented fraud or lost revenue. Scan for names, addresses, or order patterns that look like real customers — that's your false-positive rate.
4. Watch for the silent signal. If customer service starts hearing "my card was declined on your site but works everywhere else," a rule is too aggressive. Zen Cart's checkout gives the customer very little explanation, so most affected buyers simply leave without contacting you.
5. Add Tier 2 one rule at a time, with a week between each, so you can attribute any change to a specific rule.
6. Review annually. Prune rules that never fire and rules made redundant by newer ones.

A number that deserves a second look

Zero disputes alongside a large blocked-payment total is not automatically a win. It's also exactly what over-blocking looks like. The goal is the lowest total cost — fraud losses plus lost legitimate revenue — not the lowest fraud number in isolation.

8. Quick troubleshooting

Sources

• Square WebPay | Zen Cart Documentation
• Square Payments Form Module | Zen Cart Documentation
• About Payment Modules | Zen Cart Documentation
• square_payments_for_zencart (archived) | GitHub
• Strong Customer Authentication | Square Developer
• Take a Card Payment | Square Developer
• Web Payments SDK Overview | Square Developer

Rule-builder behavior described in §4–§6 was verified directly in the Square Dashboard in August 2026. Square changes this interface periodically; if what you see differs, trust the screen.