Domestic Rail Fixtures

Corridor-specific payment QA beyond IBAN.

Use a corridor-specific fixture catalog when a payment form or routing adapter needs local identifiers, negative cases and expected validation errors. Every row is synthetic and carries its source and directory references.

Open the workflow Read API docs

Scope: Synthetic and sandbox-only. This page documents QA and integration workflows; it does not claim live account verification or production payment execution.

Use it in three steps

1. Payee verification

Exercise MATCH, CLOSE MATCH, NO MATCH, unavailable and protocol-error outcomes without live account verification.

Explore payee verification →

2. Provider contracts

Replay provider-specific payment, mandate, payout and webhook states with source-linked fixtures.

Explore provider contracts →

3. Domestic rails

Cover routing, sort-code, BSB, institution/transit and currency edge cases in sandbox-only data.

Explore domestic rails →

Sources and freshness

Fixture catalog

Open the documented source or runtime contract before relying on this workflow.

View source →Page evidence checked 2026-07-29

Questions teams ask

Are these payment fixtures connected to real accounts?

No. They are synthetic or sandbox-only fixtures. They are designed for QA, CI and contract tests, not for live payment submission.

Can I export fixtures as JSON or CSV?

Public pages expose a bounded preview. Authenticated paid API and lab workflows can export larger JSON or CSV matrices according to plan limits.

Do the fixtures include expected outcomes?

Yes. Each case includes a scenario, expected status or outcome, relevant error details and a deterministic seed where supported.