How to Choose a 3DS Server Provider: 8 Questions for PSPs and Acquirers

A 3DS Server must fit your card schemes, acquiring routes and operating model. EMVCo approval is the starting point. This guide sets out the evidence, tests and responsibilities to check before selecting a provider.

What the shortlist needs to prove

Two 3DS Server products can both be EMVCo approved and still be very different choices for a PSP. One may have the scheme coverage you need but leave your team dependent on support tickets to investigate failed authentications. Another may work in a single-acquirer demo, then need rework as soon as routing becomes more complex.

Use the eight questions below to test how the platform handles failed authentications, supports your engineers and passes results to authorisation. Agree the evidence and acceptance criteria before comparing prices.

Where the 3DS Server sits in your payment flow

The merchant or PSP initiates authentication through its integration with the 3DS Server. The server creates the Authentication Request (AReq) and sends it to the scheme Directory Server (DS), which routes it to the issuer Access Control Server (ACS). The checkout API and the EMV 3DS message exchange are distinct interfaces. [1]

The ARes returns through the DS to the 3DS Server. A frictionless flow can finish at this stage. For a challenge, the browser or native 3DS SDK communicates with the ACS; the ACS sends the result in RReq through the DS to the server, and RRes acknowledges receipt in reverse. Use the server-side result and required authentication data for the separate authorisation step. A completed challenge screen alone is not proof of payment approval. [1]

Eight questions for your vendor review

1. Product approval and release scope

Do not stop at a certification logo. Request the product name, software version, approval reference and Letter of Approval (LOA). Check the details in the EMVCo approved products directory, including the applicable protocol version, status and expiry date.

Compare the specification revisions, protocol versions and extensions in the approval with the requirements of your schemes and partners. Keep the vendor software version separate from the EMV specification version. Ask which updates remain within the approval scope and which require further testing or approval.

Check product conformance, scheme onboarding and production readiness separately. An EMVCo Letter of Approval does not, by itself, establish live connectivity for your legal entity, market or acquiring relationship.

2. Scheme and market readiness

A provider saying it supports the major international card schemes tells you very little about your launch plan. Ask for a scheme-by-scheme matrix showing production connectivity, test availability, regional limitations and any work still required from your business or acquiring partners.

For a PSP expanding into Saudi Arabia, for example, the question is not simply whether the server supports EMV 3DS. It is whether the proposed setup meets the requirements for the schemes the PSP intends to process, including any relevant domestic scheme such as mada.

Get the vendor to mark each connection as live, available subject to onboarding, partner-dependent or planned. That one distinction can change your implementation schedule more than a feature comparison can.

3. Authentication data quality

Assess how the server validates, maps and transmits relevant transaction, account and device data. The issuer ACS makes the authentication decision using that information and its own policies. A 3DS Server cannot guarantee a frictionless outcome or an approved payment.

Ask how mandatory, conditional and optional fields are validated, and whether your team can diagnose missing data and inconsistent merchant mappings. For browser journeys, test 3DS Method execution, completion signalling and timeout handling. Check how card-range data is refreshed and how the supported version is selected. These checks belong in the integration review, alongside the main AReq/ARes exchange. [2]

Request a field map and examples of valid, rejected and incomplete requests. Diagnostic access should use role-based permissions, appropriate masking or redaction, defined retention and audit trails. Collect and retain only data permitted by the applicable security and privacy requirements.

4. Mobile integration and challenge behaviour

Confirm whether the vendor supplies native iOS and Android 3DS SDKs, integrates an approved third-party SDK or expects you to source one. Verify functional approval, applicable security validation, supported OS versions and the release-maintenance process.

For launches around or after 31 October 2026, check the SDK security-validation route. PCI SSC will stop accepting new PCI 3DS SDK submissions after that date; existing listings retain their normal lifecycle. PCI Secure Software v2.0 provides an alternative assessment route. Confirm the applicable payment-brand requirements. This change does not retire PCI 3DS Core. [3]

