Partner Fraud Rules

Create fraud rules once and apply them to transactions from every merchant in your portfolio. Use partner rules as a baseline fraud policy that protects all your merchants, then let individual merchants layer their own rules on top.

A fraud rule is a single condition with an action. The condition describes what to look for on a transaction (amount, country, card brand, IP velocity, and so on); the action decides what happens when that condition is met (accept, deny, or flag the transaction).

---

How Partner Rules Work

• Partner-wide scope. A rule you create as a partner is evaluated on every transaction submitted by every merchant you manage.
• Merchants can layer their own rules on top. If a merchant has their own rules enabled, both your rules and theirs run on their transactions.
• First match wins. Rules are evaluated in order. The first rule whose condition matches decides the outcome — further rules are not checked for that transaction.
• Pre or post. A rule can run either before the charge is sent to the processor (a pre rule) or after the processor's response comes back (a post rule). Pre rules can stop a transaction before any money is attempted; post rules can react to decline codes, AVS results, or CVV results.

---

When to Use Partner Rules vs Merchant Rules

Goal	Where the rule belongs
Enforce a fraud floor across every merchant in your portfolio	Partner rule
Block a pattern you've observed affecting multiple merchants (TOR traffic, carding, etc.)	Partner rule
Roll out default protection to new merchants without per-merchant setup	Partner rule
Let a merchant enforce their own risk policy on their own processors	Merchant rule
A one-off rule that only affects one merchant's specific processor	Merchant rule (or partner)

---

Creating a Rule

Control Panel

1. Log in as a partner user with rule-engine permissions.
2. Go to Fraud Protection → Rules.
3. Click Add Rule.
4. Give the rule a name and description.
5. Choose Pre or Post and add one or more conditions from the rule type catalog.
6. Pick an action (accept, deny, flag, accept_flag_batch, or deny_flag_batch).
7. Save.

TIP

Use descriptive rule names. When a rule triggers on a transaction, the rule name appears on the transaction record and in the triggered-rules webhook.

For your developer

Create a rule with POST /rules-engine/rules. See the API reference below for the full request body.

---

Enabling Rules on a Merchant

By default, merchants can't create or manage their own fraud rules. To allow a merchant to add rules on top of yours, enable Rule Engine Access when you create or update the merchant:

• Control Panel: Toggle Allow Rule Engine Access in the merchant's permissions.
• API: Set allow_rule_engine_access: true in the permissions object when calling Create new Merchant.

A merchant's users also need the manage_rule_engine permission on their own user account before they can create rules.

---

Attaching Rules to Processors

A rule only runs on a transaction when it's attached to the processor handling that transaction. There are two ways to attach a rule:

• From the rule, at creation time. When creating a rule through the Control Panel you can pick which processors it applies to. This is the most common flow.
• From the processor. When creating or editing a processor you can pass a list of rule IDs in the ruleset field. Use this when you want to attach several existing rules to a new processor at once. See Create new Processor.

A rule that isn't attached to any processor still exists but won't run on any transactions.

---

Rule Type Catalog

The gateway provides a fixed set of rule types. Each one checks a different kind of information on the transaction. Pick a type, pick an operator and value, and combine as many conditions as you need.

Each entry below describes what the rule checks, how to configure it, and a concrete example showing when it would trigger.

Amount & geography

amount

Compares the transaction's total amount against a threshold. Amounts are specified in cents — 1000 means $10.00. Works with >, <, or =.

Triggers when: You set operator: ">", value: "10000", action: "deny". A customer checks out for $150.00 — the amount (15000 cents) is greater than 10000, so the rule fires and the transaction is declined before the processor ever sees it.

Common use: cap unusually large transactions that don't match your merchants' normal ticket size, or block micro-transactions used for card testing.

country

Matches on the billing country of the transaction. Values are ISO two-letter country codes. Multiple countries can be listed separated by a pipe (for example, US|CA|GB). Works with = or !=.

Triggers when: You set operator: "!=", value: "US", action: "deny". A customer enters a German billing address at checkout — the country is DE, which is not equal to US, so the rule fires and the transaction is declined.

Common use: restrict merchants to domestic-only customers, or block known high-risk countries.

billing_state

Matches on the billing state of the transaction. Values are two-letter US state codes (CA, TX, NY, etc.). Multiple states can be listed separated by a pipe. Applies to any payment method. Works with = or !=.

