Apple Pay bypasses WooCommerce "Enable guest checkout" setting.

[jtsternberg]

What I expected

After authorizing in Apple Pay to be taken to account creation process

What happened instead

It completes purchase, and redirects to order page, without requiring an account to be created. Order shows that it is a guest checkout:

Steps to reproduce the issue

Pay with apple pay, review the order in the admin.

[jtsternberg]

The context is that we are using WooCommerce Memberships, and when users purchase an item without an account, they are not granted the membership.

[1976Hoosiers]

Thanks. I was wondering how this was handled.

[roykho]

This one is definitely up for a good debate as to "how" it should be handled. With UX in mind. So after they have paid via Apple Pay and if we wanted them to create an account, which would be the best method.

1. Show the account creation form on top of the "Order Received/Thank you" page?
2. Somehow automagically create the account in the background and send them an email ( The one listed on their Apple Pay ) with temporary login?
3. Or something else?

[dimabrook]

I'm in the same place as others where an account is really important to allow users access to paid content. I like option 2! Is there a way to extend this experience to forcing the user to create a password after checkout process?

[zjwhitehead]

Ideally there would be a config setting to choose either option 1 or 2 Option 2 would be the most seamless. How would it be handled if a customer with an existing account/subscription wants to checkout as a guest using Apple Pay? They would then have two accounts? or possibly add orders/subscriptions to an existing account if one is already created for the Apple Pay email address.

[douglsmith]

@roykho, I'm an advocate of something more like your option 2 above.

It seems like your above choices may be related to the bigger questions raised in woocommerce/woocommerce#10672. As I said over in that issue, I believe account creation, as far as the customer sees, should always happen after checkout is complete. There are always arguments whether or not an account creation contributes to cart abandonment, but we know for sure that it can't it if doesn't happen until after the customer has finished checking out.

My ideal checkout would combine that with much of what @xeroshoes also proposed in that issue. So ask for the e-mail as the first step if possible but wait until after checkout to either ask to log in for a known account e-mail address or claim an account that is always auto-created.

[roykho]

@douglsmith I am also leaning towards option 2. So the way it will work is if for any reason the items purchased needs to have an account created ( memberships, subscriptions...etc ) or if they have guest checkout disabled, then programmatically create the account in the backend and send the customer an email with their temporary login password.

With that said, I feel this logic should go into WC core. The reason being, for us to implement this, we would have to add not only the logic but the email template as well. And I see several payment gateways that will need the exact same setup ( i.e. PayPal Express ). Just thinking out loud.

[MmtBkn]

I think creating account, sending temporary password is best approach too.

Any plan adding this kind of future?

[azcomps]

Anyone have a fix for this? I'd be okay with Option #2 suggested above where Woocommerce account automatically created using Apple Pay email address with an auto-generated password.

[VioletPixel]

Option 1 would allow them to pay and then not set up an account, which would mean they couldn't access what they just purchased if they need an account to do so.

Option 2 sounds like the best one to me.

[VioletPixel]

Just a heads up: We're using a few plugins that conditionally disable guest checkout depending on what's in the cart. Some of these plugins (Groups, Sensei) use the option_woocommerce_enable_guest_checkout filter to do so. Others (Subscriptions) modify the $checkout object in the woocommerce_before_checkout_form action. So this applies to more than just the checkbox in WooCommerce's settings.

[1976Hoosiers]

@ValueBerry So what does your setup look like? I have woocommerce with memberships and I need make sure they can't pay without creating an account. You use Groups and Sensei to accomplish this functionality? Thanks for any insight!

[VioletPixel]

@1976Hoosiers We don't use the Memberships plugin. Instead, we use WooCommerce Subscriptions and the Groups plugins to manage our subscriptions/memberships and Sensei and Groups to manage our courses. Both subscriptions and courses, when purchased, require an account. This is usually enforced by the Groups plugin requiring a login whenever a product that has a group to assign at purchase is in the cart, but Apple Pay bypasses this, so we've disabled it until this issue is resolved.

[nburch]

Same issue here. Using Membership & Subscriptions (as well as Sensei) - Apple Pay does not seem to respect guest/account creation requirements. I think it should check on email address:

