Payment authentication and fraud controls

Payment authentication and fraud controls address related but separate problems. Authentication checks whether a shopper can satisfy an identity challenge in a payment flow. Fraud rules decide whether to allow, review, challenge or block an order using risk signals. A store needs both to protect payments without turning legitimate buyers away unnecessarily.

Follow the payment path

At checkout, the payment provider collects a payment attempt and may assess risk before authorisation. For card payments using EMV 3-D Secure, information can be sent to the card issuer for authentication.

The issuer may approve a frictionless flow or request a challenge such as a one-time code or banking-app confirmation. An authentication result is then returned. The exact sequence and interface depend on the provider, issuer, card and integration.

A successful challenge does not guarantee payment. Authorisation can still fail after authentication, and a payment with no visible challenge has not necessarily skipped security checks. Wait for the provider's final payment status before marking an order paid or starting fulfilment. Test completed, failed, abandoned and timed-out authentication paths, not just the happy path.

Choose proportionate controls

Fraud controls can request authentication, place an order in review or block it. A blanket rule such as “reject every order from a particular broad region” may stop some fraud but also deny legitimate buyers.

Risk-based controls can use transaction context and provider signals to reserve stronger checks for higher-risk cases. The issuer, however, may independently require a challenge; a merchant's preference does not guarantee a frictionless flow.

Write each rule's purpose and expected action. What evidence supports the condition? Can an employee review it? What happens to a customer whose legitimate payment is blocked?

Keep regulatory or issuer requirements separate from merchant-chosen fraud thresholds. Do not describe a rule as mandatory for every Australian checkout without verifying the applicable payment arrangement.

Fraud Rule Actions and Implications

Configure rules deliberately

Some payment platforms let a business label fraud rules by their basis. Adyen labels include Business for business-specific rules, Legal for rules based on laws or regulations, Fraud for specific fraud risks, and Block list or Trust list for list-based controls. Visible distinctions help staff understand why a control exists and avoid treating every rule as the same decision.

Adyen custom rules can run before or after authorisation, with conditions combined using AND or OR. Available actions depend on the rule setup and can include Allow, Block, Review or Check for 3DS. Adyen says custom rules require Protect premium, an online payments integration and risk management enabled; changing risk settings also requires an appropriate Customer Area role.

Before adding a rule, confirm who is authorised to change it and whether it belongs to the merchant's fraud policy or a legal or regulatory basis. Record its label and conditions so another authorised team member can interpret them. This supports controlled administration without presenting a provider-specific configuration as a universal checkout requirement.

Adyen Custom Rule Labels and Use Cases

Use provider risk information carefully

Risk products may combine signals a merchant cannot see at checkout. Stripe says its Radar adaptive AI models assess payments in real time using hundreds of risk factors and network data, and incorporate feedback when businesses mark payments as fraudulent. These model assessments differ from some Stripe risk settings and controls, which use specialised models.

Stripe reports risk outcomes including High risk, Elevated risk, Normal risk, Not evaluated and Unknown risk. A business can inspect payment risk information in the Dashboard or through the Charge object's Outcome attribute, and may also receive information about a decline from a financial institution. Use these provider-specific details as payment operations inputs, not as a substitute for checking the final payment status.

Key Risk Indicators from Provider Systems

Measure the cost of both errors

A lower block threshold may catch more fraudulent attempts and reject more good customers. A higher threshold may improve acceptance while increasing fraud exposure. Review blocked and reviewed payments, issuer declines, completed orders and later fraud disputes by comparable cohorts. Distinguish a payment blocked by the merchant's rule from one declined by the issuer; remedies differ.

A false decline is a good transaction rejected by the risk setup, but a blocked transaction's true status is often not directly observable. Use customer contacts, manual investigation, provider control data where available and subsequent outcomes cautiously.

Adyen's control traffic supports assessing false positives and true positives; that is one provider's method, not a universal merchant dataset. A dispute is a delayed signal, and not every dispute is fraud.

Test before broad rollout

Use a payment provider's test environment to verify integration behaviour: authentication required and completed, challenge failed or abandoned, risk rule triggered, issuer decline and retry. Stripe publishes test tools for some of these cases. These tests confirm technical handling; they do not establish a production fraud rate or prove a new rule will improve revenue.

For a proposed new rule, backtest on historical traffic where the provider supports it, inspect a sample of matches, then deploy to a limited segment or review mode if the platform allows. Watch acceptance, review workload and fraud outcomes over a meaningful period before widening it. Have an owner and rollback condition in advance.

The operating goal is a checkout that reaches a clear final status for each attempt and a risk policy that can be explained and adjusted. Neither maximum friction nor maximum approval is a complete strategy.

Pre-Rollout Testing Checklist for New Fraud Rules