What is pre-transaction fraud detection?

Pre-transaction fraud detection is the practice of evaluating risk signals — email validity, IP reputation, geolocation, device data — before a payment is processed. The goal is to identify and block fraudulent transactions before they result in chargebacks or lost revenue.

How is pre-transaction different from post-transaction fraud detection?

Pre-transaction detection blocks fraud before money changes hands, preventing chargebacks entirely. Post-transaction detection identifies fraud after payment, requiring refunds, disputes, and evidence gathering. Pre-transaction is cheaper and more effective because it avoids the chargeback fee and operational overhead.

What signals should I check before processing a payment?

The most effective pre-transaction signals are: email validity and disposable status, IP geolocation vs billing address match, VPN/proxy/Tor detection, domain age of the email provider, and a composite risk score that weights all signals together.

Will pre-transaction checks add latency to checkout?

Minimal latency. Fidro's API responds in under 200ms. Run the validation in parallel with other checkout steps (inventory check, tax calculation) and the user won't notice any delay. Set a 2-3 second timeout to ensure checkout always completes.

Can pre-transaction detection stop friendly fraud?

Partially. Pre-transaction detection catches many friendly fraud signals: mismatched geolocation, new accounts with high-value orders, and temporary emails. However, determined friendly fraudsters using their real identity are harder to catch pre-transaction and require post-transaction monitoring.

Pre-Transaction Fraud Detection: How to Catch Bad Actors Before Payment

Pre-transaction fraud detection is the practice of evaluating risk signals before a payment is processed. Rather than catching fraud after money has changed hands — when chargebacks, refunds, and evidence gathering are your only options — you block it at the door.

This approach is both cheaper and more effective. A prevented transaction costs nothing. A chargeback costs $150+ when you factor in the fee, lost product, and operational overhead.

Why Pre-Transaction Beats Post-Transaction

Most payment processors offer some form of post-transaction fraud detection. Stripe Radar, for example, evaluates transactions after they're submitted. This catches the most obvious fraud, but by the time a chargeback is filed, you've already:

Lost the revenue — The transaction amount is clawed back.
Paid the chargeback fee — $15-$100 per dispute, win or lose.
Delivered the product — Digital access consumed, physical goods shipped.
Spent team time — Hours gathering evidence for the dispute response.

Pre-transaction detection eliminates all four costs by stopping the transaction before it starts.

The Pre-Transaction Signal Stack

Effective pre-transaction detection layers multiple signals. No single signal is definitive, but together they produce a reliable risk score.

Email Signals

Signal	What It Tells You	Risk Level
Disposable email	User is hiding their identity	High
DNS invalid	Domain can't receive email	Critical
Domain age < 7 days	Recently created, potentially for fraud	Medium
Free provider (Gmail, etc.)	Normal for consumers, flag for B2B	Low
Known fraud pattern	Email matches known fraud databases	High

IP Signals

Signal	What It Tells You	Risk Level
VPN or proxy detected	User is masking their location	Medium
Tor exit node	Strong anonymity signal	High
Country mismatch	IP country ≠ billing country	High
Data center IP	Bot or automated traffic	Medium
Known bad IP	Previously associated with fraud	High

Behavioral Signals

Signal	What It Tells You	Risk Level
New account + large order	No purchase history to validate	Medium
Multiple failed payment attempts	Testing stolen card numbers	High
Rapid account creation	Automated signup pattern	High
Billing ≠ shipping address	Common in legitimate gifting, but also fraud	Low

Implementation: The Two-Call Pattern

The most effective pre-transaction pattern uses two API calls — one at signup (email validation) and one at checkout (full risk assessment):

Call 1: At Signup

curl -X POST https://api.fidro.io/v1/validate/email \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{"email": "customer@example.com"}'

Block disposable emails and invalid domains immediately. Store the validation result on the user record for later use.

Call 2: At Checkout

curl -X POST https://api.fidro.io/v1/validate/email \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{"email": "customer@example.com", "ip": "203.0.113.42"}'

Add the IP address for geolocation matching, VPN detection, and a combined risk score. Use the score to decide whether to process, review, or block the transaction.

Decision Framework

Based on the composite risk score:

Score 0.0 - 0.3 → Process normally. Low risk.
Score 0.3 - 0.6 → Process but flag for monitoring. Review if a dispute is filed.
Score 0.6 - 0.8 → Add friction. Require phone verification or additional identity confirmation.
Score 0.8 - 1.0 → Block the transaction. Redirect to a support contact form.

Start with these thresholds and adjust based on your false positive rate over the first two weeks.

Running Checks in Parallel

Pre-transaction validation should not slow down checkout. Run the fraud check in parallel with other checkout operations:

const [fraudCheck, inventory, tax] = await Promise.all([
  fidro.validate(email, ip),
  checkInventory(items),
  calculateTax(address),
]);

if (fraudCheck.risk_score > 0.8) {
  return res.status(422).json({ error: 'Transaction blocked' });
}

With a 200ms average API response time, the fraud check completes before the database queries return.

Getting Started

Sign up for free — 200 validations/month
Add email validation at signup to catch disposable emails immediately
Add IP validation at checkout for geolocation and VPN detection
Read the API docs for the complete risk score breakdown