In the high-velocity landscape of modern e-commerce, software architects and platform engineers face a persistent, dual-sided challenge: how to fortify security and eliminate card-not-present (CNP) fraud without introducing transaction friction that drives cart abandonment. Traditionally, fraud mitigation has felt like a direct compromise against user experience. The more hoops a buyer has to jump through, the lower the conversion rates drop.

Fortunately, the payment ecosystem has evolved. With the emergence of EMV 3D Secure (commonly known as 3DS2), merchants no longer have to choose between a secure checkout and a high-converting one. By implementing a 3D Secure Embedded Checkout with North's low-code ecommerce fraud protection, independent software vendors (ISVs) and merchants can seamlessly integrate the latest payer authentication standards natively into their applications. This developer-focused guide explores the mechanics of EMV 3D Secure, the substantial financial benefits it unlocks, and a step-by-step approach to implementing it within North Embedded Checkout.

While security is universally important, certain business models and transaction profiles benefit disproportionately from a robust 3DS setup:

• High-Risk & Regulated E-Commerce: Specialty merchant categories such as CBD, nutraceuticals, tobacco, and high-risk subscription services frequently face elevated dispute ratios and stricter card network monitoring. By utilizing an automated EMV 3DS integration, these merchants can dramatically lower their dispute rates, ensure continuous card-present and card-not-present processing, and helps reduce fraud ratios monitored under card network compliance programs.
• Enterprise B2B & Complex Payments: On platforms where transactions run into thousands of dollars, a single fraudulent purchase represents a significant financial loss. Implementing low-code ecommerce fraud protection ensures that high-ticket enterprise checkouts undergo strict bank-direct verification, drastically reducing the exposure to unauthorized card-not-present (CNP) fraud.
• Global SCA & PSD2 Compliance: For platforms operating internationally, especially within the European Economic Area (EEA) and the UK, Strong Customer Authentication (SCA) is a strict legal requirement under the Revised Payment Services Directive (PSD2). A compliant SCA compliance payment gateway makes international compliance seamless, helping satisfy regional regulatory requirements for transaction processing without requiring custom code forks for regional regulations.

Integrating a 3D Secure Embedded Checkout introduces immediate, measurable advantages for both software platforms and their end merchants:

1. Fraud Liability Shift for Unauthorized Transactions: This is the single most compelling financial benefit. For fraud-related chargebacks (specifically under Visa Reason Code 10.4 or Mastercard Reason Code 4837) on successfully authenticated transactions, financial liability shifts from the merchant or platform to the card-issuing bank. This applies even when the transaction is completed as a frictionless checkout without additional buyer prompts. The shift covers fraud disputes only; other chargeback reasons, such as a dispute over goods or services, are not affected.

2. Elevated Authorization Approval Rates: Card issuers are historically risk-averse. When an issuer is presented with a standard payment request, they have limited contextual data, which often leads to false-positive declines. However, when a transaction contains verified 3DS authentication payloads via the EPX 3DS API, the issuing bank receives concrete proof that the true cardholder has been authenticated. As a result, authorization approval rates rise significantly, maximizing top-line revenue.

3. Preserved Conversion Funnel: Because modern EMV 3DS relies heavily on silent background data collection, the vast majority of your buyers will never encounter a manual security check. Your checkout conversion funnel remains unobstructed, preventing the cart drop-off associated with forced redirects and manual multi-factor authentication steps.

Step 1: Request and enable 3DS

3DS is off by default and is enabled per checkout, not per session. There is no session parameter to send and no code change to make. To turn it on:

1. Request 3DS. Contact us and tell us which checkout you want 3DS on, the card brands you need (Visa and Mastercard are supported), the currency your merchants transact in (USD), and, if your merchants’ acquiring bank is not North’s sponsor bank, which bank it is.
2. North-side step: review. North reviews your request and confirms the card brands, currency, and acquiring bank.
3. North-side step: enable 3DS on your checkout. North turns on 3DS for that checkout in the North Developer admin.
4. North-side step: CyberSource setup. North looks up each merchant’s CAID and makes sure the merchant’s acquiring bank is configured in CyberSource, North’s 3DS provider.
5. Confirm 3DS is on. Open the checkout in your Embedded Checkouts dashboard. When 3DS is enabled, a Board Merchants with 3DS card appears on the checkout page.

Enabling 3DS on the checkout is only half of the setup: each merchant that uses the checkout must also be boarded to 3DS. See "Boarding Merchants to 3DS" below.

Step 2: Create a Session

