On this page

What this guide covers
Decision model
Reference architecture
Choose an authentication control
Manual review
Post-authorization verification
How solution architects should think about this
Example decision patterns
Inputs DEUNA can use in routing logic
Implementation considerations

Dynamic authentication and verification orchestration with DEUNA

Dynamic authentication selects the control a transaction needs before authorization and applies a consistent verification policy after the processor responds. The decision can use fraud results, transaction attributes, customer context, issuer behavior, market rules, and the merchant's risk policy.

Preserve conversionSend trusted traffic directly and add friction only when the evaluated transaction needs it.Recover uncertain trafficUse enrichment, strong authentication, identity verification, or human review instead of treating every risk signal as a hard decline.Apply one verification policyNormalize supported response signals such as AVS before accepting, denying, or escalating the result.

What this guide covers#

EMV 3DSApply challenge-capable cardholder authentication selectively.Data OnlyShare additional issuer context without forcing a full authentication challenge.PasskeysUse supported device-native authentication for eligible journeys.Identity verificationAdd biometric or identity controls when payment-layer evidence is insufficient.Manual reviewRoute ambiguous transactions to a supported analyst workflow.AVS policyNormalize supported address-verification responses and apply one merchant policy.

Decision model#

Moment	Rigid implementation	Orchestrated implementation
Low-risk request	Apply the same authentication to every customer.	Continue directly when the route and merchant policy permit it.
Borderline risk	Approve or reject from a single score.	Select lightweight enrichment, strong authentication, identity verification, or manual review.
High-risk request	Decline immediately.	Stop the transaction or attempt an approved recovery control when one is configured.
Processor response	Interpret provider-specific AVS values independently.	Normalize supported verification signals and apply a common merchant policy.

The routing policy should separate risk evaluation from action selection. A score or provider decision is an input; the configured route determines the next permitted action.

Reference architecture#

Below is a simple conceptual architecture.

Flow diagram

Merchant or customerDEUNAProvider or processorReview or pendingException or stopResult or outcome

Architectural interpretation

Stage	Responsibility	Output
Evaluate	Combine approved fraud, customer, transaction, issuer, market, and merchant-policy inputs.	A route decision with the permitted next action.
Control	Continue directly or invoke supported enrichment, authentication, identity verification, or manual review.	Evidence or a terminal decision.
Authorize	Send the eligible transaction to the selected payment processor.	Authorization and supported verification data.
Enforce	Normalize supported response signals and apply the merchant's common policy.	Accept, deny, or escalate.

Authentication and verification therefore remain part of the same transaction route instead of becoming isolated provider-specific integrations.

Choose an authentication control#

Select the least disruptive supported control that satisfies the route's risk and policy requirements.

Control	Best fit	Customer impact	Route outcome
Direct authorization	Trusted, low-risk traffic with no additional requirement.	No added authentication step.	Continue to the selected processor.
3DS Data Only / Data Share Only	Borderline traffic where issuer context may help but a challenge is not justified.	No full cardholder challenge.	Continue with additional issuer context where supported.
Full EMV 3DS	Elevated risk, high value, first-time use, issuer conditions, or a merchant or regulatory requirement.	Frictionless or challenged authentication according to the supported 3DS result.	Continue only with an acceptable authentication outcome.
Passkey	Eligible returning-user or device-native journeys where stronger proof is useful.	Device-native authentication where supported.	Continue with the supported passkey result.
Biometric or identity verification	Account-takeover risk, sensitive products, very high value, or stronger identity certainty.	Face, liveness, possession, or identity checks according to the selected provider.	Continue, stop, or escalate according to the configured result.
Manual review	Ambiguous or operationally sensitive transactions where human judgment adds value.	The transaction waits for an analyst decision.	Approve, reject, or escalate.

The route may evaluate transaction amount, customer tenure, device or velocity changes, issuer or BIN segment, market, fraud result, and prior attempts. Do not assume every control is available on every processor or in every market.

Manual review#

Use manual review when a supported fraud-provider workflow can make a better decision than either an automatic decline or additional customer authentication. Typical candidates include high-value orders, mixed fraud signals, strategically important customers, and transactions with operational context that static rules cannot evaluate reliably.

SendThe configured route places an eligible transaction into the supported review queue.DecideThe merchant's analyst workflow returns an approve, reject, or supported escalation result.ResumeDEUNA applies the configured next action without treating review as a separate payment flow.

Review result	Next action
Approve	Continue to authorization, capture, or fulfillment according to the merchant flow.
Reject	Stop the transaction or block fulfillment according to policy.
Escalate	Invoke a supported authentication or identity-verification path when the route permits it.

Manual review is a human validation path. It does not replace EMV 3DS, passkeys, biometric verification, or the merchant's fulfillment controls.

Post-authorization verification#

AVS is a response signal, not a replacement for 3DS or identity verification. Supported processors may expose different raw values, so DEUNA normalizes those values before the merchant policy decides the final action.

