Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Invalid shipping address for UK and Apple Pay #1198

Closed
vbelolapotkov opened this issue May 14, 2020 · 27 comments · Fixed by #1543
Closed

Invalid shipping address for UK and Apple Pay #1198

vbelolapotkov opened this issue May 14, 2020 · 27 comments · Fixed by #1543
Assignees
@ricardo
Labels
component: payment request buttons Issues related to Payment Request Buttons - e.g. Apple Pay, Google Pay priority: high The issue/PR is high priority—it affects lots of customers substantially, but not critically. type: bug The issue is a confirmed bug.

Comments

@vbelolapotkov
Copy link
Contributor

vbelolapotkov commented May 14, 2020 •
edited by v18
Loading

Added by @v18:

There's a fix for this in WCPay - it needs to be ported over.

Describe the bug
Apple Pay anonymises the part of the shipping address (postalCode and address lines) until payment is processed. This leads to invalid shipping address error in the payment request when shipping zones configured in a specific way.
I.e. when shipping zones are configured based on zip code regex (e.g. BN11*) it's not detected correctly by payment request due to zip code is truncated by Apple Pay.

More details and screenshots:
Support ticket: 2911575-zen.
Slack chat: p1589288438496600-slack-CNXMMQBDW

To Reproduce

  1. Create shipping zone with regex-based zip code filter and flat rate (like in the example above).
  2. Serve the site from a public domain, e.g. with ngrok.
  3. Add some cards to Apple Pay.
  4. Add product to the cart and go to the cart page.
  5. Try to pay with Apple Pay and shipping address from UK matching the zone regex.
  6. Invalid shipping address error.

Expected behaviour
Correct shipping zone and rate applied based on the selected shipping address.
@vbelolapotkov
Copy link
Contributor Author

There is an additional note on apple developer site with mode details on postal code truncated:

Note
The data returned may differ based on the user's geographic region. For Canada and United Kingdom, a redacted shipping address contains only the first three characters of the postal code. For US addresses, the redacted zip code contains the first five digits.
The full postal code is provided after the user authorizes the transaction.

https://developer.apple.com/documentation/apple_pay_on_the_web/applepaysession/1778009-onshippingcontactselected

@dwainm dwainm added type: bug The issue is a confirmed bug. priority: high The issue/PR is high priority—it affects lots of customers substantially, but not critically. component: LPMs/APMs Issues related to LPMs/APMs labels May 15, 2020
@grig-23
Copy link

grig-23 commented May 26, 2020

User in 2911575-zen reported that the "invalid shipping address" error message
only shows when the first part of the postcode is 4 digits, eg BN42. If
the first part of the postcode is only 3 digits, eg BN1 - the payment works.

Also, they have reported no errors at all when shipping zones are not implemented although it is not entirely clear to me what exactly does that mean and I'm asking for clarification.

@vbelolapotkov
Copy link
Contributor Author

The fix for this is probably in the core at the zip code to zone matching logic. It should properly recognize and treat partial UK postal codes.

@jarman1
Copy link

jarman1 commented May 26, 2020

Thank you for looking in to this guys (I'm the customer who reported the issue) I received the support email.

It might also be worth considering if the the postcode issue is also effecting Chrome Payment Requested buttons. I haven't personally set up Chrome/Google Pay to test.

Do you know a work around in the interim?

Thx

@vbelolapotkov
Copy link
Contributor Author

I did some experiments with Chrome Payment Request buttons and full postal code was passed causing no issues. So this is Apple Pay only thing.

@jarman1
Copy link

jarman1 commented Jun 3, 2020

Do you know if this is fixed in the 4.2.0 update ?? Thanks :)

@dougaitken
Copy link
Member

Another example, using Stripe 4.5.0 - confirmed as Vasily mentioned, this is an Apple Pay thing

https://wordpress.org/support/topic/apple-pay-wildcard-shipping-postcodes/#post-13191932

@thedermacompany
Copy link

I am having trouble with a very similar issue.

Apple Pay was working on my site until I integrated a couple of plugins, DPD for WooCommerce & Flexible Shipping. Both are required so that we can create shipping labels directly within the Wordpress dashboard for DPD consignments.

However now I have this installed, I have had to disable standard flat rate & free shipping rates that are built into WooCommerce and replace them with the Flexible Shipping opiton.

