|
Richard Wallis
|
August 22, 2019 at 10:47 am
As September is approaching rapidly can I get an update on this please.
|
|
Josh
|
August 22, 2019 at 11:52 am
Hi Richard,
I’m afraid I have no information on this. If you subscribe to our newsletter you’ll get an email about SagePay when it’s ready.
|
|
westonemanor
|
August 27, 2019 at 3:40 am
Hi Josh,
Can you guarantee that an updated SagePay plugin will be available before the deadline?
|
|
Josh
|
August 27, 2019 at 8:39 am
We’re planning on having it ready. That said, we have yet to hear back from SagePay wrt some issues with their testing environment. In other words there are factors outside of our control so no guarantees.
|
|
Richard Wallis
|
August 27, 2019 at 8:48 am
As SagePay customers, that will have to move to another payment provider if this update is not available in time; is there any pressure that westonemanor and I can focus on SagePay to help resolve this?
~Richard.
|
|
hoffman
|
August 27, 2019 at 10:22 am
And us! Thanks for reopening this, Richard.
|
|
Richard Wallis
|
August 29, 2019 at 3:57 am
Hi Josh,
I lieu of definite information and assurances as to the availability of a 3D Secure fix to the SagePay plugin sufficiently prior the deadline of September 14th to allow for confirmatory testing on our part; we need to start implementing disaster planning to protect our trading image and revenue stream. The plan to include software development/testing, investigation of alternative payment providers, and associated unexpected costs.
To that end, can you provide some information to help with shaping the plan.
In response to my original support request, you indicated that a potential alternative would be to use the Stripe add-on “which will have its 3D Secure updates ready sooner“. Can you confirm if that route now full supports the 3D Secure requirements.
If that is the case, can you confirm how different the user operation for making payments in the Stripe add-on differs from that in the SagePay add-on – my experience in moving from the Mijireh add-on was not as simple as I would have assumed.
It is my hope that you will achieve a fix in time, and such a disaster plan will not have to be carried through. However I am sure you can understand why we need to be making plans, and provisionally allocating associated development & testing time and resources.
If you are still held up by lack of response from SagePay, my offer to provide pressure (as a customer that will be forced to leave) on them is still open. I would also be willing to explore with your developers how my access to a SagePay sandbox test service could be utilised to help.
~Richard
|
|
Josh
|
August 29, 2019 at 12:27 pm
Can you confirm if that route now full supports the 3D Secure requirements.
Yes, the new version of the Stripe add-on is released, and it includes the Stripe Elements integration, which supports 3DSecure Authentication. You can learn more about it here:
https://eventespresso.com/2019/08/event-espresso-stripe-add-on-adds-psd2-compliance/
can you confirm how different the user operation for making payments in the Stripe add-on differs from that in the SagePay add-on
The two are similar, but there are a few differences with the default billing forms.
This screenshot shows an example of the SagePage billing form:
https://slack-files.com/T02SY781D-FMHDQNWFL-dbec931344
This screenshot shows an example of the Stripe Elements billing form:
https://slack-files.com/T02SY781D-FMNFP5JL9-ae9e2f2804
|
|
westonemanor
|
September 2, 2019 at 1:06 pm
Hi Josh,
It is now September so surely you’ll have an idea on whether or not the SagePay plugin will be updated in time. Clearly the plugin will not be updated in time which also factors in the time required for end users (i.e. your customers) to update and test the plugin.
An email should have been sent out informing your customers who use the SagePay plugin (and any other payment plugin which wouldn’t be compliant) instead of us having to fish for information with such a degree of uncertainty – “factors outside of our control so no guarantees”.
Now that it is clear we have to use the Stripe plugin in order to stay compliant (and still pay SagePay at the same time because we are tied into a contract). This means we have to bear the cost of a delayed plugin.
Your developers had two years to update the plugin (PSD2 was announced two years ago to prepare users for this change) – surely this is long enough? While I understand that there can be issues etc. surely this could be addressed more clearly with your customers with periodic updates?
|
|
Josh
|
September 3, 2019 at 1:13 pm
Hi,
We’re still planning on having an update to the Sage Pay plugin released before 14 of September when new requirements for authenticating online payments are introduced in Europe as part of the second Payment Services Directive (PSD2).
|
|
Josh
|
September 4, 2019 at 4:46 pm
Update: The Sage Pay add-on for Event Espresso 4, version 1.1.6 is released. The new version adds a new “Server Integration” payment method that supports 3DSecure. After you update the plugin, you will need to go to Event Espresso > Payment Methods and activate & configure the new payment method, and deactivate the old Sage Pay payment method.
You’ll find more details in the documentation:
https://eventespresso.com/wiki/sage-pay-payment-gateway/#setup
|
|
Richard Wallis
|
September 6, 2019 at 9:12 am
Thanks for the update.
However I am getting errors:
An error has occurred:
It appears the Off Site Payment Method was not configured properly.
Please try again or contact …
EE_SPCO_Reg_Step_Payment_Options – _post_payment_processing – 2430
|
|
Richard Wallis
|
September 6, 2019 at 9:19 am
I tried reactivating the original SagePay payment method and now get the same error.
We now cannot take payments!
|
|
Josh
|
September 6, 2019 at 9:30 am
Hi Richard,
You’ll need to follow the documentation where it says to add your Sage Pay Vendor Name to the Sage Pay Server Integration settings page.
https://eventespresso.com/wiki/sage-pay-payment-gateway/#setup
|
|
Richard Wallis
|
September 6, 2019 at 10:12 am
(Please ignore my supplementary message – we can now take payments via the origonal SagePayment method)
I had followed the documentation.
The SagePay vendor name was/is set.
Still getting the same error.
|
|
Josh
|
September 6, 2019 at 10:29 am
You’ll need to make sure the vendor name is correct in the Sage Pay Server Integration settings page. If it’s not correct, the error message you reported will be shown.
|
|
Richard Wallis
|
September 6, 2019 at 10:34 am
Don’t you think I checked that!
It was actually copy and pasted from the original SagePay method settings…..
… and checked and reset.
~Richard
|
|
Josh
|
September 6, 2019 at 10:49 am
Don’t you think I checked that!
Of course, but I’d be remiss if I didn’t mention it. Mistakes happen and we’re all human.
What you can do is check the Transaction entry of the failed transaction on the Event Espresso > Transactions page. When you view that entry, you’ll see a link that says “View additional transaction session details”. You’ll click that link and find the “Gateway Response” column. What’s the error code there say?
Alternatively you can get even more information about the failed payment by going to Event Espresso > Payment Methods > Logs. Then find the log entry that matches the failed transaction. Click the ID for that row, then scroll down to the “Response” section. The “Status” value will probably say INVALID. More information will follow starting with “StatusDetail”.
-
This reply was modified 5 years, 2 months ago by
 Josh. Reason: updated the information about transaction & payment logs