Then test the parts of the journey that are easy to miss in a standard demo. Put the app in the background during a challenge. Interrupt the flow and return. Try an out-of-band authentication journey. Check whether users can recover cleanly when the app or network connection is disrupted.

The 3DS SDK exchanges challenge messages with the issuer ACS, not through the 3DS Server. The vendor should be able to explain and troubleshoot that boundary rather than treating every failed challenge as a generic checkout error.

5. Performance and operational resilience

Ask for latency measurements at a throughput that resembles your business, not the average time from a lightly used sandbox. p95 and p99 response times are more useful than a single headline figure. Make sure the provider explains what is being measured: server processing alone or the wider authentication journey, which also involves the scheme and issuer.

Define which components the SLA covers, planned-maintenance exclusions and the support response and restoration targets. Ask for recovery time and recovery point objectives, evidence of failover testing and ownership of certificate renewal. Confirm which dependencies sit outside the provider's control.

Test timeouts, duplicate requests and partial failures. Ask how the system correlates asynchronous results and prevents duplicate processing. Separate safe API retries from initiating a new authentication, and agree the recovery permitted by protocol and scheme rules.

6. Authentication across acquiring routes

For a gateway or orchestrator, the authentication result must remain associated with the correct authorisation attempt. Trace the Electronic Commerce Indicator (ECI), authentication value, transaction status and relevant transaction identifiers into the downstream authorisation message.

Test a route change after authentication. Compare the acquirer and merchant identifiers, transaction details and other scheme-required fields against the new route. Confirm whether the data remains valid or a fresh authentication is required. Obtain the relevant scheme and acquirer position on liability treatment; an ECI or successful authentication alone does not establish liability shift.

There is no universal rule that an authentication result can be reused after any route change. Test the combinations you actually plan to run, including the schemes and acquiring relationships involved. A sequence diagram and end-to-end message trace should form part of the review.

7. Deployment and security responsibilities

Agree who operates the application and infrastructure, including monitoring, patching, backups, administrative access and incident response. A self-hosted licence and a vendor-hosted managed service have different boundaries. A vendor may also manage software inside your infrastructure, so define hosting location and operating responsibility separately.

Request the applicable PCI 3DS Core and PCI DSS compliance evidence, including an Attestation of Compliance (AOC) where required. Check the assessed entity, services, environment and assessment date. PCI 3DS Core addresses the 3DS environment; EMVCo product approval and PCI DSS evidence do not establish that assurance on their own. Validation obligations depend on the payment-brand programme and each party's role. [4]

Document the shared responsibilities for systems, personnel and services that can affect 3DS security, including vendor support access. Hosting the server at the customer does not, by itself, resolve the software provider's responsibilities. Request a written scope statement and delivery plan for any outstanding assurance. [4]

Put the operating model and costs on the same page. Include the licence or service fees, implementation work, hosting, scheme-related changes, support, upgrades and exit assistance. A three-year view is usually more informative than a per-transaction quote.

8. Integration access and acceptance testing

Request technical documentation, a test environment and appropriately protected diagnostic access before contracting. Your engineers should be able to reproduce representative success and failure scenarios and explain the results without relying on a sales demonstration.

Try a missing field, a challenge that is cancelled, an ACS timeout and a routing scenario that is difficult to reproduce. Can your engineers understand what happened from the available traces? Can they distinguish an integration fault from a scheme or issuer issue?

Licensed software and managed service comparison

A scorecard that helps you compare vendors

Treat approval, required scheme connectivity and security arrangements as gates before scoring. A weighted score must not hide a launch blocker.

Adjust these example weights to your architecture before circulating the RFP.

Score each area from 0 to 5. Calculate score ÷ 5 × weight in points, then add for a total out of 100. Record the supporting evidence and unresolved conditions.

Seven tests worth running before signing

Agree how test results lead to controlled live traffic, with go/no-go criteria and rollback. Simulation does not establish production readiness.

What to measure once the server is live

