What a “hosted 3DS2 solution” actually means
A hosted 3DS2 solution is a third party operating the 3DS Server: the component that collects transaction data, formats it into an Authentication Request (AReq), and sends it through the Directory Server to the card issuer. You don’t stand up that infrastructure, register it with EMVCo, or keep it patched against protocol updates. You send transaction data to the hosted service and get an authentication result back.
That’s a narrower claim than most vendor pages imply. Search for “3DS2 hosted solution” and the results are dominated by companies like GPayments, Entersekt, and FinOn, each selling a hosted 3DS Server plus Access Control Server (ACS) to acquirers, issuers, and PSPs. That’s a different buyer than a SaaS or platform team routing transactions across several PSPs, each of which already has its own 3DS implementation. For that team, “hosted” doesn’t mean renting ACS infrastructure. It means not building a separate 3DS integration for every processor in the stack.
Spreedly, a payment orchestration platform, sells directly to this second buyer: “Instead of registering merchant credentials and integrating with different 3D Secure flows per gateway, merchants can sign up via the API and meet SCA requirements across multiple gateways.” That’s the actual shape of the “hosted 3DS2 solution” query: one integration point for authentication, regardless of which PSP settles the transaction.
What you’re buying vs. what you still own: 3DS Server, ACS, and the vault
Three components sit inside the EMV 3-D Secure protocol, and a hosted 3DS2 solution only replaces one of them:
Component Who operates it What it does 3DS Server You, or a hosted provider on your behalf Sits in the acquirer/merchant domain and initiates the AReq. This is what a hosted provider takes off your plate. ACS The card issuer Receives the AReq, evaluates risk, and decides whether the transaction goes frictionless or gets challenged. No hosted 3DS2 solution changes how a given issuer’s ACS behaves. Vault Whoever tokenizes your card data Stores card data as tokens. A separate concern from 3DS2 authentication entirely.
PCI Security Standards Council publishes a dedicated standard, PCI 3DS Core Security Standard, that regulates the ACS, Directory Server, and 3DS Server as three separately-scoped components, which is the clearest confirmation that these are distinct systems with distinct owners.
Authenticating a transaction with 3DS2 says nothing about where the card number itself lives. A hosted 3DS2 solution doesn’t reduce your PCI DSS card-data scope by itself; that reduction comes from tokenization or a checkout flow that keeps raw card data off your servers. Conflating the two is the most common mistake in this buying decision: a provider that hosts your 3DS authentication is not automatically taking on your vaulting or PCI scope.
The maintenance cost of running your own 3DS Server
Building a compliant 3DS Server isn’t a weekend integration. Getting one certified with EMVCo runs through three stages, each with its own fees:
- Register the 3DS product for approval with EMVCo and receive a registration number.
- Run Pre-Compliance Testing, validating the 3DS Server against a recognized EMVCo test platform before submitting for formal review.
- Submit an Implementation Conformance Statement (ICS) and pass formal Compliance Testing.
Each new protocol version (2.1.0 to 2.2.0, and beyond) triggers re-certification. And once it’s running, you’re also inside PCI 3DS Core Security Standard scope directly: baseline security controls covering personnel, network segmentation, vulnerability management, and physical security, plus a second set of requirements specific to protecting 3DS data, cryptographic key management, and logical access to 3DS systems. That’s an audit burden layered on top of whatever PCI DSS obligations you already carry.
Even specialized payments and fraud companies treat this as a multi-year investment rather than a checkbox. Ravelin built its own 3DS Server and SDK in-house, and its own account of the decision reads as a deliberate, resourced bet on owning that infrastructure for the sake of tighter fraud-data integration, not something they backed into by accident. If a team whose core competency is fraud detection treated this as a serious build, it’s a reasonable proxy for what the effort looks like for a team whose core product is something else entirely.
And the certification burden multiplies per PSP if you’re not centralizing it. Run three processors and you either certify your own 3DS Server once and wire it into each PSP’s acceptance flow, or maintain three separate proprietary 3DS integrations, each with its own registration process, data format, and update cycle.
Integration code path: routing 3DS2 through a hosted layer across PSPs
The pattern that solves the per-PSP problem looks the same regardless of which hosted provider sits behind it: one authentication call, independent of which processor settles the transaction.
def authenticate_transaction(txn):
areq = build_authentication_request(
card=txn.card,
amount=txn.amount,
currency=txn.currency,
merchant_risk_indicators=txn.risk_data,
)
auth_result = threeds_service.authenticate(areq)
if auth_result.status == "frictionless":
return route_to_psp(txn, auth_result.eci, auth_result.cavv)
elif auth_result.status == "challenge_required":
return present_challenge(auth_result.acs_url, auth_result.creq)
else:
return DeclineResult(reason="authentication_failed")The application code doesn’t know or care which PSP eventually processes the authorization. It sends transaction and risk data once, gets back an Electronic Commerce Indicator (ECI) value and cryptogram (CAVV) once authentication completes, and passes that result along with the transaction to whichever processor is selected by your routing logic. Without a hosted, orchestration-level 3DS layer, that authenticate_transaction function would need a different branch per PSP, each with its own field names, its own AReq format, and its own way of surfacing challenge URLs.
Data completeness inside that AReq matters more than most integrations account for. Analysis of merchant submissions found that most merchants send only 60-70% of the data fields 3DS2 supports, which measurably lowers issuer frictionless approval rates. That’s a detail worth checking in any hosted provider’s implementation before assuming “3DS2 support” is a uniform feature across vendors.
Where Orchestra fits in the 3DS2 architecture (and where it doesn’t)
Orchestra’s integrations directory lists 3D Secure Support as one of its connection categories, alongside its PSD2 Strong Customer Authentication support for European markets. In practice, that means 3DS2 authentication runs through the same orchestration layer that handles routing and failover: a customer sends transaction data through either the Orchestra API or the Orchestra Library, and Orchestra normalizes the 3DS2 handshake against the connected PSP’s native support, rather than requiring the customer to build a separate 3DS integration for each processor.
That’s the “hosted” claim, precisely scoped: Orchestra sits in the 3DS Server / requestor-side integration role, consistent with the pattern in the code above. Orchestra does not operate the ACS. No vendor in this market does, since that’s issuer infrastructure by definition, and 3DS2 authentication on its own does not change PCI DSS scope. Scope reduction is a function of which Orchestra integration path a customer uses: the Library path handles card collection client-side and keeps that data off the customer’s servers, while the API path leaves card collection, and the associated PCI responsibility, with the customer. A hosted 3DS2 integration through Orchestra doesn’t substitute for that decision.
Where this ties back to compliance work more broadly, Orchestra’s compliance outsourcing service covers PCI DSS Level 1 certification, ISO 27001, and ongoing compliance monitoring across the connected PSPs. 3DS2 authentication is one piece of that, not the whole of it.
Evaluating a hosted 3DS2 provider: questions to ask
A few questions separate a provider that solves the multi-PSP problem from one that just relocates a single-PSP integration:
- Does the provider support your specific PSPs’ native 3DS2 implementations, or does it require the PSP to also adopt the provider’s proprietary flow? Spreedly, for example, offers three distinct modes precisely because PSPs vary in how they expose 3DS2 fields.
- Does the provider send the full set of data elements 3DS2 supports, or a minimal subset? Given how directly data completeness affects frictionless rates, this is worth confirming with actual field-level documentation, not a marketing claim of “3DS2 compliant.”
- What does the provider actually own versus what stays with you? If a vendor’s pitch blurs 3DS authentication, vaulting, and PCI scope together, that’s a sign to ask more specific questions before integrating.
Frequently Asked Questions
What is a hosted 3DS2 solution?
It means a third party operates the 3DS Server component that initiates and manages authentication requests to card networks and issuers, so your team doesn’t build or maintain that integration layer directly. It does not mean the provider operates the ACS, which is issuer-side infrastructure.
Do I still need PCI DSS certification if I use a hosted 3DS2 provider?
In most cases, yes. A hosted 3DS Server handles authentication, not card data storage. PCI scope reduction comes from how card data is collected and tokenized, which is a separate architectural decision from 3DS2 authentication.
What’s the difference between a hosted 3DS Server and an ACS?
The 3DS Server sits on the merchant/acquirer side and initiates authentication requests. The ACS is operated by the card issuer and decides whether to approve frictionlessly or challenge. A hosted 3DS2 solution provides the former, not the latter. No vendor sells a hosted ACS to merchants, since that decision belongs to the issuing bank.
Can a hosted 3DS2 solution work across multiple PSPs?
That’s the core use case: instead of registering a separate 3DS integration with each PSP, one authentication call handles the AReq/ARes exchange, and the result gets passed to whichever processor settles the transaction.
How does a hosted 3DS2 solution affect liability shift?
Liability shift for fraud-related chargebacks (Visa 10.1-10.5, Mastercard 4837/4840/4849/4871, Amex F-series) still depends on successful authentication under the card network’s own rules. Hosting the 3DS Server changes who maintains the integration that triggers authentication, not the liability shift mechanics themselves.
What happens if I skip a hosted solution and integrate 3DS2 myself?
You take on EMVCo certification (registration, pre-compliance testing, and Implementation Conformance Statement-based compliance testing) plus direct PCI 3DS Core Security Standard scope for your 3DS Server. That’s a real, recurring compliance workload on top of whatever you already carry for PCI DSS.
