During Black Friday, a purchase outside the usual pattern is not always a fraud attempt. A consumer may buy more products at once, try different cards, send gifts to another address, or return to checkout several times to take advantage of a promotion. At the same time, intense campaigns can attract automated attacks and illegitimate attempts. The payments team needs to distinguish those behaviors without indiscriminately allowing risky transactions.
The challenge is not simply to lower protection to approve more sales. It is to discover where the purchase was interrupted, which evidence supports the block, and what can be corrected without compromising risk controls. This article proposes an investigation plan for e-commerce, risk, product, and engineering teams before Black Friday 2026.
This guide complements Payments on Black Friday 2026: what to test before peak sales. That article examines payment operations end to end; here we explore one specific scenario: the suspicion that the fraud prevention process itself is stopping legitimate purchases.
What is a false positive in fraud prevention?
A false positive occurs when a legitimate transaction is incorrectly classified as suspicious or blocked by a risk decision. It is not synonymous with every declined purchase: a technical failure, a card with insufficient available credit, abandoned authentication, and a business-policy block may produce the same generic checkout message, but they have different causes and remedies.
It is also difficult to prove legitimacy for a purchase that was never completed. A customer who contacts support, recognizes the transaction, and manages to pay by another method provides a relevant signal, but not always definitive proof. Investigation therefore needs to work with confidence levels and record the available evidence rather than automatically classifying everything that failed to convert as a false positive.
Adyen describes using control traffic within its own product as a mechanism for estimating good transactions that a risk configuration would reject. This approach is not a universal feature: it illustrates the importance of controlled comparison when evaluating blocks. Source: Adyen, Control traffic (opens in a new tab ↗).
To understand the fundamentals of scores, signals, and risk policies, also see the payment fraud prevention guide.
Why does Black Friday increase the risk of improper blocks?
Rules calibrated to an ordinary week's behavior may respond differently to a campaign with concentrated traffic, promotions, and more frequent purchases. A legitimate buyer may try several times after authentication trouble; a family may share an address and device; a user may make successive purchases with amounts unusual for their history. These signals may merit analysis, but none alone proves fraud.
Adyen's peak-season preparation guide highlights this tension: transaction quantity, frequency, and value change; normal campaign behavior may look suspicious relative to the previous period. Its guidance is to review rules, data quality, and blocking outcomes without losing sight of genuinely fraudulent attempts. Source: Adyen, Risk and disputes for peak season (opens in a new tab ↗).
This is an operational hypothesis to test in your own store, not a prediction that false-positive rates will necessarily rise. The question is whether your system has been prepared to interpret the new context or will simply inherit normal-period rules.
Before looking at the score, identify the exact stage of the loss
The first mistake in an investigation is grouping different outcomes under “payment denied.” Build a trail that distinguishes, where applicable, abandonment before submission, risk-rule blocks, pending review, 3DS authentication failure, issuer authorization decline, technical error, and timeout without a conclusive result.
If the purchase never reached authorization because an internal rule blocked it, switching acquirers does not address the cause. If the issuer declined the card, that does not prove the decision came from the merchant's fraud engine. If a 3DS challenge did not finish, investigation starts with the authentication flow and customer experience. If there was a timeout, check the state before considering another attempt.
To verify this separation in a distributed operation, relate the order, payment intent, attempt, risk decision, authentication, and provider response through consistent identifiers. AZPay's article on decline codes and technical errors explores exactly why these outcomes cannot share a single interpretation.
Start with a comparable baseline
Do not compare only the campaign's total blocks with those on an ordinary Tuesday. Separate attempt volume, unique customer count, payment method distribution, amount bands, devices, regions, traffic sources, and promotional campaigns. Then look for comparable segments across the analyzed windows.
A rule may block twice as many payments simply because traffic tripled. Conversely, the overall rate may remain stable while a segment of returning customers starts being significantly affected. Analysis should present absolute numbers and rates, always with clear denominators.
It is also useful to record the rule version and exact timing of configuration changes or deployments. Without that trail, a conversion drop may be attributed to seasonality when it actually coincided with a risk-policy change, or vice versa.
Which metrics reveal possible blocking of legitimate purchases?
One useful metric is the risk block rate: transactions blocked by the risk layer divided by transactions actually assessed by that layer. Another is the checkout completion rate, which includes losses before and after risk analysis. They do not measure the same thing and should be tracked separately.
Also monitor the percentage of reviews, time to decision, proportion of customers returning after a block, recovery through an alternative method, 3DS challenge completion, and issuer decline distribution. To assess decision quality, track disputes and confirmed fraud signals according to their maturation periods: the immediate absence of chargebacks does not prove legitimacy.
A fictional example: in one day, 10,000 transactions reach the risk engine and 400 are blocked. The block rate is 4%. The team reviews a sample of 50 cases and finds 15 with consistent indications of legitimacy. That represents 30% of the reviewed sample, not 30% of all blocks or a proven false-positive rate for the operation. Extrapolating without appropriate sampling, criteria, and follow-up would be misleading.
How can you identify whether a rule started blocking too much?
Start with the rules or decision categories whose share grew the most, while keeping volume context. For each, check when it fired, in which segments, whether other risk signals were present, whether a quality review is available, and the likely effect of a controlled change.
Attempt velocity, registration inconsistencies, a new device, and address discrepancies can be useful, but each signal may have legitimate explanations. The point is not to declare these controls bad: it is to test whether the way they were combined remains appropriate for the campaign.
Stripe recommends understanding rule hierarchy and precedence in Radar and using backtesting where available. Broad allow rules can override blocks, which is why rule changes need to be treated as risk decisions rather than conversion shortcuts. Source: Stripe, Radar Rules 101 (opens in a new tab ↗).
A prudent practice is to document the hypothesis, affected group, expected behavior, risk indicators, and rollback criteria before any change. Avoid publishing internal thresholds, exact rule combinations, or techniques that make bypassing them easier.
What should you investigate when known customers are blocked?
A returning customer should not be automatically allowed, but history can help interpret an event. Check whether the order really belongs to the same account, whether address or amount changes are consistent, whether the device or payment method changed, and whether the customer had previous attempts interrupted by technical issues.
Compare these cases with customers of a similar profile who completed their purchases. If many trusted customers started failing after a recent change, investigate the responsible rule. If cases are isolated and present conflicting signals, the policy may be acting correctly.
Never turn purchase history into an unrestricted exception. Broad allowlists and fixes without an expiration can shift risk elsewhere in the operation.
What if many customers try to pay several times?
On Black Friday, repetitions may originate from slow checkout, failure to return from a banking app, an abandoned 3DS challenge, component unavailability, or an inconclusive financial response. Each new attempt can increase velocity signals, creating a cycle where a technical failure produces apparently suspicious behavior.
To investigate, correlate attempts with the same commercial intent. Check whether the customer received clear instructions, whether the previous stage truly ended, and whether another attempt was permitted. A repeated payment request also needs to respect the integration's idempotency guarantees.
Avoiding improper blocks does not mean allowing unlimited retries. It means eliminating accidental repetitions and distinguishing a legitimate human journey from an automated pattern that requires protection.
3DS: a risk block or interrupted authentication?
3D Secure is a card payment authentication protocol, not a generic name for fraud prevention. In a frictionless flow, the issuer may authenticate without requesting additional interaction. In a challenge, it asks the cardholder for an extra step. EMVCo describes these two paths as ways to balance authentication, risk information, and experience. Source: EMVCo, Optimising Online Payment Authentication (opens in a new tab ↗).
If abandonment after a challenge increases, investigate the device, screen loading, switching between browser and banking app, session return, and timeout handling. This may require a UX or integration fix, not a fraud-rule change. Completed authentication also does not guarantee subsequent issuer authorization.
On the blog, the guide to 3DS, frictionless, and challenge details the difference between these states. In campaign preparation, they should ideally be tested in authorized, controlled scenarios.
How do you distinguish automated abuse from high legitimate demand?
Some signals can justify an attack investigation: a sudden increase in low-value attempts, large volumes of authorization errors, abnormal credential distribution, or consistent automation patterns. However, campaign-driven concentrated traffic also creates legitimate peaks. Diagnosis needs to correlate risk characteristics, outcomes, and promotional context, not just count requests.
Adyen recommends monitoring anomalies and confirming suspicious behavior before responding to automated attacks. For engineering, a useful investigation connects available risk signals with changes in traffic, campaigns, providers, and checkout performance. Source: Adyen, Peak season risk management (opens in a new tab ↗).
Do not publish real examples that expose internal parameters or detection patterns. In training, use synthetic data and controlled scenarios that test the decision flow without teaching people how to bypass protection.
What should you do when a rule seems to have worsened conversion?
Do not disable the rule just because a dashboard line fell. First confirm the change window, segment, decision source, and sample quality. Then estimate both sides of the decision: potentially lost legitimate purchases and additional fraud exposure if the control is relaxed.
Where the available technology allows it, use historical evaluation, controlled testing, observation mode, or comparisons between groups, respecting internal policies and the provider's design. Changes should have limited scope, an identified owner, a defined duration, and a rollback plan. Not every provider offers the same tools, and no technique authorizes ignoring security requirements.
A well-calibrated rule is not necessarily the one that blocks less. It is the one that achieves the risk objective with the least unnecessary loss of legitimate customers, according to the available evidence.
When does manual review help—and when does it become a bottleneck?
Manual review can be useful for higher-value transactions or cases where the system lacks enough context for an automatic decision. But in a campaign with many concentrated purchases, unprioritized queues can miss the order's commercial window and create frustration.
Before the peak, define which cases qualify for review, what evidence can be assessed, which team decides, and how a decision is recorded. Check whether support can accurately explain that review is pending without promising approval or delivery. For digital products released immediately, review time may affect the purchase's usefulness differently than a physical order shipped later.
The operation should not let a support agent “manually approve” a purchase without respecting the financial state machine and risk policies. Commercial completion must remain associated with the correct payment evidence.
How can you organize a 15-minute investigation during the peak?
This timing is a suggested cadence for initial triage, not a universal SLA. In the first few minutes, confirm whether the increase in errors is real and identify which stage changed: risk rule, challenge, issuer authorization, technical failure, or abandonment before payment.
Next, choose a high-impact segment, compare it with baseline behavior, and locate representative events or decisions without exposing sensitive data. Relate the problem's onset to recent code, configuration, campaign, or provider changes. Record a primary hypothesis and who can validate it.
Finally, decide whether to retain the control with monitoring, expand investigation, fix a UX issue, execute a previously authorized risk change, or activate a contingency plan. Avoid improvising global exceptions under pressure. Triage should produce a documented, reversible decision, not just a screenshot.
An example: the promotion increases sales, but blocks rise
Imagine an operation launching a short-lived discount. Checkout volume grows, but the dashboard shows more risk blocks and lower mobile completion. Support starts receiving reports from customers who tried to pay repeatedly.
The first step would be to investigate whether those transactions received explicit risk blocks or whether some involved abandonment during authentication. If most impact is concentrated in one browser after a challenge, test the experience and session return before changing any rule.
If, instead, most losses appear before submission for authorization and concentrate in a risk condition whose incidence rose after the promotion, the team should assess rule quality, traffic profile, and legitimacy signals. The same business symptom can require completely different fixes.
This example is synthetic and does not represent an incident or result measured by AZPay.
Which decisions need to be agreed upon before Black Friday?
Engineering, payments, risk, commercial, and support teams should share the same definitions of purchase states and primary metrics. They also need to know who has authority to change rules, stop an experiment, review transactions, and interrupt a campaign in the event of material risk.
The plan should include dashboard segmentation, event correlation, controlled access to evidence, a rollback mechanism, and post-peak follow-up. Above all, each change needs to answer: are we correcting an identified legitimate loss, or merely reducing visibility into a problem?
Fraud prevention review complements load testing, Pix monitoring, reconciliation, and incident response. To organize these areas into one plan, see the Black Friday 2026 payments checklist.
How does AZPay connect to this investigation?
In an integrated operation, risk decisions, authentication, authorization, and payment states need to be distinguishable. AZPay's documentation and technical content help organize concepts such as charging, notification, attempt traceability, and payment integration, but this should not be interpreted as a promise of a specific backtesting tool, fraud review feature, or metrics dashboard available in every company product.
This article discusses an investigation method teams can apply, adapting it to the integrations, providers, and controls they actually use. Its value lies in turning a generic “payment declined” into evidence supporting a more precise decision.
Protecting the operation also means not losing a good customer
Black Friday preparation does not end with “how much fraud can we block?” It must also answer “how many legitimate purchases did we fail to complete, why, and how do we know?” A mature architecture does not give up protection to recover conversion or sacrifice good customers' experience because it cannot explain its own decisions.
The work begins before the peak: instrument the right states, review rule behavior, rehearse authentication, define intervention criteria, and prepare the team to investigate without improvising. On campaign day, this narrows the gap between detecting a problem and choosing the appropriate correction.
Well-run fraud prevention is not a button for blocking more or less. It is a decision discipline that needs to remain explainable precisely when commerce accelerates.