1.) If email exists in system attribute order to that account.

2.) If email does NOT exist then silently create account and email credentials to user.

[roykho]

Implemented via https://github.com/woocommerce/woocommerce-gateway-stripe/tree/4.0.0

[VioletPixel]

Reading through the new code for this fix, it looks like when an account is required and Apple Pay is being used it will check to see if the email address provided by Apple Pay is already associated with an existing WordPress login and, if it is, tie the order to the account. This is great!

However, when an account needs to be automatically created, it looks like the WordPress login name is being set to the person's first name as defined by the billing information provided by Apple Pay. This line, specifically, seems to be doing that:

$user_login   = WC_Stripe_Helper::is_pre_30() ? $this->order->billing_first_name : $this->order->get_billing_first_name();

If I'm understanding this correctly, this is going to fail nearly 100% of the time for us. We currently have 28,532 accounts in WordPress, with the vast majority of common first names already taken.

I'm also not clear on what happens if account creation fails. It looks like the order will still proceed without an account? Or will the order fail? Both of these would be bad.

Ideally the attempt to create an account would check to see if the proposed login name is already in use and, if so, create one that isn't, which would help ensure the account is created successfully.

[roykho]

@ValueBerry thanks for the feedback. Yes it is based on the billing first name because without customer actually setting one, it would be impossible for me to come up with a more unique login name. Sure I can append the first name and last name but even still, it may already exist? Do you have other suggestions for this?

Yes the checkout will still go through even if account creation fails and that is by design. No point in losing sales because an account couldn't be created IMHO.

[roykho]

@ValueBerry actually while typing the reply to you, I just thought of using the email as the user login name..Would that work?

[dimabrook]

Email is great. Unique enough versus first last name combos.

On Fri, Aug 18, 2017 at 4:18 PM Roy Ho notifications@github.com wrote:

@ValueBerry https://github.com/valueberry actually while typing the reply to you, I just thought of using the email as the user login name..Would that work?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/woocommerce/woocommerce-gateway-stripe/issues/148#issuecomment-323451366, or mute the thread https://github.com/notifications/unsubscribe-auth/ADkZIPf3rKrO-Xn1M9Df198lWpg9u44Rks5sZfGPgaJpZM4LnDBq .

-- Sent from my iPhone

[douglsmith]

Using the e-mail address as a login / username can cause a couple significant problems:

1. The user can't change the login name so they may be stuck with it even if they later change their e-mail address.
2. The login name is displayed default publicly by default in WordPress when a user leaves a comment on a blog post. It is also displayed as the default user name in bbPress and BuddyPress. That means we are potentially violating our user's privacy by displaying their e-mail address for all to see and for spammers to scrape off our sites. When WooCommerce used to do this it was a customer service nightmare for us until we turned it off.

WooCommerce already has automatic account creation that generates a username and password. It's in the settings under Accounts --> Account creation, where there are checkboxes to auto generate the username and password.

It uses the leftmost part of the user's e-mail address up to the @ sign. If the username is taken then it keeps incrementing a number that it adds to the end until an unused name is found.

Here's the code https://github.com/woocommerce/woocommerce/blob/3522857d23051844bea742a37a1b0b242f7850af/includes/wc-user-functions.php#L68-L77

WooCommerce also enables users to log in with their e-mail address as a username, which WordPress doesn't do natively. So even if the login name were totally random, we could still tell users that their e-mail address is their login, without any of the problems that would create as the actual login name.

[VioletPixel]

WooCommerce's solution sounds like the best fit to me. I can't think of any issues with it. The email idea was a good one, but it has too many ramifications to be practical.

I also wanted to point out that WordPress has a 60 character limit on user_login, which may need to be taken into account depending on how this discussion turns out. 🙂

[roykho]

@douglsmith - good find.

[simbapenn]

This is a semi-thread jack on a 2 month dead thread, but do you think it would be possible to only allow Apple Pay for people who have already created an account? Basically they order time 1, there's not apple pay. They order time 2 and Apple Pay is there b/c they now have an account from the first order.

Or was this issue fixed? Because it just happened to me yesterday with the latest woo and stripe plugin.