Support

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?

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?

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

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?