Support

Home Forums Event Espresso Premium Usability/flow issue with Stripe Elements checkout

Usability/flow issue with Stripe Elements checkout

Posted: September 11, 2019 at 11:40 am


AHI

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 🙂


Josh

  • Support Staff

September 11, 2019 at 11:45 am

Hi,

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?


AHI

September 11, 2019 at 1:27 pm

This reply has been marked as private.


Tony

  • Support Staff

September 11, 2019 at 1:58 pm

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:

Fill in identity fields,

They provide the attendee information on step 1, this may or may not match the payment info fields loaded on the payment information step.

user is taken back *up* page with choice of payment options above fields just filled in (bad)

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.

and the onscreen instruction to “Click Pay Now” which is neither on screen (bad) or even the next action to take (bad).

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.

That next step being to fill in credit card details.

It’s not just the card details, its any payment information. Any of the payment info fields can be changed during that step.

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.

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?


AHI

September 11, 2019 at 2:43 pm

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.

we need to provide the opportunity to change those fields.

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.
The modal pathway was markedly superior UX as the customer never had to look for the next step: it was always in front of them. This change is certainly a conversion issue. It’s nothing inherent to modals, and I’m sure a smoother checkout is possible with a better flow and more relevant prompting.
Thanks for details/path on how to change inline help text. Very useful. We will make it more appropriate to the new flow. Something like: “Add your card details below and “Pay Now” to proceed with payment.
Appreciate your endeavours with EE 🙂

EDIT: Reposted for clarity – apparently, I can’t close tags 😊


Tony

  • Support Staff

September 11, 2019 at 3:03 pm

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.

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).

Absolutely, yes, it all needs to be done. But it doesn’t need to be done this way, surely?

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?

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

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.

further with inline text that gives the incorrect next step, the process sows confusion to the uninitiated.

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 modal pathway was markedly superior UX as the customer never had to look for the next step: it was always in front of them.

Noted.

It’s nothing inherent to modals, and I’m sure a smoother checkout is possible with a better flow and more relevant prompting.

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 🙂 )


AHI

September 11, 2019 at 3:44 pm

The user has not filled those fields, we have auto-filled them

Ahah, interesting! This is…
a) really useful – a valiant effort to reduce user input & frustration, ultimately helping us sell tickets.
b) so smooth & transparent that the user (and me, and by the sounds of it, others) are likely blissfully unaware. So, the net effect is that these fields appear to be the fields users have just filled in and therefore will be treated as such; problem being user then believes they have seen those fields and that nothing lies beyond. Its just a perception issue at heart.
To make this journey clearer I’d be tempted to change the payment options page to something like this:
null
We show where they have come from (the option to correct that!) and that the information below is new territory with a little more inline help to orientate. Not as clean :/ And there’s probably great reasons not to do this, but I thought I’d share a notion rather than just moan 😊


Tony

  • Support Staff

September 12, 2019 at 3:28 am

a) really useful – a valiant effort to reduce user input & frustration, ultimately helping us sell tickets.

🙂 thank you, we try.

b) so smooth & transparent that the user (and me, and by the sounds of it, others) are likely blissfully unaware. So, the net effect is that these fields appear to be the fields users have just filled in and therefore will be treated as such

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).

problem being user then believes they have seen those fields and that nothing lies beyond.

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)

To make this journey clearer I’d be tempted to change the payment options page to something like this:

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?


Tony

  • Support Staff

September 12, 2019 at 4:04 am

Also, I should add in regards to this:

The modal pathway was markedly superior UX as the customer never had to look for the next step: it was always in front of them.

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.

The new payment method uses Stripe Elements with the Payment Intents API to allow your users to remain ‘on-site’ without your server handling payment details.

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.

You must be logged in to reply to this support post. Sign In or Register for an Account

Support forum for Event Espresso 3 and Event Espresso 4.
Documentation for EE3 and EE4
Documentation for Event Espresso 3

Documentation for Event Espresso 4

Status: publish

Updated by  Tony 1 week ago ago

Topic Tags

Tagged: , ,

Notifications

This topic is: not resolved
Do NOT follow this link or you will be banned from the site!