Test IBAN Numbers for Development: Selected Format Examples

Building a payment form or writing unit tests? You may need checksum-valid IBAN-shaped values to exercise formatting and validation. A value that passes MOD-97 is not automatically a payment-provider test credential and is not safe to submit to a live payment system.

Using customer IBANs in development is risky:

• A misconfigured staging environment could initiate real transfers
• An IBAN linked to an identifiable person can be personal data under applicable privacy law
• Copying production banking data into development can violate your organisation's access, retention, and test-data policies

Sample Test IBANs by Country

The values below are public format examples that pass length and MOD-97 checks. They are not guaranteed to be unassigned accounts or accepted sandbox values. Use them only in isolated validator tests, never on a payment rail.

Western Europe

Northern Europe

Eastern Europe

Need format fixtures for countries not listed here? Use our random IBAN generator to create synthetic values for supported patterns. The generator does not verify bank-code currency, account existence, or provider-sandbox compatibility.

How Test IBANs Are Generated

The process involves four steps:

1. Pick a country — determines the IBAN length and format
2. Fill the bank-code position — match the country's character pattern; use a provider-supplied value when testing an integration
3. Generate an account number — random digits matching the country's length
4. Calculate check digits — using the MOD-97 algorithm

For a detailed explanation, see our IBAN validation guide.

Unit Testing with IBANs

Your test suite should cover:

Checksum-valid cases:

• DE89370400440532013000 ✓
• GB29NWBK60161331926819 ✓
• FR7630006000011234567890189 ✓

Invalid cases:

• Wrong check digits: DE00370400440532013000 ✗
• Invalid country: XX89370400440532013000 ✗
• Incorrect length ✗
• Empty string ✗

Edge cases:

• IBANs with spaces
• Lowercase letters
• Mixed formatting

Payment Provider Test IBANs

Payment-provider sandboxes often reserve specific account values for success, refusal, verification, or pending scenarios. Those values and behaviours are provider-specific and can change. Copy them from the current official documentation for the exact API, country, payment method, and test environment you use. A RandomIBAN output or a public SWIFT format example must not be presented as a Stripe, Adyen, Mangopay, or other provider sandbox credential unless that provider currently documents it.

Form Testing Checklist

Best Practices

Do:

• Use format- and checksum-valid synthetic IBAN fixtures
• Test multiple countries (not just German IBANs)
• Test edge cases: shortest (Norway, 15 chars) and longest (Malta, 31 chars)
• Separate test and production environments
• Document test IBANs in a shared test data dictionary

Don't:

• Use real IBANs in tests (even your own)
• Hardcode test IBANs in production code
• Assume all IBANs are the same length (15–34 characters)
• Skip country-specific testing
• Use test IBANs from one payment provider with another

Multi-Currency Testing

The practical rule is to use synthetic, access-controlled fixtures for local format tests and the payment provider's current designated values for sandbox integration tests. Keep both categories blocked from production. You can generate fresh structural fixtures with our Random IBAN Generator, subject to its documented limits.