We're still only getting vague assurances like this from PayPal MTS when we ask for a status update or ETA:

We are aware of this issue and our engineers are currently working on it. Will let you know once there is an update on the matter.

At this point, we'd like to reiterate a suggestion we made earlier in this thread, during the first time this issue occurred last year:

If you'd like to offer buyers a different checkout method, this help page lists all the payment services we support3; 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 Stripe1 in particular if you're based in any of the countries they support, 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.

Better yet, if your site loads with an https:// URL and has our cart appearing as an overlay within your own sales pages3, our secure checkout screen for card payment can use the same overlay as our cart, which helps reassure buyers for better sales conversions.

Sorry to hear you're getting the runaround from PayPal. Evidently their right hand doesn't know what their left hand is doing, so every MTS ticket anyone opens about it is getting treated as a separate, isolated issue with little if any context relating it to other pertinent tickets, rather than instances of a single, common issue at their end.

At least that "Jeremy" seemed to be aware of a "callback URL" issue they'd mentioned in a related ticket, which we'd already responded to as a red herring -- they were saying our callback URL didn't return any shipping options, but that was a case where the seller they'd tested with doesn't even sell any physical goods that require shipping, so of course no shipping rates were returned in that scenario, where (until this issue arose) they'd heretofore always applied the precalculated tax amount we passed to checkout in the first place.

I don't know if responding to your own MTS ticket would do any good, but if you do, it may help to reference our own MTS case # 10167138, where PayPal has confirmed the issue at their end that they're working to fix and been escalated at their end.

PayPal is being cagey about exactly why or how the problem is happening, so we have no way of knowing whether their own purchase buttons would be affected or not.

Yes, the issue is sporadic, affecting only some transactions but not others, which has made it challenging for us and PayPal to troubleshoot.

We and a few clients did some testing that -- at least as far as we could tell from our limited test-sample sizes at the times we tested -- seemed to suggest occurrence of the issue might correlate with the following conditions:

• Buyer chose to fund the payment from their PayPal account balance, rather than from a linked card or bank account;
  ...and/or...
• Buyer clicked a link on the PayPal checkout site to view available shipping methods, but then neglected to manually select the sole shipping method available there*, yet PayPal let them go ahead and finish checkout anyway.

*Since we can already offer a choice of shipping methods (if the seller sets those up) in our cart before checkout, we only transmit the buyer's sole selected shipping method and rate to PayPal checkout, so there's only ever one method/rate available there.

That said, we don't know if those tentative findings would remain consistent across a larger volume of transactions, or if those tests just happened to coincide with PayPal tweaking things at their end that may have caused those results only temporarily, as they remain cagey about discussing any particulars whatsoever. We have at least reported those findings to PayPal in our MTS ticket about the issue.

If you want to keep your own PayPal MTS ticket open in addition to ours, you could just followup on that to reference our own MTS case # 10167138, which has been escalated and is currently set to "On Hold - Internal" status pending further action or updates from PayPal.

Interesting, this is the first we're hearing anything about "eJunkie not adapting to those changes as intended", assuming that's not just a buck-passing excuse. They certainly never informed us we needed to change or update anything, and our PayPal integration is still fully compliant with their current documentation for it.

@mbw - We'll followup on our own MTS ticket to inquire further about that with PayPal; what's your MTS case #, so we can reference that in our followup?

Thanks for that; I have now followed up on our own MTS Case # 10167138 accordingly.

Here's how PayPal MTS responded to my followup seeking clarification re: "adapting to changes as intended":

Our engineers have figured out the root cause of this issue that is caused by our system. They are currently working on a resolution to this issue. And I was not informed to have you make any changes in your integration. So you don't need to change anything at this time. If I have any further updates on the matter will let you know.

I followed up on our own MTS ticket to verify that this bug is indeed fixed. They replied Friday evening to clarify:

We have made the fix, but it is going out in the next release cycle which should be within the next week. We will restart the experiment and monitor after the release has finished to make sure things are working properly. Will let you know once it is done.

PayPal MTS has now confirmed the fix was rolled out to live production last night. Let us know if you encounter any problems going forward. Thanks again to everyone for your patience and cooperation in riding this out.

Oh dear. We'll open another ticket with MTS about that.

It would help if you could email us an affected Transaction ID and, if possible, the IPN Message for that transaction, which you can copy from your PayPal IPN History -- for instructions to access and copy that IPN Message, see Part C, Step 2 here:

It was resolved, until @mdgbv reported a regression of the issue for them last week, though they're the only one reporting that so far.

As for the new ticket we opened with PayPal MTS about it (case # 10666290), they confirmed Sunday night they'd escalated it to their engineers for correction, still awaiting any further updates from them about it.