Ship & Pay Plugin Suite

A dozen providers, one way of working.

Every carrier and payment provider publishes its own API, and no two agree on much. One returns XML, another JSON. One expects credentials in a header, another signs each request. Pickup point lists arrive in different shapes with different refresh rules. Written plugin by plugin, twelve integrations become twelve settings screens, twelve ways of storing an API key, and twelve places to fix the same bug.

The shared spine.

The suite is a dozen WordPress plugins sitting on one internal core. The core owns everything that has nothing to do with any particular provider: the settings screen and its field types, credential storage, the test and live switch, the HTTP layer with its timeouts and error handling, logging, and the connection check that decides whether a provider tile reads connected and live or not configured. A provider integration is then only the part that is genuinely provider-specific — its endpoints, its request shapes, its error codes.

That boundary is what stops the maintenance cost multiplying by twelve. A change to how credentials are validated is one change. A new provider starts with a settings screen, a connection test and a log that already work, so the work is reading the provider's documentation rather than rebuilding the plugin around it. For the merchant the effect is the same in the other direction: configuring the eleventh provider looks like configuring the first.

Parcel machines are a first-class problem.

Parcel machines are a normal delivery choice in the Baltics and the Nordics, and customers expect to choose the exact machine during checkout. That makes pickup point selection part of the checkout rather than an extra. The plugin fetches the carrier's list of machines, caches it — the lists are long and change slowly — organises it so a customer can find their own town, and carries the chosen machine through to the shipment call. Omniva and DPD both work this way and both describe their machines differently, so the core defines one internal shape for a pickup point and each integration maps its provider onto it.

Payment providers vary along the same lines. Some take the customer to a hosted page and return with a signed result; others expect the details to be collected on the store and exchanged for a token. The core handles what is common to both — the order state around the payment, the return and callback endpoints, the record of what the provider replied — so each integration deals only with its own protocol.

At checkout

What the core provides

Results

WordPress shipping and payment integrations

The Ship & Pay Plugin Suite is a set of production WordPress plugins covering carriers and payment providers used by Baltic and Nordic stores, including Omniva, DPD, Stripe and Montonio. Each plugin is thin: the provider-specific API work sits on top of a shared core that handles configuration, credentials, connection testing, pickup point handling and logging, so the suite behaves consistently for merchants and stays maintainable as providers change their APIs.