​
3D Secure

Card payments in the EEA need strong customer authentication. 3D Secure runs on the checkout page when the card issuer asks for it; you don’t need to do anything. A declined payment’s reason is on the Payment as outcome.providerReason.

​
Risk rules

Set rules in the dashboard (Settings → Risk rules) or with the API (/api/v1/fraud-rules):
Email rules need an email. They use the customerEmail (or the customer’s email) you send when you create the checkout session. Without one they are skipped, not passed; amount rules still apply. Payment links always collect the email first.

​
When a payment is blocked

  • At checkout creation (guaranteed): POST /api/v1/checkout-sessions answers 402 with type: "payment_blocked" and code rule_<kind>. No payment page is created. The response never reveals the rule’s value.
  • Right before payment (best effort): The checkout asks Zahlo once more just before the customer pays. If a rule now matches, the customer sees “This payment is no longer available”. The payment goes through if Zahlo doesn’t answer in time or is unreachable, and a page that was already open can still be paid after the session expired. Such payments are recorded normally; refund them if needed.
  • Too many attempts: payment links allow 10 checkouts per hour from one network address, 300 per link and 1,000 per merchant; a checkout allows 5 payment attempts. Over the limit the customer is asked to try again later.
Every block is listed under Blocked attempts in the dashboard. Zahlo stores a keyed hash of the email, never the email or the network address itself.

​
What Zahlo does not do

Zahlo doesn’t score payments for risk, run device fingerprinting or machine-learning fraud models, or guarantee that a blocked customer can’t pay another way. The payment processor applies its own checks independently.