How to handle foreign addresses?

[TJPride]

Not all countries use the US address format. Given that all the API offers for fields is address, city, state, zip, country, how should those be filled in for countries that don't necessarily have zip codes the way we do?

[Joy]

Hello TJPride,

When you run a transaction for non US customers we pass whatever information is given to us on to the processor according to their data requirements.  Most processors currently only verify the numeric portion of the address and zip code, but we cannot guarantee it.

Thanks!

-Joy

[TJPride]

Hmm. The thing that's confusing for me is that some foreign addresses have both letters and numbers in their zip code, and seem to have a town and city instead of city and two-character state. I suppose I could get around that by not requiring address match on credit cards or not passing an address for foreign customers, but that seems a weak way of solving the problem.

[Trevor · Accepted solution]

Part of the problem is that, at the moment, Authorize.Net only connects to credit card processors in the US.  The fields that we make available for address information are largely defined by what those processors have defined in their own specifications.  With the current state of address verification, it is generally true that the processors only look at the data contained in the Street Address and Zip/Postal code.  These two fields are fairly universal, even if their formats change.  You can choose to collect the Town and City information yourself and optionally store it in the City and State fields, but it won't currently have any impact on address verification.

[TJPride]

Well, that's good to know anyway. Thanks.