What is Directory Server?
Also: DS
Scheme-run server (Visa DS, Mastercard DS) routing 3DS authentication requests from MPI to the correct issuer ACS.
The Directory Server (DS) is a critical component within the 3D Secure (3DS) authentication ecosystem, operated by the card schemes (e. g. , Visa's DS, Mastercard's DS).
Its primary function is to receive authentication requests from the Merchant Plug-In (MPI) and, based on the card's BIN (Bank Identification Number), identify and route these requests to the correct issuer's Access Control Server (ACS) for consumer verification.
This routing ensures that the cardholder's bank is able to perform the necessary authentication steps, such as prompting for a one-time passcode or biometric confirmation, before the transaction proceeds to authorisation.
The DS also handles the initial exchange of messages, like the `PReq` (Protocol Request) and `PRes` (Protocol Response), to determine the card and issuer's 3DS support capabilities.
For a merchant, the Directory Server operates entirely in the background and is not directly interacted with; its presence is abstracted by the MPI, which handles the communication flow.
Merchants see the outcome of the DS's routing via the authentication status returned by the ACS, which contributes to the overall transaction result.
A common issue tied to the Directory Server is when an issuer's ACS is unresponsive or incorrectly configured, leading to authentication failures or timeouts, even when the cardholder's details are valid.
This can result in a "soft decline" or a transaction being processed without 3DS authentication. The Directory Server differs from liability shift, which is a scheme rule determining who bears the financial risk for fraudulent transactions based on the success of 3DS authentication.
Worked example
A merchant reviews a €240 transaction where Directory Server is the deciding factor. The Checkout submits device and transaction data, the issuer risk engine decides whether to challenge the customer, and the authentication result is passed into the authorisation request.
The operational cost is modelled at 0 basis points of interchange change, but a materially different fraud-liability outcome, and the relevant action must complete under 10 seconds.
Step 1 is to capture the original request data, including amount, currency, issuer country, MID, and response or status code. Step 2 is to apply the merchant's rule set, for example whether to retry, challenge, refund, release goods, or hold for review.
Step 3 is to reconcile the result against acquirer reporting so finance can see the cash impact. If the rule improves the outcome by even 50 basis points on 2,000 similar monthly transactions, the merchant protects roughly 10 extra orders from avoidable failure or loss.
Scheme notes
Visa Secure, Mastercard Identity Check, American Express SafeKey, and Discover ProtectBuy all sit on EMV 3D Secure principles, but issuer challenge rates and liability treatment differ by scheme, region, and enrolment status.
ECI values, exemption flags, challenge indicators, and authentication results must be passed correctly into authorisation. In the EEA and UK, PSD2 SCA creates a regulatory overlay, while non-European transactions may use the same protocol mainly for fraud control and liability shift.
Why it matters for merchants
Commercially, this affects conversion, fraud liability, SCA compliance, and the balance between frictionless Checkout and challenge rates. For a merchant processing £500,000 per month, a 25 basis point movement is worth £1,250 before secondary effects such as disputes, reserves, support tickets, or failed delivery costs.
The impact is larger in high-risk, subscription, travel, digital-goods, and cross-border models because issuer decisions and scheme monitoring can compound quickly.
Cardflo can help by combining acquiring access, MID routing, orchestration rules, KYB review, and chargeback tooling where relevant, so the merchant is not dependent on one processor interpretation or one fixed transaction path.
Frequently asked
Which data should a merchant store for Directory Server?
Store the transaction ID, MID, acquirer, amount, currency, issuer country, card scheme, response or status code, timestamp, and any 3DS, exemption, refund, or dispute reference. For card transactions, keep authorisation and Clearing identifiers because settlement or chargeback questions may arrive 30 to 120 days later.
For regulated flows, keep customer consent and evidence records for at least the period required by local law or scheme rules. Good records reduce investigation time from hours to minutes when acquirer reporting does not match the order system.
How often should Directory Server be reviewed?
High-volume merchants should review exception rates weekly and trend the main metric monthly by scheme, acquirer, issuer country, MCC, and payment method. A movement of 20 to 50 basis points can be material if the merchant processes thousands of orders.
Finance should reconcile the cash impact at settlement level, while risk or payment operations should analyse the root cause. Reviewing only blended totals hides problems that appear on a single BIN range, region, or MID.
What threshold usually triggers action on Directory Server?
The threshold depends on the category, but merchants should investigate any sudden change above 10% relative movement or 25 basis points absolute movement. For disputes and fraud, scheme thresholds such as 0.9% under Visa monitoring or 1.5% under Mastercard ECM can create immediate escalation risk.
For settlement or pricing items, even 5 to 15 basis points can justify routing or contract review. The key is to set thresholds before month-end, not after a processor invoice or scheme notice arrives.
Can Directory Server differ between acquirers?
Yes. Acquirers can map response codes differently, apply different risk rules, support different data fields, and settle on different cycles.
One acquirer may return a generic decline while another exposes issuer advice that allows a safe retry. Fee treatment can also vary by contract, especially for cross-border, FX, premium cards, and alternative payment methods.
This is why merchants using orchestration should compare performance by acquirer and scheme rather than relying on a single blended approval or cost figure.
What is the first remediation step when Directory Server creates losses?
Start with a 30-day sample and split it by scheme, issuer country, card product, payment method, MID, and response or dispute code. Quantify the value at risk in cash terms, not just percentage points.
Then decide whether the fix is operational, such as better evidence or customer communication, technical, such as richer data or 3DS indicators, or commercial, such as a different acquirer route.
Recheck the same metric after one full settlement or dispute cycle to confirm the change worked.
See how Directory Server plays out in practice
Industries and regions where this term drives real acquiring, routing, or dispute decisions.
Related terms
The current EMVCo authentication standard, sending 100+ data elements to the issuer for risk-based, mostly frictionless customer verification.
Issuer-side component in a 3DS flow that decides frictionless vs challenge, issues cryptograms, and enforces SCA rules.
Client-side or server-side component orchestrating the 3DS message flow with the DS and ACS on behalf of a merchant or PSP.
Related guides.
Ready to improve your payments setup?
Tell us about your business. We'll match you with the right acquiring partners and the right route, typically inside a week.