|
stlsafety
|
August 27, 2015 at 1:30 pm
We are using FirstData E4 in EE3. I have the relay response set up as reference in an earlier support topic but the response is not going through. The Relay Response URL is tied to my Thank You page and includes the [ESPRESSO_PAYMENTS] shortcode. This is causing issue with paid registrants continuing to show a ‘Pending’ status. They are not showing complete even if moving directly through payment.
|
|
stlsafety
|
August 27, 2015 at 1:32 pm
We are using FirstData E4 in EE3. I have the relay response set up as reference in an earlier support topic but the response is not going through. The Relay Response URL is tied to my Thank You page and includes the [ESPRESSO_PAYMENTS] shortcode. This is causing issue with paid registrants continuing to show a ‘Pending’ status. They are not showing complete even if moving directly through payment.
Earlier support topic referenced above – https://eventespresso.com/topic/firstdate-e4-gateway-issue/
|
|
Josh
|
August 27, 2015 at 2:04 pm
When you test a transaction, do you still get the “cannot proceed with payment” error from FirstData?
Can you double-check your receipt page settings and make sure they look like this?
https://www.evernote.com/shard/s4/sh/7c1bf3d2-6d9a-4bf0-bcce-956d08352ea4/80ec0a0d025a8e3711a4df6917917065
|
|
stlsafety
|
August 27, 2015 at 2:23 pm
The payment goes through successfully but does send the registrant back to originating site. EE still show the registrant’s status as ‘Pending’ even though successful payment has been made.
Receipt page is set up as your screenshot suggests. Copy and pasted the Relay Response URL directly from EE to FirstData receipt page.
Does anything need to be done with the Response Key under 9. Security in FirstData set up?
|
|
Josh
|
August 27, 2015 at 3:35 pm
Technically FirstData E4 doesn’t ever send the user back to your site after a payment is made. Instead, they try to load up a page from your site from within a receipt page that they serve.
The Response Key field on Payment Page Settings page 9 isn’t used by Event Espresso, but you do need to copy the Transaction Key that’s listed just above there into the Transaction Key in Event Espresso > Payment Settings where it asks for FirstData E4 Transaction Key.
|
|
stlsafety
|
August 27, 2015 at 4:10 pm
Thanks Josh. Transaction key is set up as needed, EE matches the current key in FirstData.
|
|
Josh
|
August 28, 2015 at 8:16 am
Can you check with your host and make sure your server is set up to use posts 80(http) and 443(https) for all web traffic? Along with that, it’s very important that the server has HTTP access control disabled, or has access control configured to always allow connections from firstdata.com/authorize.net.
Along with that, can you check with First Data support to see if they have logged errors at their end? If they have a specific error code, it will help us troubleshoot.
|
|
stlsafety
|
August 28, 2015 at 8:57 am
Josh,
80 and 443 set on production servers. I just got off of the phone with FirstData and they have no errors logged on their end. I also set up a different payment page, linked to EE and experience the same issue.
|
|
Josh
|
August 28, 2015 at 11:19 am
Does the server has HTTP access control disabled, or has access control configured to always allow connections from firstdata.com/authorize.net?
|
|
stlsafety
|
September 2, 2015 at 7:52 am
Everything is set up as your question suggests.
|
|
Josh
|
September 2, 2015 at 8:49 am
Does your site allow for https connections? IE, do you have an SSL certificate set up for your domain?
|
|
Alyssa Pitchford
|
September 3, 2015 at 2:15 pm
I am having a very similar problem. Only, My transactions are going through and approved and first data shows a completed transaction page, however in my event overview all of my attendees are showing incomplete. Not sure if switching to managed wordpress hosting with godaddy has made a difference? or if first data e4 now being Payeezy is amking the difference?
thebetterhalfstudio.com
|
|
Josh
|
September 3, 2015 at 3:00 pm
Hi Alyssa,
Switching to Godaddy Managed Hosting may be causing this because they cache everything, which causes a few problems with the payment update because the thank you page needs to be served dynamically, not served from a cached file. The last time I checked Godaddy was not allowing managed hosting accounts to selectively turn off caching for specific pages. If you want a managed WordPress type hosting solution, I can recommend WPEngine because they’ll set up no cache rules for Event Espresso pages if you ask.
|
|
stlsafety
|
September 3, 2015 at 3:39 pm
Josh,
You mention ports 80 and 443 above. The plugin provides the option to require https but I have that turned off and http set as relay response. Should this work without https if set up correctly?
|
|
Josh
|
September 9, 2015 at 7:07 am
Maybe, but you’ll find that when FirstData E4 loads up the thank you page it will end up looking like this in some browsers:
https://www.evernote.com/shard/s4/sh/9f6a2f45-24c1-4389-b7e9-d4a322596efb/e11f95880620bd2549bb2e183a95345b
Some browsers will not load http content (in this case your theme’s stylesheets) onto an https page. So we recommend using https.
Another First Data E4 alternative that works without https is the Mijireh gateway integration that’s built into EE4. Mijireh works a bit different in that they do a “slurp” page where they take a snapshot of your site and do a nice job to make the billing form look like it’s part of your website.
|
|
stlsafety
|
September 10, 2015 at 12:20 pm
Josh,
Our access log is showing the following. Any guidance on where that error is being generated?
=================================Access log entry:
XXXXXXXXXX- – [09/Sep/2015:15:22:49 -0500] “POST /?type=firstdata_e4&page_id=732 HTTP/1.0” 500 3015 “-” “First Data Relay Response Agent, v1.9.3”
|
|
stlsafety
|
September 10, 2015 at 1:28 pm
Is it a requirement to set ‘Bypass Payment Overview Page’ to ‘Yes’ in order for relay response to work appropriately? This was previously set to ‘No’. I changed to ‘Yes’ and the relay response is now operating correctly.
I do, however, run into the style issue your pointed out due to use of http.
|
|
Josh
|
September 10, 2015 at 1:54 pm
It shouldn’t normally be a requirement to set the Bypass Payment overview page to yes, but if it makes a difference, it could mean something extra is getting passed from loading the page. So if something on the Payment Overview page is causing an error, then it’d make sense that bypassing the page would help.
The quick and easy way to avoid the style issue is use https and force https on the return page, which if you set that up you’ll need to update your response URL to https in the First Data E4 account.
The other option is set up a page template for that page that uses inline styles instead of trying to load a CSS file over http.
|
