The 3DS Sunset Playbook: Migrating to Visa Payment Passkey and Mastercard Identity Check Before September 2026

The September 2026 Visa Digital Authentication Framework (DAF) sunset is now five months out, and Mastercard is running a parallel deprecation track for legacy 3DS endpoints. Most merchants we talk to know this is happening; far fewer have confirmed that their actual processing path — gateway, PSP, cart platform, mobile SDK — will land on the new authentication surface cleanly when the cutover happens.

This is the playbook we use with our merchants and ISO partners. It assumes you have card-not-present volume meaningful enough that an authentication outage would matter, and that you'd rather discover the gaps now than discover them in a chargeback review six months from now.

1. What's actually changing

On the Visa side, DAF is the authentication framework that has underpinned 3DS protections for the better part of a decade. Its successor — Visa Payment Passkey — is built on the FIDO passkey standard, with biometric or device-bound authentication replacing the SMS-OTP and password fallbacks that DAF tolerated. The user experience is materially better: native biometric prompts, no SMS delays, no manual code entry. The merchant experience is materially different: new SDKs, new authentication responses, new liability-shift mechanics.

Mastercard's Identity Check is the parallel track. Identity Check has existed for years, but the 2026 push consolidates it as the default step-up surface, deprecates legacy 3DS 1.x endpoints, and aligns the cardholder experience with the same biometric/passkey patterns Visa is moving to. The endpoints, SDKs, and authentication-response shapes are different from Visa's — merchants need to plan migration on both tracks in parallel rather than treating it as one project.

2. What breaks if you do nothing

If your processing path still depends on DAF-era 3DS endpoints when the sunset lands, the practical consequences cascade through your payment stack:

• Authentication requests fail or fall through unauthenticated. Depending on your gateway's fallback behavior, requests either error out (worst case — visible declines) or proceed unauthenticated (silent — but you lose the liability shift).
• Liability shift evaporates on disputed transactions. Chargeback protection that depends on a successful authentication response stops applying. Merchants typically notice this 30–60 days later when chargebacks start landing on transactions that "should" have been protected.
• Issuer-side step-ups get inconsistent. Issuers increasingly route step-up authentication exclusively through the new surfaces. Your cardholders end up in inconsistent flows — some get a clean Passkey/Identity Check prompt, others get nothing and the transaction declines for authentication-failure reasons that don't make sense from the cardholder's perspective.

3. The migration sequence we recommend

The work is genuinely cross-functional — gateway, PSP, mobile SDKs, cart platforms, fraud rules, customer-service training. We sequence it like this:

1. Inventory. Map every place in your stack that participates in a 3DS exchange today. Web checkout, mobile app, recurring-billing rebill flows, agent-channel MOTO transactions, hosted payment pages from PSPs. Each one is its own migration scope.
2. Confirm gateway and PSP roadmaps.Ask each provider for their cutover date, their SDK version targets, and whether they'll be running both authentication paths in parallel or doing a hard cut. The answer determines whether you can migrate progressively or need a coordinated all-at-once switch.
3. Update SDKs and endpoints. The web side is typically straightforward — script tag updates plus minor response handling. Mobile SDKs are slower; iOS and Android updates touch the app store release cycle, and field rollout takes weeks even after a release ships.
4. Validate liability-shift response shapes. The new authentication responses carry the liability-shift indicator differently than DAF did. If your fraud / dispute-evidence pipeline reads authentication results, it needs to be updated to read the new fields — this is the most commonly missed step.
5. Test cardholder fallback flows.What happens when a cardholder's device doesn't support Passkeys, or biometrics fail, or the issuer falls back to a one-time code? The cardholder experience in those cases is where conversion is won or lost.
6. Update operational tooling.Customer-service scripts, dispute-representment evidence templates, fraud-rule thresholds tied to authentication signals. The migration isn't finished until your operational tooling reflects the new authentication signals.

4. The places merchants get caught

Three patterns account for most of the migration trouble we see:

• Inherited PSP integrations on legacy versions. Merchants who integrated with their PSP three or four years ago and haven't touched the integration since are frequently on SDK or API versions that don't support the new authentication paths. The PSP may have published a newer integration that does — but switching requires real engineering work, not a configuration toggle.
• Mobile-app release cadence mismatched with the deadline. Apps that release every two months end up needing the authentication SDK update in their May or July release to land before September. Apps that release quarterly or slower need to plan even further ahead.
• Recurring-billing rebill flows.Subscription merchants often authenticate on the initial signup and rebill against a credential-on-file framework that doesn't exchange 3DS messages on every transaction. The authentication update may be invisible day-to-day — until a dispute lands and the representment evidence needs to cite the original authentication, which now lives in a different shape.

5. What good looks like at September 2026

A merchant who's done the migration cleanly looks like this in October 2026:

• Authentication success rate flat or improved versus pre-sunset.
• Liability-shift coverage on disputed transactions unchanged or expanded.
• Cardholder-side authentication friction reduced (Passkeys beat OTPs measurably on completion rate).
• No spike in authentication-failure declines in the 30 days following cutover.
• Dispute-representment evidence templates updated to cite the new authentication response fields.

How Superior Payments helps

Superior runs an authentication-readiness audit across each of the surfaces in your processing path — gateway, PSP, mobile SDKs, cart platform, fraud pipeline. The audit returns a prioritized punch list of integrations that need updates, with version targets and the liability-shift response-shape changes flagged explicitly. For merchants who'd rather have us run the migration than the audit alone, our integrations team can coordinate the work across PSPs and platforms directly.