Tune AI payment screening around false declines as well as fraud

A worked merchant review that asks which customers are being interrupted and whether the intervention helps.

A payment screen has two expensive mistakes available to it: accepting a fraudulent transaction and rejecting a legitimate customer. AI can help rank risk, but a merchant needs to understand both outcomes before changing a rule. A system that simply blocks more activity may produce a reassuring dashboard while making the business harder to use.

Stripe describes AI payment optimisation and Radar upgrades. Visa describes adaptive payment protection. The FCA discusses evaluating AI through a supported testing programme. These are vendor and supervisory accounts, not independent performance guarantees for a merchant's configuration. [Stripe tools](https://stripe.com/blog/using-ai-optimize-payments-performance-payments-intelligence-suite), [Visa approach](https://corporate.visa.com/en/sites/visa-perspectives/security-trust/ai-and-trust-at-scale.html), [FCA testing](https://www.fca.org.uk/publications/feedback-statements/fs25-5-ai-live-testing).

Consider a fictional ticket retailer called Lantern Seats. It sells low-priced local events and occasional expensive group bookings. A single threshold may interrupt one type of order more often than the other. Lantern begins by collecting approved, minimised operational records: order type, payment outcome, authentication request, later dispute and support contact. It does not need to copy complete card details into an AI experiment.

The first analysis groups outcomes by the business context already known to the merchant. New customers are considered separately from returning customers, and group orders separately from individual tickets. The team inspects whether declines cluster around a particular issuer, market or checkout path. A pattern is a lead for investigation; it is not proof that a population is fraudulent. Avoid turning demographic proxies into undocumented risk policy.

A worked case has a returning customer buying eight tickets while travelling. A score prompts additional authentication. The customer completes it and the order succeeds. Another case has repeated attempts on many cards and no successful authentication. These fictional cases help the merchant describe the interventions it wants to evaluate. They do not establish the correct provider rule or a safe fraud threshold for every business.

Start changes in a controlled environment with the provider's approved testing tools. Check what the chosen rule actually does: block, request authentication, queue review or merely add information. Then design a limited authorised experiment with clear stop criteria and operational ownership. A model score should not be treated as a universal probability unless its calibration and interpretation have been established for the relevant use.

A customer's experience needs attention. If authentication fails, explain that the payment could not be completed and offer an appropriate next step. Do not display a raw risk score or accuse the person of fraud. Preserve the basket where safe. If the outcome is uncertain after a network interruption, check the existing payment state before retrying, so the customer is not charged twice.

Manual review is useful only if staff have sufficient evidence and authority. A queue that contains hundreds of opaque scores may simply move the burden from checkout to support. Lantern specifies the questions a reviewer can answer, the time available before an event sells out and when to contact the customer. Decisions and reasons are recorded so the rule can be evaluated later.

Measure accepted legitimate orders, confirmed fraudulent losses, disputes, additional authentication completion and support effort. Fraud labels arrive late, so early results remain provisional. A short experiment may look successful before disputes mature. Also inspect customers who gave up; a completed-order dataset cannot show everyone who was incorrectly interrupted. The merchant should state those coverage limits in its internal report.

The cited vendor pages discuss broad capabilities and their own results. This article does not reproduce their headline performance figures or imply that Lantern will obtain the same effect. Current fees, local payment methods, integration support and account eligibility need direct verification. Costs can include transaction services, additional risk features, staff review and lost legitimate orders, alongside fraud losses.

The decision is not necessarily to make screening stricter. It may be to improve authentication, repair a checkout problem or provide a better review path for an unusual order. AI is useful when it supplies information that improves this decision. A payment process should protect the merchant while giving legitimate customers a clear, recoverable way to complete the purchase.