Skip to main content
A fraudulent payment costs you the money, a $15 dispute fee, and a worse dispute rate. Whop screens checkouts with its own fraud controls. Payment rules add your own layer on top: conditions you write, and an action Whop takes when a checkout matches them all. Rules run after Whop’s controls and never loosen them. A payment Whop blocks stays blocked.

Four ways a rule can act

A rule can read risk_score, amount_in_usd, card_country, card_bin, customer_email, and ip_address. card_bin is the Bank Identification Number of the card used to make the payment: the first six digits of the card number. List fields returns the operators and values each one accepts. Where you’re unsure, challenge rather than block. A block also turns away real buyers who match, while a challenge lets them prove they’re the cardholder.
Run these examples in a trusted server environment with WHOP_API_KEY set. Reuse the imports and client setup from the first example for your language.

Block the obvious fraud

Start with the pattern you see most in your disputes. This rule blocks a payment Whop scores 85 or higher on a card issued outside the US.
Always pass account_id. Without it the rule lands on whichever account your credential defaults to, which is easy to get wrong for a platform that manages several. Rules are published to checkout every minute, so a new or changed rule starts applying within a couple of minutes.
Required permission: payment:manage to write rules, payment:basic:read to read them. Add permissions from the Permissions guide.

Challenge large orders

A large order from a stolen card is the chargeback you least want. A large order from a real customer is the sale you least want to lose. A 3D Secure challenge separates the two, and the payment records three_ds_verified: true when the buyer passes. enforce_3ds is skipped, but still recorded on the payment, when the checkout can’t carry a challenge. That covers off-session payments such as renewals, variants that set their own 3D Secure level, non-card payments, cards the processor can’t challenge, and American Express.

Review a payment before charging it

A review rule authorizes an eligible card payment without capturing it. The buyer completes checkout and gets membership access at authorization. Use it for orders you fulfil by hand, or for a pattern that’s risky but not certainly fraud. Whop captures automatically 48 hours later unless you act first:
  • Capture to collect the money. The payment becomes paid and Whop sends payment.succeeded, your signal to fulfil the order.
  • Void to release the hold. Whop revokes access, returns reserved stock, and sends payment.canceled.
Whop sends payment.authorized when the hold starts, and for API-requested authorizations too. A held payment reads status: "authorized" with substatus: "requires_capture". Retrieve the payment status for auto_capture_at. This rule holds card payments of at least $250 whose card was issued outside the US.
Once you have reviewed the order, capture it by payment ID:
Or void it:

Review limitations

  • Only on-session cards can be held. Apple Pay, Google Pay, bank, balance, and off-session payments such as renewals skip review. The match is still recorded in payment_rule_matches.
  • Payments created with capture: false keep their own schedule. A review rule never overrides it.
  • Capture is all or nothing. Refund afterwards to return part of it.
  • Buyers have the product before you decide. Tell them if you void.

Keep trusted buyers moving

An allow rule exempts buyers you trust from your block, review, and challenge rules.

Tighten a rule

What a rule does is fixed once created, so the payments it decided keep naming the rule that decided them. To change its action or conditions, replace it: the old rule is deleted and a successor with a new ID inherits its name, metadata, and active state. Here the block threshold is raised from 85 to 90 after catching too many real buyers.
Deactivate a rule to pause it and activate it to resume. Delete it to retire it. It stays readable with status: "deleted".

Measure the effect

Each payment lists the rules that matched it in payment_rule_matches, with the name the rule had at the time.
Disputes arriving on payments with no matches mean a rule is too narrow. A rule matching far more payments than you were losing is too broad. For totals over time, the Stats API metrics payment_rule_matches and payment_rule_matched_volume break down by payment_rule_ids or action.

Next steps

Payment Rules reference

Every endpoint, parameter, and response field.

Refunds and disputes

Respond to the chargebacks that still get through.