Choosing a 3DS Server: Where Five Vendors Sit in the Chain and What Each Actually Covers

Choosing a 3DS Server: Where Five Vendors Sit in the Chain and What Each Actually Covers

"We need to pick a 3DS Server" — when that sentence appears in a procurement meeting, people are frequently not discussing the same thing. 3DS is not a product but a chain: merchant and acquirer → 3DS Server → card network Directory Server → issuer ACS → result returns along the same path. Every link is supplied by a different vendor, and merchants usually touch only the 3DS Server directly — or only use it indirectly inside their acquirer or gateway; the Directory belongs to the card network, and the ACS is built or bought by the issuer.

So the real question is not "which 3DS Server is stronger" but three things: which link you stand on, whether you are buying compliance or conversion optimisation, and whether you have local deployment or data residency requirements. For the mechanics of flows, exemptions and liability shift, see 3D Secure 2 authentication in practice. This article answers one thing: who supplies what on this chain, and how should you screen them.

1. Locate first: you can really only choose two of the links

1.1 Where each of the five sits

The second column is what makes the table readable. If you are an ordinary merchant, the third, fourth and fifth vendors are mostly not aimed at you — their customers are issuers, acquirers and government agencies. The only link you can genuinely buy is the 3DS Server itself, and that link is often already included in your acquirer's or gateway's service.

1.2 Why "choose a 3DS Server" is imprecise

Because the 3DS Server's job is to assemble and sign the merchant request according to card network specifications, send it to the Directory, and handle the result. It is a courier for messages and flows, not the arbiter of experience. Experience is decided at both ends: the challenge page is whatever the issuer's chosen ACS renders, and whether frictionless applies is decided by the issuer's risk model and its regulatory exemption stance.

That leads to a counterintuitive conclusion: selection at this link can mainly optimise integration coverage, version compatibility and speed of integration — not approval rates. Load your approval-rate expectations onto the 3DS Server and you will end up with a system that is technically flawless and commercially inert.

2. What each of the five actually covers

2.1 Netcetera: both ends of the hub, but you are probably not its customer

Netcetera (G+D Netcetera as the site brand, Netcetera AG of Zurich as the entity) is the only one of the five offering both a Directory Server and an Issuer Service. Those two roles are the hub of 3DS; most vendors do one end, and doing both means deeper accumulated experience in specification implementation and card network certification.

Its 3DS line has five components: Directory Server, Issuer Service, Quality Assurance Platform, 3DS SDK and 3DS Server. Shipping quality assurance as a standalone product is a revealing detail: what slows 3DS projects down is rarely business logic but card network certification and integration testing, and a vendor that productises this has clearly run a lot of projects.

It also carries a decisive limitation: merchants usually cannot buy from it directly, because Directory and Issuer customers are issuers, acquirers and networks. That leads to the more important point — whichever 3DS Server you choose, the ACS on the issuer side is not your decision, and quite possibly is a product from exactly this type of vendor.

2.2 Entersekt: selling authentication context, not a 3DS server

Headquartered in South Africa and describing itself as "the financial authentication company", Entersekt delivers all three 3DS roles — ACS, 3DS Server and Server Directory — as separately orderable pieces, but that is just one layer of a five-layer architecture.

Its real differentiation lies elsewhere: authentication context that can be reused across channels. Device fingerprints, login history, behavioural traces and call-centre interactions on the bank side all become inputs. Many 3DS vendors make decisions only at the moment of the transaction, whereas Entersekt argues that the institution already knows this person before the transaction starts. For businesses with a login state, that gives frictionless rates room to improve — which is how it turns 3DS from a compliance switch into a conversion tool.

This advantage is highly sensitive to the scenario. Guest checkout with no login state, large B2B transfers, or agent-initiated orders all dilute it sharply. And the honest caveat remains: however well your 3DS Server is configured, the challenge UI and authentication pass rate stay substantially outside your control.

2.3 Outseer: combining decisions, intelligence and takedown

Outseer positions itself as an all-cause fraud prevention platform covering scam, payment and account takeover risk, built on a risk engine plus a cross-institution global data network.

Its differentiation is not 3DS itself but putting 3DS decisions, fraud intelligence and 24/7 takedown of online attacks on one platform. Handling counterfeit sites, phishing domains and malicious apps requires continuous work across time zones and jurisdictions, and that is a scarce capability; when your problem is not "occasional card testing" but "an organised group attacking the brand", intelligence and takedown outweigh the decision engine.

Conversely, if your problem is genuinely sporadic fraud and card testing, the intelligence and takedown parts go unused. It fits banks and institutions with a brand attack surface better than a merchant that simply needs to pass 3DS certification.

2.4 Modirum: a project-based engineering contractor

Modirum is an Estonian group spanning fintech and broadcasting among other fields, with public figures of 25+ years, 50 countries covered and 15 governments served. Its role on this chain is engineering contractor, not a merchant-facing tool vendor.

Read "project-based" precisely: requirements can be customised, and interfaces, reporting and compliance evidence can all be negotiated, at the cost of no room to experiment — a SaaS product can be piloted then expanded, while a project contract locks scope at signature. Its other strength is that 3DS and PKI/security come from the same root: the authentication layer rests on key management, signing and certificate lifecycle, and it covers that too.

The conditions for choosing it are specific: institutions with data residency, on-premise deployment or public procurement requirements. Those institutions generally cannot use SaaS, and vendors of this shape can deliver local deployment and sovereignty compliance.

2.5 mSIGNIA: the only pure tooling vendor that never touches a transaction

