Posted: September 11, 2019 at 11:40 am
Regards EE4 stripe plugin. We’ve transferred to “Elements” for SCA compliance.
Checkout experience is now a bit janky. Fill in identity fields, then proceed…user is taken back *up* page with choice of payment options above fields just filled in (bad), and the onscreen instruction to “Click Pay Now” which is neither on screen (bad) or even the next action to take (bad). That next step being to fill in credit card details. This all seems to be straight lifted from the Stripe Legacy flow which worked in the context of a modal, but is now disorientating for customers and will hurt conversions for sure. Please let us know that this is going to be tidied up in an upcoming patch 🙂
What you’ve described doesn’t sound like the new Elements checkout. May I ask can you share a URL to an event page so we can investigate further?
Testing live payments on Stripe is against their TOS (See HERE), they provide every account with live and test keys to allow you to test payments in exactly the same way live mode works.
We (Event Espresso) will also not test live payments if test/staging/debug mode is available on a payment method.
To work through the points raised:
They provide the attendee information on step 1, this may or may not match the payment info fields loaded on the payment information step.
What is actually happening, is the payment information step is loading after the attendeee info and the details used in attendee information step is preloaded into the required Stripe fields. As mentioned above the payment information may not match the registrant info, so we need to provide the opportunity to change those fields.
The ‘Click to Pay Now’ text is set on the payment method itself and you are fre to change it to whatever you prefer, you do this in:
Event Espresso -> Payment methods -> Stripe -> Description.
With regards to the what I assume you mean, the pay now button being offscreen, the fields loading in the payment info section change depending on your settings so with the current setup the pay now button loads at the bottom, I’m not sure how we can make sure that is always above the fold on load.
It’s not just the card details, its any payment information. Any of the payment info fields can be changed during that step.
The steps used are the same for ‘onsite’ payment methods, Stripe isn’t technically onsite but point being that Stripe checkout was the exception to the normal flow of EE’s payment methods.
Attendee info – > Payment options (which includes providing all payment fields) -> Click to pay (which whichever button it is set up to use) -> Thank you page.
Stripe checkout had:
Attendee info -> Payment options -> Click to pay -> Modal -> Pay -> Thank you page.
If the above appears to simply dismiss your feedback, that’s not intentional, but may I ask how you would prefer this to work?
Thanks for your thoughtful answers and the TOS insight, I will certainly work with that in future. That said, we’re not actually starting a transaction here as the issue occurs before even filling in card details so we’re certainly not creating live charges.
Absolutely, yes, it all needs to be done. But it doesn’t need to be done this way, surely? By returning the user to options above what the user has already filled in, and then putting the fields they need to change below what they have already filled in, further with inline text that gives the incorrect next step, the process sows confusion to the uninitiated.
EDIT: Reposted for clarity – apparently, I can’t close tags ?
Yeah I know, it’s just with you setting the events to use a 50p charge, which just so happens to be the Stripe minimum, it hinted towards completing the transactions which could potentially cause you to lose you Stripe account (tbh, its unlikely but better safe than sorry).
Possibly not, I personally don’t have an issue with adding card details in the way we request them but I’m not saying it can’t be improved which is why I ask, how you would you prefer we collect that info?
Again, the user has not filled those fields, we have auto-filled them with the details we can use from the attendee information. That is an important distinction because it’s an assumption on our part that the payee is generally going to be the attendee and that needs to be confirmed by the user. We could simply leave those fields blank but then I’m certain we’d see other threads asking why we don’t auto-fill the details and provide the user with an opportunity to change them.
In fact, we’ve had those exact threads before for other on-site payment methods.
The text is a little confusing and I’ll create a ticket to change that. However, adding your details to a payment options step is common practice so I don’t see how confirming the details and adding your card details is confusing, but we can try and make it a little clearer.
The other option is to simply hide those inputs and send over the attendee information as is, but again, that’s another assumption that the attendee is always the payee and that’s not always going to be correct.
The prompt could be hidden completely with CSS if that helps any? Personally I prefer it, but as mentioned I do agree the text needs to be changed a little.
(Note I’ve trashed your ‘broken’ reply, so now your edit comment makes no sense, until this comment 🙂 )
Ahah, interesting! This is…
🙂 thank you, we try.
In your case, you kind of have the perfect storm…
On attendee information, you only request first name, last name, email address.
On the payment options, you only have a single payment method available (Stripe).
You have the Stripe payment method to be open by default, so it displays the 3 required fields straight away, which again, just so happen to be the only 3 fields you require on your registration form (attendee info).
It becomes much more obvious when your registration form has different fields to the payment form. As a quick example, go to Event Espresso -> Payment methods -> Stripe -> Collect the user’s billing address?
Set that to Yes, save and refresh a checkout page, now the payment form has additional fields compared to the reg form.
(Change the option back and save again, you can leave the checkout page as is to view it but any new registrations will no longer have the address fields requested)
So, I don’t have anything against that setup up, but it does break up the payment form a little and I think it’s unlikely something we would add to the core plugin… however, with the hooks available within EE and the fact that you can load custom versions of various template it should be possible to do the above yourself. I can check into it and let you know which hooks are available if interested?
Also, I should add in regards to this:
Stripe obviously felt different about this as it was Stripe that dropped support for the modal checkout, not EE, when they introduced support for Strong Customer Authentication (SCA) to fall in line with PSD2.
Technically they didn’t drop ‘Checkout’ but they did completely change it to be more like a traditional ‘off-site’ payment method where the user is directed off-site, makes the payment and then back again. The modal Checkout is still available but will not support SCA, making it effectively useless for anyone in the EU.
So, right now the options are to either have some form of on-site setup like we have, or switch to Checkout and completely redirect the user to Stripe.
The support post ‘Usability/flow issue with Stripe Elements checkout’ is closed to new replies.
Have a question about this support post? Create a new support post in our support forums and include a link to this existing support post so we can help you.