|
|
Richard Wallis
|
September 6, 2019 at 11:08 am
Sorry for my terseness in my previous message – patience is a little in short supply here at the moment.
Transaction was status incomplete.
However it has the following gateway response:
3082 : The Description value is too long.
|
|
Josh
|
September 6, 2019 at 12:06 pm
Ah ha! That’s a very useful message.
I did some checking and what’s happening is the new server integration payment method sends a different description, which pulls in the website title. Since your site’s title is a little longer than average, you’ll likely want to send a shorter description.
Here’s how to do that:
1) Add this code to the site:
add_filter( 'FHEE__EE_Gateway___order_description',
'my_custom_order_desc', 10, 3
);
function my_custom_order_desc($desc, $gateway, $payment) {
$desc = 'Tickets';
$long_desc = 'Tickets for ' . $payment->get_first_event_name();
if (strlen($long_desc) < 100 ) {
$desc = $long_desc;
}
return $desc;
}
You can add the above to a functions plugin. If you’re not sure how to create a functions plugin, the above link will show you how.
2) Activate the plugin.
What the plugin will do is completely remove the site’s title from the description sent to Sage Pay, and instead send “Tickets” or if allowed by Sage Pay’s limit it will send “Tickets for {event name}”.
|
|
Richard Wallis
|
September 6, 2019 at 12:33 pm
W00t! Success.
Got there in the end.
Thank you for finally bringing this saga to a positive conclusion.
~Richard.
|
|
westonemanor
|
September 9, 2019 at 9:42 am
I’ve noticed with the new sagepay plugin, when a customer abandons their card (eg, reaches the SagePay site but doesn’t complete their order), the registration changes from pending payment to approved despite the total paid is £0.
I’ve done two test transactions on my site (didn’t complete it) and both were automatically changed to the approved state.
Is this a known issue?
|
|
Tony
|
September 9, 2019 at 10:26 am
It’s not a known issue and I can’t reproduce, with the exception of when the events ‘Default Registration Status’ (DRS) is set to Approved.
I checked over your events and can see that is what you have you DRS set to. With that setting, you basically tell EE to ignore the payment status and on registration finalization set the registration status to Approved.
So it is expected with your current setup for registrations to be Approved regardless of payment status and will happen with any payment method if the user hits the thank you page or if its an offsite payment method (like SagePay) once the users session expires and EE uses a cron job to confirm the payment hasn’t been made.
The majority of users want to use a DRS of ‘Pending Payment’ which means the registration does NOT apply to the sold values until payment has been made (or you manually approve the registration). Approved registrations apply to sold values, all other statuses do not.
So if you don’t want the above to happen, you’ll need to switch your events to use a DRS of ‘Pending Payment’ (which is the default DRS Event Espresso uses). If you have also set your site’s default DRS to be ‘Approved’, you may also want to change that in:
Event Espresso -> Events -> Default settings
That value is used when a new event is created, the event itself saves the value set and it is then a per-event setting, so changing the above does not affect current events and you will need to changes those individually.
|
