To protect your business from chargebacks and fraudulent activity, PayPack utilizes Stripe Radar for Teams. While Stripe’s machine learning provides a robust baseline defense, Radar for Teams allows you to write custom "if/then" logic tailored to your specific business model.

Below are advanced rule examples that can be implemented for Stripe merchants to help minimize risk while ensuring legitimate transactions flow seamlessly into NetSuite.

Default Block Lists

This is your first line of defense. Stripe maintains global lists of known fraudulent actors based on data from millions of businesses.

• The Rule: Block if payment matches one or more values in default Stripe block lists

• How to use it: This rule is typically enabled by default. It automatically blocks transactions from cards, IP addresses, or emails that have been verified as fraudulent elsewhere on the Stripe network. It is a high-confidence rule that requires no manual intervention.

Block Credit Cards

While Stripe’s standard card payment element doesn't offer a toggle to filter by card type, you can manage this through Stripe Radar. If your business model requires restricting transactions to debit cards only, you can implement a custom fraud rule to intercept and decline credit card attempts.

To implement this restriction:

1. Navigate to the Radar section of your Stripe Dashboard.
2. Under Rules, locate the "When should a payment be blocked?" section.
3. Add the following custom rule:
   • Block if :card_funding: = 'credit'
4. Review and activate the rule to begin blocking non-debit transactions in real-time.

Velocity Rules

Fraudsters often perform "card testing" by attempting multiple small charges in a short window. Alternatively, if your business model doesn't typically see repeat customers in the same week, high frequency can be a red flag.

• The Rule: Review if :authorized_charges_per_email_weekly: > 2

• How to use it: By setting this rule to Review, Stripe will allow the transaction to succeed but will place it in a pending state in your dashboard. This allows your team to verify if the customer is genuinely making multiple purchases or if a bot is cycling through stolen credentials.

Behavioral Analysis

Some of the most dangerous fraud comes from accounts that appear legitimate at first glance. This rule looks at the historical behavior of a card across the entire Stripe network.

• The Rule: Review if :total_usd_amount_successful_on_card_all_time: > 2000 and :blocked_charges_per_card_number_all_time: > 0

• How to use it: This flags "high-spend" cards that have also been blocked previously. If a card has successfully spent $2,000 but has a history of being blocked on other sites, it could indicate a stolen high-limit card. We recommend reviewing these immediately before shipping high-value goods.

Geographic & Postal Code Targeting

Certain regions or specific postal codes (often associated with freight forwarders or "re-shipping" centers) are statistically linked to higher fraud rates for certain industries.

• The Rule: Review if :billing_address_postal_code: = '33182'

• How to use it: If you notice a pattern of chargebacks originating from a specific zip code, you can set a rule to manually review all incoming orders from that area. This allows you to request additional ID verification or phone confirmation before the transaction is finalized.

Best Practices for Implementation

1. Test Before You Apply: Always use the "Test rule" feature in Stripe Radar before setting a rule to "Block." This allows you to see how many legitimate customers would have been affected over the last 180 days.

2. Start with Review, then Block: If you are unsure about a rule's impact, set the action to Review first. Once you are confident the rule is only catching fraudsters, you can upgrade it to Block.

3. Monitor Rule Performance: Regularly check the "Performance" section of each rule (as seen in the images above) to ensure that your blocked volume isn't including "Successful" payments you actually wanted to keep.