Stage	DEUNA behavior	Merchant decision
Receive	Read the supported raw AVS response from the processor or gateway.	No provider-specific parsing in the checkout flow.
Normalize	Map the response to the supported DEUNA AVS model.	Maintain one policy across eligible connections.
Enforce	Evaluate the normalized result against the configured policy.	Accept, deny, or escalate.

Example context	Policy result
Low risk with an acceptable AVS result	Continue normally.
Moderate risk with a weak or partial match	Deny or escalate according to merchant policy.
Authorization succeeds but the normalized AVS result is blocked	Apply the configured post-response denial.
Strategically important order with an uncertain result	Escalate to supported review or another permitted action.

Set auto-denial rules in DEUNA Admin

A typical configuration flow is:

Log in to DEUNA Admin.
Navigate to Error Management.
Open AVS Settings.
Select the DEUNA AVS codes that represent unacceptable risk for your business.
Save the configuration.

Once configured, the policy applies consistently to supported routes where AVS data is available. See AVS management for the detailed response model and configuration behavior.

How solution architects should think about this#

A good implementation does not add more authentication everywhere. It defines a decision ladder and moves a transaction only as far as its risk, policy, and evidence require.

Recommended decision ladder

Level	Control	Use when
1	Direct authorization	The transaction is trusted and no additional control is required.
2	Lightweight enrichment	Issuer context is useful but a full challenge is not justified.
3	Strong cardholder authentication	Risk or policy requires stronger cardholder proof.
4	Human validation	The signal is ambiguous and analyst judgment can add value.
5	Stronger identity certainty	The transaction requires confidence beyond payment-layer checks.
6	Response verification enforcement	A supported post-response signal must still be accepted, denied, or escalated.

The ladder prevents unnecessary strong authentication, recoverable transactions defaulting to hard declines, and provider-specific response semantics fragmenting the merchant's policy.

Example decision patterns#

Recover an anti-fraud rejectUse transaction value, customer trust, and identity requirements to choose Data Only, full 3DS, passkey, or identity verification instead of an immediate decline.Segment by customer trustKeep trusted repeat traffic light; step up first-time or anomalous traffic according to the configured route.Align control with economicsUse lighter controls for tolerant low-value traffic and stronger controls or review for high-value exposure.Review ambiguous transactionsSend mixed or review-range signals to analysts, then continue or stop from the returned decision.Standardize AVS policyApply the same accept, deny, or escalation policy to normalized responses from supported providers.Coordinate controlsCombine pre-authorization authentication with manual review and post-response verification without splitting ownership across separate flows.

Inputs DEUNA can use in routing logic#

A robust route combines approved inputs instead of relying on one score.

Signal group	Examples
Fraud	Decision, score, reject reason, review band, queue, or manual-review outcome.
Customer	History, tenure, trust level, and prior outcomes.
Transaction	Amount, basket profile, product sensitivity, and previous attempts.
Card and issuer	BIN, issuer, card type, country, and supported authentication context.
Session	Device, location, velocity, and other approved session anomalies.
Merchant policy	Vertical, market, geography, route, and risk-tolerance requirements.
Processor response	Supported normalized signals such as AVS.

Keep route inputs explicit and observable so a decision can be reproduced without duplicating provider-specific logic in checkout code.

Implementation considerations#

Centralize policyKeep authentication and verification decisions in the route instead of duplicating them across checkout, processors, and fraud tools.Separate score from actionTreat a fraud score as evidence; let the route choose the permitted action for that transaction.Segment deliberatelyDo not apply rules designed for high-value first-time traffic to trusted, low-value repeat customers.

Measure each branch

Measurement area	Useful metrics
Recovery	Recovery rate and authorization uplift for previously rejected traffic.
Customer friction	Challenge rate, abandonment, and conversion impact by segment.
Risk	Fraud rate, AVS mismatch rate, and policy-driven denial rate.
Economics	Processing cost and cost to recover an eligible transaction.

Protect authentication evidence

When 3DS is part of the flow, handle authentication data under current card-network, payment-provider, and compliance rules. Do not depend on long-term storage of cryptographic authentication values such as CAVV or AAV, and do not retain raw cryptograms in merchant logs or analytics.

Treat AVS as one signal alongside customer history, transaction value, fraud evidence, device behavior, and market context—not as the only source of truth.

Production checklist

Every route has an explicit direct, authentication, review, denial, and fallback outcome where applicable.The merchant has confirmed which controls are supported for each production market, method, and processor connection.Timeouts, unavailable providers, abandoned challenges, and uncertain results have safe terminal behavior.Authentication evidence and raw cryptograms are excluded from merchant logs and analytics.Branch-level conversion, fraud, friction, recovery, and cost metrics are available before traffic exposure increases.

What this guide coversAsk Athia about this#

Decision modelAsk Athia about this#

Reference architectureAsk Athia about this#

Architectural interpretation

Choose an authentication controlAsk Athia about this#

Manual reviewAsk Athia about this#

Post-authorization verificationAsk Athia about this#