mSIGNIA is the only one of the five that neither touches transactions nor carries risk. It ships two lines: Payment Simulator (end-to-end payment testing for continuous testing and prototyping by product teams, demonstrations by sales, and verification of third-party implementations by PSPs) and 3-D Secure Split SDKs (a white-labellable EMV 3DS authentication SDK on 3DS v2.3 covering web, iOS and Android).

It is the key to understanding what tooling vendors are worth: their value is not that any link becomes stronger, but that building the chain becomes faster. The Split design exists to break one large integration into steps so merchants connect faster. For 3DS Server vendors and PSPs, a white-label SDK removes the work of adapting three platforms separately.

But its boundary belongs up front: it does not raise approval rates, does not change pricing, and does not process transactions. No approval-rate expectation belongs on this category, and you still need your own 3DS Server and compliance regime — the SDK is a component added to an existing Server. Payment Simulator's value is equally specific: compressing integration and card network certification cycles, not improving live performance.

3. Three prerequisite questions that decide whether these five apply

3.1 Are you a merchant, an acquirer or an issuer

This is the most effective filter. Merchants: the only real choice is the 3DS Server link, often already bundled with the acquirer, where independent procurement mainly buys version currency and integration speed. Acquirers: need 3DS Server and quality assurance, putting Netcetera and Entersekt on the list. Issuers: need an ACS, putting Entersekt and Modirum on the list, with Netcetera's Issuer Service alongside.

3.2 Do you want compliance connectivity or conversion optimisation

The two goals produce entirely different shortlists. To satisfy a regulatory requirement, any card-network-certified 3DS Server will do, and selection focuses on version tracking and integration speed. To turn 3DS into a conversion tool, you have to move upstream — either through a login state and identity layer (Entersekt's territory) or through stronger risk decisioning (Outseer's), which usually means you are no longer buying a 3DS Server.

3.3 Do you have local deployment or data residency requirements

Once on-premise deployment, public-sector compliance or data localisation enters the picture, SaaS candidates drop out and project-based local delivery becomes a hard gate. That is the one scenario where a vendor like Modirum cannot be substituted.

4. The dimensions that actually work (there are four)

4.1 Card network certification and version currency

Card networks drive the specification, and each version brings new fields, flows and exemption rules. Confirm the implementation holds current valid card network certification, and ask about the upgrade cadence — not "do you support v2" but "how long does it take you from a new specification version to delivery".

4.2 Three-platform coverage and integration method

Whether web, iOS and Android need the same implementation determines integration effort. A hosted page is easiest but loses control of experience; an embedded SDK is coherent but needs three adaptations; assembling messages yourself gives the most control and demands the most from the team. The value of each path differs by business stage.

4.3 Fit with your existing risk and identity stack

If you already run a fraud vendor and an identity system, 3DS decisions must be able to talk to them, otherwise two judgments contradict each other in production: risk blocks the transaction while 3DS lets it through frictionless. For how the layers relate see ordering the 3DS, risk and chargeback layers; for vendor selection at the risk layer see choosing a third-party fraud prevention vendor.

4.4 Who owns an authentication failure

This is the least-asked question and the one that most affects daily operations. Who defines the error semantics, how timeouts are handled, whether retries are allowed, and what you can see when a user is stuck on a challenge page — all of it determines whether support and engineering can diagnose problems quickly. If the answer is only "it returns a failure", you will fill the gap with support tickets.

5. One premise to accept: experience is not fully yours

This is the most important sentence in the article: challenge page form, frictionless pass rates and authentication failure semantics are substantially determined by the issuer's ACS and the network Directory rules, not by the merchant.

Three practical conclusions follow. First, frictionless rates cannot be forced up by buying a product; they result from risk model thresholds and regulatory exemption scope (for how low-value exemptions, trusted beneficiaries and SCA interpretations work, see 3DS2 authentication in practice). Second, report 3DS metrics split by card network and issuer, otherwise you will spend forever optimising a number you cannot control. Third, liability shift rests on authentication being genuinely completed with matching amount and data elements — a condition no vendor can change.

6. Acceptance and go-live checklist

Whichever vendor you pick, run acceptance the same way:

1. Confirm version and certification status: current specification version, certification coverage, expected timing of the next upgrade.
2. Run all three platforms separately: challenge and non-challenge flows on web, iOS and Android — do not test only one.
3. Cover six outcomes: authentication success, authentication failure, user abandonment, timeout, system error, and retry-required scenarios, confirming both the returned semantics and the front-end behaviour.
4. Verify amount and element consistency: whether partial capture, tipping or exchange-rate changes can invalidate a completed authentication.
5. Confirm sandbox versus production differences: flows that pass in sandbox do not necessarily behave identically in production, especially across issuer ACS implementations.
6. Instrument the metrics before launch: challenge rate, frictionless rate, authentication success rate, split by issuer country. Without this data you cannot attribute anything later.

For testing method see payment gateway sandbox testing; for how 3DS relates to acceptance overall see payment success rate optimisation.

7. Four common misjudgments

1. Expecting a new 3DS Server to raise approval rates: approval is driven mainly by the issuer ACS and risk policy; changing the Server side changes coverage and version currency, not authorisation outcomes.
2. Treating a tooling vendor as a provider: SDKs and test tools compress build time and change no live metric, so the procurement purpose must be stated explicitly.
3. Ignoring issuer-side choices: you cannot decide which ACS an issuer uses, but you can split your data by issuer and quantify the uncontrollable part instead of complaining about it.
4. Assuming 3DS covers all fraud: post-authorisation fraud, friendly fraud and payment methods that bypass card network rails all sit outside its reach.

Source: 16IDC original. Each vendor's role on the chain, component scope and certification status follow its official documentation and card network published rules.