The strongest reason to want a US address for a test checkout is that the major processors publish test-mode values that force specific address-verification outcomes, and you need somewhere valid to put them. The mechanism differs by gateway, which is the first thing worth knowing. Stripe drives the outcome from the card number: 4000000000000028 (pm_card_avsLine1Fail) fails the address line 1 check, 4000000000000036 (pm_card_avsZipFail) fails the postal code check if you provide a postal code, 4000000000000044 (pm_card_avsUnchecked) makes both the postal code and line 1 checks unavailable, and 4000000000000101 (pm_card_cvcCheckFail) fails the CVC check if you provide a CVC. The outcome turns on the card number rather than on matching a particular billing address, but Stripe's wording is conditional, so an omitted postal code leaves you with no postal result to assert on. Braintree and Authorize.Net work the other way round and key off the address itself.
In the Braintree sandbox the billing values are the trigger. Postal code 20000 returns N (no match), 20001 returns U (not verified), 30000 returns E (AVS system error) and 30001 returns S (issuer does not support AVS); street number 200 returns N and 201 returns U. Any other value returns M, an omitted field returns I. These only fire with AVS and CVV rules enabled in your sandbox. Authorize.Net publishes a fixed list of ZIPs for the purpose — its testing guide says to "use the following zip codes to generate specific AVS responses" — 46201 for A, 46203 for E, 46204 for G, 46205 for N, 46207 for R, 46208 for S, 46209 for U, 46211 for W, 46214 for X and 46217 for Z. Square is narrower: postal code 99999 produces a card-postal-code-incorrect error, and payments in USD, CAD or GBP require a valid postal code.
That last requirement is where generic placeholder data falls over, because a US address is not four independent fields. The five-digit ZIP is geographically structured. USPS presort standards describe mail whose delivery ZIP "begins with one of the 3-digit prefixes processed at the sectional center facility (SCF)/local processing center (LPC) in whose service area the mail is verified or entered" — so the first three digits map to a processing catchment, and that catchment sits inside a single state in all but a handful of border cases. 42223 covers Fort Campbell on both the Kentucky and Tennessee sides of the line; 06390, Fishers Island, is New York under Connecticut's 063 prefix. In practice a ZIP implies a state and a set of cities: put 90210 beside New York and a lookup validator rejects the pair, while five arbitrary digits fail more often than not, roughly 41,000 of the 100,000 possible values being assigned.
A validator treating that rule as absolute deserves its own fixture: it wrongly rejects the two border addresses above, both of which are real and deliverable. AVS is a separate check, and narrower than most people expect. At authorization the numeric portion of the street line and the postal code go to the issuing bank, which compares them against the billing address it holds for that card and returns a single letter. It does not confirm the address exists, that anyone lives there, or that the name matches. Stripe surfaces the outcome as address_line1_check and address_postal_code_check, each documented as pass, fail, unavailable or unchecked. Coverage is uneven: Stripe notes that most cards issued in the United States, Canada and the United Kingdom support street address verification, and that "AVS checks can fail for legitimate payments" when a customer mistypes an address or moves without telling their issuer.
So a useful test matrix has two axes: does the address parse and geocode, and does AVS return the letter you expect. Both want addresses whose city, state and ZIP genuinely agree. This generator pins those parts — a real city, a postal code actually issued for it, and a NANPA area code for the same region — while the street name and house number are both randomized, so the record clears a validator while pointing at no real occupant. It emits five-digit ZIP codes; there is no ZIP+4 output, though Authorize.Net's sandbox still forces its nine-digit-match codes, W and X, from a five-digit value. Keep ordinary fixtures clear of the trigger values above unless you mean to hit them, or a random house number of 200 will quietly return N in Braintree. Beyond these four processors the behaviour is unpublished and varies by gateway and issuer, so test against your own stack.
How the generator helps with test checkout and address verification: City, state and ZIP that genuinely agree — the pairing an address validator actually checks; Randomized street name and house number, so the address is format-valid but resolves to no real occupant; Real NANPA area code for the same region, so the phone field matches the billing address; Pin a specific US state or city when a fixture needs a known place, and get that place's real postal code with it; Bulk export to CSV, JSON or SQL when you need a fixture set rather than a single order; The JSON API accepts a seed, so a failing checkout test can replay with exactly the same address.