3-D Secure for Issuing

Overview

When a cardholder pays online, the merchant can ask the card issuer to authenticate the cardholder with 3-D Secure (3DS). For cards you issue on Highnote, Highnote's 3DS service answers these requests on your behalf. Highnote supports EMV 3DS for Visa and Mastercard cards.

Each authentication request ends in one of these outcomes:

• Authenticated without a challenge (frictionless). Highnote's 3DS service finds the risk checks pass, and the cardholder sees nothing.
• Authenticated after a challenge. The cardholder enters a one-time passcode (OTP) that Highnote sends by SMS or email.
• Rejected. The risk checks fail, and authentication does not complete.

The merchant then sends the result with its authorization request, and Highnote approves or declines the authorization as usual. You cannot control the initiation of a 3DS request. The merchant decides when to request it.

Liability shift

3DS shifts fraud liability. When a payment is authenticated, the merchant is protected from most fraud chargebacks, and the issuer is liable for the loss. Your program agreement sets how you bear that loss.

For your program, this means:

• If a cardholder reports an authenticated payment as fraud, Highnote usually cannot charge it back to the merchant.
• A frictionless authentication protects the merchant as fully as a passcode challenge does.

Network	Result on the authorization	Merchant protected from fraud chargebacks
Visa	Authenticated: Electronic Commerce Indicator (ECI) 05 (SECURE_ELECTRONIC_COMMERCE_TRANSACTION) with a valid cryptogram	Yes
Visa	Attempted: ECI 06 (NON_AUTHENTICATED_SECURITY_TRANSACTION_WITH_3D_SECURE) with a valid cryptogram	Yes, except on non-reloadable prepaid cards
Visa	Not authenticated: ECI 07 (NON_AUTHENTICATED_SECURITY_TRANSACTION)	No
Mastercard	Authenticated: ucafCollectionIndicator = UCAF_DATA_REQUIRED	Yes
Mastercard	Merchant supports Universal Cardholder Authentication Field (UCAF) data, typically an attempt or network stand-in: ucafCollectionIndicator = UCAF_DATA_SUPPORTED	Yes
Mastercard	Merchant decides on risk without authenticating the cardholder: MERCHANT_RISK_DECISIONING	No
Mastercard	Later payment tied to an authenticated one: PARTIAL_SHIPMENT_OR_RECURRING_PAYMENT	Yes, if tied to a valid authenticated first payment
Mastercard	Not authenticated: NOT_SUPPORTED or no value	No

For Mastercard, the API exposes one digit of the security level indicator, so this table is a general guide and does not list every ucafCollectionIndicator value. Network rules list other exceptions in which the issuer keeps its fraud chargeback rights, such as certain high-risk merchant categories and a missing or invalid cryptogram. To find these values on a transaction, see Find 3DS results.

When the network answers for the issuer

If you have chosen to not have Highnote enroll your card range in Highnote's 3DS service, or the service is unavailable, the card network can answer the authentication request instead. This is called an attempts response. The merchant still receives the liability shift, except where the table above lists an exception, such as Visa attempted payments on non-reloadable prepaid cards. Where the merchant is protected, the issuer still carries the fraud loss.

On a Visa authorization, an attempts response shows threeDSecureIndicator = ATTEMPTS_SERVER_RESPONDING. If you see attempts responses on your cards, contact Highnote support at support@highnote.com. Highnote can investigate why the 3DS service did not respond.

Choose a risk policy

Highnote's 3DS service checks each request against the risk policy set for the card range. A risk policy takes one of two forms:

Policy	What the cardholder sees	Fits
Frictionless only	Never a challenge. Highnote authenticates or rejects on its risk checks alone.	Programs that cannot reach the cardholder, such as anonymous prepaid cards, and programs that want no checkout friction
Frictionless with challenge	A passcode challenge when the risk checks find elevated risk	Programs that hold a phone number or email address for each cardholder

