Skip to content

    3DS: What We’ve Learned Implementing 3D Secure with Merchants

    3DS Transaction Workflow Graphic

     

    3D Secure (3DS) is so effective at preventing fraud, sometimes it feels like it’s preventing transactions altogther—including the merchant’s own implementation.

    Nevertheless, 3DS is the unsung hero of modern payment authentication—essential for preventing fraud—yet often overlooked until absolutely needed. After building this as a feature at Basis Theory—and helping several merchants implement 3DS—I learned to never underestimate how complex (and sometimes confusing) it can be for merchants and developers. So, I’m sharing my takeaways from implementing 3DS with multiple merchants because we need to better set expectations before implementing 3DS.

    Agnostic 3DS will never be a “click button” solution—and if it is, life will be harder because of it. 

    Let me explain…

    When Abstraction Becomes an Obstacle 

    Maybe the biggest surprise when implementing 3DS was discovering how little practical knowledge is available about it! This would include artificial intelligence, which is viewed as the ultimate search tool and knowledge index. But with no straightforward answers, 3DS has turned out to be more complicated than that.

    What I mean is, many Payment Service Providers (PSPs) abstract nearly everything behind their APIs, which leaves merchants—and even some developers—unaware of the underlying complexities. This abstraction can be a double-edged sword: simplifying the merchant’s day-to-day, but it also breeds confusion when you need to implement, customize, or switch 3DS solutions.

    Everyone loves a good abstraction—until it hides essential details you need for troubleshooting or integration with third-party services. Merchants aren’t even able to provide their own registered merchant IDs. Obtaining this information can be the longest element of a 3DS implementation. 

    Many 3DS implementations deviate from formal specs to create “custom” solutions that claim to simplify the process. In reality, these solutions can deviate just enough to break compatibility with other systems or hamper your ability to port 3DS logic across PSPs. This is especially frustrating for merchants who want more control or wish to personalize their own payment flows. Suddenly, you find yourself hunting for transaction data or cardholder information that your PSP handled in the past. 

    That lack of visibility ultimately stifles flexibility. Own your knowledge base and all the details from each acquirer or PSP. A smooth 3DS process hinges on accurate data about the merchant, the cardholder, and the transaction itself.

    Return to Top

    A Maze of Documentation 

    The documentation for 3DS can feel like a labyrinth—full of twists, dead ends, and expected challenges. From version 1.0 to 2.0, there are significant changes in flow, technical requirements, and data points. Worse still, each PSP or acquirer tends to put their own spin on the docs, often straying from standard terminology or rearranging steps in the authentication flow. 

    For merchants who have only seen 3DS “just work,” diving deeper can be daunting.

    • 3DSv1 vs. 3DSv2: With 3DSv1, the user experience was often clunky—think static password pages and confusing redirects. 3DSv2 aims to improve by requiring more data to authenticate seamlessly, but merchants must provide significantly more information about the customer and transaction.
    • Proprietary Twists: PSPs frequently bundle their own unique “enhancements.” While these might help in some cases, they can also lead to confusion when comparing implementations across providers or when trying to move to an “agnostic” 3DS solution.

    But what happens when your PSP has always handled data collection behind the scenes? When you switch providers or attempt to implement 3DS in-house, you realize you may not have direct access to key info. This leaves merchants scrambling to gather merchant information, purchase history, or customer identifiers to pass along to the 3DS rails. Without these details, your authentication rates or conversions can suffer.

    At Basis Theory, we've shifted away from traditional 3DS implementation documentation, which typically includes lengthy lists of more than 50 properties accompanied by minimal context. 

    Instead, we've embraced a more guided approach. Our documentation doesn't just clarify technical details—it helps effectively engage Payment Service Providers (PSPs) to obtain the right values, provides tailored guidance based on your specific business and transaction types, and shares actionable recommendations to achieve higher transaction success rates.

    3DS is really 80% setup, 20% implementation. Getting 3DS to work is one thing—gettng the best results is another. We believe we’re able to help with both. 

    Return to Top

    The Data Dilemma: Merchant, PSP, and Cardholder Information 

    How 3DS works

    Part of the confusion also stems from not knowing who is responsible for which piece of the puzzle:

    • Merchant: Responsible for initiating 3DS, providing transaction and customer data, and ensuring compliance with the card brands’ rules.
    • PSP/Acquirer: Typically provides the payment gateway, handles the connectivity to card networks, and implements risk checks.
    • Issuer: Ultimately makes the authentication decision, often leveraging the card network’s 3DS server.
    • Card Network: Oversees the overall 3DS specification, ensuring global adoption standards are met.

    When something goes wrong—be it a technical glitch or a missing piece of information—the bigger challenge is identifying who should fix the issue. This lack of clarity only grows when each party’s documentation looks (and reads) differently.

    At Basis Theory, we believe 3DS shouldn’t (completely) be a black box. Our platform streamlines external or agnostic 3DS by giving a merchant the control over tokenized card data, compliance-friendly storage, and secure data exchange—without locking into a single PSP’s ecosystem. 

    When it comes to 3DS, Basis Theory is able to help a merchant:

    • Retain Data Ownership: With tokenization you control, you’re never held hostage by a PSP’s proprietary rules.
    • Simplify Integrations: Our developer-friendly APIs and transparent documentation make it easy to embed 3DS in an existing flow without entirely abstracting away information that you may need when switching providers.
    • Enhance Security and Compliance: We meet the latest PCI and data protection standards, so you can innovate without compromising security.

    Understanding how 3DS works is key to unlocking smoother payment flows and better fraud protection. By using an agnostic approach, merchants can break away from the walled gardens that many providers create, freeing themselves to choose the PSP or acquirer that best fits their evolving needs. Whether you’re a seasoned developer or a merchant stepping into the world of 3DS for the first time, gaining visibility into the process and owning your data is well worth the effort.

    Return to Top

    Stay Connected

    Receive the latest updates straight to your inbox