Create a hosted backend

Updated Sep 29, 2026·7 min read

A hosted backend is a backend we run for you. It serves the providers you pick and answers at an address of its own, so your integration calls it the way it calls the provider. This page takes one from nothing to an address you can call.

To run a backend in your own network instead, see the self-hosted section.

See Self-hosted backends overview.

The video builds a hosted backend for Stripe and PayPal, adds a rule that declines $66.60 as fraud, deploys it and points a small checkout at it. Only the shop's API address changes.

Before you start

You need a provider of the type you want to run. The backend can only serve brands your organization holds.

See Add providers.

Your plan has to allow a backend, and the Backend store says so when it does not. Each backend also counts as one simulation toward your plan's allowance.

Anyone with the editor role or above can create one. Buying providers is for owners only, but building a backend from what the organization holds is not.

Create it

Open Backend store, find the type under Types, and use New backend there. You can also open Simulations, use the arrow next to New simulation and pick Backend.

The new backend dialog: the type, a name, and the hostname that follows it. — The type, a name, and the hostname that follows it.

The dialog has three fields:

Type: payments or identity. Only the types you hold a provider of are listed, and the type cannot change later.
Name: for you, and what the lists show. Change it whenever you like.
Hostname: the first part of the backend's address, such as shop-payments in shop-payments.pay.mockz.io. It follows the name as you type, until you edit it.

A hostname is 3 to 63 lowercase letters, digits and single hyphens. Words we reserve, such as api or admin, cannot be used, and neither can a provider's name, such as adyen or stripe, or a hostname another organization uses. You can change it until the first deploy. After that it is fixed.

Creating a backend deploys nothing. It opens on Providers, with nothing selected yet.

Choose what it serves

Providers lists every brand your organization holds of this type. Select what this backend serves, and the change saves on its own.

The provider picker, with Adyen served and Stripe not selected. — Pick a whole brand, or narrow to one API or one exact version.

Pick at whichever level fits:

The brand, such as Adyen, which covers every API and version under it.
One API of that brand, such as checkout.
One exact version, such as v71.

Selecting a brand covers the rows under it, and those rows say so. Select all takes every brand you hold. A row marked Not in this build is one the backend's build does not ship, and it cannot be picked.

Base image, at the top right, is the build the backend runs. By default that is the latest build.

See Pin a build version.

Running more than one backend with different picks is normal. A backend that serves a single brand sends every request to that provider and no other, which is what a test about one integration needs.

Deploy it

Use Deploy in the header. The status goes from Offline to Deploying to Active, and the address appears under the name, with buttons to copy or open it. The first deploy takes longer than later ones.

A deployed backend: Active, with the address it answers at. — Active, with the address the backend answers at.

What you change later, such as the providers, the settings or the scenarios, is saved at once and reaches the backend on its next deploy.

If a deploy is refused, the page says why. The most common reason is a backend with no provider selected.

Where it answers

A hosted backend answers at its own host:

Payments: https://<hostname>.pay.mockz.io
Identity: https://<hostname>.kyx.mockz.io

Each provider version answers under its own path on that host, such as /adyen/checkout/v71. Everything after that path is the provider's own route, so a payment request is:

POST https://shop-payments.pay.mockz.io/adyen/checkout/v71/payments

A provider's own SDK sends its requests to the root of a host. To use one, serve that version at the root: open Service config, pick the version, clear its path and press Enter. It then answers at https://shop-payments.pay.mockz.io/payments as well, and keeps answering at its own path.

Service config for one provider version: the path it answers at, and an example request. — Where one provider version answers, with a request that reaches it.

To put the backend on another of our domains, pick it in Host under Deployment and save, before the first deploy. The host and the hostname are both fixed from the first deploy on.

Settings worth knowing

General holds the name, the icon and Behavior, which controls what the backend does besides answering:

The Behavior settings: API explorer, Record traffic and Replay. — What the backend does besides answering requests.

API explorer: a browsable UI at the backend's address. Turn it off and only the API answers.
Record traffic: keeps every request and response, which is what fills History. It is off until you turn it on. Keep for is how long they stay, up to what your plan allows.
Replay: records a response once and answers matching requests with it. Its own Keep for is how long a recording is kept, 24 hours unless you change it.

Access decides who can reach the backend, with an API key, a password for the explorer or an IP allowlist. This works as it does for any simulation.

See Access control.

Take it offline

A backend you are not using can come down. Use the arrow next to Deploy and pick Take offline. The address stops answering, and everything you set up stays. Deploy brings it back.

Take offline, under the arrow next to Deploy.

Deleting a backend, under General, removes it for good. If it was ever deployed, its hostname stays with your organization for 90 days, so nobody else can take it in the meantime.

After it is up

The backend keeps a record of what it has done, such as the payments it took, and its sidebar lists them.

See Backend activity.