Triggers when: You set operator: "=", value: "CA|NY", action: "flag". A customer checks out with a California billing address — the state matches, the rule fires, and the transaction is flagged for manual review.

Common use: flag transactions from states where you've seen elevated chargeback risk, or block states where a merchant isn't licensed to operate.

billing_state_card_only

Identical to billing_state but only applies to card transactions — ACH payments are ignored. Use this when the policy is card-specific.

Triggers when: You set operator: "=", value: "FL", action: "deny". A customer pays with a card using a Florida billing address — the rule fires and the card charge is declined. The same customer's ACH payment from the same Florida address would go through unaffected.

ip_country

Matches on the country inferred from the customer's IP address, rather than the billing address. Values are ISO country codes. Works with = or !=.

Triggers when: You set operator: "=", value: "RU|CN", action: "deny". A customer connects from a Russian IP — regardless of what they type as their billing address — the rule fires and the transaction is declined.

Common use: block traffic originating from countries you don't serve, even when the billing address looks legitimate.

IP & network

ip_address

Matches on the customer's IP address, exactly or against a list. Multiple IPs can be listed separated by a pipe. Works with = or !=.

Triggers when: You set operator: "=", value: "203.0.113.50|198.51.100.4", action: "deny". A customer submits a payment from 203.0.113.50 — the rule fires and the transaction is declined.

Common use: permanently block specific IPs you've identified as fraudulent.

ip_proxy

Matches on whether the customer's IP is classified as an anonymizing proxy. Valid values: TOR (Tor network), VPN (commercial VPN service), DCH (data center hosting), WEB (web-based anonymizer), PUB (public open proxy). Multiple values can be listed separated by a pipe. Works with = or !=.

Triggers when: You set operator: "=", value: "TOR|VPN", action: "deny". A customer connects through a commercial VPN — their IP matches the VPN category, so the rule fires and the transaction is declined.

Common use: block anonymous traffic that can't be tied back to a real location. The highest-fraud categories are typically Tor exit nodes, commercial VPNs, and data-center IPs.

ip_anomaly

Compares an anomaly score for the customer's IP against a threshold. The score runs from 0 to 100 and reflects how unusual the IP's recent behavior looks compared to normal traffic. Works with >, <, or =.

Triggers when: You set operator: ">", value: "75", action: "flag". A customer's IP has been involved in unusual patterns recently, producing a score of 82 — greater than 75, so the rule fires and the transaction is flagged for review.

Common use: catch suspicious IPs that don't fall neatly into a proxy category.

Velocity — merchant-wide

These rules count how many transactions the merchant has processed in a rolling time window and compare the count against a threshold. They catch volume spikes that may indicate an attack or a misconfigured integration.

velocity_check_1hour

Count of this merchant's transactions in the last hour. Works with >, <, or =.

Triggers when: You set operator: ">", value: "50", action: "flag". The merchant has already processed 60 transactions in the past hour and the 61st comes in — the count exceeds 50, so the rule fires and the 61st transaction is flagged.

Common use: detect sudden volume spikes that don't match normal traffic.

velocity_check_24hours

Same as above, over a 24-hour rolling window.

Triggers when: You set operator: ">", value: "500", action: "deny". A small merchant who normally processes under 100 transactions a day suddenly sees 501 attempts — the 501st transaction is declined.

velocity_check_72hours

Same as above, over a 72-hour rolling window. Use this when normal merchant volume fluctuates by day of week and a 24-hour view is too noisy.

Velocity — per IP

These rules count how many transactions have been submitted from the same IP address. Effective against carding attacks where a single machine runs through many stolen card numbers.

ip_velocity_check_1hour

Count of transactions from the same IP in the last hour. Works with >, <, or =.

Triggers when: You set operator: ">", value: "10", action: "deny". A single IP address has submitted 11 payments in the past hour — the 11th triggers the rule and is declined.

Common use: block carding attacks where a script runs through many stolen card numbers from a single machine.

ip_velocity_check_24hours

Same count, 24-hour rolling window.

ip_velocity_check_72hours

Same count, 72-hour rolling window.

Velocity — per customer account

These rules count how many transactions a stored customer (in the customer vault) has submitted in a time window. Useful for catching compromised customer accounts that are being used to test other stolen cards.

