CyberSource 3DS: authorization loses the ECI because the connector never reads eci / eciRaw

[MileniumTick]

CyberSource 3DS: authorization loses the ECI because the connector never reads eci / eciRaw

Summary

With CyberSource as the payment connector, a card payment that completes a successful 3-D
Secure authentication is authorized without the commerce indicator, so CyberSource and the
issuer record it as ECI 07 (unauthenticated). The authentication itself works: PARes Y,
CAVV, XID and directoryServerTransactionId are all present. Only the value that carries them
into the authorization is lost.

The connector deserialises a field named indicator from the payer-authentication response.
CyberSource does not send a field with that name; it sends eci, eciRaw and
ecommerceIndicator. indicator is therefore always None.

Affected versions

Checked on v1.125.0, v1.126.0, v1.127.0, v1.128.0 and main: the struct and the
mapping are identical in all of them.

crates/hyperswitch_connectors/src/connectors/cybersource/transformers.rs

// Fields read from the payer authentication response
pub struct CybersourceConsumerAuthValidateResponse {
    ucaf_collection_indicator: Option<String>,
    cavv: Option<Secret<String>>,
    ucaf_authentication_data: Option<String>,
    xid: Option<String>,
    specification_version: Option<SemanticVersion>,
    directory_server_transaction_id: Option<Secret<String>>,
    indicator: Option<String>,   // <- CyberSource never sends this
}

impl ForeignTryFrom<&CybersourceConsumerAuthValidateResponse> for UcsAuthenticationData {
    fn foreign_try_from(value: &CybersourceConsumerAuthValidateResponse) -> ... {
        Ok(Self {
            eci: value.indicator.clone(),   // <- always None
            ...
        })
    }
}

Downstream, ProcessingInformation for the follow-up authorization falls back to the literal
"internet", which is the value that means "not authenticated":

commerce_indicator: three_ds_data
    .indicator
    .to_owned()
    .unwrap_or(String::from("internet")),

and get_commerce_indicator_for_external_authentication() expects the numeric ECI (05, 06,
07), so even a non-empty indicator (a string such as vbv) would take the default branch.

What CyberSource actually returns

Captured from POST /risk/v1/authentications against the CyberSource sandbox, Visa test card
4000000000002701, 3DS 2.2.0, frictionless:

"consumerAuthenticationInformation": {
  "authenticationTransactionId": "zz1DGLmEmxR8ectF0nf1",
  "eci": "05",
  "eciRaw": "05",
  "ecommerceIndicator": "vbv",
  "cavv": "AJkBBkhgQQAAAE4gSEJydQAAAAA=",
  "xid": "AJkBBkhgQQAAAE4gSEJydQAAAAA=",
  "paresStatus": "Y",
  "veresEnrolled": "Y",
  "specificationVersion": "2.2.0",
  "directoryServerTransactionId": "39ab3818-b27c-4c8e-9af2-3b24271a2bdb"
}

Mastercard returns eciRaw: "02", ecommerceIndicator: "spa" and ucafAuthenticationData
instead of cavv.

The authorization as this router sends it today

processingInformation.commerceIndicator = "internet"
consumerAuthenticationInformation.eciRaw = null
consumerAuthenticationInformation.cavv    = <present>
consumerAuthenticationInformation.paresStatus = "Y"

data.is_three_ds() is true, so the 3DS flow did run. The authorization is simply sent as if it
had not.

Minimal fix (18 lines, one file)

Add the three fields and use them:

pub struct CybersourceConsumerAuthValidateResponse {
    // ...existing fields...
    eci: Option<String>,
    eci_raw: Option<String>,
    ecommerce_indicator: Option<String>,
}

// UcsAuthenticationData
eci: value.eci_raw.clone().or(value.eci.clone()).or(value.indicator.clone()),

// ProcessingInformation (complete authorize)
commerce_indicator: three_ds_data
    .ecommerce_indicator
    .clone()
    .or(three_ds_data.indicator.clone())
    .unwrap_or(String::from("internet")),

// CybersourceConsumerAuthInformation
eci_raw: three_ds_info.three_ds_data.eci_raw.clone(),

sent eciRaw is not actually required for CyberSource to honour the authentication: a minimal
authorization carrying only commerceIndicator (vbv / spa / aesk) plus cavv, xid,
specificationVersion and directoryServerTransactionId already returns
processorInformation.consumerAuthenticationResponse.code = 2. So the essential part is
ecommerceIndicator → commerceIndicator.