Within the flexible shipping options I can create a number of shipping options that are directly linked to a service offered by DPD, eg before 12pm, Saturday etc.

This all works fine but the issue arises when I try to use this in conjunction with Apple Pay, I get the dreaded 'Shipping Address Invalid'. As soon as I disable Flexible Shipping as the shipping method and reenable the standard options all is fine again.

I don't believe the postcode wildcards is causing any further issues as I have removed them and tested and I get the same issue with flexible shipping. If reverted to standard shipping and still include shipping wildcards then it works fine.

So to conclude I can either have Apple Pay live and working but then we will need to create a DPD consignment manually each time an order is placed or turn off Apple Pay and have the easier shipping methods integrated fully.

ps Google Pay works with these integration plug-ins with no issue at all.

@allendav allendav added the component: payment request buttons Issues related to Payment Request Buttons - e.g. Apple Pay, Google Pay label Oct 5, 2020
@katinthehatsite
Copy link

Just wanted to add that this also happens with Canadian addresses and Apple Pay that also use the combination of letters and numbers in the addresses

@treibalen
Copy link

treibalen commented Dec 21, 2020 •
edited
Loading

I believe this is another instance of the same bug. I created two shipping zones for the UK: one with postcodes and wildcards and the second one for the rest:

https://d.pr/i/JPSUMz
Full Size: https://d.pr/i/JPSUMz

When I use Apple Pay, it doesn't match the first zone even though it should:

https://d.pr/i/vmICPV
Full Size: https://d.pr/i/vmICPV

If I cancel it and go to the cart page, this how the postcode is truncated:

https://d.pr/i/Qp0Pfs
Full Size: https://d.pr/i/Qp0Pfs

However, if I fill in the postcode normally, it shows the correct rate:

https://d.pr/i/QOt0cp
Full Size: https://d.pr/i/QOt0cp

@vbelolapotkov can you please confirm that it's related to the same bug?

@thedermacompany
Copy link

thedermacompany commented Dec 21, 2020 via email

@treibalen
Copy link

Hi there @thedermacompany,

My wildcard setup can be seen on this screenshot: https://d.pr/i/IvI7Gr

Even if I add the postcode like GL40TY to the zone, it doesn't match with Apple Pay, but works with calculations on cart/checkout page.

So the issue might be with the combination of letters and numbers in the postcode in general.

@thedermacompany
Copy link

thedermacompany commented Dec 21, 2020 via email

@v18 v18 added this to the Sprint 24 milestone Jan 7, 2021
@mouligreenlaw
Copy link

3590824-zen

@ricardo ricardo self-assigned this Feb 9, 2021
@ricardo
Copy link
Member

ricardo commented Feb 10, 2021

I wasn't able to reproduce this issue - It works fine for me when I use a UK postcode with a wilcard flat rate shipping method. Apple Pay selects the right shipping method and the payment goes through.

