**find better title for doc** (in the Word doc Tim provided it’s Sharing Risk Data with Issuers)
- Sharing Risk Data with Issuers?
- Risk Data Sharing (Mastercard DSC and Visa DCAP)?
- 3DS Data Only for Risk Data Sharing
- 3DS Data Only – Risk Data Sharing
- Risk Data Sharing – 3DS Data Only
Overview
Nuvei provides enhanced support for Mastercard Data Share Only (DSO) and the Visa Digital Commerce Authentication Program (DCAP).
Enhanced card-not-present Visa and Mastercard authorization messages with additional risk and transaction data so that issuers can make informed decisions on merchant traffic. The enhancement is backed by the following scheme programs:
- Mastercard Data Share Only (DSO) under the Identity Check program
- Visa Digital Commerce Authentication Program (DCAP), which Nuvei delivers through Visa Intelligent Data Exchange (IDX). **[rewrite]**
Both scheme programs provide rich data (cardholder, device and transaction data) that is passed to the issuer prior to an authorization decision, without the need for a step-up challenge at checkout and with an unaffected user experience. The issuer benefits from an enriched context to base an approval decision on, including how the transaction is priced by the scheme. ** [move to benefits?]**
**feature name?**Benefits
An issuer typically declines a card-not-present transaction because there is insufficient data available to support the authorization decision. By providing the issuer with device, address, and contact context prior to an authorization decision removes a common cause of false declines. For example, Visa publishes an authorization rate increase of 280 basis points if enhanced data is provided and an additional 50 basis points if the full DCAP standard is met.
The same data that supports an approval also supports a decline on genuinely risky traffic.
Both schemes route risk scoring into the decision in addition to merchant data. Fewer fraudulent approvals result in a lower chargeback rate and a healthier position against scheme fraud monitoring thresholds. **[name schemes?]**
Both Visa and Mastercard have restructured pricing so sharing data is less expensive than not sharing data. As of late 2026, sending a card-not-present transaction with no authentication and no data is the most expensive way to transact.
Mastercard DSO
Mastercard DSO is a flow within the Mastercard Identity Check program.
A Mastercard risk data sharing transaction requires collection of the browser data block via the 3DS flow using the threeD input class. DSO is valid for customer-initiated transactions on the app and browser device channels only. There is no DSO equivalent for the 3RI device channel in EMV 3DS 2.2; therefore, DSO does not apply to merchant-initiated or recurring transactions.
Each authentication request must include at least one fully populated and accurate field from each of the following categories, unless prohibited by local regulation:
- Cardholder identifier – Cardholder name; phone number (home, work or mobile); email address
- Address or delivery – Billing address line 1; shipping address line 1
- Technical – Browser or device IP address; device ID; device location (latitude and longitude); SDK app ID
Liability remains with the merchant, exactly as on a transaction sent directly for authorization.
Mastercard DSO Flow
- A transaction is submitted over the 3-D Secure rails carrying a full set of cardholder, address, and device data.
- The Access Control Server receives the merchant data together a Mastercard risk assessment.
- The Access Control Server acknowledges receipt of the data and the risk assessement.
The transaction proceeds to authorization.
Visa DCAP
Visa DCAP is the Visa program for rewarding a merchant that submits enhanced data with a card-not-present transaction.
Visa requirements vary by region. For a transaction to qualify, certain data must be provided.
| Data Category | For Values (one or more) |
|---|---|
| Cardholder Identifier | - cardholder name - phone number (home, work, or mobile) - email address |
| Address / Delivery | - billing address line 1 - shipping address line 1 |
| Technical | - browser or device IP address - device ID - device location (latitude and longitude) - SDK app ID |
Visa DCAP Flow
- Nuvei provides the data to Visa via the Intelligent Data Exchange.
- Visa enriches the authorization message for the issuer with the data and with an DCAP indicator.
Requirements
Data Requirements
Each scheme sets a minimum data standard to qualify. Meeting the minimum is sufficient to participate; however, the best practice is to send as much accurate data as you hold with every transaction so that the decision of the issuer potentially improves with each additional element.
Integration Requirements
Integration
Fields are added to your existing integration through the Nuvei REST API /payment and /openOrder endpoints. No new endpoint is introduced and no change to your payment flow is required beyond populating them.
To qualify for both Visa and Mastercard programs globally you should send all the fields described in the following table.
**check/edit capitalization, formatting etc. in table**
| Parameter | Data Carried by Parameter |
|---|---|
| deviceDetails.deviceManufacturerIdentifier | Device ID or device fingerprint |
| deviceDetails.ipAddress | Browser or device IP address |
| billingAddress.email | Cardholder email address |
| billingAddress.phone | Cardholder phone number |
| billingAddress.address | Billing address line 1 |
| billingAddress.streetNumber | Street number |
| billingAddress.zip | Postal or ZIP code |
| billingAddress.city | City |
| billingAddress.state | State or province |
| billingAddress.addressLine2 | Billing address line 2 |
| billingAddress.addressLine3 | Billing address line 3 |
| billingAddress.country | Country |
The
billingAddress and userDetails parameters provide details in:
- Session Initiation > /openOrder
- REST API >
/payment - Web SDK >
createPayment() - Simply Connect > checkout()
Transaction Flow
To qualify for these programmes all transactions must be submitted as sale3D allowing the full browser data to be collected. Your risk account manager can configure the rules that route qualifying transactions to the data share flow. Optionally this can be driven by including a risk score in the API request to specify which transactions should be processed as data share. The sequence is:
Create InitPayment, with an optional risk score.
Create Payment with all required data elements and the threeD input class.
The transaction is routed to the data share flow, so no challenge is presented to the cardholder.
The risk data is shared with the issuer in the authorization message.
The authorization response is returned, carrying the DCAP indicator on qualifying Visa transactions.
Collecting the device ID
Visa requires a device ID on every transaction to qualify for DCAP in the United States. It is the one mandatory element that is not already part of a typical checkout payload, and a transaction that reaches Visa without it does not qualify, so standard interchange is applied and the benefit is lost.
The value is passed to Nuvei in deviceDetails.deviceManufacturerIdentifier. How you produce it depends on your checkout:
If you have an app, use the device identifier returned by the operating system and place it in that field. This is the simplest case and requires no additional tooling.
If your checkout is web based, there is no operating system identifier to read, so you will need to perform device fingerprinting using the browser information available and generate an ID from it. In practice this means running a client-side script on your checkout page that collects browser and environment signals, such as user agent, language, time zone and screen characteristics, and deriving a stable identifier from them.
If you already use a third-party risk or fraud service, that service almost certainly already mints a device or session identifier. Pass that value straight through in the same API field rather than building anything new.
Whichever route you take, the identifier must be a genuine value derived from the actual session. Do not send a constant, a placeholder or a randomly generated string for each request. Visa assesses the quality of enhanced data, and a field populated with meaningless values is treated as absent, with the added risk of disqualifying otherwise good traffic. If in doubt about the identifier your checkout is producing, ask your Nuvei contact to review a sample of live transactions with you before you enable the feature.
For merchants outside the United States the device ID is not mandatory for Visa, but it remains one of the technical elements that satisfies the Mastercard requirement, so there is value in collecting it wherever you can.
Interchange and scheme fee benefits
Mastercard: two fees you stop paying
Mastercard has deliberately repriced its European fees so that data sharing reduces the fees charged.
The first change is the Authorization Acquirer Exemption Indicator fee charged on Consumer CIT Ecommerce non-3D transactions using the exemption indicator in the authorization message. From 12 October 2026, with first billing on 18 October 2026, the current flat fee of EUR 0.02 is replaced by an ad valorem charge across the EEA and the United Kingdom: 5 basis points on domestic transactions, 10 basis points intraregional and 15 basis points interregional.
Nuvei does not send an exemption indicator in the authorization message for interregional transactions and so the 15bps will not be charged even for merchants not using 3DS/DSO
The fee applies to declined transactions as well as approved ones, with a transaction cap on qualifying transactions above EUR 10,000. Data Share Only transactions sit outside the scope of the charge, so the exemption indicator fee does not apply to them.
The second charge is the No Authentication assessment under the Customer Performance Development Program in the UK and Ireland. From 1 January 2027, with first billing on 28 February 2027, Mastercard applies 5bps to non-3D consumer-initiated e-commerce card-not-present transactions, capped at EUR 50 per transaction, and charged on declines as well as approvals. Data Share Only takes the transaction out of that assessment.
**ADD NEW TABLE IF NEEDED FOR THIS INFO:**
| Mastercard charge | Rate | Effective | Position under Data Share Only |
| Authorization Acquirer Exemption Indicator fee (EEA and UK) | 5 bps domestic, 10 bps intraregional, 15 bps interregional, on approvals and declines | 12 October 2026 | Not applied |
| No Authentication assessment, Customer Performance Development Program | 5bps, capped at EUR 50 per transaction, on approvals and declines | 1 January 2027 | Not applied |
Enablement and configuration
Risk data sharing needs to be configured on an account level. Once you have made the integration changes described above, contact your account manager or Nuvei technical support to request that the feature is enabled.
We strongly recommend not enabling the feature until you are confident that every mandatory data element is being sent on every eligible transaction. Partial data does not produce a partial benefit. A transaction missing a mandatory element simply fails to qualify, is priced at the standard rate, and is not shared with the issuer, so an early switch-on with an incomplete payload delivers nothing. Your account manager can review a sample of your live traffic to confirm the payload before enabling.
Points to be aware of
Liability does not shift. Because no challenge is presented, fraud liability remains with the merchant on both Mastercard Data Share Only and Visa DCAP transactions, exactly as it does on a transaction sent straight to authorization. If a liability shift is what you need, full 3DS authentication remains the route to it, and the two approaches can sit side by side under your risk rules.
PSD2 SCA is not covered by risk data sharing. It is possible you will see soft declines on high value transactions in EEA if attempting to process as data share. Nuvei’s 3DS soft decline cascading can seamlessly recover these for you
Issuer behaviour is not guaranteed. The approval and fraud benefits depend on issuers using the data they now receive. Adoption is good and improving, but performance varies by issuer country
Merchant-initiated and recurring transactions are not supported by both Visa and Mastercard
Next steps
Review the data requirements against what your checkout sends today and identify the gaps, which for most merchants means the device identifier and, in some cases, a complete billing address.
Add the missing parameters to your REST API or Open Order integration.
If you have a web checkout and process Visa in the US, decide how you will generate the device ID, whether through your own fingerprinting, an existing third-party risk service, or with our help.
Speak to your risk account manager about the rules that route qualifying transactions to the non-3D flow.
Ask your account manager or Nuvei technical support to enable risk data sharing on your account, and agree how you will measure the result over the first few weeks.