|
chris.sabido@gmail.com
|
October 18, 2017 at 12:47 pm
Can you please provide an update on the status of updating the QB Payment Gateway plugin to support oAuth 2.0?
We are unable to use the plugin because all new Intuit apps created only support oAuth 2.0.
Thank you!
|
|
Josh
|
October 18, 2017 at 2:49 pm
Hi there,
This was included in version 1.0.1 of the Quickbooks gqteway. If you do not see an update notification on your WordPress > Plugins page, you can go to the Event Espresso > General Settings admin page and click Update. That will force a check for updates and you’ll see an update notification on the WP > Plugins page.
|
|
chris.sabido@gmail.com
|
October 18, 2017 at 3:30 pm
Hi Josh, thanks for the quick reply. I was able to see the updated plugin by following your instructions to force an update.
I am having an issue with the redirect uri. In the help section in the plugin settings it says to use format of https://mysite.com (mysite.com is replaced with my real domain) however in the QuickBooks key settings page it says the format is invalid. It will only accept it if I add a tailing slash – so the format they want is https://mysite.com/. However then I get an error saying “The redirect_uri query parameter value is invalid” when clicking the connect button in the plugin. Any suggestions?
|
|
Tony
|
October 19, 2017 at 3:14 am
This looks like a bug on the QuickBooks site.
https://mysite.com is equivalent to https://mysite.com/, there’s really no exception to that for the root URL (another argument for other paths, but not root).
Another interesting note is that https://domain.co.uk is considered valid, yet https://domain.com is not – http://take.ms/FddkC
I’d recommend creating a ticket for QuickBooks support to investigate this (I’ve also contacted them but it may take a while for a response), I’ve also created a ticket to investigate this further on our end.
|
|
Tony
|
October 19, 2017 at 3:25 am
Hi Chris,
One thing we can do is patch the payment method to add a trailing slash to the URL when its passed to QuickBooks.
I’m not sure if that’s the direction we will take officially (as I do think this should be fixed on QuickBooks end rather than within EE) but I can send you a patched copy of the payment method for you to test and confirm if that works on your site if you would like?
|
|
chris.sabido@gmail.com
|
October 19, 2017 at 4:44 am
Hi Tony, I have opened a ticket with QuickBooks to see if they can resolve on there end.
I was able to modify the code to add the trailing slash so I can workaround their bug for now but hopefully they will resolve it soon.
Thanks so much for your help!
|
|
Tony
|
October 19, 2017 at 5:03 am
You’re most welcome, I’m glad you have it working.
On the fix you use, did you just add something like $redirect_uri = trailingslashit($redirect_uri); below both instances of $redirect_uri = site_url(); within EED_QuickBooks_Oauth_v2.module.php?
I’m just wondering as you have it working already so I can note on the ticket, the above fixed it for me either way.
|
|
chris.sabido@gmail.com
|
October 19, 2017 at 11:44 am
Hi Tony, yes that is what I did to make it work as well.
|
|
Tony
|
October 19, 2017 at 1:47 pm
We’ve just pushed an update to the QuickBooks payment method with the above fix included.
Whilst I do still think this should be fixed on QuickBooks side we have no idea on timeframes from them our fix at least fixes the problems for our users right now.
|
|
chris.sabido@gmail.com
|
October 20, 2017 at 6:15 am
Thanks Tony!
We heard back from QuickBooks support and this was their reply:
“It is a security requirements configured by QBO Gateway Team. I believe we once had a debate whether we should allow omitting www or not, and the decision is we don’t want to allow it. I will send your comments to the project managers and see what they will say to it.”
|
|
Tony
|
October 20, 2017 at 7:40 am
Hmm, if they class this as a security risk then it actually makes it worse.
(‘Naked’ domains don’t cause security issues imo but anyway)
So… http://www.domain.com is valid and ‘secure’.
http://domain.com is invalid and ‘insecure’
http://domain.com/ is valid and ‘secure’….
I think there are some crossed wires with the support tech that replied but either way I’m glad we went with the above fix so we at least have something consistent 🙂
|
|
chris.sabido@gmail.com
|
October 27, 2017 at 6:33 pm
Hi Tony, it worked perfectly in debug mode but trying to use it in production it doesn’t work.
The error I’m seeing is (note it really doesn’t give any details):
“QuickBooks Card Authorization/Capture Error:”
I made sure to disconnect, input the production api information and then reconnect.
QuickBooks Payments Gateway plugin version: 1.0.2.p
Have tried turning on the debug logs under general -> admin options but no details are showing up regarding the error.
Any suggestions?
|
|
chris.sabido@gmail.com
|
October 27, 2017 at 6:37 pm
I guess it would help to mention where I’m seeing this error! -sorry
This error happens when trying to make a payment through the plugin on the registration form.
|
|
Josh
|
October 28, 2017 at 8:56 am
Do you get the same error if you try a different credit card?
|
|
chris.sabido@gmail.com
|
October 30, 2017 at 6:25 am
Hi Josh, yes different cards were used but they all results in “QuickBooks Card Authorization/Capture Error:” – with no actual message after the colon.
|
|
Tony
|
October 30, 2017 at 6:41 am
Could I take a look at the payment logs on the site?
If so you can send temp login details using this form:
https://eventespresso.com/send-login-details/
You can find them yourself in Event Espresso -> Payment Methods -> Logs but I’m looking for any clues QuickBooks are providing (as they aren’t providing an error) so not sure what will be available in the logs.
|
|
chris.sabido@gmail.com
|
October 30, 2017 at 6:44 am
Hi Tony, I didn’t see any clues under the Payment Methods log so I’ll send you login details.
|
|
Tony
|
October 30, 2017 at 11:36 am
The error being thrown during your payment request is:
"code":"PMT-4000","type":"invalid_request","message":"ExpirationMonth/ExpirationYear. is invalid.","detail":"ExpirationMonth/ExpirationYear."
Can you double check those values (Expiry month/year) are being set correctly during payment, please?
|
|
chris.sabido@gmail.com
|
October 31, 2017 at 6:32 am
Hi Tony, it seems to be working fine now.
Can you point me in the direction to find the detailed error you pasted above?
When I look under Espresso -> Payment Methods -> Logs it doesn’t show any of the message you provided above.
Thank you!
|
|
Tony
|
October 31, 2017 at 6:52 am
Sure it does, that’s where I got the info from 🙂
So within Payment methods -> Logs.
You’ll have this – http://take.ms/PP1u1
Log entry 40 and 41 are from the same transaction and show the problem.
Open up entry 40 (click the ID) you’ll have this – http://take.ms/4mGvvB
41 is the one that shows the problem – http://take.ms/sO9Lx
|
|
chris.sabido@gmail.com
|
October 31, 2017 at 8:12 am
Ahh okay I was clicking the wrong thing. On the first screenshot (Log page) I was clicking the “view txn” link not realizing that the ID number link would take me to a different view. Thanks for the tip!
|
