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.
Something weird is happening now. All orders are without the shipping charge and the weird thing is that now ejunkie is no longer saying suspected fraud it just shows like a normal sale but still the shipping is not added. Are you guys sure that this has nothing to do with ejunkie?
I received another sale today and the email message that I received from E-Junkie contained the words "Suspected Fraud" and the buyer was not billed for shipping just like before.
Sorry about that @universalsynergygroup -- our Devs briefly attempted a workaround last night that should have allowed us to process/log affected orders as normal and email the seller a Suspected Fraud notification when tax/shipping was unpaid, but that didn't work out as expected, so they promptly rolled that back and went back to the proverbial drawing board.
I appreciate you guys still trying to fix this problem. We really need to get this resolved ASAP as 99% of all sales we are receiving now shipping is not added and its costing us too much.
I just a received another sale today and, in this case, my customer was charged for the cost of shipping. The one difference from earlier sales was that this one also required a charge for sales tax. I don't know if that had anything to do with the fact that the shipping cost was also billed properly.
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.
Thank you for contacting PayPal Merchant Technical Support. We recently responded to your case. This is a courtesy email to inform you that your case will be closing shortly. However, you can keep the case open by replying with any new details or create a new ticket in the future.
Case Number: 10224177
Subject: Guest checkout deducts shipping cost for all guest buyers
Date Created: February 17, 2022
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.
Nothing new to report. Every time I followup on our MTS ticket to ask for a status update, they just say they're aware of the issue and have escalated it to their engineers who are working on a solution.
Received the following reply from PayPal Global Technical Support regarding my inquiry about this problem:
"Our Engineers are currently working on temporary measures to address the issue. The problem is twofold between eJunkie, and PayPal related to the way our Integration has changed over time and eJunkie not adapting to those changes as intended. I believe the plan is to roll back some of those changes, but I am still wanting on a confirmation on that situation."
As I read it, this blames e-Junkie.
My response so far has been to no longer use PayPal with the e-Junkie cart.
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?
The case number is 10200744. I opened it on February 7, 2022
Here's the full email:
Dear M B Walker,
Our Engineers are currently working on temporary measures to address the issue. The problem is twofold between eJunkie, and PayPal related to the way our Integration has changed over time and eJunkie not adapting to those changes as intended. I believe the plan is to roll back some of those changes, but I am still wanting on a confirmation on that situation.
I will update you as soon as I know more. I apologize for any inconvenience.
Thank you,
Brian
Global Technical Support
PayPal, Inc.
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.
Received this reply from PayPal support:
Hi Dale,
Developers have resolved this issue. Please confirm resolution by replying to this ticket. Thank you for your business and I hope you have a great day!
Sincerely,
Jeremy
Global Technical Support
PayPal, Inc.
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.