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, customer_email, and ip_address. 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.

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, plans 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 requests authorization for the full amount of an eligible card payment, without capturing it. Whop grants membership access after successful authorization. Checkout Elements supports completion while the payment is held. Legacy embeds have a completion limitation described below. Eligible means an on-session card payment through Whop Payments, including saved cards. Apple Pay, Google Pay, bank payments, balance payments, and other unsupported methods skip review. They continue through normal payment processing. Other applicable rules and fraud controls still apply. Matching skipped rules are recorded on the payment. Automatic capture is scheduled for 24 hours after authorization. Before then, you can:
  • Capture the payment to collect the authorized amount. Once capture succeeds, the payment becomes paid and Whop sends payment.succeeded.
  • Void the payment to release the authorization before capture. A successful void revokes membership access, schedules reserved stock to be returned, and sends payment.canceled.
  • Leave it held. Whop attempts automatic capture once auto_capture_at is due.
Capture can remain in progress or fail. Confirm collection through the payment status or payment.succeeded before fulfilling an order by hand. Whop sends payment.authorized after successful authorization, which you can use to start a review workflow. This event also covers API-requested authorizations, so it doesn’t identify review-rule holds on its own. While held, the payment has status: "authorized" and substatus: "requires_capture". Retrieve its status to read auto_capture_at. This rule matches eligible card payments of at least $250 whose card was issued outside the US. Higher-priority account rules and Whop’s fraud controls still apply. If your installed SDK doesn’t accept the review action, use the cURL example.
Once you have looked at the order, capture or void it by payment ID.

Where a review rule helps

  • Orders you fulfil by hand. Review physical goods or bookings before delivery. Confirm capture succeeded before you fulfil the order.
  • A pattern that’s risky but not certainly fraud. Review delays capture while you assess the order, with membership access granted during the hold.
  • A new market or campaign. Apply a review rule while you assess payment patterns, then adjust or deactivate it as you learn.

Review limitations

  • Only eligible cards can be held. Apple Pay and Google Pay, including saved wallet cards, and every other unsupported method skip review. A matching rule still appears in payment_rule_matches, and another matching rule can apply.
  • Off-session payments skip review. This includes automatic subscription renewals. An on-session renewal recovery can still match a review rule.
  • Payments already created with capture: false keep their capture settings. A review rule doesn’t replace the API caller’s capture schedule.
  • One account-rule action wins. review takes precedence over an account’s enforce_3ds rule, while allow and block take precedence over review. Other 3DS requirements still apply.
  • The automatic capture delay is fixed at 24 hours. This schedules a capture attempt. It doesn’t guarantee completion within 24 hours. For another schedule, create each eligible card payment through POST /payments with capture: false and auto_capture_after_minutes. The delay must be between 5 and 5,760 minutes. Other fraud controls still apply.
  • Capture is all or nothing. Capture collects the full authorized amount. Use the refund API after capture to return part of it.
  • Tell the buyer if you void their order. A successful void releases the authorization before capture and revokes membership access.
  • Legacy embedded checkout has a completion limitation. Its completion flow can remain on Processing until capture, even though authorization can already grant membership access. Capture may complete after the scheduled time or fail. Rules are account-wide and still apply to legacy embeds. Migrate those embeds if buyers must see checkout complete while the payment is held.
  • Membership access starts at authorization. A review hold grants access before you decide whether to capture. Voiding revokes that access, so consider whether buyers could consume the product before your decision.

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.