Test Identity Generator — Names, Addresses

Payment forms need more than a card number. They need a billing address, a postcode that matches, a name on the card, and often a contact email and phone. This tool generates all of it as synthetic test data, so you can test address validation, AVS logic, and form behaviour without touching anyone’s real details.

Everything here is invented, and the way it is invented matters. Names come from a generic word list. Email domains are reserved by RFC 2606 and can never be registered by anyone. Phone numbers are drawn from the ranges national regulators set aside for fiction, where such a range exists. Nothing corresponds to a real person.

How the data is kept safe

Three of the fields could plausibly collide with a real person’s details if generated carelessly, so each is drawn from something that cannot.

Email. Every address ends in example.com, example.net or example.org. RFC 2606 reserves those second-level domains permanently — nobody can register them, so no message sent to one can reach a person. A generator that invents plausible-looking domains instead is generating addresses that might belong to somebody.

Phone. Where a regulator publishes a range reserved for drama and fiction, the tool uses it: 555-0100 to 555-0199 in the North American Numbering Plan, Ofcom’s 07700 900xxx and 020 7946 0xxx in the UK, and ACMA’s 0491 570 xxx for Australian mobiles. Those numbers are guaranteed never to be allocated. For Germany, France, Türkiye and Ireland no equivalent range is published, so the tool produces a correctly formatted number and says plainly that it is a format fixture rather than a guaranteed-unroutable one. That is a real limitation, and pretending otherwise would be worse than stating it.

Address. Street names are transparent placeholders and street numbers start in the thousands, which makes a collision with a deliverable address unlikely. Postcodes are format-valid because a postcode that fails your validation tests nothing.

Address Verification System (AVS) testing

AVS is the part of this that developers get wrong most expensively.

When a card is authorised, the processor passes the numeric parts of the billing address — the street number and the postcode — to the issuer, which compares them against its records and returns a code. The common codes:

Many merchants decline transactions returning N, which is a defensible rule. The expensive mistake is declining G as well.

G does not mean the address was wrong. It means the issuing bank is outside the AVS system and therefore never checked. AVS is largely a US and UK arrangement, and most issuers in the rest of the world do not participate at all. A rule that treats “no answer” as “wrong answer” declines a large share of your international customers, every time, with a generic failure message. From the inside it looks like international conversion is simply poor. U and R deserve the same care — unavailable and retry are not evidence of anything.

Note also that not every processor exposes the raw letter codes. Stripe, for instance, normalises them into address_line1_check and address_postal_code_check fields with values of pass, fail, unavailable or unchecked. The underlying signal is the same; the shape your code branches on is not, so write your rules against your processor’s representation rather than the table above.

To exercise those branches, gateways publish cards that force particular results. Stripe’s 4000 0000 0000 0028 fails the line 1 check while the postcode passes, 4000 0000 0000 0010 fails both, and 4000 0000 0000 0044 returns both as unavailable — which is the one that tests your G-equivalent path.

Source: Stripe — Testing · Verified: 2026-08-04

The test card numbers reference collects the equivalents for other gateways.

Address format differences by country

Four mistakes account for most international checkout failures:

• Storing the postcode as an integer. 01234 becomes 1234, Australian 0800 becomes 800, and the UK and Canada do not survive the cast at all. Postcodes are strings that happen to contain digits.
• Requiring exactly five characters. This excludes the UK, Canada and Ireland outright.
• Making the state or province field mandatory. Many countries have no such division, and a required field with no valid answer is a dead end.
• Capping the address line at fifty characters. Long street names and building references exceed that regularly outside the US.

GDPR and test data

Synthetic test data is not personal data, which is precisely why you should use it. If you copy production customer records into a staging environment, those records remain personal data under GDPR — with the same lawful basis, retention, and breach notification obligations, in an environment that is usually less protected than production. Generating fresh synthetic data removes the problem rather than managing it.

The practical version: a staging database full of real customers is a breach waiting to be reported, and it is a breach of production data even though it happened in staging. Nobody budgets for that. Our test data guide goes further into how to keep the two apart.

Testing scenarios

• AVS code handling. Assert a defined behaviour for every code, not just Y and N. The G, U and R branches are where revenue leaks.
• Postcode validation by country. The regex should change when the country select changes. Test that switching country after typing a postcode revalidates rather than keeping a stale result.
• Billing separate from shipping. Generate two records and confirm the AVS check uses the billing address, not whichever one was entered last.
• Address autocomplete. Confirm your form still works when the user ignores the autocomplete and types the address by hand, which a surprising share of people do.
• Accented characters. The name pool deliberately includes ö, ü, ç, é and ñ. Push a name like Günther Öztürk through the form, the API, the database and back onto the confirmation screen, and check the bytes survive every hop. Encoding bugs almost never show up in ASCII-only test data, which is exactly why they reach production. The same names are worth pushing through any card preview component you render — the card mockup generator covers where those layouts break.

What this generator does not produce

• National identifiers of any kind — no social security, tax, passport or licence numbers
• Any data belonging to a real person
• Real, deliverable addresses
• Anything that would help pass an identity check

A test identity is a set of well-formed strings for exercising a form. It is not an identity, and it will not satisfy any system that actually verifies who you are — those systems check against government and credit bureau records, which no generator can touch.

The reserved ranges and AVS test cards above were last checked against provider documentation on 4 August 2026. Providers do change what they publish — the official link beside each claim is authoritative.

Related tools and guides

Pair these records with numbers from the all-network generator, or produce both together at volume with the bulk generator, which carries the same fixture strategy advice. The validator checks any number you are unsure about, and the IBAN generator covers the bank transfer side — same synthetic-data reasoning, different payment rail. The tool directory lists everything else, and the FAQ covers what a Luhn-valid number does and does not prove.