Dear all,

I have come across this problem:

Day A:

  • A user fills out the registration form
    • Registration is saved and set to pending.
  • Completes billing form
  • the summary is presented
  • User exists, due to reasons.

Day B
The user returns and reruns this process.

Expected result:

  • A user fills out the registration form
    • Registration is saved and set to pending.
  • Completes billing form
  • the summary is presented
  • User completes payment
    • Registration is saved and set to complete.

Actual result:

  • A user fills out the registration form
    • Registration is denied. Because of the registration of Day A.

How can I fix this?

Comments

pglatz’s picture

This is a big problem for a site I'm working on, lots of confused customers. The only thing we can do right now is have them email the admin to revert the order status to cart.

We're using Cybersource HOP, which doesn't provide a cancel button on their hosted payment page, which makes things worse; if there is an error in submitting the card number, there is no graceful way to get back to the site. Perhaps if there was a cancel button required as part of the payment API and a rules event to capture it, the cart could automatically be put back in the correct state.

My feeling is that a cart abandoned during payment, for whatever reason should never be left in the payment state.

djkentuckyham’s picture

I am experiencing this issue too. "User A" fills out the reg form and then abandons before checking out. Next day, Same "User A" comes back to tries to register and complete the checkout. Entered email will not work as prev days registration was saved as "Pending". I tried experimenting with various Registration States (admin/structure/registration/registration_states) but when I test it either adds another email entry in registration and breaks cart or does not work at all. It would be nice if there were a rul to check the registrations before checkout and if email exists and status =pending, the the order will pick up and flip to complete post payment.

djkentuckyham’s picture

I am experiencing this issue too. "User A" fills out the reg form and then abandons before checking out. Next day, Same "User A" comes back to tries to register and complete the checkout. Entered email will not work as prev days registration was saved as "Pending". I tried experimenting with various Registration States (admin/structure/registration/registration_states) but when I test it either adds another email entry in registration and breaks cart or does not work at all. It would be nice if there were a rule to check the registrations before checkout and if email exists and status =pending, the the order will pick up and flip to complete post payment.

gc11’s picture

Same issue here. When a user goes through to Paypal WPS and the payment fails they get redirected back to the site. They cannot see their previous order (as it is at checkout:payment) and so try to register again. Once they do that they get the 'already registered' error.

Has anyone found a work around yet?

blacklabel_tom’s picture

Issue summary: View changes

Hi All,

Sounds like if the user has a previous registration and then tries to re-register they should have the option to continue with their last registration.

The other option is to kill the registration if the user fails payment to allow them to re-register.

What do people think is the better option?

Patches welcome BTW!

Cheers

Tom

nhck’s picture

Tom,
basically yes.

The validation is incorrect and really the other registration will never be completed.

The question really is: Should the validation fail if one of the conflicting registrations is "pending"?

blacklabel_tom’s picture

Hi Nhck,

As a short term solution we could disable that validation to allow duplicate registrations.

The worry is that having duplicate registrations would be more of a problem than stopping users from creating them..

What do you think?

Cheers

Tom

gc11’s picture

We actually use this solution currently, we allow multiple registrations and to be honest it hasn't caused too many issues. We still have a problem with the payment failure redirect though.

I guess an option for Nhck could be to move the registration section further through the checkout so that it is at the very last point (maybe at review) where the registration would save. Then the only problem would be if the payment failed (like my issue), if they exited earlier than that stage the registration would obviously not be saved. This causes it's own problems though if you want users to register early into the checkout process, user experience etc.

The solution for me might be that instead of the user being redirected to 'payment' when a payment fails, they get redirected to an earlier stage of the checkout. Where they can resubmit their payment or choose a different payment method. The problem is that if a user say gets redirected to paypal, then decides to not come back to the site then their registration will be held as being in progress and the user will not know that because they cannot 'see' an order when it is on the 'payment' redirect page after review. They then try to register again but the system throws the error.

I think the best solution could be that when a user logs in, the module checks to see if there is a registration in progress. If so then it gives the option to carry on with that registration or start a new one. If they start a new one the previous registration is deleted.

Cheers,

nhck’s picture

Just a quick update for a workaround

  • Enable: commerce_cart_expiration
  • Edit the rule accordingly and set an expiration time. I have 5 hours.
  • Add a reaction rule "Delete Registrations if Cart is deleted"
  • For the event select: "Before deleting an expired cart"
  • And for the action choose: "Delete all registrations on an Order"
  • If you are using Paypal WPS your order might hang in the Checkout: Payment status. Read these instructions on how to circumvent that: https://www.drupal.org/node/1913138#7

I am testing this - let me know how it goes on your pages as well.

nwoodland’s picture

Nhck, I was faced with a slightly different issue, but your workaround seems to work great in my case as well. Thanks for posting this!