|
office@lmgnow.com
|
May 19, 2020 at 11:00 am
I tested a registration myself after setting up my PayPal Pro gateway with EE4. After entering in my billing info and clicking “Proceed to Finalize Registration”, I receive the following error message:
“No response received from PayPal Pro”
I double checked the API credentials, no issues there. What should I try next?
|
|
Tony
|
May 19, 2020 at 12:22 pm
Hi there,
You’ll see that error message if nothing at all is received back from the cURL request set to PayPal.
If you go to Event Espresso -> Payment methods -> Logs, you’ll see EE create log entries through each payment step. Can you see any log entries for your attempted payments?
(Note you click on the ID to the left to view the individual log entries, not the TXN ID on the right)
|
|
office@lmgnow.com
|
May 20, 2020 at 1:24 am
Thanks yes I see the transaction logs.
In the logs, each txn has 2 entries.
The 2nd entry is blank/empty after the “RAWRESPONSE” section.
|
|
Tony
|
May 20, 2020 at 3:59 am
Which host are you using for the site?
“RAWRESPONSE” is the key in the array we check for, you said everything after that is empty, so RAWRESPONSE is not empty? If not can you post the contents of that section here (you can set the post to private so only support can see it).
Are you aware of the PCI compliance requirement when using PayPal Pro? (I’m just checking as it requires the highest level and often users aren’t aware of this)
|
|
office@lmgnow.com
|
May 20, 2020 at 11:08 am
The site is hosted on a GoDaddy Dedicated server with linux and WHM.
I also have another Dedicated server with GoDaddy (also linux and WHM), I moved the site to the other server and still got the same error.
Futhermore, it turns out that the txn was in fact successful. (the money is actually in the paypal account). But the backend shows it as a failed txn and the emails sent out by the system all report failure.
RAWRESPONSE is empty. Sorry if my language is unclear. The log shows the “RAWRESPONSE” section label but it is all blank after that label.
ID 52
Payment Method Paypal Pro
Transaction 2136
Content
Paypal Request
DPFields
paymentaction Sale
ipaddress ***.***.***.***
returnfmfdetails 1
CCDetails
creditcardtype MasterCard
PayerInfo
email *******@***.com
payerid
payerstatus
business
PayerName
salutation
firstname *********
middlename
lastname *******
suffix
BillingAddress
street ****************
street2
city ********
state *********
countrycode US
zip *****
ShippingAddress
shiptoname ***************
shiptostreet *********
shiptostreet2
shiptocity ****************
shiptostate ************
shiptocountry US
shiptozip *****
shiptophonenum **********
PaymentDetails
amt 152.00
currencycode USD
itemamt 152.00
shippingamt
handlingamt
taxamt 0.00
desc Event Registrations from American Subcontractors Association of Western PA for ASA Annual Clay Shoot
custom ****
invnum ***********
notifyurl
buttonsource EventEspresso_SP
OrderItems
l_name Admission for ASA Annual Clay Shoot
l_desc (For ASA Annual Clay Shoot)
l_amt 152
l_number 1
l_qty 1
l_taxamt
l_ebayitemnumber
l_ebayitemauctiontxnid
l_ebayitemorderid
ID 53
Payment Method Paypal Pro
Transaction 2136
Content
Paypal Response
ERRORS
REQUESTDATA
USER ************************
PWD ****************
VERSION 64.0
SIGNATURE ************************************
METHOD DoDirectPayment
BUTTONSOURCE EventEspresso_SP
PAYMENTACTION Sale
IPADDRESS ***.***.***.***
RETURNFMFDETAILS 1
EMAIL ************@***.com
PAYERID
PAYERSTATUS
BUSINESS
SALUTATION
FIRSTNAME ********
MIDDLENAME
LASTNAME ********
SUFFIX
STREET *****************
STREET2
CITY ******************
STATE ************
COUNTRYCODE US
ZIP *****
AMT 152.00
CURRENCYCODE USD
ITEMAMT 152.00
SHIPPINGAMT
HANDLINGAMT
TAXAMT 0.00
DESC Event Registrations from American Subcontractors Association of Western PA for ASA Annual Clay Shoot
CUSTOM ****
INVNUM **********
NOTIFYURL
L_NAME0 Admission for ASA Annual Clay Shoot
L_DESC0 (For ASA Annual Clay Shoot)
L_AMT0 152
L_NUMBER0 1
L_QTY0 1
L_TAXAMT0
L_EBAYITEMNUMBER0
L_EBAYITEMAUCTIONTXNID0
L_EBAYITEMORDERID0
SHIPTONAME **************
SHIPTOSTREET ***********
SHIPTOSTREET2
SHIPTOCITY **************
SHIPTOSTATE **********
SHIPTOCOUNTRY US
SHIPTOZIP *****
SHIPTOPHONENUM **********
RAWRESPONSE
|
|
Tony
|
May 20, 2020 at 12:16 pm
Ok, so the log is showing you the values passed to PayPal from EE’s side and then from RAWRESPONSE onwards it is what EE received back from PayPal (Nothing).
However, being on GoDaddy changes things a little as we’ve recently had reports of users having issues with PayPal on GoDaddy (EE3 rather then EE4 but the communication between them is using cURL either way).
If you’d like to view those threads the first is HERE and then the other HERE.
The short of it is that when CURLOPT_RETURNTRANSFER is set to true (so the values are returned rather then echoed to the page) the connection shows as failed (curl error 28, connection timeout) and returns false. If I manually set CURLOPT_RETURNTRANSFER to false the details are output to the page, that doesn’t fix the problem but shows something very strange going on with the cURL request.
I can’t say that’s the problem for certain, but it’s sounding very similar.
In the second thread, Godaddy blamed an SMTP plugin setting the FROM address to the TO address, meaning the email was sending to itself and failed, causing the connection to timeout. I’m not really sure I buy that as the cURL request to PayPal has nothing to do with emails, however it’s worth checking, so do you have any email/smtp plugins active on the site?
If you temporarily disable the EE messaging system in Event Espresso -> Messages -> Settings. Looks at Email settings and you’ll see a green toggle switch, switch that off and test a payment, does it work as expected then?
(Note 2 things about the above, it stops EE triggering any emails for your registrations whilst disabled, which is the obvious side effect of disabling emails. Something that may not be obvious is if you disabled any email messages by dragging them over to the disabled section on the above, when you re-enable the setting those message types may not longer be disabled)
|
|
office@lmgnow.com
|
May 20, 2020 at 1:33 pm
Thanks for that info. I already suspected it was an issue with the hosting, but after spending hours online with GoDaddy support they assured me that it’s not their fault.
I disabled all plugins except EE4, switched the theme to twentytwenty, and disable the messaging system as recommended, and I still got the exact same error. 🙁
Any other suggestions? Also, I’d be happy to give you access to the server if you’d like to take a look.
|
|
Tony
|
May 20, 2020 at 2:26 pm
I had access to one of the previous servers and couldn’t get it working, one site switched to Stripe as GoDaddy kept doing exactly the same thing and blaming EE. The other apparently had the above email issue but again, I’m not really sure that answer from GoDaddy is correct/valid. The cURL request sent to PayPal has literally nothing to do with emails, those are triggered AFTER that request is closed and processed.
I’ll happily double-check if that’s the issue on your site if you can send wp-admin and FTP credentials using this form:
https://eventespresso.com/send-login-details/
We would usually require a support token to work directly on a site but I could confirm the above fairly quickly using a script completely separate from EE and WordPress.
|
|
office@lmgnow.com
|
May 20, 2020 at 3:09 pm
That would be great! Thank you so much. I filled out the form.
|
|
Tony
|
May 21, 2020 at 5:27 am
Yeah, it’s the same issue.
The script I created uses my PayPal sandbox credentials to send a fake payment request to PayPal sandbox using a unique ID on each load (meaning you can re-test a payment simply by refreshing the page), it’s essentially the same request EE uses but runs without EE or WP using cURL directly.
The cURL response (which is what would be set to ‘RAWRESPONSE’) on my servers is something like this:
cURL Response:string(191) "TIMESTAMP=2020%2d05%2d21T11%3a12%3a58Z&CORRELATIONID=f8679cde9321a&ACK=Success&VERSION=64%2e0&BUILD=54492453&AMT=10%2e00&CURRENCYCODE=GBP&AVSCODE=Y&CVV2MATCH=S&TRANSACTIONID=1VU81865MW6181433"
cURL Error: 0
When I run the script on your server, I get:
cURL Response:bool(false)
cURL Error: 28
If I set CURLOPT_RETURNTRANSFER to false (explained above) a response similar to the one on my server (the values obviously won’t match exactly) is echoed to the screen yet the cURL response still returns false with error 28 (connection timeout).
This is something GoDaddy need to fix on their end, unfortunately, convincing them of that has not been easy so far. Also, note that my script has nothing at all to do with emails, so emails are not the issue.
I can share the script with you if you’d like to punch in your own sandbox credentials and test this yourself and/or show it it to GoDaddy tech support (you’ll need their higher-level tech support)?
|
|
office@lmgnow.com
|
May 21, 2020 at 11:35 am
OK thank you so much for checking that. Awesome support!
This problem wasn’t even an issue with EE. It is definitely a GoDaddy issue, yet you guys are 10x more helpful than GoDaddy.
I moved the site to BlueHost and everything works perfectly now!
Thanks again!
|
|
office@lmgnow.com
|
May 21, 2020 at 1:09 pm
Also, yes if you could share the script that would be awesome.
|
|
Tony
|
May 22, 2020 at 3:51 am
You’re most welcome, I’m glad it’s working fine on BlueHost for you.
The script can be found here: https://github.com/eventespresso/ee-code-snippet-library/blob/master/utility/tw_ee_paypal_pro_curl_test.php
Create a PayPal Pro sandbox account.
Input your user, password and signature into the script. You can find those details in the sandbox account in the same way you can from a live account:
https://eventespresso.com/wiki/paypal-pro-payment-gateway/#locate
But again, remember to use sandbox credentials here, not live. (Live credentials simply will not work at all as the request is sent to sandbox).
Place that script on your site, root is fine but it can go anywhere and then navigate to the script. You’ll see various details output to the page.
cURL Response: is whatever is returned by the cURL request.
cURL error: is any errors thrown on the request.
curl_setopt($curl, CURLOPT_RETURNTRANSFER, true); tells cURL to return the values rather than echo them (See the options HERE), set that to false and you’ll see at the top of the page the response gets echo’d. On GoDaddy’s servers that either echo’s and the request returns no errors, or it echos and returns an error, then if you set it to true, it will return false and error 28.
So far, this has only happened on GoDaddy servers and I’ve been unable to reproduce. That option is a standard cURL option and as you’ve seen works everywhere else so I have no idea what is different on their servers. I’m happy to investigate further if anyone provides any additional information but so far is just points to their config.
|
