Most fraud decisions happen after the payment is already in motion. The card details have been entered, the request has been sent to your payment service provider (PSP), the issuer responds, and somewhere in that chain a decision gets made.
It works, but it’s certainly not the only place to intervene.
In a high-volume payment funnel, waiting for an authorization response to screen for fraud is an increasingly expensive way to manage risk. By the time a processor issues an approval, the merchant has already incurred gateway fees, triggered network integrity surcharges, and committed to an operational path that is notoriously difficult to reverse.
Effective fraud prevention requires a “front-door” philosophy. Rather than reacting to an authorization, merchants should treat the pre-authorization (pre-auth) stage as a strategic filter, so that by the time a transaction hits the payment rail, it has already been vetted for identity and intent.
This article breaks down why it matters, what you lose when you try to do it, and how to make it work anyway.
Why pre-authorization fraud prevention matters
There are a few distinct reasons merchants benefit from catching fraud before the authorization hits the network. Some are about cost, some are about reputation, and the one I find most interesting is about the experience you create for the shopper.
Stopping fraud after the fact is expensive
When fraud happens post-auth, the transaction is already done. Money has changed hands. Goods or services may have already been delivered. Reversing a post-auth transaction means refunds, cancellations, operational overhead, and in many cases you absorb the loss anyway.
Pre-auth detection doesn’t just reduce fraud losses. It eliminates the reversal process entirely. The bad transaction never enters the system, so there’s no refund to fight, no dispute to log, and no customer experience to repair after the fact.
That’s a fundamentally different cost profile than catching fraud post-auth, and it’s the strongest argument for moving detection upstream. Every authorization request sent to a gateway or processor carries a price tag like interchange, processing costs, or gateway fees. Blocking a fraudulent payment before it reaches the PSP eliminates that spend entirely, which matters most when mitigating rapid-fire attacks.
Merchant ID health and better acceptance rates over time
Every payment you send out affects how your merchant looks to issuers and acquirers over time. When your traffic is clean, with low fraud rates and low declines, you build a reputation. Issuers recognize your Merchant ID (MID) as a healthy one, which translates directly into higher acceptance rates and fewer false declines on legitimate customers.
The inverse is also true. When a MID consistently sends noisy, high-risk traffic, issuers become more conservative. They decline more. Your acceptance rate drops. And that’s a much harder problem to fix retroactively.
This dynamic has gotten more concrete with the arrival of VAMP, Visa’s Acquirer Monitoring Program. VAMP tracks fraud and dispute levels per merchant on a monthly basis. Exceed the thresholds and you’re required to implement risk mitigation measures; continue exceeding them and you face penalties.
The program makes what used to be a soft reputational concern into a hard compliance requirement. Pre-auth filtering means the traffic that reaches the network is your cleanest, which directly helps keep your VAMP ratios in check.
Instant feedback and conversion opportunity
This is often the most critical advantage for conversion. If a merchant determines a specific card can’t be used for a transaction, they can tell the shopper immediately. Rather than a hard decline, the merchant can dynamically offer alternative payment methods, such as a different card, a digital wallet, or a buy now, pay later (BNPL) option, before the payment is ever placed.
The experience for the user and the overall conversion rate improve when these decisions happen before the shopper actually places the payment. Catching a bad actor pre-auth also means you’re not forcing a legitimate customer through an awkward post-auth reversal process.
What you’re giving up
Pre-auth sounds good in theory, but there’s a significant data problem and you need to go into this with your eyes open.
Shifting to pre-auth requires acknowledging a real visibility gap. For merchants who prioritize staying out of Payment Card Industry (PCI) compliance scope, touching raw card data is not an option. This security choice creates an immediate intelligence deficit.
Card details and BIN intelligence
If you’re not PCI compliant, and many merchants aren’t, you’re not handling raw card data directly. Your PSP hosts the payment form, tokenizes the card on their end, and you never see the actual number. That means no Bank Identification Number (BIN), no issuer, no card type, and no country of origin.
The BIN, the first six to eight digits of a card number, carries a significant amount of intelligence. It tells you which bank issued the card, what country it’s from, whether it’s debit or credit, and whether it’s prepaid. A U.S.-issued card being used from Mexico reads very differently from a Mexican card used in Mexico. None of that geographic signal is available pre-auth without PCI compliance.
A token helps partially. Even without PCI compliance, merchants may still receive a token that represents the card, which is useful for blacklisting and basic velocity checks. But a token does not restore BIN intelligence. Whether a token gives you enough signal depends entirely on its depth.
A “blind” token provides a persistent identifier without card metadata. A “rich” token preserves BIN and essential card metadata while keeping raw card data out of your environment.
Without the latter, you have a useful security placeholder rather than a fraud tool.
The Address Verification Service response
Without hitting the payment rails, you also lose the Address Verification Service (AVS) response, which is the issuer’s feedback on whether the billing address entered at checkout matches what they have on file. Granted, it’s not a silver bullet: AVS match rates vary significantly by geography, and fraudsters with full card data can often provide the correct billing address anyway. Even so, it’s an independent signal from the issuer, and one more data point your model no longer has pre-auth.
What to keep in mind when doing fraud prevention pre-authorization
Given these constraints, what does good pre-auth fraud detection actually look like? There are two things you need to get right.
Start with a payment-method-agnostic model
The single biggest mistake is building, or buying, a fraud model that is deeply dependent on card data. If BIN is a required input and the model literally cannot score a transaction without it, you’re stuck before you even start.
Most legacy fraud engines are card-centric, requiring a BIN and an AVS response to function. In a pre-auth environment, these models don’t just lose accuracy. They often become entirely inoperable because they’re missing the mandatory data fields they were built to consume.
The better approach is a model designed to be payment-method agnostic from the beginning. Think about what this means in practice: bank transfers, BNPL, wallets, and other alternative payment methods (APMs) carry none of the card-like intelligence layer. A model built to handle card and non-card payments simultaneously has already learned to score transactions without BIN data, so the absence of card details doesn’t collapse it.
There’s also a subtler version of this problem: models that treat card data as optional but still degrade dramatically without it. You want a model where the absence of card details is genuinely handled gracefully, not one that simply doesn’t error out but quietly loses half its discriminating power.
Compensate with stronger signals elsewhere
The absence of card intelligence needs to be offset by being stronger in everything else. There are three high-strength signal categories to build around:
Device intelligence and identity-based behavior
This is where I'd put the most weight. A rich device fingerprint, one that persists across sessions and survives common evasion tactics like browser resets, app reinstalls, or device ID spoofing, gives you a durable identifier that has nothing to do with the payment method.
Combined with behavioral signals at checkout, such as typing cadence, navigation patterns, and whether behavior matches previous sessions, this combination is powerful precisely because it operates independently of card data.
A fraudster may have a perfectly valid stolen card, but if their device fingerprint links to a history of fraud and their checkout behavior doesn't match anything in your legitimate user population, you can catch them before the authorization hits the network.
Deep email and IP intelligence
In the absence of an AVS address match, the email address becomes the primary anchor for identity. Email age, domain reputation, prior appearances across fraud cases at other merchants, and whether the domain is disposable are all available pre-auth, and most merchants underuse them.
On the IP side, if you can see through proxies and VPNs to the true network origin of the device, you get real geolocation data, datacenter versus residential detection, and meaningful velocity checks.
Advanced cross-entity velocity checks
Traditional velocity checks often fail pre-auth because they look for repeated card numbers. What moves the needle is cross-entity velocity: whether a device fingerprint links to five different email addresses in the last 24 hours, whether an IP address associates with a wave of new account creations, or whether multiple card tokens are hitting the same device.
The pattern stays visible even when the tokens vary. That's the point.
Pre-auth fraud detection doesn't ask you to do more with less. It asks you to be very good at the signals that don't require the card, and that's a different skill than what most post-auth fraud stacks are optimized for.
The clean-room approach: Layering pre- and post-auth detection
Pre-authorization detection is a clean room for the payments ecosystem, not a replacement for traditional fraud tools. The goal is to ensure that only high-quality, high-intent traffic ever touches the payment rails.
A merchant doesn’t have to choose between pre-auth and post-auth environments. The most resilient defense comes from layering the two. Pre-auth filtering handles the heavy lifting of identifying bots and validating identity markers, which allows the post-auth stage to act as a final verification point using the issuer’s specific authorization data. This sequence ensures that the most intensive risk models are reserved for traffic that has already proven a baseline of trust.
The combination offers clear advantages: lower costs, healthier issuer relationships, and the ability to use instant feedback to stop user churn. By vetting intent before the transaction is finalized, businesses take ownership of the customer experience.
The bottom line
Pre-auth fraud detection isn’t the right move for every merchant. If your fraud volume is low and the operational lift doesn’t justify it, there’s no reason to rush. But if you’re dealing with meaningful fraud rates, a dragging acceptance rate, or VAMP compliance pressure, or if you’ve watched good customers get stuck because your fraud model had a bad signal on their card and nothing better to offer, it’s worth asking whether you’re intervening at the right point in the flow.
The data constraints are real, and so is the work required to compensate for them. Done well, though, pre-auth detection gives you something post-auth can’t: the ability to stop bad payments before they touch the network and to give good customers a better path forward when their payment method isn’t going to work.
That’s worth the investment.
