Pre-Authorization Screening · The Kombatix Network
Catch friendly fraudsters before you authorize.
Kombatix PreAuth checks every incoming transaction against the Kombatix Network — our growing database of identities confirmed as friendly fraud by other merchants. If someone who's filed a false dispute with another Kombatix customer tries to pay you, you know before the charge goes through.
Why PreAuth Matters
Friendly fraudsters rarely stop at one merchant.
Someone who successfully got a refund by disputing a legitimate purchase will try it again — with the same email, same card patterns, similar behavior. The Kombatix Network makes that pattern visible before the next merchant gets burned.
The Network Is the Product
Every Defense score that lands in the friendly-fraud band populates the Kombatix Network. Every PreAuth customer screens against that network.
Defense scoring runs through both the Defense API and the Web Portal — every score of 60 or higher (the "pay for actionable results" threshold) flows back into the shared network. The more merchants scoring, the faster friendly fraudsters are identified across the ecosystem.
How PreAuth Works
Four steps. Milliseconds. Your decision.
| Step | What Happens |
|---|---|
| 1. Incoming Transaction | At checkout, subscription renewal, or any authorization event, you call the PreAuth endpoint with the customer's identity (name, email, phone, address, optional card token). |
| 2. Network Check | Kombatix checks the submitted identity against the Network — identities confirmed as friendly fraud by other merchants. Milliseconds, no external latency added to your flow. |
| 3. Hit or No-Hit Response | If the identity is in the network, you get a hit response with severity and optional match detail. If not, a clean no-hit. Your downstream logic decides what to do with that signal. |
| 4. Your Decision | You choose how to act — decline, step-up auth, hold for review, flag for support — based on your risk tolerance. Kombatix provides the signal; the decision stays with you. |
Where It Fits in Your Stack
Upstream of your existing fraud tools. Complementary, not a replacement.
PreAuth sits upstream of your existing fraud tools. It is not a replacement for Kount, Signifyd, Stripe Radar, or Sift — those tools are excellent at catching strangers using stolen cards. PreAuth catches the opposite problem: authorized cardholders who have a history of disputing their own legitimate purchases. Different threat model, different screening layer, complementary stack.
PreAuth Pricing
Three plans. Pay-per-check overage. No long-term contract.
Each plan includes a monthly usage credit. No-hit checks are a fraction of a cent; hits are billed at your tier's hit rate. One-time $250 implementation fee applies at onboarding for all tiers.
PreAuth Starter
Starts at
$49/month
Up to ~25K transactions/month
- No-hit: $0.005 each
- Hits: $0.15 each
- $49 monthly credit toward usage
- API access live as soon as you subscribe
PreAuth Growth
Starts at
$149/month
25K–100K transactions/month
- No-hit: $0.005 each
- Hits: $0.10 each
- $149 monthly credit
- Priority support
- API access live as soon as you subscribe
PreAuth Enterprise
Starts at
$499/month
100K+ transactions/month
- No-hit: $0.005 each
- Hits: $0.05 each
- $499 monthly credit
- Dedicated support
- Custom integrations
One-time $250 implementation fee applies to all PreAuth plans at onboarding.
Who PreAuth Is For
Segment fit guide.
| Segment | Fit |
|---|---|
| Subscription / SaaS with free or low-cost trials | Strong fit — trial-to-paid conversion is the highest-risk moment for friendly fraud. |
| Digital goods / services (downloadable, streaming, content) | Strong fit — no physical delivery means no shipping evidence, making friendly fraud easier to claim. |
| High-volume e-commerce with repeat customers | Strong fit — catches serial refund-abuse patterns across merchants. |
| Low-volume / high-ticket e-commerce | Check fit — volume-based pricing may not be the best match; talk to sales about Defense-primary pricing. |
| Marketplaces | Case-by-case — depends on which side of the transaction you're screening. |