The problem and decision criteria
Technical and operational design reference: September 26, 2026
You tightened fraud rules, but payment completion fell. More customers ask, “Why can't I pay with my own card?” Reverting the rules could restore the losses you meant to prevent. Comparing block counts with payment completion alone does not tell you what action to take.
First, separate transactions blocked by your own fraud detection system, those stalled during additional verification, and those declined by the gateway or card issuer. Then examine payment completion, confirmed fraud, customer abandonment, and review delays for the same transaction cohort. Instead of blocking every risk signal or allowing everything to avoid inconvenience, choose treatment according to what additional evidence each transaction can provide.
Here, FDS means a fraud detection system that assesses potentially fraudulent transaction use. The merchant is not always the decision maker. Toss Payments also describes analyzing contracted merchants' transactions to identify and block fraudulent payments. A decline alone therefore does not establish that your changed rule caused it.[1]
Locate the stage and decision maker that stopped the payment
An authentication success screen, a gateway payment confirmation response, issuer authorization, and completed fulfillment are different events. Toss Payments' payment widget integration guide separates buyer authentication from server-side payment confirmation. PAY_PROCESS_CANCELED, indicating user cancellation, and REJECT_CARD_COMPANY, indicating a card-company decline, are separate errors. Neither error name alone proves a false positive in your FDS.[2]
Stripe likewise separates risk evaluation from financial institution decline information, including examples blocked before being sent to the network. Confirm when the FDS intervenes for the particular provider and integration.[3]
Operational records should retain a transaction reference together with stage, decision maker, result code, occurrence time, and applied policy version. If the gateway does not provide a detailed reason, retain “declined in gateway response; detailed cause unconfirmed.” Do not fill an unknown cause with “successful fraud detection.”
These distinctions also establish the starting point for metrics. User journey monitoring design explains defining the customer's actual outcome before measuring server responses.
From transaction signals to risk decisions and review — Connect account, device and payment signals to decision rules, then use review outcomes to refine those rules.
Replace one approval rate with a map of explicit denominators
The following is an operational design example for online prepayment. A purchase intent is an internal service unit grouping multiple payment attempts for one purchase; it is not assumed to match any gateway's object name. Define separate linkage units if you support split payments or combined payments for several orders.
Define eligible transactions first. For example, include actual purchases initiated with supported payment methods in production, and do not later remove an attempt from the denominator because the FDS flagged it. Record exclusion reasons and definition versions for test transactions, unsupported methods, or other exclusions.
| Stage | Metric and denominator: design example | Where to investigate failure and responsibility |
|---|---|---|
| Entry and eligibility | Record unique purchase intents that started payment; eligible purchase intents ÷ purchase intents starting payment | Service and data owners check product/channel mix changes and changes to measurement scope |
| FDS evaluation and blocking | Completed evaluations ÷ eligible attempts requiring evaluation; block rate = attempts blocked by that control ÷ completed evaluations by the same control | Distinguish merchant, gateway, and issuer where observable; separate unevaluated, error, and unknown-risk states from normal evaluation |
| Additional verification | Eligible attempts requiring verification ÷ eligible attempts; verification starts ÷ verification requests; successful verifications ÷ starts | Separate your policy from gateway/issuer requirements; distinguish missing UI, user cancellation, authentication failure, technical error, and in-progress states |
| Authorization | Issuer authorization rate = authorizations ÷ requests actually sent to the issuer; separately, gateway confirmation API success = successful responses ÷ API requests | Do not estimate issuer authorization rate without observing issuer submission; do not mix gateway API and card-network metrics |
| Payment completion | Unique purchase intents with completed payment ÷ eligible purchase intents | Use the selected gateway/method's status definitions to distinguish authorization from full completion |
| Product or entitlement fulfillment | Orders fulfilled by their promised deadline ÷ completed-payment orders whose fulfillment deadline has arrived | Payment operations and fulfillment owners check together; orders not yet due are not fulfillment failures |
| Confirmed fraud | Confirmed fraudulent payments in a cohort completed during a specified period ÷ all completed payments in that cohort; include judgment criteria and observation end date | Risk owner manages evidence source and decision date; do not combine reported, suspected, and confirmed cases |
| Disputes | Payments with a filed dispute in a completed-payment cohort ÷ all completed payments in the cohort; separate fraud and other reasons | Dispute owner distinguishes reasons and progress; filing alone is not confirmed fraud |
| Manual review | Decisions completed ÷ reviews registered in the same entry cohort; allow decisions ÷ completed decisions is a composition metric | Review owner separately tracks unassigned, in-progress, overdue, and completed follow-up actions |
These definitions are proposals in this article, not copied vendor dashboard values. Stripe analytics documentation also distinguishes aggregation rules and transaction dates from dispute dates. Compare the actual numerator and denominator, rather than the metric name.[8]
Retries can turn one purchase intent into several attempts, causing attempt-based authorization and intent-based completion rates to move differently. Use attempt metrics to investigate errors and declines, and unique purchase intent metrics for purchase completion. Fix per-control aggregation rules when one attempt generates multiple evaluation events.
A zero denominator means not applicable, not 0%. Define when an unfinished authentication or payment becomes abandonment. These rows answer different questions, so do not add their percentages to 100%. Separate count-based and amount-based metrics, and do not add different currencies without a conversion basis.
The true outcome of a declined transaction is usually not immediately observable
You cannot observe whether a blocked transaction would have become legitimate or fraudulent had it proceeded. Stripe explicitly identifies this counterfactual limitation when evaluating allow rules on previously blocked payments.[7]
Distinguish the strict false-positive rate from easier-to-collect operational metrics. For a binary decision that incorrectly blocks legitimate transactions as fraudulent, the false-positive rate is:[9]
False-positive rate (FPR) = legitimate transactions incorrectly blocked ÷ all actually legitimate transactions
In contrast, decisions reversed to allow after appeal ÷ completed appeals is an appeal reversal rate. Blocked transactions judged legitimate in a sample ÷ reviewed blocked sample transactions is the legitimate judgment proportion within that sample. Neither becomes the overall false-positive rate without a separate estimation procedure.
This produces practical limitations. Customers who leave without appealing never enter appeal data. Reviewing only convenient cases biases the sample. A human allow decision is a decision made at that time, not final proof of legitimacy throughout the payment's lifetime. Retain sample selection, decision evidence, and unresolved counts with the results.
Align time as well. Disputes and fraud information can arrive after payment, changing the measured rate for the same cohort later. All-cause disputes and fraud-related disputes are different metrics.[8][10]
Do not compare well-observed pre-change transactions with yesterday's post-change transactions and declare a lower fraud rate. Align payment periods, observation end dates, and observation ages; mark immature results provisional. Increased blocking may reduce the transaction population itself, so fewer fraud cases alone do not prove improvement.
Choose among allowing, additional checks, holds, manual review, and blocking
A risk score is an input, not an answer key. Stripe explains that a payment assessed as normal risk can later prove fraudulent and distinguishes not assessed from unknown risk.[3] Do not treat different providers' or internal models' scores as one scale; establish their meaning in the applicable environment.
The following is a policy design example. Criteria include fraud likelihood, potential damage, reversibility, the value of more evidence, customer friction, review cost, and delay. A hold and manual review may be used together; these are not necessarily five mutually exclusive system states.
| Treatment | Conditions to prioritize | Benefit and tradeoff | Required policy decisions |
|---|---|---|---|
| Allow | Evidence is consistent and residual risk is acceptable to the business | Less friction, with residual possibility of later fraud | Decision rationale and owner; this does not guarantee gateway or issuer approval |
| Additional verification | Supported authentication or verification can reduce current uncertainty | Stronger evidence, with abandonment, failure, and technical delay | Required evidence and the next step and communication for incomplete, failed, or unsupported verification |
| Hold | Evidence may arrive, and waiting fits fulfillment commitments and payment deadlines | Opportunity to prevent immediate loss, at the cost of customer waiting and operating workload | Precisely whether authorization requests, capture, or fulfillment stops; release owner and expiry action |
| Manual review | Signals conflict or human review of context could change the decision | Contextual decisions, dependent on review quality, workload, and delay | Owner and backup, evidence, decision deadline, payment/fulfillment state during review, and follow-up executor |
| Block | Expected harm is unacceptable and no timely verification can sufficiently reduce risk | Stops this attempt but may lose a legitimate customer | Internal rationale, customer communication and appeal route, exception review authority; do not disclose detection rules |
Sending every ambiguous transaction to a queue is not a solution. Without new information for a person to examine, manual review is merely a waiting queue. Redesign evidence collection and automated decision boundaries before simply adding reviewers.
Completing additional authentication does not establish legitimacy
EMV 3-D Secure helps merchants and issuers exchange information to authenticate users in online card payments. Risk assessment determines whether the flow proceeds without extra input or challenges the customer. A record of requesting 3DS is therefore different from a record that a challenge screen actually appeared.[5]
Authentication success does not mean final payment authorization or resolution of every transaction problem. Stripe's 3DS documentation describes subsequent payment processing and issuer influence over the actual authentication flow. Liability shifts after successful 3DS also have conditions and exceptions; they do not provide blanket protection against disputes for reasons other than fraud.[6]
For Korean payments, first confirm which additional checks the chosen gateway, card, payment method, and integration support. Do not assume an international product's Request 3DS has an identical Korean gateway setting, or that any one customer check makes a transaction safe.
From transaction alerts to response and provider review — Follow symptom-based checks to establish transaction status and handle incidents, refunds and recurring issues.
Registering a review is separate from holding payment or fulfillment
Stripe Radar's review queue can contain both already processed payments and payments awaiting later capture. Unless authorization and capture are separately configured, reviewed payments are generally already processed. Approve in the review interface closes the review without changing the payment itself.[4]
When adding manual review, check review status, payment status, and fulfillment status separately. The existence of a queue alone does not establish that loss has been prevented.
Suppose a service issues an immediately usable entitlement. If it issues the entitlement immediately after payment and simultaneously registers a review, the entitlement may be used before a decision arrives. This is a fictional design example, not a customer case. To make review a pre-issuance control, connect actual fulfillment waiting, its allowed deadline, and payment follow-up after rejection. Also avoid telling an already charged customer that payment is incomplete.
Radar manual review and custom rules also vary by plan, payment method, and API object. Do not generalize its behavior to another gateway's defaults or every account's entitlements.[3][4][11]
Hand off evidence and deadlines together with the case
Keep the following records in the operating policy. These are design criteria for explaining decisions and completing follow-up, not a list of features automatically supplied by a product.
| Record | Required content |
|---|---|
| Assignment and accountability | Reviewer and backup, decision approval authority, payment follow-up and fulfillment executors |
| Decision evidence | Transaction reference, internal risk reason code, information sources, times and reliability, and unresolved items |
| Decision and execution | Allow, verify, retain, or block decision and rationale; separate decision time from completed release, cancellation, refund, or fulfillment |
| Deadlines and customer communication | Decision deadline reflecting payment constraints and promised fulfillment, safe overdue treatment, and current status to communicate |
| Appeals and change history | Review by another person, reversal reason, transaction exception scope and review time, policy version, editor, approver, and rollback conditions |
Creating review records does not require bringing all payment payloads and customer information into one screen. Start with transaction references and the minimum decision data; separate detailed information permissions. Determine actual collection and retention through a separate security and privacy review.
Do not choose a universal number of minutes as the deadline. Consider payment method constraints, time to obtain evidence, fulfillment commitments, and reviewer availability. Avoid a gap that automatically allows transactions when no reviewer is available or time expires.
Do not assess review speed only through averages. Separate waiting-time distributions for completed cases from actual working time; also track waiting age and overdue counts for open cases. Excluding old unfinished cases can make performance appear better than it is.
After changing rules, compare transactions under the same conditions
Before changing anything, write down the failure you intend to reduce. Reducing technical failures at a verification step and diverting uncertain transactions to review require different validation. Record policy version, target population, payment methods, channels, product mix, and comparison periods.
Applying a new rule to historical transactions can show how its targets differ. Stripe describes examining historical matches before adding or editing rules. Those results still do not recover the actual outcomes of blocked transactions.[7]
Separate validation as follows.
Behavior validation checks whether branches connect as intended. In environments you own or are explicitly authorized to test, verify authentication failure, verification expiry, unassigned review, fulfillment hold and release, and customer messaging after blocking. Passing sandbox tests does not establish real-world false-positive rates or fraud prevention performance.
Policy comparisons use only information available at the decision time. Do not mix later dispute results into historical decision inputs. Observation without changing actual actions can help, but it cannot recover outcomes hidden by existing controls. Do not indiscriminately allow blocked transactions to obtain ground truth.
Production changes stay within an owner's approved scope and stopping conditions. Monitor payment completion alongside early fraud signals, losses, verification abandonment, review backlog, and customer inquiries. Define acceptable loss and delay, stop signals, and rollback conditions in advance according to business constraints.
Final evaluation includes delayed outcomes. Match cohort composition and observation ages, and keep effects provisional when samples are small or many transactions remain unresolved. Report increased authorization and increased fraud losses together if both occur.
The next action may be clearer accountability rather than more blocks
If gateway failure details, stage-specific metrics, and review ownership already exist, organize existing policies before buying another tool. If you cannot see who declined the transaction or review decisions do not affect payment and fulfillment, first align available evidence and control boundaries with the gateway, engineering, and operations teams.
Do not define FDS success as blocking more. Prevent unacceptable harm, assign verification to transactions where additional evidence is valuable, and explain the costs those decisions impose on customers and operations. A lower fraud rate or higher approval rate alone cannot establish that outcome.
For external implementation support, consult IXC's fraud detection service scope, and discuss decision making, review, and follow-up execution as separate work areas.
