Stripe US ACH Direct Debit fixtures

Stripe ACH test account numbers and webhook QA.

Use 12 Stripe-documented US bank account examples to test ACH success and failure paths in Stripe test mode. These values are provider fixtures, not randomly generated bank accounts or live payment credentials.

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.

Try it: provider fixture contract

First fixture free. Every scenario, credential and webhook expectation with export on Pro.

Provider

Loading a preview…

All fixtures export

Every scenario with credentials, status transitions and webhook expectations. Pro plan.

Format

Use it in three steps

1. Preview a provider

Inspect the first fixture and provider catalog metadata before authenticating.

Explore preview a provider →

2. Export for CI

Paid API access can export the provider matrix as JSON or CSV under plan limits.

Explore export for ci →

3. Run the ACH QA checker

Download five terminal-outcome contracts, an offline Python checker and a CI report recipe. Sandbox execution and webhook signatures remain your responsibility.

Explore run the ach qa checker →

Documented sandbox examples

Never use in live mode. Use these values only in the provider's test environment. They are not account verification, live credentials or generic random bank-account output.

Scenario	Routing number	Account number	Expected outcome
payment succeeds	`110000000`	`000123456789`	succeeded
account closed	`110000000`	`000111111113`	requires payment method
radar high risk block	`110000000`	`000000004954`	blocked by radar high risk
no account	`110000000`	`000111111116`	requires payment method
insufficient funds	`110000000`	`000222222227`	requires payment method
debit not authorized	`110000000`	`000333333335`	requires payment method
invalid currency	`110000000`	`000444444440`	payment fails invalid currency
microdeposits fail to send	`110000000`	`000666666661`	microdeposits fail to send
payment processing	`110000000`	`000000000009`	processing until canceled
payment disputed	`110000000`	`000555555559`	succeeded then disputed
weekly limit exceeded	`110000000`	`000777777771`	payment fails weekly volume limit
deactivated tokenized account	`110000000`	`000888888885`	payment fails deactivated tokenized account

Verify all values in the provider's documentation. Open the full fixture workflow for source-linked exports.

ACH webhook testing: from test account to a CI report

Five terminal outcomes

Success, closed account, missing account, insufficient funds and unauthorized debit. The other seven catalog cases above are reference-only, not automated coverage.

Payment and run correlation

Check sandbox markers, USD ACH scope, PaymentIntent IDs and run metadata. Missing terminal events stay pending; conflicting results fail. Delivery order does not determine success.

Local Python checker

Unzip the pack and run verify.py against your captured events. No dependencies or evidence upload to IBANgen. Keep the JSON report as a CI artifact.

Review access and download cost →

Demo is not sandbox execution: The included demo checks the runner locally. You create test payments and authenticate webhooks in your own Stripe integration. The checker does not verify signatures, failure reason codes, mandates or production readiness.

Sources and freshness

Provider documentation

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

View source →Page evidence checked 2026-10-01

Questions teams ask

Do these fixtures charge a real Stripe US ACH Direct Debit payment method?

No. They are synthetic or provider-sandbox examples for QA and contract testing. Never submit them to a live payment flow.

What is included in a provider fixture?

Depending on the provider, rows can include scenario, sandbox routing/account number or IBAN, token, expected status, webhook and source context.

Can I request a provider not listed here?

Yes. Use the Business intake to submit a bounded provider and scenario list; coverage is reviewed before any implementation or commercial promise.

What test routing number should I use for Stripe ACH?

Stripe documents 110000000 for its manually entered ACH test accounts. Choose the matching documented account number or token for the outcome you want. These examples are for Stripe test mode only; a random routing number is not a substitute.

How do I test insufficient funds or a closed bank account?

Use the corresponding Stripe-documented test account or token in your own sandbox integration. Complete any required mandate and verification steps, then inspect payment_intent.payment_failed. The offline pack checks the expected terminal event/status, not the exact failure reason code.

Does the ACH QA Pack run a Stripe payment for me?

No. It includes five outcome contracts, a Python checker, demo JSON and a report recipe. You create test payments in your own integration and verify webhook signatures there. Demo evidence is a local self-test, not a sandbox execution or production certification.

How should I handle delayed or duplicate ACH webhooks?

Do not treat processing as success or rely on delivery order. Correlate events to the PaymentIntent and deduplicate event IDs in your handler. The pack accepts reordered delivery and counts identical duplicates once; it cannot prove your handler side effects are idempotent.

Why pay when Stripe publishes test account numbers?

The numbers remain public. Existing Pro or higher access purchases an assembled export workflow: five contracts, a dependency-free runner, source/file hashes and JSON report instructions. A normal bundle costs five API credits and one export credit, shown before confirmation.