account_velocity_check_24hours

Count of transactions against the same stored customer in the past 24 hours. Works with >, <, or =.

Triggers when: You set operator: ">", value: "5", action: "flag". A stored customer has already made 5 transactions in the past 24 hours and submits a 6th — the rule fires and the 6th is flagged.

Common use: detect subscription abuse or compromised customer accounts.

account_velocity_check_72hours

Same count, 72-hour window.

account_velocity_check_30days

Same count, 30-day window. Use this for long-term pattern detection.

Velocity — per card / BIN

bin_velocity_check

Counts how many different cards sharing the same BIN (the first several digits of the card number, which identifies the issuing bank) have been submitted to the merchant within a time window. Takes two dynamic parameters: a time threshold in minutes and a count threshold.

Triggers when: You set time_threshold: "10", count: "10", action: "deny". An attacker runs 10 stolen cards from the same BIN — for example, all Visa cards from the same issuer — through the merchant within 10 minutes. The 10th one triggers the rule and is declined.

Common use: detect carding attacks where an attacker has a batch of cards from the same breach.

weekly_velocity_per_card

Counts how many times the exact same card has been used at the merchant in the past week. Works with >, <, or =.

Triggers when: You set operator: ">", value: "20", action: "flag". The same card has been used 21 times at the merchant in 7 days — the rule fires and the 21st transaction is flagged.

Common use: detect compromised cards being hammered at one merchant.

Card attributes

card_type

Matches on the card's funding type. Valid values: debit, credit, prepaid. Works with = or !=.

Triggers when: You set operator: "=", value: "prepaid", action: "deny". A customer checks out with a prepaid debit card — the type matches, the rule fires, and the transaction is declined.

Common use: block prepaid cards (commonly used by fraudsters) on high-risk merchants, or enforce debit-only on merchants with specific fee structures.

card_brand

Matches on the card's network brand. Valid values: VISA, MASTERCARD, DISCOVER, AMEX, and others depending on processor support. Multiple brands can be listed separated by a pipe. Works with = or !=.

Triggers when: You set operator: "!=", value: "VISA|MASTERCARD", action: "deny". A customer pays with American Express — the brand isn't in the allowed list, so the rule fires and the transaction is declined.

Common use: restrict accepted brands for merchants whose processors only support certain networks.

bin_range

Matches on whether the card's BIN falls within a numeric range you specify. Ranges are written as 411111-411199. Multiple ranges can be listed separated by a pipe.

Triggers when: You set value: "411111-411199", action: "deny". A customer pays with a card whose BIN is 411150 — the BIN falls within the configured range, the rule fires, and the transaction is declined.

Common use: block or flag cards from specific issuers with elevated chargeback rates.

bin_generic_level

Matches on the BIN's commercial classification. Valid values: CONSUMER, COMMERCIAL, CORPORATE. Works with = or !=.

Triggers when: You set operator: "=", value: "CORPORATE", action: "flag". A customer pays with a corporate credit card — the rule fires and the transaction is flagged for manual verification.

Common use: flag commercial or corporate cards on B2C merchants where they'd be unusual.

Card lists

These rules check whether a card or BIN is on a per-merchant list that's maintained over time — either by manual entry or automatically by other rules.

card_ban

Checks whether the card is on the merchant's card ban list. The list is built up by manual additions or by rules like post_category_1_ban that automatically add cards after specific patterns.

Triggers when: A customer pays with a card that was added to the ban list last week after a series of fraud attempts. The rule fires and the transaction is declined.

Common use: permanently block cards you've identified as fraudulent, even when other rules would let them through.

bin_watch_list

Checks whether the card's BIN is on the merchant's BIN watch list. Like the card ban list, maintained per merchant.

Triggers when: A merchant has added BIN 453201 to their watch list because cards from that BIN are frequently chargebacked. A customer pays with a 453201-prefixed card — the rule fires and the transaction is flagged.

Common use: monitor (rather than block) cards from BINs that have shown elevated risk without committing to a full decline.

Contact & identity

email_address

Matches on the exact billing email address. Multiple emails can be listed separated by a pipe. Works with = or !=.

Triggers when: You set operator: "=", value: "fraud@example.com|bad@testmail.net", action: "deny". A customer enters one of those email addresses at checkout — the rule fires and the transaction is declined.

