US ACH QA

US ACH edge cases for payment QA.

Create sandbox-only US fixtures for US ACH with explicit expected validity and error codes. Assignment to a live bank account is intentionally not claimed; directory links and validation scope stay visible.

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. Choose scenarios

Combine valid-format and negative cases such as invalid routing, invalid account and unsupported currency.

Explore choose scenarios →

2. Export a matrix

Use the Business lab or API to generate repeatable JSON or CSV rows for your test suite.

Explore export a matrix →

3. Check source scope

Review the public source and directory references before adding a corridor to a production test policy.

Explore check source scope →

Sources and freshness

Rail source

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

View source →Page evidence checked 2026-07-29
Directory reference

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 real US ACH account details?

No. The identifiers are synthetic QA values. The generated rows do not prove that a real account exists or can receive a payment.

What does validation cover?

This catalog entry declares routing_checksum validation. It does not silently upgrade a format check into live directory or account verification.

Can I use these fixtures in CI?

Yes. Use the deterministic seed and expected error list to assert parser, routing and payment-form behavior in CI or staging.

Availability and source coverage are bounded by the current registry, fixture catalog and plan entitlements. If a target is not matched, IBANgen reports that state instead of inventing authoritative coverage.