Measure completed flows, successful authentication and payment approval separately. A failed or rejected authentication can still have a valid final result; counting it as successful would conceal a material problem.

These definitions are suggested reporting conventions. Agree eligible populations, time windows, exclusions and treatment of attempts, errors and non-payment messages before comparison. Segment results by scheme, issuer, market, channel and protocol version so changes in traffic mix are visible.

RFP checklist for PSPs and acquirers

Request written answers and supporting evidence for each applicable item. Use these questions alongside the scorecard and acceptance tests.

• Which exact product, software version, approval scope and EMVCo LOA cover our deployment?
• Which EMV 3DS specification versions and extensions are supported in our deployment?
• Which schemes and Directory Servers are live in our markets? What still requires onboarding?
• Who owns scheme onboarding, certificates, renewals and operational approvals?
• How are fields, card-range data, 3DS Method execution and version selection handled?
• Which SDK approvals and security validations apply, and how are interrupted challenges tested?
• Where is latency measured, and can you provide p95/p99 figures at our expected load?
• Which failures, recovery objectives and response targets are covered by the SLA?
• How will authentication values, ECI and identifiers reach each of our acquiring routes?
• What are the PCI 3DS Core and PCI DSS scope, supporting evidence and shared responsibilities?
• How are access, log redaction, data location, retention and deletion controlled?
• Can our engineers access documentation and representative test cases before contracting?
• What is the three-year cost, including integration, support, upgrades and exit assistance?
• What are the milestones and acceptance tests between contract signature and live traffic?

Where FinOn fits

FinOn offers a 3DS Server and native iOS and Android SDKs, with licensed and managed options described on its product pages. Match the proposed release and service scope to your scheme coverage, architecture and operating requirements. [5], [6]

The published EMVCo LOA identifies 3DSS FINON version 2.3.1, covering specifications 2.2.0 and 2.3.1.1. Reference 3DS_LOA_SER_FITC_020301_01050 was issued on 10 July 2025 and lists expiry on 28 May 2027. The LOA identifies Ubuntu 20.04; confirm how your intended platform and release map to the approved configuration. Current validity remains subject to the EMVCo listing. [7]

Discuss your 3DS Server requirements with FinOn

Bring your target schemes, expected volumes, acquiring routes and preferred deployment model to a technical discussion. Review the proposed integration, evidence requirements and acceptance tests with the FinOn team. Book a technical discussion.

Questions buyers also ask

How to verify EMVCo approval

Use the exact product and version from the vendor's LOA to search the EMVCo approved products directory. Check the version, approval scope and current status against the proposed deployment.

What EMVCo approval says about scheme connectivity

EMVCo approval covers conformance within the stated product scope. Scheme connectivity, onboarding and production readiness must be confirmed for the proposed deployment.

How a 3DS Server can support frictionless authentication

Correct data mapping and transmission can give the issuer ACS better information. The issuer's decision, scheme rules and transaction mix still determine the outcome; a server cannot promise a specific frictionless rate.

Using one 3DS Server with several acquirers

Yes, with the appropriate architecture and scheme support. The important point is what happens to authentication data when the acquiring route changes. Test that flow rather than assuming results can always be reused.

What belongs in a hosted 3DS Server SLA

Define availability, measurement boundaries, maintenance exclusions, support hours, incident response, escalation, recovery objectives and ownership. For contractual latency, state the measurement points and treatment of external dependencies.

What to test before migration

Scheme readiness, message and field mapping, browser and SDK challenges, error handling, routing, monitoring, staged cutover and rollback. Agree who will validate every path before live volume moves.

Sources and verification references

1. EMVCo EMV 3DS whitepaper and app challenge flow
2. EMVCo browser device information and 3DS Method
3. PCI SSC 3DS SDK sunset bulletin dated 1 May 2026
4. PCI SSC 3DS Core scope and outsourcing FAQs
5. FinOn 3DS Server and SDK product page
6. FinOn 3D Secure as a Service product page
7. EMVCo LOA for 3DSS FINON
8. EMVCo approved products directory