Posted: December 11, 2019 at 9:50 am
|
Hello! The Submit Promotion button effectively clicks the “Submit” button on a purchase if the promotion code value is greater than the value of the item being purchased. This was very surprising to discover and I wanted to know: Thank you! |
|
|
Hi Daniel,
Yes, it is expected. The promotion field shows on the payment options step, if the amount owed value is greater than 0 the payment options are displayed. If you apply a promotion that effectively removes the value, then no payment option is needed. For example if your transaction is $100 and you apply a 100% promotion to the cart it becomes free, you aren’t going to then select say the Stripe payment method and try to pay as now monies are owed, so the checkout page submits to finalize the registration.
Not currently, may I ask why would you want to select a payment method on a transaction that requires no payment? |
|
|
Hi Tony, Thanks for the quick reply. I want to stop this behavior because it is confusing and non-standard and takes away the opportunity for a final review of the registration data. It’s a better user experience from my POV to provide the information about the promotion code and then give the customer the normal final review “pause” so they can submit as they wish. Even if the amount owed is $0 there still should be a “pause” with an explicit “Submit.” This is the main reason it is confusing: Very important! This is a final chance to correct email address, phone number, address, etc… I have seen many customers refine email addresses and add other missing information at this stage of the checkout. Finally, causing the checkout submit button to be triggered on checking the Promotion Code value is very non-standard checkout behavior. Very non-standard. I don’t know of a single other checkout that does this auto-triggering on $0 balance. It’s just not good UX. I just want the values to update in the checkout sums (per the promotion code) and show that the balance is $0 and then the customer can hit the Submit button once they have done a final review. Thanks for your consideration. Please point me to where in the code this checkout process happens. I’d like to take a look. Dan |
|
Thing is, there is nothing to pause and review at that point, you can’t change anything on the form that will apply in this situation. You want your users to review a ticket with a cost, then after submitting a promotion that applies 100% discount, review that the discount was applied, then know that they should skip the payment options and submit themselves? I’d consider that more confusing than getting to a payment step, applying a 100% discount promotion and then seeing a confirmation that shows your registration is complete.
It’s not misleading, your submitting a promotion code. So what should it say here with your current behaviour? “Submit Promotion Code, review your promotion and if it’s greater than monies owed skip payment options and click finalize”?
This is incorrect, nothing on the payment options steps refines/updates/changes anything on the registration(s) other than the values sent directly to the payment merchant through the payment method, which you now don’t need as you don’t use the payment merchant when you owe nothing.
I don’t see how continuing to show the user a payment option step when no payment is to be made is any better UX than instantly showing a confirmation after their amount due is now nothing.
So what do you do with the payment methods already shown on the page? Leaving them causes confusion, adding a feature to hide them for the user to then possibly click finalize, or skip clicking it themselves and leave site leaving the session open with very little benefit to the user. Not automatically submitting the promotion code in this situation needs more work than just simply not submitting the checkout after applying the promotion code. It sounds like you’d prefer another step, after the payment options step but before the thank you page allowing the user to review their details/transaction etc. We have a filter for adding your own reg steps if you’d like to investigate that further:
This isn’t something you can change with a hook and applies through the promotion add-on, the cart system and the single page checkout system within core. The only way you could modify this currently is by modifying core which is not something we can support or provide guidance on. |
|
|
Thank you for the thoughtful reply. I will look at the reg step customizations. I love that EE is so customizable! Bottom line for me is that the “Submit Promotion Code” button should not finalize the checkout – it doesn’t when the value is lower than the purchase and it shouldn’t change its behavior when the value is GTE the checkout total. A “Submit Promotion Code” button should only submit promotion code. Period. You *can* change form fields in the final step of checkout… I just reviewed it now and I see form fields for Email, Address, Phone, etc… These can be changed in the final submit payment step. I guess we’ll just agree to disagree about the UX here. In my humble (but experienced with many other carts) opinion a Submit Promo code button should never submit a “payment” even if it covers the entire cost. It should always be a separate step. Even at the risk of leaving someone in the cart. It’s just non-standard and labeled wrong. In any case, I’d still like to look at the core code. Can you point me to where that is? Maybe a Github link? Thank you! |
|
That’s not correct. What you saw there are fields for the credit card billing form. If you change any of the values there, the registration form values don’t change. In other words, that’s a separate billing form for the credit card payment. Which, I think you can agree with this point: If the user owes $0.00 dollars at that point, the user should not be prompted to fill out a billing form that gets submitted to a credit card processor. |
|
Then yes, for this will have to agree to disagree. I do not consider showing a user options/fields/sections etc that have no relevance at all to their next step (payment options when they can no longer make a ‘payment’) good UX.
You can change them, but as I said, they don’t apply to the registration 🙂 So what I said was you cant change anything that applies in this situation and that is correct. What you are changing is the values sent to the payment merchant for the selected payment method (yes, even name, email address etc as they can all be linked to a payment depending on the merchant depending on the provider). Those fields are NOT registration fields, they are payment fields and the values were auto-filled from the registration data on load but that is the only connection between them. So, let’s say you do stop the redirect and continue to show the user the payment methods because you want to leave them the ability to ‘update’ those field, I’m guessing you have one set to open by default and that payment method shows payment fields. So the user applies a 100% discount and can still see those fields…. now they change their name, address, email etc to completely different data to what they had previously and click finalize. Where did those payment merchant fields go as they aren’t going to a merchant, there is no payment, so they aren’t sent anywhere, they aren’t saved anywhere and the billing form does nothing. In fact, you may end up with something completely unexpected as SPCO doesn’t expect you to try an attempt a payment when one isn’t due. Make sense? That’s why I keep saying those fields are irrelevant in this case, they do not update the registration and are used solely for the payment itself (this of the case were you register a child and the parent pays). The payment options step is pointless unless you are making a payment, displaying it and allowing users to change values that do nothing at all after they’ve submitted 100% discount, is much more confusing than automatically submitting the checkout.
We appreciate any and all feedback, doesn’t mean we will always agree with it but it is appreciated 🙂
The point I was trying to make is that if you going to change core to do something we don’t support then we can’t work through doing that with you. I can point you in the direction I’d start with, take a look at the
and work your way back through there to follow the methods used within core to find where this happens but, there’s much more to this than simply stopping the redirect. |
|
The support post ‘Submit Promotion Code button submits Checkout when value greaterthan item’ 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.
