Not having city & state could improve conversion, particularly on mobile. If we were to do this for the long run, we would need to fill this information from the Zip, but before we commit to that work we want to run a test and see if it actually helps us.
To consider: is this possible with GC or WP or do they require these fields?
We will have to plan to have someone manually backfill the data for the short test.
Change 319414 had a related patch set uploaded (by XenoRyet):
Adyen US form without address fields
We just added a table of US zip codes with city & state to Civi. It shouldn't be too hard to wire that up to the address save hook and fill in missing fields.
Change 319480 had a related patch set uploaded (by Ejegg):
Fill in missing city and state from US zip code
This is ready to go out. @Pcoombe , @Ppena , @MeganHernandez_WMF , @Jseddon : want me to hold off deploying? After this is deployed, the US Adyen form will switch to street & zip code only. To get the form chooser routing US/USD to Adyen, for some reason you need to include both 'ffname=adyen-test' and 'gateway=adyen' parameters.
There's a matching Civi patch that should automatically get the states and cities backfilled - the data we found for @CCogdill_WMF's time zone request had those for each zip code too, so it was an easy win.
Thanks @Ejegg . Can you confirm that the fields being removed are city and state?
And if so, are we passing anything to Adyen on those fields? I want to make sure to explain the changes to Adyen correctly.
@Ppena , correct, we're removing city and state. We'll be stuffing those fields with 'NA' to avoid Adyen complaining about incomplete addresses (as with the standalone 'house name or number' field that held us up with GB). We will continue to send the donor's street address and postal code, as well as the country code.
I'm a little worried the time zone data we got was incomplete, so just want
to flag that Legal requests we send specific donation totals raised in
about 10 states each year. We should be really positive the postal codes
are backfilling the correct states before running this test. If I'm wrong
about the time zone data, please ignore this comment :D
@CCogdill_WMF good thought. @Ejegg pls send the link around for internal testing first.
@CCogdill_WMF : the timezone data looks pretty good. Of US addresses with 5 characters in the postal code field, 4.2M have a timezone vs 55k without. US 10 char postal codes are 218k with timezones and only 3.5k without.
The missing timezones in the export file are due to an oversight in the export logic - I think a lot of rows in the file are missing postal codes due to the same bug.
This will be the testing link as soon as I deploy it:
https://payments.wikimedia.org/index.php?title=Special:AdyenGateway&appeal=JimmyQuote&ffname=adyen&payment_method=cc&uselang=en&language=en¤cy_code=USD&amount=1&country=US&utm_source=internal_test
Should I go ahead and do that?
Oh, cool, so just an issue with the silverpop file, then?
That link looks like it still has city/state on it to me...
OK, both halves of this are deployed now.
As a bonus, the city/state lookup works from the Civi UI as well, so anyone adding US addresses can leave those fields blank and just enter the zip. After saving, the city and state should magically appear.