MWS (Merchant Web Service)

A merchant web service, or MWS, is a way for a firm's own systems to talk to a payment platform in code. It works in place of a hosted page or a screen someone clicks. Through it a firm can send payments and ask for status. It can start refunds, pull settlement data and handle stored card details, all from its own software. The name is loose enough that providers use it for different things. So it is worth checking what a given platform means by it rather than assuming.

The shift towards this model has been steady, and it is largely about control. A hosted page is quicker to build, and it keeps sensitive data out of the firm's own systems. A service interface hands the firm a grip on the look, the timing and the data it holds. The price of that grip is more duty. Neither is right in every case. A lot of firms end up using both, with a hosted part for card capture and a service interface for all that sits around it.

What Such An Interface Exposes

The common set covers starting a payment, plus approval and capture as two steps. It covers refunds and voids, and payment lookup. It covers webhook registration for later events, and token management for stored card details. It also covers pulling reports or settlement data. Splitting approval from capture is worth a note. It is what makes delayed capture work for firms that only charge on despatch.

Instant Replies And Later Events

Payments do not always settle inside a single request. Builds that assume they do tend to be brittle. An approval may come back at once. A bank transfer or a buyer challenge may not. That is why webhooks exist next to the call-and-reply interface. It is also why a build needs to cope with getting the same event more than once. Repeat-safe handling on both sides is often the gap between a build that rides out a network glitch and one that bills a buyer twice.

Where The Law Shapes API Design

In European open banking the rules for the interface are written into law rather than left to providers. The PSD2 regulatory technical standards ask banks that hold accounts to keep at least one interface. It must let approved third parties name themselves and talk securely, using standards set by world or European bodies. Docs must be on hand no less than 6 months before go-live. A summary must be put out in public, and a test bed must be ready on the same date.

Uptime And Performance Duties

The same standards go further than most commercial API terms. A dedicated interface must offer the same uptime and speed, support included, as the ones given to the bank's own users. Its targets must be at least as strict. There is also a fallback. Third parties may drop back to the user-facing interface if the dedicated one fails, subject to terms and to any waiver the local watchdog grants. These duties hold in the EEA.

Message Standards Underneath

Above the transport layer sit data standards. They decide whether two systems really grasp each other. ISO 20022 gives one approach covering payments, securities, trade finance, cards and foreign exchange. It holds a model, a central word list, and design rules for building message shapes. Payment plumbing keeps moving onto it, so lining up with those terms matters more each year.

Security Expectations

An interface handling payment orders needs the calling system checked and the traffic encrypted. Keys need to be swapped out often, with limits on what each key can do. Signing webhook payloads matters too, since an unchecked callback is an obvious way in. This is one of the places a message authentication code does routine work. Taking card data straight through a service interface also brings wider PCI DSS scope than a hosted option would.

Common Build Mistakes

Three keep coming up. Treating every non-success reply as a lasting failure, when a timeout may mean the payment worked and the reply was lost. Storing replies with no matching step, so nobody spots a gap between what the firm logged and what the provider settled. And tying a build to one provider so tightly that adding a second means a rewrite of the payment layer. That last choice only shows its cost later.

Cutting Build Cost Across Providers

That last problem is what a shared layer exists to solve. Build once against a shared interface and wire providers in behind it. Adding a bank or a local method then costs no rewrite of the app. finera. covers that in its piece on integrating with multiple PSPs through a single API. The trade-off is that the shared layer has to keep pace with what each provider behind it supports. So it is worth asking how fast new provider features show up in it. A layer that lags by two releases can cost more than it saves.

‍