Apple Pay continues to provide a partial postcode (first three digits) to wc_stripe_get_shipping_options, so I guess they fixed it in WooCommerce core (I couldn't find where they fixed it though).

Can someone on this thread please confirm if the issue isn't happening anymore? Then we can close this.

@ricardo ricardo added the needs feedback The issue/PR needs a response from any of the parties involved in the issue. label Feb 10, 2021
@graftonhosting
Copy link

The issue still exists for some UK postcodes, specifically when trying SK11* today using latest released versions of Woocommerce and Stripe gateway. As per earlier examples Apple Pay returns Shipping Address Invalid

@ricardo
Copy link
Member

ricardo commented Feb 11, 2021

@graftonhosting, thanks for checking! I had tested with a 2 and a 3 character wildcard postcode, that's why it worked for me.

Unfortunately, Apple Pay only exposes the first 3 characters for WooCommerce to calculate the shipping options. This is due to privacy reasons. Other browsers don't do that.

This seems like an ongoing discussion at W3C. I added a comment there explaining our use case. If I understood correctly, they have an ongoing PR to allow merchants to negotiate the redacted fields.

For now, I don't have any ideas on how to fix this, but for those having problems, I'd suggest having a maximum of 3 characters wildcard postcodes.

@jarman1
Copy link

jarman1 commented Feb 11, 2021

Thanks for looking at this Ricardo

For most of the UK it would be sound to use 2-3 character wildcards. The issue arises in areas like the Scottish highlands where couriers charge different rates across the first 4 digits of a post code. A made up example would be say:

AB41* = The courier charges normal UK mainland shipping at £5
AB47* = The courier charges a "Scottish highlands" rate of £20

Again the above is a made up example, but If we to choose a flat rate for just AB* or AB4* I could either disadvantage the a customer as the charge is too high, or be under charging the shipping for another customer.

Anyway it might be worth putting that differentiation forward?

@thedermacompany
Copy link

thedermacompany commented Feb 11, 2021 via email

@jarman1
Copy link

jarman1 commented Feb 11, 2021

Thanks for this Asa..

I will look at setting my zones up like that. Unfortunately, I can't test if that works with Apple Pay as I don't live in those zones. Maybe Ricardo could check?

Cheers

@thedermacompany
Copy link

thedermacompany commented Feb 11, 2021 via email

@jarman1
Copy link

jarman1 commented Feb 11, 2021

Unfortunately I'm getting another bug if I set up using the below.

UK Mainland
AB6...AB43
AB46…AB49

UK Offshore
AB37...AB38
AB44...AB45
AB51...AB56

UK mainland zone 1 is at the top of the zones list.

I enter an AB6 post code for example but get "No shipping options were found for" ?

@graftonhosting
Copy link

Yes, it's definitely still an issue for 4 character postcode prefixes. I have a shipping zone that should include LN1 to LN10 but not LN11, LN12, LN13.

However I set up the zones it is not possible to avoid the Apple Pay error because of the 3 character limit.

@v18 v18 removed the component: LPMs/APMs Issues related to LPMs/APMs label Feb 20, 2021
@ricardo
Copy link
Member

ricardo commented Mar 2, 2021

Unfortunately, it looks like there's nothing we can do in Stripe to fix this.

TL;DR:

From Apple:

The data returned may differ based on the user's geographic region. For Canada and United Kingdom, a redacted shipping address contains only the first three characters of the postal code. For US addresses, the redacted zip code contains the first five digits.

The full postal code is provided after the user authorizes the transaction.

We get only the first 3 characters of a postal code when calculating shipping methods for the UK and Canada, e.g. full postal code is LN10 6SH, but we only get LN1 from Apple.

That creates an issue with wildcard shipping zones like LN10*, which should match, but don't because the provided postal code is redacted.

Perhaps what we can do here is to provide a notice for the merchant explaining the incompatibility with Apple Pay if Apple Pay is enabled and the store has UK or CA shipping zones with more than 4 digits.

@v18 Any thoughts?

@v18 v18 added status: blocked The issue is blocked from progressing, waiting for another piece of work to be done. and removed bundle: payment request buttons needs feedback The issue/PR needs a response from any of the parties involved in the issue. labels Mar 4, 2021
@v18
Copy link
Contributor

v18 commented Mar 13, 2021

Perhaps what we can do here is to provide a notice for the merchant explaining the incompatibility with Apple Pay if Apple Pay is enabled and the store has UK or CA shipping zones with more than 4 digits.

@ricardo - since we're not able to provide a fix for this - it sounds like a good idea to let merchants know about this incompatibility. Probably in the shipping zone area would be best, but could also do it near the payment request buttons.

@LevinMedia - I'd be curious to hear your thoughts about how to best let the users know about this problem: basically when using Apply Pay for shipping addresses in the UK, when using 4+ digit wildcard postal codes to calculate shipping, we aren't able to correctly calculate shipping and cannot complete the order. This is because Apple Pay only exposes the first 3 digits of the post code.

@v18
Copy link
Contributor

v18 commented Apr 16, 2021

Related fix in WooCommerce Payments: Automattic/woocommerce-payments#1528

@ricardo
Copy link
Member

ricardo commented Apr 16, 2021

@v18 I can sync the changes to this repository.

@v18 v18 removed the status: blocked The issue is blocked from progressing, waiting for another piece of work to be done. label Apr 24, 2021
@ricardo ricardo mentioned this issue Apr 28, 2021
Merged
@eltipografico eltipografico mentioned this issue Mar 6, 2022
Open
@ChadReitsma ChadReitsma mentioned this issue Dec 19, 2023
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@ricardo ricardo

Labels
component: payment request buttons Issues related to Payment Request Buttons - e.g. Apple Pay, Google Pay priority: high The issue/PR is high priority—it affects lots of customers substantially, but not critically. type: bug The issue is a confirmed bug.
Projects
None yet
Milestone
No milestone