Create the session from your server exactly as you do without 3DS. A representative Node.js example (illustrative; see the Integration Guide for every parameter):

To maximize your frictionless rate, give the issuer as much context as you can. The issuer receives the cardholder name, email, and billing address that the shopper enters in the checkout form, so turn those fields on for your checkout in the Checkout Designer. This data comes from the form, not from the session request.

Step 3: Render the Checkout

Include the standard checkout.js script and mount the checkout with the session token. The checkout handles device data collection and, when the issuer asks for it, shows the challenge inline in the iframe. There are no 3DS-specific options or callbacks: 3DS success and failure are handled inside the checkout, and you receive the final result through checkout.onPaymentComplete().

Step 4: What Happens When the Shopper Pays

You do not send or receive any 3DS data. When the shopper authenticates, silently or through a challenge, North keeps the authentication proof on the server, tied to the card used and the amount authenticated. When the shopper submits the payment, North adds the proof to the authorization request sent to the processor, which is what supports the chargeback liability shift. If the amount changes after the shopper authenticates (for example, a tip), the shopper is authenticated again.

As with any Embedded Checkout payment, confirm the result on your server before you fulfill an order. See Handle Checkout Completion.

You run the boarding step yourself from the checkout page: open the checkout and click Board Merchants with 3DS. It boards every merchant on the checkout in one pass, skips merchants that are already boarded, and is safe to repeat.

New merchants

1. Board the merchant to North through your boarding template with Embedded Checkout selected as the Equipment. See Template Setup for Partners & ISVs.
2. The merchant is added to your default checkout in a nightly run, and your Signup Webhook fires when that happens.
3. After the nightly add, open the checkout and click Board Merchants with 3DS.

A new merchant gets 3DS after the nightly add and this boarding step, not when it is first boarded to North. Bank partners who board through WebSuite or by spreadsheet follow the same sequence: the merchant is set up with Embedded Checkout equipment, is added to the default checkout in the nightly run, and then needs the Board Merchants with 3DS step.

Merchants already on Embedded Checkout

1. If the merchant’s MIDs are not in your developer account yet, ask Sales Engineering to make them available. See Migrating to Embedded Checkout.
2. Make sure the merchant is assigned to the 3DS-enabled checkout with Add Merchants. See Manage MIDs.
3. Click Board Merchants with 3DS on the checkout page.

Prerequisites

For a merchant to board successfully:

• The merchant’s CAID must be available. This is a North-side step; North looks it up.
• The acquiring bank must be configured in CyberSource. This is a North-side step; North coordinates it when the bank is not North’s sponsor bank.
• The card brands and currency must be supported. Visa and Mastercard cards in USD. Other brands, such as Amex and Discover, are not supported.

What you see if something is missing

After you click Board Merchants with 3DS, the dashboard shows one of these messages:

• Successfully boarded N merchants to 3DS! The merchants are boarded.
• All merchants are already boarded to 3DS. There was nothing left to board.
• No merchants were boarded. Skipped: … Each merchant was skipped for the reason shown, for example it is a sandbox or inactive merchant, or its registration is still waiting on North.
• Registration is still processing at CyberSource. North confirms the result; nothing further is needed from you.
• 3DS boarding partially completed: X boarded, Y failed. Some merchants are boarded; the rest could not be.
• Failed to board merchants to 3DS. Please verify merchant details. None of the merchants could be boarded.
• No merchants added to this checkout. Add merchants to the checkout first.

The message does not say which prerequisite is missing, and a merchant that fails does not stop the others from boarding. A merchant that could not be boarded keeps processing payments without 3DS. If a merchant still does not board after you try again, contact us with the checkout name and the merchant’s MID, and North will tell you what is missing.

1. Make sure 3DS is enabled on the checkout and that the merchant you test with has been boarded to 3DS.
2. Run each path with the 3DS test cards in the Integration Guide’s test card table: a frictionless success, a challenge, and a failed authentication.
3. Verify that a frictionless payment completes with no extra prompt; that the challenge appears inline in the checkout and completing it completes the payment; that a failed authentication does not complete the payment and your order is not fulfilled; and that checkout.onPaymentComplete() and your server-side payment verification still behave as before.
4. Confirm Board Merchants with 3DS reports that all merchants are already boarded.

Going to production

A checkout that has never been certified goes through the normal certification before it goes live: use Request Publish to submit it to Sales Engineering for review, and test with 3DS enabled first. See Next Steps. Merchants that share an already-certified integration do not need to re-certify to use 3DS.