Using One 3DS Server Across Multiple Acquirers

Many enterprise merchants now route card payments through more than one acquirer, for cost, resilience, or local acquiring in different markets. Authentication often lags behind. Each payment service provider brings its own bundled 3D Secure, so the same customer can be authenticated with different data, different challenge behaviour and different reporting depending on where the payment happens to be routed.

Running a single 3DS Server under the merchant’s control removes that inconsistency. It does not make authentication independent of the acquirer, though. EMV 3D Secure (EMV 3DS) ties every authentication request to a specific acquirer and merchant, and the architecture has to respect that.

What ties an authentication to an acquirer

The Authentication Request (AReq) a 3DS Server sends carries several identifiers that describe who will process the payment:

The issuer sees these values when it decides whether to authenticate, and the authentication record held by the DS keeps them. If the payment is then authorised through a different acquirer, the authentication describes one acquirer and the authorisation another.

Route first, then authenticate

The practical consequence is a fixed order of operations:

1. Screen the transaction with your own risk and velocity rules.
2. Choose the acquirer for this payment.
3. Authenticate with that acquirer’s identifiers in the AReq.
4. Send the authorisation through the same acquirer, carrying the authentication result intact, as described in why authenticated transactions lose their protection at authorisation.

The awkward case is failover. If the chosen acquirer declines or is unavailable and the payment is retried elsewhere, the original authentication was built for the first acquirer. Whether it can be carried to another acquirer is a matter of card scheme rules and acquirer policy, so confirm it for each scheme rather than assuming it. Where it cannot, the safer design re-authenticates for the new route.

What a single 3DS Server gives you

• The same data quality on every authentication, whichever acquirer is used, which is one of the main levers on issuer decisions (the field-level rules behind requestor data quality).
• One place to measure authentication across all routes (how merchants should measure 3D Secure performance).
• One protocol-version policy rather than one per provider (EMV 3DS version management).
• Control of your own fallback policy when authentication degrades, instead of inheriting each provider’s defaults.

What it asks of you

Every acquirer in the routing mix has to accept authentication performed outside its own platform and map the results into its authorisation messages. Not all do, and those that do may expect the data in different formats. The merchant, or its orchestration provider, also takes on scheme registration of the 3DS Requestor and the operational work of running a 3DS Server.

Operating a 3DS Server environment also brings the PCI 3DS Core Security Standard into scope, which applies to environments performing 3DS Server, ACS or DS functions. A hosted 3DS Server keeps the merchant-side control while the provider runs the certified environment; the trade-offs are covered in full-stack versus multi-vendor 3D Secure.

Questions for each acquirer

• Do you accept externally authenticated transactions for each card scheme we route to you?
• Which acquirer BIN and merchant ID should our 3DS Server send for each scheme?
• How is our 3DS Requestor registered with each scheme’s Directory Server?
• In what format do you expect the authentication value, ECI and DS Transaction ID?
• Is liability treatment identical to authentication performed through your own 3DS Server?
• Can we test end to end before switching live traffic?

Frequently asked questions

Can an authentication be reused if the payment is sent to a different acquirer?

Do not assume so. The authentication request names a specific acquirer and merchant. Whether a result can be carried to another acquirer depends on card scheme rules and acquirer policy, so confirm it per scheme and re-authenticate where it is not allowed.

Does a merchant need its own 3DS Requestor ID?

Each Directory Server assigns 3DS Requestor identifiers. How a merchant is registered, directly or through an acquirer or provider, varies by scheme. Ask each acquirer how registration works for your set-up.

Does running our own 3DS Server mean PCI 3DS compliance?

The PCI 3DS Core Security Standard applies to environments that perform 3DS Server functions. If you operate the 3DS Server environment yourself, expect it to apply. If a provider hosts it for you, the provider carries the environment’s compliance, and you should confirm what remains in your scope.

Does using an independent 3DS Server change liability shift?

Liability follows the authentication outcome and the card scheme’s rules, provided the results reach the authorisation intact. Confirm with each acquirer that externally authenticated transactions are treated the same way as those authenticated on their own platform.

Is this only worth doing for very large merchants?

It matters most where several acquirers handle meaningful volume. A merchant with one acquirer gains less, although consistent data and reporting still help if a second acquirer is likely to be added.

Talk through your routing

GPayments’ ActiveServer is a 3DS Server used by acquirers, payment gateways, PSPs, and merchants. To discuss authentication across a multi-acquirer set-up, request a demo or speak with a GPayments 3DS specialist.