Test payment forms with synthetic IBANs that exercise every validation path: without touching real customer data. Proper IBAN testing covers format acceptance, checksum logic, country-specific rules, and graceful error handling. Here's a practical checklist.
1. Test valid inputs per country
Generate IBANs for the countries you support (at minimum your top markets) with our IBAN generator. Each must be accepted: correct length, structure and mod-97 checksum. Cover short (Norway, 15), medium (Germany, 22) and long (France, 27) formats.
2. Test invalid inputs
- Wrong length (drop or add a character) → must be rejected with a clear message.
- Bad check digits (change one digit) → checksum must fail.
- Unknown country code (e.g. XX) → rejected.
- Lowercase, spaces and dashes → should be normalized, not rejected.
See common IBAN errors for the full catalog.
3. Test the UX around the field
Auto-spacing every 4 characters, paste handling, inline validation timing (on blur vs on type), and accessible error messages. Never silently reformat user input in ways that change its meaning.
4. Use fixtures, not randomness, in automated tests
Generate a fixed set once with our bulk generator (CSV/JSON export), then hard-code known-valid and known-invalid values into your test suite. Deterministic fixtures make failures reproducible; random data belongs in load tests, not unit tests.
5. Remember what test IBANs cannot do
Synthetic IBANs validate format only. End-to-end payment testing needs provider sandboxes (Stripe, Adyen, PayPal) with their official test credentials. And never let test values reach production: a generated value can coincidentally match a real identifier.
Separate three types of test
A local form test asks whether the interface accepts the right characters, shows clear errors and preserves the input. An application test checks what your own backend stores and rejects. A payment-provider sandbox test checks an external integration, using the provider’s documented identifiers and test environment. The same value is not necessarily suitable for all three.
Use synthetic IBANs for layout and local format tests. Use approved provider fixtures when testing authorizations, debits, payouts, mandates or simulated payment failures. Passing MOD-97 does not turn a random identifier into a provider-supported sandbox account.
A compact regression matrix
| Case | Input or action | Expected behavior |
|---|---|---|
| Valid example | DE89370400440532013000 | Local format check passes |
| Checksum failure | DE88370400440532013000 | Specific checksum error |
| Short input | Remove the final character | Country-length error |
| Printed format | Paste the example with spaces | Normalize without changing digits |
| Empty input | Submit a blank field | Accessible required-field message |
| Alphanumeric format | Use a UK or French documentation example | Preserve letters in national fields |
| Copy and export | Copy a batch into CSV or JSON | Preserve leading zeroes and full strings |
Test the interaction, not just the algorithm
Use the keyboard to reach the country selector, submit control and result. Check whether Enter submits where appropriate and whether a screen reader announces a new result. Error messages should identify the rule and remain associated with the input. A red border alone is not enough.
Test narrow screens and long values. The copy action should preserve the compact identifier, while a displayed value can use grouping for readability. Try pasting from a PDF and verify how your application handles non-breaking spaces. Do not silently strip arbitrary punctuation that could hide a malformed value.
Make failures reproducible
Save a small approved set of fixtures in version control with country, intended validation layer and expected result. Label synthetic data clearly and keep it out of production recipient records. For a random failure, record the generated value and application version so another developer can reproduce it. Do not log live customer account data to create a test fixture.
Sources and scope
Swift: national IBAN formats and registration authority · Stripe: official sandbox testing guidance.
Examples and test matrices are explanatory fixtures, not receiving instructions. This page covers format checks and software testing. It does not verify account ownership or provide a guarantee that a payment will succeed.
Technical notes updated 8 October 2026. Read the editorial policy. Send a correction.