If what you are testing is a streaming or subscription app you are building, start with the store sandbox rather than with an address at all. Apple's guide to creating a Sandbox Apple Account asks for a first and last name, an email address not already used as an Apple Account, a password, and one of the 175 App Store storefronts — the documented field list carries no payment method and no billing address — and Apple is clear that these accounts “can't be used to sign in to or make purchases on the App Store”. Google Play's testing guide issues test instruments to registered license testers, including one that “always approves” and one that “approves then charges back”, and says Play Billing Lab “lets you test offer regional eligibility and the user experience in any region, regardless of where you are physically testing”.
A generated address earns its place one layer up: your own sign-up form, your own profile and billing screens, and any fixture that has to clear address validation before your code ever runs. It is worth being equally clear about what it does not do. Spotify, which does publish developer documentation here, keys region off the account rather than off a parsed billing address. Its profile country field is documented as “The country of the user, as set in the user's account profile” — now marked deprecated, and returned only where the user-read-private scope has been granted — while its market parameter accepts from_token, which the docs call “the same thing as setting the market parameter to the user's country”. Beyond that, no major streaming service publishes developer documentation on billing-address validation, so the specifics vary and are largely unstated.
What makes the address field itself awkward is that a US address is not four independent values. The five-digit ZIP is geographically structured, and the first three digits are the prefix USPS sorts on: the Domestic Mail Manual defines one presort level as bundles for “one or more 3-digit areas served by the same sectional center facility (SCF)/local processing center (LPC)”. In all but a handful of border cases that service area sits inside a single state, so a ZIP and the state beside it agree in all but a handful of border cases. Put 90210 next to New York and any validator doing a real lookup rejects the pair, even though both values are individually well formed. Five arbitrary digits usually fail the same check, though about two in five are assigned codes that then disagree with the city beside them.
The border cases are real addresses, and worth a fixture of their own: 42223 covers Fort Campbell on both the Kentucky and Tennessee sides, and 06390, Fishers Island, sits in New York under Connecticut's 063 prefix, so a validator that hard-codes the rule as absolute rejects two genuine ZIPs. Nor is the answer binary. Google's Address Validation API returns verdict.addressComplete when an address “has no missing, unresolved, or unexpected components”, treats a validationGranularity of PREMISE or SUB_PREMISE as “a quality address that is likely deliverable”, and sets hasInferredComponents and hasUnconfirmedComponents to flag the parts it had to infer or could not confirm. Your form needs a branch for “probably this, please confirm”.
A card billing address is checked by something else. AVS — the Address Verification Service — does not ask whether an address exists; the issuing bank compares the numeric parts you submit, the street number and the postal code, against what it holds on file for that card. Adyen documents 7 for “Both postal code and address match” and 2 for “Neither postal code nor address match”, caps a US postalCode at five digits, and states that “AVS does not validate stateOrProvince”. A failure is usually driven by the card: Stripe's 4000000000000028 fails the line 1 check, and 4000000000000044 returns both as unavailable. Braintree keys off the address instead — postal code 20000 returns N, 20001 returns U, with AVS and CVV rules enabled in the sandbox. This generator supplies the other half: a real city, a state-correct five-digit ZIP, a matching area code and a randomized street name and house number.
How the generator helps with streaming app testing: City, state and ZIP that genuinely agree — the pairing a real address lookup checks, rather than four fields filled independently; Street number and five-digit ZIP always populated, so an AVS check has something to compare instead of being skipped; Real NANPA area code for the same region, so the phone field does not contradict the address; Randomized street name and house number, so the record is region-consistent while resolving to no real occupant; Pin a specific state or city when a fixture needs a known place, and that place's real postal codes and area codes come with it; Bulk export to CSV, JSON or SQL for a fixture set, and a seed parameter on the JSON API so the same request returns the same records.