In the past day or so a few merchants have reported receiving Suspected Fraud notification emails from us for orders paid by PayPal. The problem appears to be that PayPal checkout is sometimes dropping tax and/or shipping amounts when they calculate the buyer's final payment total, so the buyer wound up only paying for the actual item prices alone, without tax or shipping. We've already opened a ticket with PayPal MTS about this to get the issue at their end resolved.

When we receive IPN (Instant Payment Notification) from PayPal confirming completed payment, before processing the order we perform a price-check to make sure the reported payment total mc_gross matches the sum of the purchased items' current price settings, plus the tax and mc_shipping amounts reported in the IPN. This is primarily intended to catch price tampering, but it also catches any failures to collect tax/shipping, as happened here. If that payment total is short, we don't process the order as usual but instead send you the order details in a Suspected Fraud notice, so you can decide what to do about it.

In this case, you can decide if you want to ask the buyer to pay the tax/shipping amount(s) that PayPal missed, and either way if it's a digital product you can fulfill the order manually by using "Send free download link/code" in your E-junkie Dashboard under Manage Buyers.

We'll followup here to confirm once PayPal MTS informs us they have resolved the issue at their end.

I've followed up on that ticket we opened with PayPal MTS asking for a status update, as they haven't responded in two days now. Pretty absurd of their customer service agents to suggest it's on our side, since they clearly have tax/shipping amounts -- they're reported in the IPNs they're sending us, which we include as-is in our Suspected Fraud emails -- but just aren't adding that to the payment total at their end; we have no influence over that whatsoever.

If you also accept direct card payment and just want to disable the PayPal checkout option in 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).

As for collecting the unpaid shipping, you can use PayPal's Request Money feature with the payer_email reported in our Suspected Fraud email (that's the buyer's PayPal Email), or you can add a product in your E-junkie Dashboard named something obvious like Shipping Due with a 0.00 price, then send the buyer a link like this:

https://www.e-junkie.com/ecom/gb.php?c=single&cl=XXXXXX&i=YYYYYY&amount=Z.ZZ

...where XXXXXX is your E-junkie Client ID (which you can find in your E-junkie Dashboard under Manage Seller Account > View Account Summary), YYYYYY is the item number of that Shipping Due product, and Z.ZZ is the unpaid shipping amount due. You can change the e-junkie.com in that link to fatfreecartpro.com if you prefer; it should work fine either way. If you're already maxed out on products allowed for your plan, we can bump that up for you; just let us know1.

It's up to you if you want to enable Require buyer's shipping address for this product or just rely on the shipping address you already got for the original order. If you do enable it, the link above won't engage your tax/shipping calculation settings to add any extra charges, as it's a Buy Now link that skips past our cart to take the buyer directly to instant checkout with PayPal for the price (amount=Z.ZZ) of that single item alone.

Still no word back from PayPal MTS, so for now to mitigate the situation, we're going to temporarily omit the parameters we normally pass to PayPal checkout telling them to callback to our system to recalculate tax/shipping based on the buyer's final shipping address.

That callback seems to be where PayPal's glitch is dropping any tax/shipping amounts that should get added to the final payment total, so hopefully skipping that callback will at least allow them to add the tax/shipping pre-calculated in our cart as-is.

This does open a potential for some PayPal buyers to calculate tax/shipping in our cart with a country or postal code that differs from their final shipping address, but that's how things were before the recalculation callback routine existed at all. That sort of trickery wasn't at all common then anyway, so that small risk at least beats not charging buyers for tax/shipping at all.

Well, we finally got a reply from PayPal MTS today on that ticket we opened with them last week, but they only cited spotty details about some vague error they saw that I'm not even sure is at all relevant to this issue, so I'm referring that to our Development staff in case they can make heads or tails of it.

Regardless, it's still PayPal's end that clearly has tax/shipping amounts and just isn't adding that to the buyer's final payment total for whatever reason. Seems like we're getting fewer reports of it over the past few days, so maybe our workaround mitigated the issue and/or PayPal has finally started getting a handle on it.

Unfortunately, going by all accounts we've heard over the years here, PayPal's front-line customer service agents don't seem trained or equipped for actual tech support (that's what MTS is for), and their longstanding track record of buck-passing and uninformed wild guesswork suggest their staffing metrics may prioritize quick answers over correct or responsible ones.

As for MTS, the cryptic info in their latest response was too vague to be at all helpful, if it's even relevant to the issue at all, so I've asked them to clarify. BTW, our case number is #09397939 for that MTS ticket, not that PayPal customer service is likely to be able to do anything useful with it.

Nothing at our end changed to account for this emergent issue, and we're still doing everything correctly in compliance with their current technical documentation. Just as you say, their system clearly has applicable tax/shipping amounts -- they're getting reported back to us in IPNs after payment -- and their checkout site just isn't adding those amounts to the buyer's final payment total.

That payment total gets calculated at PayPal's end without any influence from us once the buyer arrives there -- especially now that we're not even asking PayPal's system to callback to ours to recalculate tax/shipping, and even when we did, they'd still have the precalculated fallback amounts from our cart to apply in case the callback ever failed for any reason.

That was all working fine until early last week, so if nothing changed at our end, and nothing changed in their technical requirements to integrate with their end, which suddenly started sporadically failing to properly add up all the amounts we are correctly transmitting to them, the problem must be due to something that changed at their end, which they have to fix.

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.

They didn't give us any timeline or ETA, but at least they now seem to have a handle on just what the problem is and where, so hopefully it shouldn't take them much longer to get it sorted. 🤞

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.

Still no word from PayPal MTS about any progress or ETA on a fix at their end. The ticket we opened with MTS is Case # 10167138.

I have followed up on our PayPal MTS ticket once again to ask them for an ETA on their resolution of the issue.