Safari multiship shipping state

We're noticing an issue with selecting the Shipping state when there are multiple gifts shipping to different addresses. The first Shipping Address section doesn't allow selection of the state if the City is already entered.

Screenshot of the issue: https://s3.amazonaws.com/oxfamamericaunwrapped.com/scratch/safari-shipping.jpg

I'm seeing the following errors:
[Error] TypeError: undefined is not an object (evaluating 'safari.application.addEventListener')
(anonymous function)
[Error] Viewport argument key "minimal-ui" not recognized and ignored. (checkout, line 4)
[Error] Viewport argument key "minimal-ui" not recognized and ignored. (checkout, line 10)
Tagged:
Comments
  • fc_adamfc_adam FoxyCart Team
    @jingari,

    Are you able to replicate this repeatedly? I was able to get it to trigger once - but then I couldn't get it to do it again. If there are some specific steps you could detail, that would be great.

    Also - have you tried this out on the default checkout template to see if it still does it then as well? That way we can tell if it's something that's affecting the standard implementation or if it's something with the customisations made to the checkout - and will give us a smaller focus for our testing.
  • It is actually only repeatedly happening for me on our live site, so it is probably a result of a customization. Ideally, we would use the auto-completes for country, state, etc, however we couldn't get that to work with the issue of having shipping address show up for non-shipped gifts: https://forum.foxycart.com/discussion/7461/disable-multiship-to-on-checkout-for-downloadable-products
  • fc_adamfc_adam FoxyCart Team
    @jingari,

    Is that an issue you were still experiencing in 2.0?
  • Yes, when there are both shippable and non-shippable gifts in the same order.
  • fc_adamfc_adam FoxyCart Team
    @jingari,

    Thanks for confirming and whispering those details. I had thought we had fixed that issue - but have since found the ticket on our side detailing the issue. I've given that ticket a bump so we can get that fixed sooner rather than later.
  • It appears that there are some issues with the way the error notification for form filling works when using a browser's auto-fill.
  • Adding to this, when someone tries to use Paypal as a payment method on Safari, they're getting this error:
    Error: There was an error processing your payment: (10736 Shipping Address Invalid City State Postal Code) A match of the Shipping Address City, State, and Postal Code failed.
    or this one:
    (10730 Shipping Address Postal Code Empty) The field Shipping Address Postal Code is required
    Even though the postal codes are both filled and correct.

    This happens both on our live site which doesn't use any of the autocompletes on the addresses, and also on the dev environment we created which uses the default checkout page.
  • fc_adamfc_adam FoxyCart Team
    @jingari,

    Do you receive that error when you click to go to complete the checkout and proceed to PayPal?
  • Yes, when you click the complete your order button, it should take you over to PayPal to make payment, but instead it remains on the /checkout page and has that error at the top.

    I can't actually get this to repeat today, but you can see hundreds of these 10736 and 10730 errors in our error log over the past week or so.Yesterday, we were even getting complaints via social media about it not working. Not sure what may have changed since then?
  • Ok, I see the issue is with the Shipping address for our products, which shouldn't matter to PayPal at all, but when that address is US-based, the 10736 error is happening. PayPal should just be concerned with the billing address, no?

    If the gift is going to a foreign address, then there isn't an issue, so it seems to be something with the state/zip associated with US addresses
  • Also, there's not an issue if the Billing address is the same as the Shipping address, so it seems to be comparing the Shipping address to the Billing address, which is not normally going to be the same when using Multiship.
  • fc_adamfc_adam FoxyCart Team
    @jingari,

    When checking out with PayPal, it does use the shipping address we provide it - it's the billing address it doesn't care about because it has that on file for the customer. The shipping address however could be to somewhere else so the address entered into the FoxyCart checkout for shipping is sent to PayPal for use there. They validate it to ensure that it's correct in their systems as well.

    I did a quick check of the 10736 Shipping Address Invalid City State Postal Code errors for your store, and for the handful I checked they were all valid. Some were non-existent zip codes, some were a valid zipcode but an incorrect city or state, and some were correct but used an abbreviation for part of the city name which PayPal can be finicky about sometimes.

    The 10730 Shipping Address Postal Code Empty error is one I'm still digging into, and haven't gotten to the bottom of yet. The instances of the error occurring does appear to be when a user has multiship addresses. I've created a ticket for some other team members to take a look into this and see if they can spot what the root cause is.
  • Thanks for digging in to this. In the meantime, is there an easy way that we can modify those error messages so that they're a bit easier for the customer to understand? Is there something I can hook into to change them with jquery?
  • fc_adamfc_adam FoxyCart Team
    edited December 2015
    @jingari,

    As those errors are displayed from PayPal, you could hook into the ready.done event within the checkout template, look for that string at the top of the page and replace it with whatever you would prefer to show. More information on our events at http://wiki.foxycart.com/static/redirect/javascript
  • thanks, I've adjusted those error messages.
  • fc_adamfc_adam FoxyCart Team
    @jingari,

    Thanks for your patience, we've just rolled out a fix for the 10730 error you were experiencing, that shouldn't happen moving forward.
Sign In or Register to comment.