-
Notifications
You must be signed in to change notification settings - Fork 206
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.
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
Apple Pay postcode backfill blocks address checks #2645
Comments
@peterspicer-unfold Having faced the exact same issue as you describe in the UK with postcodes and shipping zones, I dug deeper into how Apple Pay truncates the postcodes in the UK (I haven't looked at Canada) and I implemented a fix that allows the original shipping zone regexes to work like N1 * matching N1 postcodes and avoiding N10, N11, N12, N13, N14, N15, N16, N17, N18, and N19 without the user needing to know the # knowledge that you embedded into your fix. The way Apple truncates turns out to be a really good implementation and actually keeps the space if it is there. It also truncates at the right point irrespective of the space, so it must do a real validation on the postcode and not just a naive truncation. Which is great for us!! The one thing that definitely can't be fixed is where full postcodes are used in the regex, and this can never work with Apple Pay unfortunately so something like this would need to be solved a different way in the setup. We used to use this after a customer would email asking if we'd deliver and then we check it out on google maps and see how viable, and if ok we'd add an explicit postcode. Those users we need to tell them just not to use apple pay to complete the purchase. Btw I did try your code and it did work, but it was bugging me that I needed to have N1#* and N1 * in my regexes so that the Apple Pay and non Apple Pay payment methods were correctly matched. I have put this manually onto my e-commerce site and it is working as expected. If you want to try it with your own Apple Pay on my site before adding to yours just let me know. |
I agree, it's a better fix than mine - but the client in question has long since moved on as this was over a year ago. Though I will note that part of the reason I did fix it the way I fixed it was because I wasn't sure how long it would take for this fix to get included so in the meantime I did a bit of fiddling with the woocommerce_cart_shipping_packages hook (which would survive other updates to this plugin in the interim) to change the postcode in the first place, and then reverse engineered this fix from that and do so in a way that would mean it would just work when it got patched without me having to explicitly monitor it. |
Describe the bug
When the shipping address is supplied by Apple Pay, it is only initially a partial postcode, backfilled in this plugin with
*
symbols. This backfilling makes it impossible to do certain address checks correctly for shipping types.In our case, shipping from London to central Brighton (BN1 postcode) has one pricing structure, while shipping further west such as Lancing (BN15) has a different price.
But since the postcode is padded with
*
characters, the same as the wildcard character, we cannot differentiate betweenBN1*
andBN15*
with Apple Pay.To Reproduce
Steps to reproduce the behavior:
BN1 *
vsBN15*
- note that we cannot just insert a rule forBN1*
because that will match BN1 and BN15 when it shouldn't.BN1****
doesn't match eitherBN1 *
or any otherBN1x
(e.g.BN15*
) rulesExpected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Environment (please complete the following information):
Additional context
The change to fix this is very simple in class-wc-stripe-payment-request.php, in method get_normalized_postal_code, the following code is present:
This just needs to use any character other than * to be able to differentiate between a digit and a wildcard - I've tested this with # and it seems to work as I'd expect.
The text was updated successfully, but these errors were encountered: