- This topic has 41 replies, 4 voices, and was last updated 9 years, 9 months ago by
.
-
Posts
-
I think I’ve fixed it – I deactivated PayPal Payments for WooC. and the payment was split properly.
Will test it again in the morning to be sure, will let you know.
Hi Douglas,
I’m sorry to hear that your test from Friday didn’t work. The log data makes me wonder if the entire transaction was processed using something other than our own Tribe Adaptive Payments gateway – and if you have any further feedback on that count we’d love to hear from you.
I think I’ve fixed it – I deactivated PayPal Payments for WooC. and the payment was split properly.
Great! Are the problems now resolved?
Not yet. The Test/Sandbox DID work – split the payment properly. When I went live, it doesn’t work. I was not able to get it to log the new event, either.
I’ll send more details later today. Have things to do this morning.
That’s a shame.
The log again looks somewhat dissimilar to what I’d expect, though – more in line with the log file output I’d expect from WC_Gateway_Paypal_IPN_Handler (one part of WooCommerce’s bundled PayPal gateway).
Are you absolutely positive that:
- You are viewing the correct log file? Ours ought to be named something like tribe-paypal-adaptive-payments-(unique_code).log (date)
- Have you disabled all other payment gateways, such as the PayPal gateway bundled with WooCommerce?
On that final point, please do note that the user interface found in WooCommerce → Settings → Checkout is slightly confusing as (presently) the tribe-paypal-adaptive-payments gateway will appear not to be activated. This may make you think that you need to enable/see a check mark next to the regular WooCommerce PayPal gateway, but that isn’t actually so.
Hello,
Thank you for reporting this issue. We weren’t able to get a fix for it into our upcoming release (4.1). However, please know that the problem is still on our radar and is ticketed within our system to be addressed in a future maintenance release. We’ll do our best to keep you posted when we are able to get a solution in place. Thank you for your patience while we improve and expand our plugins.
Best,
LeahI’m sorry, Leah – what’s that? You’ve classified this now as a known “issue?” That it’s not going to work until a “fix” is published?
ok, Barry, ya’lls stuff is really confusing. This is getting quite tiring, esp when your explanation of setting up PayPal sandbox is so incorrect.
Right, Tribe Adaptive Payments is found in WooCommerce settings, which makes no sense if we’re not to use WooCommerce paypal settings. Under WC Checkout, Enable PayPal standard is not enabled and never has been.
Under Events Settings Community, Live PayPal info is correct.
What does Leah mean that this has been reported as an issue to be fixed in the future? Has this option not been seen to work yet, or has it worked before? (She hasn’t even answered my query re this…)
My client has paid 300 dollars for this software and you say you’re not willing to login our backend after I’ve given you permission to to help us fix this?
Hi Douglas,
What does Leah mean that this has been reported as an issue to be fixed in the future?
I’m sorry if this caused some confusion, but let me explain.
Our exchange so far has highlighted a number of valid problems and so I went ahead and logged a number of action points on our internal issue tracker, some of which were geared towards improving our documentation and others at improving the plugin’s user interface.
Close to the end of each release cycle, Leah (or another team member) looks through our list of outstanding issues – including those logged during the current cycle – and drops by each related forum thread to update users like yourself. This thread is particularly long and covers a lot of ground so it may not have been clear exactly which problem Leah was referring to and, again, I’m sorry if that was confusing.
In short it can be distilled down to this: we’re taking a lot of your feedback on board and will be making some changes, but given where we are in our development cycle those changes will not be realized in our very next release.
My client has paid 300 dollars for this software and you say you’re not willing to login our backend after I’ve given you permission to to help us fix this?
It looks as though we’re still within 30 days of purchase: naturally we’d be sad to lose you, but I do feel it’s worth highlighting that you are still eligible for a refund if you prefer to take that course of action.
I would also like to be clear that I did not say we were unwilling to login to your site, only that in general we prefer not to – which is as much for your security and peace of mind as anything else. With that said, I did just attempt to login so I could observe some of your settings but was unable to do so:
- Are the username and password you provided earlier still valid?
- Can you confirm the correct URL I should use when logging in (I just want to double check this, as the regular WP login screen seems not to be accessible)?
Thanks!
That’s good to hear, just a shame the experience has been a little frustrating. In any case – thanks for the fresh login. Here’s a piece of logged data that might be important:
The X-PAYPAL-APPLICATION-ID header contains an invalid value
So that maps to the Events → Settings → Community → PayPal Client ID field – can you confirm this is correct and that it (and indeed the other settings beside it) were all updated when you switched from sandbox testing to live?
Just checking in here: did you have a chance to check out and possibly revise the PayPal Client ID and any other related values? Are things working for you now in terms of receiving and splitting live payments?
- The topic ‘ETickets Split Payments debits test Buyer but Receiver account gets nada.’ is closed to new replies.