Weigh the trade-off before you choose:

• Under a frictionless-only policy, the risk checks are the only control between a stolen card number and an authenticated payment, and the issuer carries the loss on most authenticated payments (see Liability shift).
• A challenge adds friction, but when the risk checks call for one, it stops an unauthorized party who does not control the cardholder's phone or email.
• Stricter rules have limits. Network rules limit how many requests an issuer can reject, so Highnote cannot reject all risky traffic.

Highnote can also tailor rules to your program. To review or change the risk policy for your card program, contact your Highnote representative.

Card testing

Unauthorized parties can use 3DS to test stolen or guessed card numbers. Card-testing activity typically involves a high volume of authentication requests for card numbers in a single Bank Identification Number (BIN) range, often in a short burst. Each frictionless authentication gives the unauthorized party a payment that the issuer usually cannot charge back.

Highnote monitors transactions for card testing and can apply stricter checks to an affected card range during a testing event. To limit your exposure:

• Contact Highnote support at support@highnote.com at once if you see a spike in online authorizations or fraud disputes on your cards.
• When an account holder reports fraud, open a dispute and close the compromised card. Issue a new card rather than reissuing it.

Find 3DS results

Highnote records the 3DS result that the card network sends with each authorization. The result appears for frictionless and challenged authentications alike. A field is blank when the network does not send it. For example, Visa often leaves the verification method blank.

• API: Read additionalNetworkData on an AuthorizationEvent or AuthorizationAndClearEvent. It returns VisaData or MastercardData.
• Dashboard: Open the transaction's details page. The Card Network Details section shows the 3DS verification result and the verification method, and for Mastercard the 3DS cardholder authentication. For Mastercard, the method row shows whether the merchant collected 3DS data, not how the cardholder authenticated. The Dashboard does not show the ECI that the liability table uses, so read the ECI from the API.

Network	Field	What it tells you	Example values
Visa	cavvResultCode	Whether the cryptogram passed validation	PASSED, PASSED_VISA_ATTEMPT, FAILED
Visa	threeDSecureIndicator	How the cardholder was authenticated	FRICTIONLESS_RBA, CHALLENGE_OTP_SMS, ATTEMPTS_SERVER_RESPONDING
Visa	motoAndElectronicCommerceIndicator	The Electronic Commerce Indicator (ECI)	SECURE_ELECTRONIC_COMMERCE_TRANSACTION, NON_AUTHENTICATED_SECURITY_TRANSACTION
Mastercard	aavResultCode	Whether the cryptogram, the Accountholder Authentication Value (AAV), passed validation	AAV_PASSED_VALIDATION, AAV_FAILED_VALIDATION
Mastercard	ucafCollectionIndicator	Whether the merchant collected 3DS data, not how the cardholder authenticated	UCAF_DATA_REQUIRED, UCAF_DATA_SUPPORTED, NOT_SUPPORTED
Mastercard	threeDSecureCardholderAuthentication	Whether a token or a certificate was used	CARDHOLDER_CERTIFICATE_NOT_USED, TOKENIZED_PAYMENT

In the Dashboard, a Visa transaction shows two of these fields and a Mastercard transaction shows three. CARDHOLDER_CERTIFICATE_NOT_USED appears on almost every Mastercard online purchase, so it does not show that 3DS took place.

A frictionless Visa authentication looks like this:

Visa frictionless authentication (excerpt of an authorization event)

{
  "additionalNetworkData": {
    "__typename": "VisaData",
    "cavvResultCode": "PASSED",
    "motoAndElectronicCommerceIndicator": "SECURE_ELECTRONIC_COMMERCE_TRANSACTION",
    "threeDSecureIndicator": "FRICTIONLESS_RBA"
  }
}

If the card network reports that the 3DS cryptogram on an authorization failed validation, Highnote declines the authorization with INVALID_3DS_VERIFICATION.

To test these fields, see Simulate a 3DS verification.