Dynamic authentication and verification orchestration with DEUNA

Payment orchestration should not stop at choosing a processor.

In many real-world payment stacks, the hardest decision is not only where to send a transaction, but how much authentication or verification should be required before the payment is authorized, retried, approved, or declined.

That is where DEUNA creates leverage.

DEUNA’s routing engine can be extended beyond processor selection to orchestrate dynamic authentication and transaction-verification decisions inside the payment flow. This allows merchants to react to fraud outcomes, issuer behavior, transaction attributes, user context, and gateway response signals by inserting the right control only when it adds value.

The result is a more adaptive architecture:

fewer false positives
less dependence on static reject rules
stronger protection on the transactions that actually need it
better balance between fraud control and conversion
more consistent fraud policy across PSPs and markets

What this guide covers

This page explains how DEUNA can be used to orchestrate authentication and verification controls such as:

Full EMV 3DS authentication
3DS Data Only / Data Share Only patterns
Mastercard passkey-based authentication experiences
Biometric and identity-verification providers such as face-based or device-based verification
Manual review orchestration leveraging fraud-provider analyst review capabilities
Standardized AVS orchestration to normalize issuer address-check responses and apply a universal rejection policy

This is not just a payment routing feature. It is a decisioning architecture where authentication and transaction verification become configurable controls in the merchant’s payment strategy.

📘
The next generation of payment orchestration is not only about choosing the best processor. It is about choosing the best end-to-end transaction path. That path may include no additional step, a lightweight enrichment flow, a full authentication event, a stronger identity-verification control, or a post-response verification decision such as standardized AVS enforcement. DEUNA gives merchants the orchestration layer to make that decision dynamically

Why this matters

Many merchants still operate with a rigid model:

fraud engine says approve → send to processor
fraud engine says reject → decline the payment
gateway returns an AVS response → each PSP exposes it differently and the merchant handles it inconsistently or ignores it

That model is simple, but expensive.

It tends to produce three problems at the same time:

False positives: legitimate customers get rejected because the rule set is too aggressive.
Unnecessary friction: every risky-looking case is treated as equally dangerous, even when a lighter step-up could recover the payment safely.
Fragmented post-authorization controls: AVS and similar response signals vary by gateway, making a unified fraud policy difficult to enforce.

DEUNA allows merchants to replace that binary decision with a more nuanced flow:

approve directly when confidence is high
step up with stronger authentication when confidence is low
use lighter data-sharing paths when the merchant wants to preserve conversion
apply biometric or device-native verification when identity certainty matters more than card risk alone
standardize AVS results and decide whether an authorization should still be accepted or denied based on one universal policy

This is especially valuable for merchants operating across different geographies, issuers, risk profiles, and customer segments.

The DEUNA approach

DEUNA enables merchants to treat authentication and verification as pluggable transaction controls.

Instead of hardwiring one static behavior into checkout, merchants can define routing logic such as:

if the anti-fraud provider approves, continue directly to authorization
if the anti-fraud provider rejects, do not immediately lose the payment
evaluate the reason for rejection, transaction amount, customer trust level, issuer behavior, market, or merchant rule set
dynamically invoke the best authentication step for that scenario
once the payment response returns, standardize issuer and gateway verification artifacts such as AVS and apply a universal policy
re-enter the transaction into the merchant’s decision flow with stronger evidence or richer context

This turns DEUNA into a control plane for both:

payment routing
authentication routing
response verification standardization and policy enforcement

That combination is powerful because it keeps the merchant’s decisioning logic centralized in one orchestration layer instead of scattering it across PSPs, anti-fraud tools, gateway-specific AVS code tables, and custom checkout logic.

Reference architecture

Below is a simple conceptual architecture.