Verification

With that mapping, three test cards through the full flow (device data collection in a real
browser, then enrollment, then authorization) produced:

Brand	commerceIndicator sent	eciRaw	Authorization	consumerAuthenticationResponse.code
Visa 4000000000002701	vbv	05	AUTHORIZED	2
Mastercard 5200000000002235	spa	02	AUTHORIZED	2
Amex 340000002708	aesk	05	AUTHORIZED	2

Before the change the same flow produced commerceIndicator: "internet", which is ECI 07.

Also worth noting

• hyperswitch-prism (the Unified Connector Service) carries the same mapping up to tag
  2026.09.30.2 and release v0.6.0; the fallback to ecommerceIndicator exists only on its
  main (commit bf871e23). A router pinned to those tags behaves the same way whether it
  routes through UCS or directly.
• #13527 touched this area but for a different case: an externally authenticated
  transaction where the merchant supplies three_ds_data. The native CyberSource 3DS flow still
  loses the ECI.

Why it matters

Without liability shift the merchant absorbs chargebacks on transactions the cardholder did
authenticate. In our case the acquirer (BAC Credomatic) validates a sandbox certification by
looking at the ECI on the authorization, and rejected the integration for exactly this reason.

Happy to open a PR with the change and the connector tests if that is the preferred route; the
patch is small and self-contained.

[Narayanbhat166]

Nice catch, and thanks for the detail. I checked this against main and it matches your report:

• CybersourceConsumerAuthValidateResponse only deserializes indicator; there is no eci / eciRaw field, so UcsAuthenticationData.eci (set from value.indicator) is always None.
• In the authorize path, commerce_indicator falls back to "internet" via three_ds_data.indicator.unwrap_or("internet").

One correction to how I first framed the fix: the ECI → commerce indicator mapping already exists (get_commerce_indicator_for_external_authentication), and it is per card network (e.g. Visa 05 → vbv, Visa 06 → vbv_attempted, Mastercard → spa). So no new mapping is needed. Note also that indicator is currently used two different ways: directly as a commerce-indicator string in the authorize path, and as an ECI in the UCS conversion. A fix would probably add eci / eciRaw to the response struct, feed that ECI into the existing mapper, and stop using indicator for both purposes. I haven't tested this against the CyberSource sandbox, so your Visa and Mastercard captures would make good test fixtures.

Disclosure: I work on self-hosted Hyperswitch deployments at BetterSwitch (betterswitch.io). Happy to help review or test if you open a PR.

[MileniumTick]

Thanks, that is a fair correction and it is the right shape for the upstream fix. Two things I want to add, one of which is a snag in "no new mapping needed".

Agreed: the mapper already exists, and the double use of indicator is the root defect

get_commerce_indicator_for_external_authentication already does ECI + network -> commerce
indicator, and it covers exactly the cases we saw:

eciRaw	Visa	Mastercard	Amex
05	vbv	spa	aesk
02	—	spa	—
06	vbv_attempted	spa	aesk_attempted

So no new table. And you are right that indicator is doing two incompatible jobs: as a literal
commerce-indicator string in the complete-authorize path, and as an ECI in the UCS conversion. It
was never populated by CyberSource either way, so both usages were dead.

Snag: the mapper needs the card network, and complete-authorize does not have it

The external-authentication path calls it as get_commerce_indicator_for_external_authentication(network, eci)
because the ProcessingInformation TryFrom for PaymentsAuthorizeRouterData receives network
as a tuple element:

