Choosing a 3DS Server: An Evaluation Guide for Acquirers and PSPs
The 3DS Server sits on the acquirer side of the 3D Secure protocol: it builds and validates authentication requests, routes them to the correct issuer via the Directory Server, and interprets the result. For acquirers, PSPs, and payment gateways, this is the component that determines how much of the authentication request’s (AReq) available data actually reaches the issuer, and by extension, how much of a merchant portfolio’s transaction volume qualifies for frictionless authentication and liability shift. A weak or thin 3DS Server implementation shows up directly in a merchant’s approval rates and chargeback exposure.
GPayments has built 3DS infrastructure since 1999 and provides ActiveServer alongside ActiveAccess, ActiveSDK, and TestLabs to acquirers and issuers across 33 countries. This is an evaluation framework for the acquirer side of the vendor decision, the mirror image of the ACS evaluation issuers run on the issuing side.
1. AReq Data Completeness
The EMV 3DS authentication request supports well over 100 data fields, but a 3DS Server implementation is only as good as the data it actually populates and forwards. Industry analysis of live deployments consistently finds most merchants sending only 60 to 70% of what the AReq supports, which directly suppresses frictionless rates on the issuer side regardless of how good the issuer’s own risk engine is. Ask vendors specifically which optional fields their integration populates by default, device fingerprinting, address match indicators, account and transaction history, merchant risk context, and whether merchants need custom development to send fields the platform doesn’t handle out of the box.
2. TRA and SCA Exemption Flagging
In SCA-regulated markets, the ability to flag transactions for Transaction Risk Analysis (TRA) exemption is one of the single biggest levers on authorisation rate. A 3DS Server that supports TRA exemption flagging, alongside low-value, trusted beneficiary, and recurring-transaction exemptions, lets eligible low-risk transactions skip a full challenge cycle entirely. A vendor without mature exemption flagging capability leaves acquirers pushing transactions through full SCA that regulation would otherwise allow to bypass it, at a direct cost to conversion.
3. Protocol Version Currency and Fallback Handling
EMVCo has shipped multiple minor versions of the EMV 3DS specification (2.1, 2.2, 2.3, 2.3.1), each adding capability the previous version lacked: exemption flagging in 2.2, native non-payment authentication and SPC/WebAuthn support in 2.3. An acquirer’s 3DS Server and an issuer’s ACS are frequently on different versions at any given time, and the 3DS Server needs to handle version negotiation and graceful fallback correctly rather than assuming both sides are current. Ask vendors which protocol versions are supported today, how quickly they’ve historically adopted new minor versions after EMVCo publication, and how fallback behaves when an issuer’s ACS is on an older version.
4. Certification and Liability Shift Mechanics
The 3DS Server must hold current EMVCo 3DS certification and, for hosted deployments, PCI DSS and PCI 3DS compliance covering the 3DS Data Environment. Liability shift itself depends on more than a successful authentication result: the correct ECI (Electronic Commerce Indicator) value and authentication cryptogram (CAVV/AAV) need to be captured and carried through to authorisation correctly, and liability shift only covers fraud-coded disputes, not non-fraud disputes like item-not-received or processing errors. A 3DS Server that doesn’t cleanly pass ECI and authentication values through to the acquirer’s authorisation flow undermines the liability protection the whole implementation exists to provide, even when authentication itself succeeds.
|
Evaluation Criterion |
What to Verify |
|
AReq data completeness |
Which optional fields are populated by default vs requiring custom development |
|
TRA/SCA exemption flagging |
Support for TRA, low-value, trusted beneficiary, and recurring-transaction exemptions |
|
Protocol version currency |
Current EMV 3DS version supported, and fallback handling for mismatched issuer versions |
|
Certification |
Current EMVCo 3DS certification; PCI DSS and PCI 3DS for hosted deployments |
|
ECI/CAVV handling |
Correct capture and pass-through of liability-shift evidence to the authorisation flow |
|
Deployment model |
Hosted vs on-premise options, and migration path if requirements change |
|
Multi-acquirer/merchant support |
Ability to manage multiple merchant configurations distinctly, relevant for PSPs and gateways |
5. Deployment Flexibility
Acquirers and PSPs have different infrastructure constraints depending on scale and internal security posture. A hosted 3DS Server removes the burden of PCI certification and card scheme compliance management from the acquirer, at the cost of some infrastructure control. An on-premise deployment gives full control but requires the acquirer to carry certification and maintenance responsibility directly. Evaluate whether the vendor offers both, what the pricing difference is, and what the migration path looks like if requirements change after go-live.
|
Where GPayments Fits GPayments’ ActiveServer is EMVCo-certified and PCI DSS Level 1 certified, available as a hosted service on AWS with high availability or for on-premise deployment, and supports major global card schemes with ongoing expansion. Paired with ActiveSDK for native mobile integration and TestLabs for full end-to-end pre-launch validation, it covers the acquirer side of the same full-stack 3DS capability GPayments provides to issuers via ActiveAccess. |
Frequently Asked Questions
What does a 3DS Server actually do?
A 3DS Server sits in the acquirer/merchant domain of the 3D Secure protocol. It builds and validates authentication requests (AReq), routes them through the Directory Server to the correct issuer’s Access Control Server, and interprets the returned authentication result, including the liability-shift evidence, so the merchant’s authorisation flow can proceed correctly.
Why does AReq data completeness matter when choosing a 3DS Server?
The EMV 3DS authentication request supports over 100 data fields, but many 3DS Server implementations only populate a subset by default. Since issuers rely on this data to make frictionless versus challenge decisions, a 3DS Server that captures and forwards more of the available fields directly improves a merchant portfolio’s frictionless rate and approval rates, independent of the issuer’s own risk engine quality.
What is TRA exemption flagging, and why does it matter for acquirers?
Transaction Risk Analysis (TRA) exemption flagging allows eligible low-risk transactions to skip full Strong Customer Authentication in SCA-regulated markets, based on an acquirer’s aggregate fraud rate falling below defined thresholds. A 3DS Server without mature TRA flagging capability forces more transactions through full authentication than regulation requires, directly reducing conversion for eligible low-risk transactions.
Does successful 3DS authentication guarantee liability shift on a chargeback?
No. Liability shift depends on the correct Electronic Commerce Indicator (ECI) value and authentication cryptogram (CAVV/AAV) being captured and carried through to the authorisation request, and it only applies to fraud-coded disputes, not non-fraud disputes such as item-not-received or processing errors. A 3DS Server that doesn’t pass this evidence through cleanly can undermine liability protection even when the underlying authentication succeeded.
Should acquirers choose a hosted or on-premise 3DS Server?
It depends on internal infrastructure capability and risk appetite. A hosted 3DS Server removes the PCI certification and card scheme compliance burden from the acquirer, while an on-premise deployment gives full infrastructure control at the cost of carrying that certification responsibility directly. Acquirers should evaluate vendors offering both models and confirm the migration path if requirements change after go-live.
How does GPayments’ ActiveServer support acquirers and PSPs?
ActiveServer is EMVCo-certified and PCI DSS Level 1 certified, available as a hosted AWS-based service or for on-premise deployment, and supports major global card schemes. Combined with ActiveSDK for native mobile integration and TestLabs for pre-launch end-to-end validation, it gives acquirers and PSPs the same full-stack 3DS capability GPayments provides to issuers on the ACS side.
|
Evaluating 3DS Server Vendors? Request a technical evaluation of ActiveServer against your acquiring stack: gpayments.com/contact |
