PayPal payment keeps spinning and gets stuck for some of our customers

Support
,
#1

Hi,
some of our customers get stuck at the third step (the Paypal payment) of the checkout.
The spinner keeps loading and it says that the payment is being prepared, but nothing happens.

Is there something we can do to fix this?

Thank you very much!

Andrea

Stuck at "Preparing payment..."
#2

Hi @azicchetti,

This often occurs when permissions aren’t set up correctly inside PayPal.

I’d double-check that you’ve granted all the required permissions to Snipcart as explained in this section of our documentation.

If you’re still having issues, you can contact our support directly at geeks@snipcart.com (make sure you let us know the email address you used to created your Snipcart account). We’ll take a look at our logs to see what’s going on.

Let me know if that helps,

Cheers!

#3

Thanks Michael, permissions seem to be ok for geeks_api1.snipcart.com, so I’ll contact the support directly.

Thank you very much,
Andrea

#4

Hi @Michael,

I’ve written to the support, but apparently my emails got ignored.
Our customers are still experiencing this issue and probably we’re losing some sales, is there anything we can do?

Thank you very much,
Andrea

#5

Hi @azicchetti,

Sorry for the delays. I just followed up by email.

1 Like
#6

Thanks, I’ve replied to your email, too.

In the last few days we had some other customers complaining about the “Preparing payment” message never going away, I’ve written their details in my last email.

Seems a serious issue, please help, thank you!
Andrea

#7

We had another report today, I’ve sent you an email with more detail about the problematic cart.

We noticed that the protocol under “DEFAULT WEBSITE DOMAIN” in our Admin Dashboard was previously set to “http”.
Our NGINX setup performs a 301 redirect to https://www…our…domain: could it be that the json crawler gets confused by the redirect?

We also have a products.json in which the product url is not absolute but relative.
Should we update the url by prefixing it with our https domain?

Thank you very much,
Andrea

#8

After a few days we were able to track down the problem, it seems related to discount codes.

Here is another thread describing the issue: Serious bug with discount codes: "Value must not have more than 2 decimal positions"

Temporary solution: disable the offending discount code and use another rule in a different discount item.

Cheers,
Andrea