flowchart LR
    A[Checkout / payment intent] --> B[DEUNA orchestration layer]
    B --> C[Risk evaluation inputs]

    C --> C1[Anti-fraud score / reject reason]
    C --> C2[User profile / trust history]
    C --> C3[Amount / product / channel]
    C --> C4[BIN / issuer / market]
    C --> C5[Merchant strategy rules]

    B --> D{Authentication decision}

    D -->|No step-up| E[Send to processor]
    D -->|Full authentication| F[EMV 3DS]
    D -->|Lightweight enrichment| G[3DS Data Only]
    D -->|Device-native auth| H[Passkey flow]
    D -->|Identity certainty| I[Biometric / identity provider]
    D -->|Human validation| Q[Manual review queue]

    F --> E
    G --> E
    H --> E
    I --> E
    Q --> R{Review outcome}
    R -->|Approve| E
    R -->|Reject| O[Automatic transaction denial]

    E --> J[Authorization response]
    J --> K[Raw AVS / gateway response]
    K --> L[DEUNA AVS standardization]
    L --> M{Universal policy}
    M -->|Accept| N[Approve / capture flow]
    M -->|Deny| O[Automatic transaction denial]
    M -->|Escalate| P[Review / alternative action]

Architectural interpretation

In this model, DEUNA sits between checkout intent creation and final payment outcome.

It can ingest signals from multiple systems, evaluate routing logic, and determine whether the transaction should:

continue with no additional step
be enriched with additional data
be stepped up into stronger cardholder authentication
be routed through an additional identity-verification control before payment submission
be routed into a fraud-provider manual review queue when a human decision is more appropriate than an automatic decline
have gateway verification signals such as AVS normalized and interpreted consistently after the authorization response

This is the key architectural difference: authentication and verification are no longer isolated features. They become part of transaction orchestration.

Authentication and verification controls DEUNA can orchestrate

1. Full EMV 3DS authentication

When stronger authentication is required, DEUNA can route the transaction into a full EMV 3DS flow before authorization.

Typical triggers include:

anti-fraud rejection or severe risk score
high transaction value
first-time buyer or weak customer trust signals
suspicious device, velocity, or location changes
issuer, BIN, or market conditions associated with higher fraud pressure
merchant or regulatory requirement for stronger customer authentication

When to use it

Full 3DS is typically the right choice when the merchant wants a stronger proof of cardholder legitimacy before attempting authorization.

It is especially useful when the merchant is willing to introduce some friction in exchange for:

higher confidence in the transaction
better fraud control
potential chargeback and liability advantages depending on network and transaction context

DEUNA design role

DEUNA’s role is not limited to “3DS on or off.”

It can use routing criteria such as:

transaction amount thresholds
issuer or BIN segment
anti-fraud decision code
customer tenure or trust level
merchant vertical or country
fallback behavior after a previous decline

This enables merchants to apply 3DS selectively instead of indiscriminately.

2. 3DS Data Only / Data Share Only patterns

Not every suspicious transaction should be pushed into a full challenge-capable 3DS flow.

In some cases, the merchant wants to preserve conversion while still giving the issuer richer context. That is where Data Only or Data Share Only patterns become useful.

What it is

This is a lighter path where transaction and customer data are shared through 3DS-related rails or program constructs, but the merchant is not performing full cardholder authentication in the same way as a standard 3DS step-up.

When to use it

This path is useful when:

the amount is low or economically tolerant to some additional risk
the transaction is borderline-risky, not clearly fraudulent
the merchant wants to improve issuer decisioning without adding meaningful checkout friction
the goal is to preserve conversion rather than force a challenge
the merchant is willing to retain more fraud exposure in exchange for a lighter user experience

Architecture value

From a DEUNA perspective, this is important because it adds a middle layer between:

hard approve
hard reject

It gives merchants a softer recovery path for transactions that do not justify a full challenge but still benefit from additional issuer context.

In other words, DEUNA can route some traffic to:

full authentication
lightweight enrichment
or no step-up at all

based on the merchant’s strategy.

3. Mastercard passkey-based authentication experiences

Mastercard passkey-based experiences represent a newer authentication model that can reduce reliance on OTP-heavy flows and make security more native to the device.

What it means architecturally

For merchants, this introduces an additional authentication option that may be better suited than traditional challenge patterns in some checkout journeys.

Instead of treating passkeys as a separate product silo, DEUNA can position them as another pluggable authentication branch inside routing logic where ecosystem support exists.

When to use it

Potential use cases include:

suspicious transactions where the merchant wants stronger proof without a traditional OTP experience
card-on-file or returning-user journeys that benefit from device-native authentication
premium UX scenarios where minimizing friction matters but identity strength still needs to be high
markets or programs where strong authentication alignment matters

Why it fits DEUNA well

