MPS (Merchant Plug-in Server)

A merchant plug-in server, shortened to MPIS or more often MPI, is the shop-side part that starts a 3D Secure check and handles the messages that follow. When a buyer reaches checkout and the shop wants the card checked before approval, this part builds the request. It sends that request towards the card network's directory and reads whatever comes back. It sits between the shop's own systems and the checking layer. Many shops do not touch it direct, because a gateway or provider runs it for them.

The naming has moved on, which is worth knowing when you read older guides next to current specs. A U.S. Payments Forum white paper puts the mapping plainly: a 3DS Server, referred to in earlier versions of 3DS as a merchant plug-in or an MPI, is designed to facilitate EMV 3DS authentications. So MPI is the old label for what current EMVCo specs call the 3DS Server. There is a related idea called the 3DS Requestor. Older build guides still use the old term freely.

What This Part Actually Does

Its job is handling the protocol rather than making calls. It formats the request, sends it, takes the reply, and passes the outcome back into the payment flow. Approval can then go ahead or stop. It does not decide whether a buyer is real. That call belongs to the card issuer. Grasping that split explains why shops cannot simply set their way to fewer challenges. All they can do is send better data and hope the issuer likes it.

Where It Sits In The Message Flow

EMVCo's own technical material sets out the order of play. The 3DS Server sends a request stating what it wants, whether frictionless or challenge. The issuer's access control server then replies. Where a challenge is needed, EMVCo notes that the 3DS Client communicates directly with the access control server over a secure link. The issuer can then deal with the cardholder itself. It reports the outcome back to the 3DS Server in a results message.

The Directory And Access Control Servers

Two other parts complete the picture. The directory server, run by the card network, routes request and reply messages between taking-part shops and issuers. The access control server is run by the issuer. It works out whether a card number is eligible, sets the risk limits, and checks the cardholder. The shop-side part talks to the first. The buyer, during a challenge, in effect talks to the second.

Frictionless And Challenge Outcomes

Most checks now finish without the buyer noticing. EMVCo describes the pattern as shoppers simply clicking buy with the payment approved. It adds that issuers may choose to require further authentication for higher-risk payments. The data the shop-side part sends shapes that call. A request carrying rich context gives the issuer more to work with than a thin one. The issuer keeps the final say either way. No setting on the shop side can force a yes.

Why Data Quality In The Request Matters

This is the practical lever shops hold. The request can carry device details, purchase history markers, billing and shipping addresses and other context. Thin requests tend to draw more challenges than well-filled ones. Firms that fill in the fewest fields they can often end up with a higher challenge rate than they need. They then blame the drop-off on the checks rather than on their own build.

Running It Yourself, Or Not

Running this part yourself means handling network sign-off and protocol upgrades. It also means ongoing conformance as EMVCo puts out updates and bulletins. Many shops use a provider's version instead. That shifts the upkeep but limits their control to whatever data and settings the provider opens up. Asking which fields can actually be filled in is a better question than asking which version is supported.

How It Connects To Legal Duties

In markets that require checks on remote payments, this part is how those duties tend to get met in a card flow. SCA (Strong Customer Authentication) rules in the EEA, and their like elsewhere, are usually met through 3D Secure. SCA exemptions are asked for through the same messages. Because the rules differ by country, one set of settings will not suit every market a firm trades in.

Getting More From An Existing Build

Look at which optional fields are being sent. Look at whether exemption requests are used where they are on offer. Look at how failed checks are handled. That work usually pays better than switching provider. A payment that fails a check is not lost by default. How the flow responds decides whether the buyer gets a second go. finera.'s explainer on what 3D Secure is and how it works covers the wider mechanics. The theme that keeps coming up is that the same protocol gives very different results depending on how well it is built.