impl TryFrom<(&CybersourceRouterData<&PaymentsAuthorizeRouterData>, Option<PaymentSolution>, Option<String>)>
    for ProcessingInformation
{
    fn try_from((item, solution, network): (...)) -> Result<Self, Self::Error> {

But the complete-authorize conversion — the one that actually holds
CybersourceConsumerAuthValidateResponse — receives (item, solution, three_ds_data) with no
network:

impl TryFrom<(&CybersourceRouterData<&PaymentsCompleteAuthorizeRouterData>, Option<PaymentSolution>, &CybersourceConsumerAuthValidateResponse)>
    for ProcessingInformation

So reusing the mapper there means the network has to be derived in that conversion (from
item.router_data.request.payment_method_data, which is where the authorize path takes it from
when it builds the tuple). Small change, but it is not a one-line swap.

What we do today

We patch eci / eciRaw into the struct and prefer them, falling back to ecommerceIndicator
and then to internet. I would keep ecommerceIndicator as a fallback even after switching to the
mapper, because CyberSource sends it brand-correct on every response while the mapper's wildcard
arms are lossy: unknown network with ECI 05 falls through to internet, and any ECI outside
00-07 falls to vbv_failure. The field is authoritative; the mapper is the portable path.

One result worth keeping in the PR: eciRaw in the authorization is not what makes CyberSource
honour the authentication. An authorization carrying only commerceIndicator (vbv / spa /
aesk) plus cavv, xid, specificationVersion and directoryServerTransactionId already
returns processorInformation.consumerAuthenticationResponse.code = 2. Sending eciRaw is still
correct for the record, but the essential mapping is ecommerceIndicator -> commerceIndicator.

Fixtures

Happy to hand these over. All three ran the full flow (device data collection in a real browser,
then enrollment, then authorization) against the CyberSource sandbox, 3DS 2.2.0:

Brand	Card	ecommerceIndicator	eciRaw	Result
Visa	4000000000002701	vbv	05	AUTHORIZED, code 2
Mastercard	5200000000002235	spa	02	AUTHORIZED, code 2
Amex	340000002708	aesk	05	AUTHORIZED, code 2

Visa response, trimmed to the fields under discussion:

"consumerAuthenticationInformation": {
  "authenticationTransactionId": "zz1DGLmEmxR8ectF0nf1",
  "eci": "05",
  "eciRaw": "05",
  "ecommerceIndicator": "vbv",
  "cavv": "AJkBBkhgQQAAAE4gSEJydQAAAAA=",
  "xid": "AJkBBkhgQQAAAE4gSEJydQAAAAA=",
  "paresStatus": "Y",
  "veresEnrolled": "Y",
  "specificationVersion": "2.2.0",
  "directoryServerTransactionId": "39ab3818-b27c-4c8e-9af2-3b24271a2bdb"
}

Mastercard returns eciRaw: "02", ecommerceIndicator: "spa" and
ucafAuthenticationData instead of cavv, so it exercises the UCAF branch rather than the
CAVV one — worth a separate fixture.

I can turn these into connector request/response fixtures and open the PR with the struct change,
the network threaded into the complete-authorize conversion, and the mapper call. If you would
rather do the PR yourself I will hand over the JSON as-is, just say which.

Why this matters here

We are mid-certification with our acquirer (BAC Credomatic), and they validate the ECI on the
authorization. Before the fix the flow reported commerceIndicator: "internet" and the acquirer
read it as ECI 07, which is exactly the symptom you confirmed on main.

[Siddharth-Dangi]

Hi @MileniumTick @Narayanbhat166 @neerajkumar-n and team! 👋

I have submitted an upstream fix addressing this issue in PR #15194: fix(connectors): parse and preserve CyberSource 3DS ECI fields (#15108).

Summary of What Was Implemented in PR #15194:

1. Model Deserialization:
   • Expanded CybersourceConsumerAuthValidateResponse to parse ecommerce_indicator, eci, and eci_raw with camelCase deserialization and Serde aliases (ECI, eci_raw, ecommerce_indicator).
   • Retained backward-compatible indicator for existing legacy payloads.
2. Prioritized Fallback Extraction:
   • Implemented helper methods get_commerce_indicator(&self) -> String and get_eci(&self) -> Option<String> with empty-string filtering (ecommerce_indicator -> eci -> eci_raw -> indicator -> default "internet").
   • In ProcessingInformation::try_from, three_ds_data now reliably extracts the authoritative ecommerceIndicator / eci sent by CyberSource, preventing the fallback to "internet" (ECI 07) during complete-authorize and protecting merchant liability shift.
3. UCS Authentication Data Propagation:
   • Updated ForeignTryFrom<&CybersourceConsumerAuthValidateResponse> for UcsAuthenticationData to map eci from eci_raw / eci with fallback to indicator.
4. Verification & Tests:
   • Added a dedicated 7-test suite (crates/hyperswitch_connectors/src/connectors/cybersource/transformers/tests.rs) covering the Visa (vbv, ECI 05) and Mastercard (spa, ECI 02) payloads shared above, raw ECI payloads, legacy indicator fallback, empty-string filtering cascade, and secret masking integrity.
   • All tests pass (cargo test -p hyperswitch_connectors --features "v1,frm,payouts"), and cargo clippy -- -D warnings passes with zero warnings.

Please feel free to review the PR: #15194. Happy to incorporate any feedback or additional test vectors!