Passkeys are a strong example of why payment orchestration must evolve beyond processor switching.

A modern merchant may want to decide dynamically:

whether to use 3DS
whether to use a lighter enrichment path
whether to use a device-native authentication method
whether to send directly to authorization

That decision belongs naturally in a routing engine like DEUNA.

4. Biometric and identity-verification providers

Some merchants need stronger identity certainty than card-risk models alone can provide.

In those cases, DEUNA can orchestrate biometric or identity-verification providers as conditional controls inside the payment flow.

Examples include providers that can support:

face verification
liveness checks
device possession checks
identity match against known customer records

When to use it

This is particularly useful in scenarios such as:

account takeover risk
very high-value purchases
suspicious first-time users
regulated or sensitive product categories
merchant flows where the person transacting must be tied more strongly to a known identity

Architecture value

These providers do not need to be forced across all payment traffic.

DEUNA can use them selectively when a transaction pattern justifies a more identity-centric verification step. This makes them economically and operationally viable as part of a tiered decision strategy.

5. Manual review orchestration

Not every risky transaction should be automatically denied, and not every borderline case should be forced into stronger customer authentication.

For some merchants, the right path is to send selected transactions into a manual review queue powered by the fraud platform already in the stack. DEUNA can treat that as another orchestration branch in the payment decision flow.

What it means

In this model, DEUNA routes the transaction to a fraud provider that supports analyst review or case management. The provider can then place the order into a review state so an analyst or fraud operations team can make the final decision.

This is especially relevant for providers such as:

Cybersource Decision Manager, which explicitly supports identifying and reviewing potentially risky orders and provides review-handling patterns after the decision is returned
Accertify, whose platform and recent guidance highlight human expertise, centralized case management, analyst assignment, and escalation rules as part of operating fraud-review workflows

When to use it

Manual review is often appropriate when:

the transaction is high-value or operationally sensitive
the fraud signal is ambiguous rather than clearly fraudulent
the customer is strategically important and the merchant wants to avoid a hard decline
the order contains characteristics that are better judged by a fraud analyst than by a static rule
the merchant already operates a fraud-operations team and wants DEUNA to feed cases into that process

Architecture value

Manual review is not the same thing as EMV 3DS, passkeys, or biometric verification. It is better understood as a human validation path inside the same orchestration model.

That still makes it extremely valuable in DEUNA because the merchant can decide dynamically:

when a transaction should be auto-approved
when it should step up into customer authentication
when it should go to identity verification
and when the best next action is analyst review instead of losing the payment

Typical orchestration patterns

Examples include:

anti-fraud score falls into a review band → send to manual review instead of immediate decline
first-time user with unusually high order value → send to analyst review before capture or fulfillment
suspicious but not conclusive transaction → combine upstream scoring with manual review
unacceptable AVS result on a strategically important order → escalate to review instead of blanket denial
high-risk airline, travel, ticketing, or digital-goods scenario → allow a fraud team to apply merchant-specific judgment

Outcome handling

Once the fraud provider returns a review outcome, DEUNA can route the next step accordingly, for example:

approve and continue to authorization, capture, or fulfillment according to the merchant flow
reject and stop the transaction
escalate to a stronger authentication or identity-verification path if the merchant wants a hybrid model

This is one more reason DEUNA is not only a processor router. It becomes the coordination layer between automated fraud systems, human review operations, and payment execution.

6. AVS orchestration and standardized AVS management

The Address Verification Service (AVS) is a core fraud-control signal that checks whether the billing address submitted by the customer matches the address on file with the issuing bank.

The challenge for merchants is not whether AVS is useful. The challenge is that PSPs and gateways expose AVS differently:

each PSP may return its own raw AVS code set
response semantics vary by gateway and acquirer
merchants end up maintaining fragmented mappings and inconsistent decision rules

DEUNA simplifies this by treating AVS as a standardized orchestration layer, not just a gateway-specific field.

What DEUNA does

When transactions are processed through supported PSPs and AVS data is returned, DEUNA can:

retrieve the raw AVS response from the PSP or gateway
normalize that response into a single DEUNA AVS code model
let merchants define one universal fraud policy using DEUNA AVS codes
automatically apply that policy across every configured payment strategy that receives AVS data

This gives merchants a single, consistent fraud-control language instead of maintaining one AVS interpretation per provider.

