We can't speak for PayPal, so you'd need to inquire with them about any potential compensation. As for fixing issues at their end, typically they get things sorted within a day or so at most, so the duration of this case is highly unusual albeit not entirely unheard-of over the dozen-plus years I've been working here.

They still haven't responded to my followup yesterday, asking them to clarify their latest reply -- which may be moot, as our Devs say the cryptic information they'd provided there "doesn't make any sense, Its like they didn't even take a proper look at the issue" and "seems like they aren't that serious about the issue". I can only guess they may be at an impasse diagnosing the issue at their end, so meanwhile they're just throwing irrelevant flack back at us to make it seem like they're working on it or trying to help.

Dev is still scrutinizing our logs for any clues that could indicate any potential tweaks or workarounds we might apply to try mitigating the problem.

We first reported the issue to PayPal MTS on Aug. 23. They finally acknowledged just yesterday that they've identified a relevant timeout issue at their end and are working to fix it.

This corresponds to what our Devs found when they enabled more detailed logging at our end, where we did not see any recalculation callback attempt logged at all for affected orders.

In that scenario, PayPal should apply the precalculated fallback amount(s) passed from our cart -- which appear to be getting reported correctly as tax and mc_shipping in IPN after payment -- but they haven't been adding that to the buyer's payment total.

So apparently their callback routine is sporadically just stalling out completely, failing to perform the callback and failing to add the precalculated fallback amounts, yet still reporting those amounts in IPN, causing the IPNs to fail the Suspected Fraud price-check we perform before processing the order.

If you'd like to offer buyers a different checkout method, this help page lists all the payment services we support5; any of those will add a separate checkout button in your E-junkie Cart for buyers to pay directly with a card.

If you do this and also want to remove the PayPal checkout option from your E-junkie Cart until they resolve this issue, you can do that in your E-junkie Dashboard under Manage Seller Account > Edit Profile > More Payment Options > Show PayPal in shopping cart (unfortunately that can't be disabled if you're using PayPal Payments Advanced or Pro).

Of those services, we'd recommend Stripe in particular if you're based in any of the countries they support2, as they're pretty quick to approve new accounts, very easy to set up with us, and don't even require buyers to enter their card billing address during checkout.

We've received a few reports indicating this problem has cropped up again. We've already reported the issue to PayPal MTS, so they can fix the glitch at their end causing this. Meanwhile, the 4th post in this thread above suggests a workaround you can use to request any unpaid tax or shipping from affected buyers. We apologize for the trouble and hope PayPal can correct the problem forthwith.

PayPal MTS is still investigating this issue.

@jsb I tested PayPal checkout but haven't seen that radio button you mentioned, though all your products I tried to test with had free shipping, so I just used a test product of our own. Could you take a screenshot and email that to us?

Just got another report from a seller that sometimes the PayPal checkout site is not showing buyers any shipping charge at all nor adding such to their payment total, even when shipping was precalculated in the cart before checkout and the default shipping address from the buyer's PayPal profile was applied automatically.

This seems likely related to the issue discussed above, so I've added details about that to the ticket we opened with PayPal MTS about it.

All this, along with those screenshots @jsb sent us (showing stuff in PayPal checkout that we'd never seen before and could not replicate), seems to indicate PayPal might have rolled out a half-baked update to the way they show/apply shipping charges at checkout. MTS says they're working on it, so hopefully they'll roll back to the pre-update version or iron out the problems in the update forthwith.

No further updates from PayPal MTS so far, so we're still waiting on them to fix the issue, which seems to be sporadically ongoing according to further reports of it that we've received from affected sellers today.

Unfortunately, PayPal's front-line customer service agents don't seem informed about technical issues reported to PayPal MTS, nor trained to handle any technical issues in general at all, and by all accounts their training seems to prioritize quick answers over correct or helpful ones.

As mentioned above here, we have reported this issue to PayPal MTS along with proof documenting the issue could only be occurring at their end, and they have confirmed that they are aware of and working to resolve the problem at their end.