Resilient backends overview

Updated Oct 2, 2026·6 min read

A resilient backend is your own copy of a provider's API. It answers on the same paths as theirs, returns the same response shapes and the same status codes, and behaves the way the provider does. Your integration changes its base URL and nothing else.

The word resilient is about ownership. The backend is yours alone, it stays up when the provider's sandbox is down, and it produces the failures their sandbox will not.

Two ways to run one

A backend runs in one of two ways:

Hosted: we run the backend for you, and it answers at an address of its own. Your hosted backends are listed under Simulations.
Self-hosted: you download the backend as an image and run it in your own network. Your self-hosted backends are listed under Self-hosted.

Both are the same backend underneath, so the types and triggers below work the same way in either. You buy providers in the Backend store in the sidebar, and its switch at the top right sets which kind you are buying for. Each kind is bought on its own: a provider you hold for hosted backends does not cover a self-hosted one, and the other way round.

See Self-hosted backends overview.

Why teams run one

A vendor sandbox sits outside the production SLA. When it goes down, your release waits, and there is nobody to call.
Your whole company usually shares one vendor account. What another team does in it shows up in your build.
Some providers only hand out sandbox credentials after a sales call, and a few never for the API you need.
The cases worth testing are the ones a vendor sandbox will not produce on demand: a stolen card, a sanctions hit, an issuer that times out.
Flows that send a person to a page and wait there cannot be automated against the real thing.

Types

A type is a family of providers with one engine behind it. These are available today.

Payments. Card and wallet providers. Authorise, capture, partially capture, refund, cancel, adjust an authorisation, plus 3D Secure and idempotency keys.

See Payments backend overview.

Identity. Verification of people and companies, KYC and KYB together, because the providers treat them as one thing. Document and selfie checks, watchlist screening, business registration and ownership, and the hosted flows that normally need a person.

See Identity backend overview.

You decide what comes back

Name the subject of a request after the outcome you want and that is what you get. Call the cardholder insufficient_funds and the payment is refused for that reason. Call the applicant sanctions_match and the check comes back with the hit on the report that would have found it.

The triggers are the same words on every provider, and each one answers in its own format. You write the test once, and adding a second vendor does not mean learning a new set of magic values. Each provider also keeps its own published test data, so the card numbers and reserved names from its documentation work here too.

When the built-in triggers do not cover a case, write your own. A scenario says what a request looks like and what should come back, and it sits on top of what we ship rather than replacing it.

See Write your own scenarios.

How a hosted backend fits together

Providers belong to your organization. You add the brands you want once, and every hosted backend you run can serve them.

See Add providers.

A hosted backend is a simulation with an address of its own, and you pick which of your organization's providers it serves. You can run more than one, and each keeps its own records. Point CI at one and keep another for testing by hand.

See Create a hosted backend.

Each hosted backend answers at its own host:

https://<hostname>.pay.mockz.io    # payments
https://<hostname>.kyx.mockz.io    # identity

On that host, each provider version answers under a path that names it:

https://shop-payments.pay.mockz.io/adyen/checkout/v71/payments
https://kyc-checks.kyx.mockz.io/onfido/v3.6/applicants

Everything after that path is the provider's own route. A provider's SDK that only takes a root address can have its version served at the root instead.

Because it is a simulation, the rest of the app works on it as usual: request history, replays, access control and share links. On top of that it keeps a record of what it has done, such as the payments taken, or the cases, subjects and documents filed.

See Backend activity.

We publish new builds of each type, adding providers and fixing behaviour. A hosted backend follows the latest build unless you pin it to one, and a pinned backend stays there until you move it yourself.

See Pin a build version.

What you need

A hosted backend runs on a plan that includes backends, and it needs a certain amount of memory to run at all. The Backend store tells you where you stand before you buy anything, and points you at plans if yours cannot host one. Self-hosted backends do not depend on your plan.

Providers are billed apart from your plan:

Hosted: one subscription per type, paid monthly or yearly with the card you pay your plan with. Your first order of each type runs free for a trial period. Nothing is charged for the trial, and you order the providers again to keep them after it ends.
Self-hosted: paid monthly by card or yearly by invoice.

Only organization owners buy providers, and they cancel them under Billing, in Subscriptions. Everyone else can use what the organization holds.

See Subscriptions.