|
Greg Phillips
|
November 13, 2013 at 2:23 pm
I’ve seen a few posts where you mentioned the need to make some modifications for hosted payment gateways on WPEngine. For example, Josh posted this elsewhere:
HTTPS is recommended if you’ll be accepting payments on-site. If it’s an off-site payment option like standard PayPal or 2checkout, it’s not needed.
If you do end up using HTTPS, getting this to work on WPEngine can be tricky. Here are a few things to know about using on-site payment methods if you’re hosted on WPEngine:
WPEngine has their own way of redirecting pages to https, so a plugin like WordPress HTTPS can not be used to make pages secure:
http://support.wpengine.com/disallowed-plugins/
In that case they’ll set up the https redirect for you. We’ve found that in the case where the site is using Pretty permalinks, it will force the Event Espresso Return payment page to use pretty permalinks, which then requires a slight modification to the gateway’s payment form. If you end up using a payment method that requires https and you’re using pretty permalinks let us know and we can walk you through how to make the modification.
Right now, we’re using Auth.net SIM and the return thank you page is loading but the various css resources are blocked as non-secure. Checking the “Force HTTPS” doesn’t solve the problem – and in fact, leads to an error from Auth.net:
An error occurred while trying to report this transaction to the merchant. An e-mail has been sent to the merchant informing them of the error. The following is the result of the attempt to charge your credit card.
This transaction has been approved.
It is advisable for you to contact the merchant to verify that you will receive the product or service.
Can you post the instructions on how to modify the payment gateway form to work with pretty permalinks?
Thanks!
Greg
|
|
Josh
|
November 13, 2013 at 3:01 pm
Hi Greg,
The simplest way to deal with this would be to install the beta version of Event Espresso 3.1.36, which has this change already in place. Or you can open up event-espresso/gateways/authnet/authnet_vars.php and change line 35 where it currently says:
$myAuthorize->addField('x_Relay_URL', $home . '/?page_id=' . $org_options['return_url'] . '&r_id=' . $registration_id . '&type=authnet');
to this:
$myAuthorize->addField('x_Relay_URL',my_espresso_build_gateway_url('return_url', $payment_data, 'authnet') );
Then add this to your theme’s functions.php file:
function my_espresso_build_gateway_url($type, $payment_data, $gateway_slug, $extra_args = array() ){
global $org_options;
$url = get_permalink($org_options[$type]);
$gateway_settings = get_option("event_espresso_{$gateway_slug}_settings");
if($gateway_settings['force_ssl_return']){
$url = str_replace("http://","https://",$url);
}
$query_args = array(
'id'=>$payment_data['attendee_id'],
'r_id'=>$payment_data['registration_id'],
'type'=>$gateway_slug
);
switch($type){
case 'notify_url':
case 'return_url':
$query_args['attendee_action']='post_payment';
$query_args['form_action']='payment';
}
$query_args = array_merge($query_args,$extra_args);
$full_url = add_query_arg($query_args,$url);
return $full_url;
}
Then what you’ll need to do is uncheck the Force SSL option in the payment settings, then contact WPEngine support and ask them to set up the Return page so it loads as https.
Note: The modification was made for Authorize.net in version 3.1.36 of Event Espresso. So when .36 is released your changes to the gateway file will be overwritten but the gateway will continue to work because it will have this same change built in.
|
|
Greg Phillips
|
November 13, 2013 at 7:55 pm
Thanks Josh. We implemented your suggestions and had WPE set the return page to load as https, and we still get the error:
An error occurred while trying to report this transaction to the merchant. An e-mail has been sent to the merchant informing them of the error. The following is the result of the attempt to charge your credit card.
This transaction has been approved.
It is advisable for you to contact the merchant to verify that you will receive the product or service.
We reverted back your changes and ran a quick test with a different thank you url page (so we bypass WPE’s rewrite) and we are successful at getting back to the thank-you page but with all of the insecure resources blocked.
Do you have any other suggestions on how to get this working or what specifically to request from WPE? I think their ngnx rules aren’t playing nicely with Auth.net… 🙂
|
|
Josh
|
November 14, 2013 at 9:03 am
When it was set up to use the secure return page, was the URL set in the Authnet account settings using the pretty permalink version of the URL?
|
|
Greg Phillips
|
November 14, 2013 at 11:07 am
Hey Josh,
We have tried just about every combination of settings in EE, Auth.net and with WPE and nothing worked. We think the issue has to do with Auth.net not accepting the SSL redirect on WPE. At this point, the only way we got it to work was to hardcode absolute secured paths to the resources that were blocked as insecure (i.e. style.css, jquery, etc.). Not the cleanest solution, but nothing else would work.
Would appreciate any help or suggestions on what exactly WPE needs to do with their redirects and SSL config to make sure EE and WPE work well together.
Thanks!
Greg
|
|
Josh
|
November 15, 2013 at 9:16 am
Hi Greg,
Does original payment page work if the site is set to use the default WP permalinks?
It will help to know what the relay response URL is in your Authnet account settings. Another thing to check is make sure that the “Force SSL box” is left unchecked in your Event Espresso>Payment Settings>Authnet SIM Settings.
|
|
Greg Phillips
|
November 15, 2013 at 9:35 am
We added multiple urls to the auth.net relay response settings to cover both http:// and https:// of the pretty permalink and “non-pretty” links. We tested it both with and without redirects set by WPE.
Did not test the option with turning off %postname% in the site permalinks, mainly because this would create problems with site links and SEO. But, that would probably be useful info to have.
Greg
|
|
Josh
|
November 15, 2013 at 11:41 am
It will help to narrow down the issue if you can post the actual URLs that you had set for the relay response.
It may also help narrow down the issue if you can run a quick test with the permalinks set to default -and- the thank you page set to use the page that’s set up to redirect as https.
|