Why this matters architecturally

AVS is not a replacement for 3DS or identity verification. It plays a different role.

AVS is best understood as a verification signal returned in the payment response path that can still materially affect the final transaction outcome.

That makes it highly valuable in a DEUNA architecture because merchants can combine:

pre-authorization controls, such as fraud scoring and step-up authentication
post-response controls, such as standardized AVS interpretation and automatic denial rules

This creates a more complete decision stack.

DEUNA AVS standardization

Different gateways expose AVS differently, which makes a unified fraud strategy difficult.

DEUNA solves this by standardizing raw provider AVS codes into a common set of DEUNA AVS codes that are easier to understand and easier to operationalize.

That standardization allows merchants to create one fraud policy that can be reused across multiple gateways without rebuilding logic for each one.

Automatic transaction denial

One of the strongest uses of DEUNA AVS is the ability to automatically stop transactions that appear too risky, even when the gateway or processor would otherwise accept them.

For example, merchants can configure specific DEUNA AVS codes to:

always allow
always deny
escalate for downstream action, such as review, alternative routing, or additional verification

This means the merchant’s policy can override blind gateway acceptance when the AVS outcome does not meet the merchant’s tolerance for risk.

When to use it

AVS orchestration is especially useful when merchants want to:

enforce one fraud policy across multiple PSPs
reduce gateway-specific AVS code handling inside application code
block risky address mismatches quickly and consistently
combine billing-address verification with broader risk and authentication strategy
improve fraud control without forcing stronger authentication on every transaction

Positioning AVS inside a DEUNA strategy

A strong pattern is to use AVS as a complementary layer alongside dynamic authentication.

For example:

low-risk transaction + good AVS result → approve normally
moderate-risk transaction + weak AVS result → deny or escalate according to policy
anti-fraud reject + merchant wants recovery path → step up with 3DS before authorization
approved authorization + unacceptable AVS result → automatically deny based on DEUNA AVS policy

This is where DEUNA adds real architectural value: authentication decisions and payment-response verification can both live in the same orchestration model.

Set auto-denial rules in DEUNA Admin

A typical operational flow can be documented as:

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, that policy can be applied consistently across transactions processed through supported strategies where AVS data is available.

How solution architects should think about this

A good implementation is not “add more authentication everywhere.”

A good implementation defines a decision ladder.

Recommended decision ladder

Level 1 — Direct authorization
Use for low-risk, trusted, repeatable patterns where conversion should remain as frictionless as possible.

Level 2 — Lightweight enrichment
Use Data Only / Data Share Only paths when issuer context is useful but a full challenge is too expensive for conversion.

Level 3 — Strong cardholder authentication
Use full 3DS when risk increases materially or when stronger cardholder proof is required.

Level 4 — Human validation
Use manual review when the signal is ambiguous and a fraud analyst can make a better business decision than a static rule.

Level 5 — Stronger identity certainty
Use biometric or identity-verification controls when the transaction requires confidence beyond standard payment-layer checks.

Level 6 — Response verification enforcement
Use standardized AVS policy enforcement to decide whether an authorization should still be accepted, denied, or escalated after the payment response returns.

This tiered model helps merchants avoid three common architecture mistakes:

overusing strong authentication on traffic that does not justify it
underusing recoverable step-up paths and defaulting to hard declines
letting gateway-specific AVS semantics fragment fraud policy across providers

Example decision patterns

Pattern A — Recovering anti-fraud rejects

Objective: rescue good transactions that would otherwise be declined.

Example policy:

if anti-fraud rejects and amount is high → trigger full 3DS
if anti-fraud rejects and amount is low → attempt Data Only path
if anti-fraud rejects and merchant has strong returning-user confidence → try passkey-enabled path where supported
if anti-fraud rejects and user identity certainty is critical → trigger biometric verification

This is one of the clearest examples of DEUNA’s value: a fraud reject does not have to be the end of the transaction.

Pattern B — User-trust segmentation

Objective: avoid applying the same rules to every customer.

Example policy:

trusted repeat user → direct authorization or lightweight enrichment only
repeat user with abnormal device or geo behavior → passkey or 3DS
first-time user with high basket → full 3DS
first-time user with identity-sensitive purchase → biometric verification

