If you are integrating Amazon Pay Checkout v2, a US address is something you build fixtures for rather than something you are handed. Amazon's address formatting and validation page lists the addressDetails parameters required for the US — name, addressLine1, city, stateOrRegion, postalCode, countryCode and phoneNumber — with addressLine2, addressLine3 and districtOrCounty optional, and you must populate that object when checkoutMode is ProcessOrder with productType PayAndShip. deliverySpecifications is the neighbouring control, and worth a fixture per branch: it restricts which addresses a buyer may select from their Amazon address book, through specialRestrictions such as RestrictPOBoxes and through per-country statesOrRegions and zipCodes lists under addressRestrictions. Amazon validates those values in Sandbox only. Borrowing real addresses from production is no answer either — SP-API puts getOrderAddress and the Merchant Fulfillment shipment calls behind a Restricted Data Token, because restricted operations return buyers' personally identifiable information.
The difficulty is that a US address is not four independent fields. The five-digit ZIP is geographically structured — its first three digits identify a USPS sectional centre facility — so in all but a handful of cases a ZIP implies its state, and a validator doing a real lookup rejects 90210 beside New York, or five arbitrary digits, which are unassigned about three times in five and disagree with the city beside them the rest of the time. The handful still matters. A ZIP is a set of delivery points rather than an area, which is why one can straddle a state line: 42223 covers Fort Campbell addresses in both Kentucky and Tennessee, and 06390, Fishers Island, is New York despite sitting under Connecticut's 063 prefix. A validator treating one ZIP as meaning exactly one state rejects those genuine addresses. USPS ZIP Code Lookup settles any pair you are unsure of.
This generator pins the parts that must be real — a genuine US city, a five-digit ZIP actually issued for that city, and a NANPA area code from the same region — while the street name and house number are both randomised, so the record clears a lookup while resolving to no real occupant. Pin a state or a city outright when a fixture has to sit in a known jurisdiction. What it will not do is invent the +4: US postal codes come out five digits, so to reach Amazon Pay's documented US transformation — a dash inserted into a nine-digit postalCode, which its own example writes as 98104 - 3442 — append four digits to the generated value yourself. The same page documents three transformations applied everywhere: whitespace trimmed from all inputs, postalCode and countryCode uppercased, and name and addressLine1 truncated at 50 and 60 characters.
Those truncation limits deserve fixtures of their own, because Amazon's schemas disagree about them. In Checkout v2 the response address type allows an addressLine1 of 180 characters where the request addressDetails type allows 60, and a countryCode of 3 against 2. Across SP-API the picture repeats: Merchant Fulfillment v0 caps Name and City at 30 and AddressLine1 at 180, Shipping v2 caps name at 50 and addressLine1 at 60, and Orders v0 sets no length constraints at all, though it does mark an AddressType of Residential or Commercial. The clearest error Amazon publishes sits in the Merchant Fulfillment sandbox: send createShipment or getEligibleShipmentServices with a countryCode of USA rather than US, and the documented static response is a 400 reporting that the value USA failed the constraint “Member must have length less than or equal to 2”. These interfaces check shape and length, not whether anybody lives there.
The SP-API models cited below define address shape and length and nothing more — none exposes an address-validation or normalisation endpoint — so any account of how Amazon judges an address beyond shape is inference rather than documentation. Address verification is a different mechanism again, and routinely confused with the above. AVS belongs to the card networks rather than the merchant: the acquirer sends the numeric portion of the billing street address and the billing ZIP, the issuer compares them with the record it holds for that card, and a code comes back saying whether both matched, the ZIP only, the street only, or neither. It never looks at city or state, and never establishes that the address exists. With Amazon Pay it does not arise on the request side: billingAddress is response-only, the address for the buyer-selected payment instrument, so AVS paths belong in your processor's test mode.
How the generator helps with Amazon Pay and SP-API address testing: City, state and ZIP that genuinely agree — the pairing any lookup-based validator actually checks; Real five-digit US ZIP codes for the city on the record, never five arbitrary digits; A NANPA area code from the same region, since Amazon Pay lists phoneNumber as required for US addresses; Randomised street name and house number, so the record is region-consistent while resolving to no real occupant; Pin a specific US state or city when a fixture has to sit in a known jurisdiction rather than wherever the generator lands; Bulk export to CSV, JSON or SQL, and the JSON API additionally accepts a seed so a fixture can be committed and replayed exactly.