Common use: block specific email addresses you've identified as repeat offenders.

email_domain

Matches on the domain portion of the billing email. Multiple domains can be listed. Works with = or !=.

Triggers when: You set operator: "=", value: "tempmail.com|guerrillamail.com", action: "flag". A customer uses an email on one of those throwaway domains — the rule fires and the transaction is flagged.

Common use: catch transactions from disposable email providers, which are a common fraud signal.

email_anomaly

Compares an anomaly score for the email against a threshold. The score summarizes how unusual the email looks compared to legitimate patterns. Works with >, <, or =.

Triggers when: You set operator: ">", value: "70", action: "flag". A customer enters an email whose anomaly score is 85 — greater than 70, so the rule fires and the transaction is flagged.

Common use: catch randomly-generated email addresses without maintaining a hard-coded list of bad domains.

address_match

Compares the billing and shipping addresses on the transaction. Works with = (addresses match) or != (addresses don't match).

Triggers when: You set operator: "!=", action: "flag". A customer's billing address is in Texas but the shipping address is in Florida — the rule fires and the transaction is flagged.

Common use: physical-goods merchants often flag address-mismatching transactions for manual review, since shipping to an address different from billing is a classic stolen-card pattern.

Processor response

These rules can only be used as post rules — they run after the processor returns a response, because they depend on data that only exists in that response.

avs_response

Matches on the AVS response code returned by the issuing bank. Valid values: Y, A, Z, N, U, R, S, G, B, C, D, M. See Common AVS Codes for what each one means. Multiple codes can be listed separated by a pipe. Works with = or !=.

Triggers when: You set operator: "=", value: "N", action: "flag". The issuer returns AVS code N (no match on street address or ZIP) — the rule fires and the transaction is flagged for review.

Common use: flag transactions where neither the street address nor the ZIP code matches what the bank has on file.

cvv_response

Matches on the CVV response code returned by the issuing bank. Valid values: M (match), N (no match), P (not processed), S (should be on card but not provided), U (not supported). Multiple codes can be listed separated by a pipe. Works with = or !=.

Triggers when: You set operator: "=", value: "N", action: "deny". The issuer confirms the CVV the customer entered doesn't match — the rule fires and the transaction is declined.

Common use: hard-decline any transaction where the CVV explicitly fails verification.

Decline categories

These post rules track how many times a card has been declined for a specific category of reason. They're used to build escalating responses — for example, banning a card after repeated hard declines.

category_card_decline_cat2

Triggered based on how many Category 2 declines (issuer unavailable, temporary network issues) a card has received at the merchant.

Triggers when: You set value: "5", action: "deny". A card has already received 5 Cat-2 declines at the merchant; the 5th declined transaction triggers the rule.

Common use: stop retrying cards that keep failing due to issuer-side problems — retries don't help and generate unnecessary fees.

category_card_decline_cat3

Same as category_card_decline_cat2, for Category 3 declines (no response from the issuer).

category_card_decline_cat4

Same as above, for Category 4 declines (expired or lost/stolen card). Repeated Cat-4 declines are a strong signal of stolen card testing.

post_category_card_decline

A post-transaction counter that tracks declines across all categories and fires when a card has accumulated enough declines to warrant action.

Triggers when: You set value: "3", action: "deny". A card has been declined 3 times for mixed reasons; the 3rd decline triggers the rule.

post_category_1_ban

Automatically adds the card to the merchant's ban list after a threshold of Category 1 declines (hard declines — stolen card, fraud flag, do not honor). Use this together with the card_ban rule to permanently block cards that are clearly bad.

Triggers when: You set value: "2". After 2 Cat-1 declines on a card, the rule adds the card to the merchant's ban list. Any future transaction with that card then hits the card_ban rule and is declined.

3D Secure

require_3dsecure

Forces matching transactions through 3D Secure authentication before they can be charged. Used in pre rules to add extra protection on high-risk patterns.

Triggers when: Combined with an amount condition and value: "50000", the rule requires 3D Secure on any purchase over $500. A customer tries to check out for $600 — the rule fires and the customer is prompted to authenticate with their bank before the charge goes through.

Common use: shift the fraud liability to the issuer on high-value or unusual transactions.

failed_3dsecure

Counts how many times a card has failed 3D Secure authentication and takes action when a threshold is reached.

Triggers when: You set value: "3", action: "deny". A card has already failed 3D Secure twice; the third failure triggers the rule and the transaction is declined.

Common use: block cards where the real cardholder clearly isn't the one at the keyboard.

post_3ds_remove_ban

Automatically removes a card from the ban list if it successfully passes 3D Secure authentication. Pair this with ban-based rules when you want to give legitimate customers a way to recover from a false positive.

Triggers when: A card that was added to the ban list yesterday passes 3D Secure today. The rule fires on the successful 3DS result and removes the card from the ban list. Future transactions from that card can proceed normally.

Enforcement

These rules don't block based on data — they enforce that certain data must be present or certain setup steps must happen.

require_cvv_on_card_payment

Requires the CVV security code to be submitted on every card transaction. Set value: "true" to enable the check.

Triggers when: A customer tries to check out without entering a CVV code. The rule fires and the transaction is declined.

Common use: enforce CVV on all card transactions as a baseline anti-fraud policy.

require_vault_create_on_card_payment

Requires card transactions to create a customer vault entry (a saved payment method) rather than running as a one-off charge. Set value: "true" to enable.

Triggers when: A transaction is submitted as a one-off card charge without vault creation. The rule fires and the transaction is declined until it's resubmitted with vault creation enabled.

Common use: enforce that all card payments are tokenized for future use or recurring billing.

Advanced — anomaly & scoring

These rules use behavioral patterns or scoring models. They require enabled_advanced: true on the rule's settings.

fraud_score

Compares the gateway's 0–100 fraud risk score for the transaction against a threshold. The score is calculated from dozens of signals — device fingerprinting, session behavior, velocity patterns, card history, and more — and is available on every transaction. Works with >, <, or =.

Triggers when: You set operator: ">", value: "70", action: "flag". A transaction comes in with a score of 82 — greater than 70, so the rule fires and the transaction is flagged.

Common use: set a high threshold for hard declines (> 90), a medium threshold for review (> 60), and let anything below pass through.

frequency_transaction

Detects anomalies in how quickly transactions are being submitted compared to the merchant's historical norm.

Triggers when: A merchant normally submits a transaction every few minutes but suddenly starts submitting dozens per minute. The rule detects the deviation and flags (or denies) the transactions in the spike.

Common use: catch sudden bursts that don't match normal traffic even if they fall under the raw velocity thresholds.

frequency_device

Detects anomalies in how often a single device fingerprint appears. A legitimate shopper's device shows up occasionally; a fraudster's device may submit many transactions in quick succession.

Triggers when: A device fingerprint that has never been seen before submits 20 transactions in 5 minutes. The rule detects the anomaly and flags the transactions.

frequency_payment_method

Detects anomalies in how often the same payment method (card or ACH) is being reused across different billing details.

Triggers when: A single card has been attempted with many different billing addresses and email addresses in a short time. The rule detects the pattern and flags or denies.

Common use: catch a stolen card being tested with fake identity data.

decline_ratio_anomaly

Tracks the approval-to-decline ratio for the merchant. When the ratio shifts sharply — a lot more declines than normal — something suspicious is usually happening.

Triggers when: A merchant's normal decline rate is 3%. Over the past hour, the rate has jumped to 40%. The rule fires on transactions submitted during that spike.

Common use: catch carding attacks where many cards are being tried against the merchant and most of them are failing.

closed_contact

Scores whether the issuing bank's listed contact information looks reliable or stale. A "closed contact" score signals that the bank may not respond to chargeback retrievals, increasing the merchant's risk. Works with >, <, or =.

Triggers when: You set operator: ">", value: "60", action: "flag". A card comes from an issuer with a high closed-contact score — the transaction is flagged for manual review.

Advanced — external services & composites

guardian_action

Delegates the decision to the Guardian fraud service — an external fraud-scoring engine that can reach its own accept/deny conclusion based on its own models. Setup requires coordinating with Guardian separately.

Triggers when: Guardian analyzes the transaction and returns a "high risk" verdict. The rule fires and applies its configured action (typically deny).

Common use: merchants who have an existing Guardian subscription and want to gate transactions on its output.

bot_detected

Blocks transactions where device fingerprinting has flagged the session as a bot rather than a real user. The rule takes no value — it simply fires whenever the bot flag is set on the incoming transaction.

Triggers when: A headless browser or scraping tool submits a checkout. The fingerprint service identifies it as non-human and sets the bot flag on the transaction. The rule fires and the transaction is denied.

Common use: block automated card-testing traffic regardless of what the cards look like.

group

A composite rule that combines multiple conditions into one. The group fires only if all of its child conditions match on the same transaction. Nested groups are not allowed.

Triggers when: A group contains three conditions — amount > 10000, country != US, and ip_proxy = TOR|VPN. A customer submits a $150 international transaction from a commercial VPN. All three conditions match on the same transaction, so the group fires and applies its action (for example, deny). If the same customer were shopping for $50 (below the $100 amount threshold), the group would not fire, even though the other two conditions still match.

Common use: build multi-factor rules where any single condition on its own would cause too many false positives. Groups let you require several risk signals at once before taking action.

---

Actions

When a rule's condition matches, the rule's action is applied.

Action	Effect	Stops further rules?
accept	Allow the transaction through	Yes
deny	Decline the transaction	Yes
flag	Allow the transaction but mark it for review	Yes
accept_flag_batch	Allow the transaction and batch-flag suspicious patterns for later analysis	Yes
deny_flag_batch	Decline the transaction and batch-flag it for analysis	Yes

---

Rule Settings

Each rule has a settings block that controls how it behaves:

Setting	Purpose
enabled	Turn the rule on or off without deleting it
enabled_advanced	Allow the rule to use the advanced rule types (anomaly, scoring, external services)
enabled_community_rules	Enable the gateway's baked-in community fraud rules as a starting floor
default_community_rule	Default action when a community rule matches (accept, deny, or flag)
default_action_for_flagged_transactions	Default action when a transaction is flagged by any rule (accept, deny, or flag)
whitelisted_ips	A list of IPs (including CIDR ranges) that should bypass all rule evaluation

Community rules

Community rules are a curated set of rules the gateway maintains for well-known fraud patterns (velocity attacks, anonymous proxies, suspicious BIN patterns). Turning them on gives your merchants immediate baseline protection with no per-rule configuration.

---

Examples

Each example below describes a real-world rule you can set up from the Control Panel. The tables show what to configure and when the rule fires.

Portfolio-wide proxy block

Block any transaction coming from an anonymous proxy — Tor, a commercial VPN, or a data center IP — across every merchant you manage, without requiring any per-merchant setup.

Setting	Value
When it runs	Before the charge is attempted
Rule type	ip_proxy
Condition	IP category equals TOR, VPN, or DCH
Action	Deny

Triggers when: a customer connects through a commercial VPN and tries to check out. The rule fires before the payment reaches the processor and the charge is declined.

AVS mismatch review

Flag transactions where the billing address doesn't match what the issuer has on file, so your team can review them before they get charged back. Merchants can layer a stricter rule on top — for example, a hard decline on the same AVS code — that runs alongside yours.

Setting	Value
When it runs	After the processor responds
Rule type	avs_response
Condition	AVS code equals N (no match) or C (not verified)
Action	Flag

Triggers when: a customer submits a payment with a billing address that doesn't match the card on file. The processor approves the charge, the issuer returns AVS code N, and the rule flags the transaction for manual review.

Community rules baseline

Give every merchant in your portfolio a basic fraud floor the moment they're onboarded, without configuring any individual rules. This turns on the gateway's curated community rules (velocity attacks, anonymous proxies, suspicious BIN patterns) with a strict "deny on match" default.

Setting	Value
Community rules	Enabled
Default action when a community rule matches	Deny
Default action for flagged transactions	Deny
Your own conditions	None — community rules do the work

Triggers when: any transaction that matches one of the community rules is automatically denied. The community rule set is maintained by the gateway and updated as new fraud patterns emerge.

Require 3D Secure on large purchases

Shift fraud liability to the issuer on high-value transactions. Any charge over $500 has to go through 3D Secure, where the customer authenticates with their bank before the charge is allowed to go through.

Setting	Value
When it runs	Before the charge is attempted
Rule type	require_3dsecure combined with amount
Condition	Transaction amount greater than 50000 (= $500.00)
Action	Require 3D Secure

Triggers when: a customer tries to check out for $650. The rule fires and the customer is prompted to authenticate with their bank. If they pass, the charge proceeds with the issuer taking on the fraud liability. If they fail, the charge never reaches the processor.

Domestic-only transactions

Restrict a merchant's acceptance to US customers. Any transaction with a non-US billing address is declined before it reaches the processor.

Setting	Value
When it runs	Before the charge is attempted
Rule type	country
Condition	Billing country not equal to US
Action	Deny

Triggers when: a customer enters a Canadian billing address. The country is CA, which is not equal to US, so the rule fires and the transaction is declined.

Carding attack protection

Detect and block carding attacks where an attacker runs many stolen card numbers from a single machine in a short period. Stops the attack before it racks up processor fees and chargebacks.

Setting	Value
When it runs	Before the charge is attempted
Rule type	ip_velocity_check_1hour
Condition	More than 15 transactions from the same IP in the past hour
Action	Deny

Triggers when: an attacker scripts their way through 16 card numbers from the same IP in under an hour. The 16th transaction triggers the rule and is declined. Any further attempts from that IP within the same hour are also denied.

Flag disposable email addresses

Catch transactions submitted with throwaway email addresses. Disposable email providers are a common fraud signal, but they're used by legitimate customers too — so flagging rather than denying gives you a chance to review each one.

Setting	Value
When it runs	Before the charge is attempted
Rule type	email_domain
Condition	Email domain equals tempmail.com, guerrillamail.com, or similar
Action	Flag

Triggers when: a customer enters an email on a known throwaway domain. The rule fires and the transaction is flagged for review before the charge is finalized.

Block prepaid cards on high-risk merchants

Prepaid cards are commonly used by fraudsters because they're anonymous and disposable. For high-risk merchants (high ticket size, digital goods, subscription services), blocking them outright reduces chargeback exposure.

Setting	Value
When it runs	Before the charge is attempted
Rule type	card_type
Condition	Card type equals prepaid
Action	Deny

Triggers when: a customer pays with a prepaid Visa card. The card's funding type is prepaid, so the rule fires and the transaction is declined.

Multi-factor group rule

Combine several risk signals into a single decision. The rule only fires when every condition matches on the same transaction — so a single signal on its own won't cause false positives, but the combination of all three is a strong indicator of fraud.

Setting	Value
When it runs	Before the charge is attempted
Rule type	group, containing three nested conditions
Condition 1	Transaction amount greater than 10000 (= $100.00)
Condition 2	Billing country not equal to US
Condition 3	IP category equals TOR or VPN
Action	Deny

Triggers when: a customer submits a $150 international transaction from a commercial VPN. All three conditions match on the same transaction, so the group fires and the charge is declined. If the same customer were buying a $50 item instead, the group would not fire even though the other two signals are still there — the amount threshold hasn't been crossed.

---

API Reference

All endpoints require a partner user with the manage_rule_engine permission.

List rules

Request Method: GET

URL Endpoint: /api/rules-engine/rules

Returns every rule that belongs to your partner account.

Get a rule

Request Method: GET

URL Endpoint: /api/rules-engine/rules/{rule_id}

Search rules

Request Method: POST

URL Endpoint: /api/rules-engine/rules/search

Body: { "name": "partial name to match" }

Create a rule

Request Method: POST

URL Endpoint: /api/rules-engine/rules

Name	Type	Description	Required
name	string	Unique rule name	true
description	string	Human-readable description	false
settings	object	See Rule Settings	true
pre	array	Conditions that run before the charge is attempted	true
post	array	Conditions that run after the processor responds	true
processor_ids	array	Processor IDs to attach this rule to. Optional for partner rules — leave empty to create the rule without attaching.	false

Each entry in pre or post is an object with the following fields:

Name	Type	Description
type	string	Rule type name from the catalog
operator	string	>, <, =, or != — depending on the rule type
action	string	accept, deny, flag, accept_flag_batch, or deny_flag_batch
value	string	Value to compare against (format depends on rule type)
notification	string	"true" to send a notification webhook when this rule triggers
advanced	bool	Set to true for rules in the Advanced categories

Update a rule

Request Method: POST

URL Endpoint: /api/rules-engine/rules/{rule_id}

Same request body as Create.

Delete a rule

Request Method: DELETE

URL Endpoint: /api/rules-engine/rules/{rule_id}