Pattern C — Cost-aware authentication strategy

Objective: align authentication depth with transaction economics.

Example policy:

low-value basket → preserve UX, use light enrichment first
medium-value basket with moderate risk → selective 3DS
high-value basket or high-margin fraud target → stronger step-up by default
strategically important but ambiguous order → manual review instead of automatic rejection

This helps merchants avoid applying the cost of strong authentication uniformly across all traffic.

Pattern D — Manual review for ambiguous transactions

Objective: avoid unnecessary declines when a human analyst can add value.

Example policy:

if fraud provider returns review-range score → send transaction to manual review
if high-value first-time order has mixed signals → route to analyst queue
if review approves → continue according to merchant flow
if review rejects → deny transaction or block fulfillment

This is especially useful for merchants that already operate fraud analysts and want DEUNA to orchestrate the handoff instead of treating review as an entirely separate system.

Pattern E — Universal AVS rejection policy across PSPs

Objective: standardize billing-address risk handling across providers.

Example policy:

if gateway returns AVS code that DEUNA maps to full match → allow
if gateway returns AVS code that DEUNA maps to partial mismatch → evaluate according to merchant policy
if gateway returns AVS code that DEUNA maps to high-risk mismatch or unavailable pattern that the merchant has blocked → automatically deny
if merchant wants softer handling for some segments → escalate to review or downstream action instead of blanket denial

This allows the merchant to manage one AVS policy across payment gateways instead of building one code table per integration.

Pattern F — Combined authentication, review, and AVS decisioning

Objective: use different controls at different moments of the transaction flow.

Example policy:

anti-fraud rejection before authorization → recover with 3DS
successful authorization with unacceptable AVS result → deny post-response according to DEUNA policy
trusted repeat user with strong history and acceptable AVS → approve with minimal friction
first-time user with weak address match and high basket → stronger step-up or stricter denial posture

This pattern demonstrates that the best fraud strategy is often not one control, but several coordinated controls under one orchestration layer.

Inputs DEUNA can use in routing logic

A robust implementation usually combines multiple inputs rather than relying on one risk score alone.

Typical inputs include:

anti-fraud decision, score, or reject reason
customer history and trust level
payment amount and basket profile
product type or fraud sensitivity of the order
BIN, issuer, card type, or country
device or session anomalies
velocity patterns
merchant vertical policies
geography-specific requirements
historical approval or fraud outcomes by segment
AVS results returned by supported PSPs or gateways
fraud-provider review bands, queues, or manual-review outcomes

This allows DEUNA to act as a centralized decision engine instead of hardcoding logic inside each provider integration.

Implementation considerations

1. Keep decisioning centralized

Authentication and verification policy should live in the orchestration layer, not be fragmented across frontend code, PSP settings, and fraud tools independently.

2. Separate risk scoring from action selection

A fraud score by itself does not define the best action.

The orchestration layer should translate risk signals into the right action for that transaction, such as:

approve
enrich
step up
verify identity
apply AVS-based denial or escalation
route to manual review
retry or fallback

3. Design for observability

Merchants should measure the performance of each branch, including:

recovery rate of previously rejected transactions
authorization uplift by authentication path
fraud rate by path
challenge rate and abandonment rate where applicable
conversion impact by user segment
AVS mismatch rate by PSP and segment
denial rate driven by standardized AVS policy
cost-to-recovery economics

4. Avoid static one-size-fits-all rules

A rule that performs well for high-value first-time users may be harmful for low-value repeat customers.

DEUNA is most effective when merchants segment strategy by risk and business context.

5. Treat authentication artifacts carefully

When 3DS is part of the flow, implementations must handle authentication data under current scheme, processor, and compliance rules. Public designs should avoid depending on long-term storage of cryptographic authentication values such as CAVV or AAV for later consultation. Your attached PCI/CAVV reference explicitly notes that the cryptogram may continue to be sent in the online authorization request, but should not be stored for later lookup.

6. Treat AVS as a signal, not as the only source of truth

AVS is valuable, but it should not be interpreted in isolation.

The best implementations evaluate AVS together with:

user history
transaction value
anti-fraud score
device behavior
market-specific fraud patterns

This is exactly why AVS belongs inside an orchestration model rather than as a standalone hardcoded gateway rule