New users being created as level 0 in error

#1

Something since v260927 and Stripe pro forms has changed the signup process which is now creating users at level 0, despite their being purchased at a level above 0, and its then modifying the user to the desired level.

This is generating a few unexpected behaviours

I’ve not yet located the exact code generating the issue (although its almost certainly going to be something to do with the pending membership logic within /s2member-pro\src\includes\classes\gateways\stripe\stripe-checkout-in.inc.php) but I’ll tell you what I’ve discovered so far.

It looks like despite users joining from a s2Member-Pro-Stripe-Form shortcode which defines them as level 1 (or more) that they are being created as level 0 then somehow upgraded to the level defined in the shortcode.

For instance my shortocde for level 1 is:

[s2Member-Pro-Stripe-Form level="1" ccaps="" desc="🤖 Replicant (£3 per month)" cc="GBP" custom="www.sciencefictionbookclub.org" ta="0" tp="0" tt="D" ra="3.00" rp="1" rt="M" rr="1" coupon="" accept_coupons="0" default_country_code="GB" captcha="0" success="/congratulations-and-megathanks-for-supporting-the-science-fiction-book-club/" /]

This is creating the following errors:

  1. instead of users being send the usual custom Signup Confirmation Email they are instead being send a Modification Confirmation Email, which will almost certainly be different.

This is unexpected behaviour

  1. The %%label%% in the admin’s New User Notification Message email is being defaulted to the Level 0 label no matter what level the user has purchased.

This is unexpected behaviour

The new users New User Email Message / ws_plugin__s2member_new_user_email_message seems to be uneffected and the %%label%% is functioning properly in that.

1 Like
#2

there is the rather suspicious line 1177 in s2member-pro\src\includes\classes\gateways\stripe\stripe-checkout-in.inc.php which sets the ws_plugin__s2member_custom_reg_field_s2member_level to 0

							//260925.2349 Create one-time SCA accounts at Level 0 until Stripe confirms the PaymentIntent; final fulfillment upgrades the same durable guest-owned account.
							if(!empty($stripe_pending_payment))
							{
								$GLOBALS['ws_plugin__s2member_registration_vars']['ws_plugin__s2member_custom_reg_field_s2member_level']  = '0';
								$GLOBALS['ws_plugin__s2member_registration_vars']['ws_plugin__s2member_custom_reg_field_s2member_ccaps']  = '';
								$GLOBALS['ws_plugin__s2member_registration_vars']['ws_plugin__s2member_custom_reg_field_s2member_custom'] = $post_vars['attr']['custom'];
							}
							else
							{
								$GLOBALS['ws_plugin__s2member_registration_vars']['ws_plugin__s2member_custom_reg_field_s2member_subscr_gateway'] = 'stripe';
								$GLOBALS['ws_plugin__s2member_registration_vars']['ws_plugin__s2member_custom_reg_field_s2member_subscr_cid']     = $new__txn_cid;
								$GLOBALS['ws_plugin__s2member_registration_vars']['ws_plugin__s2member_custom_reg_field_s2member_subscr_id']      = $new__txn_id;
								$GLOBALS['ws_plugin__s2member_registration_vars']['ws_plugin__s2member_custom_reg_field_s2member_level']          = $post_vars['attr']['level'];
								$GLOBALS['ws_plugin__s2member_registration_vars']['ws_plugin__s2member_custom_reg_field_s2member_ccaps']          = $post_vars['attr']['ccaps'];
								$GLOBALS['ws_plugin__s2member_registration_vars']['ws_plugin__s2member_custom_reg_field_s2member_custom']         = $post_vars['attr']['custom'];
								@list ($level, $ccaps, $eotper) = preg_split('/\:/', $post_vars['attr']['level_ccaps_eotper'], 3);
								if(!empty($eotper)) $GLOBALS['ws_plugin__s2member_registration_vars']['ws_plugin__s2member_custom_reg_field_s2member_auto_eot_time']
									= date('Y-m-d H:i:s', c_ws_plugin__s2member_utils_time::auto_eot_time('', '', '', $eotper));
							}

Looks like there is some funky wp_create_user() vs ms_create_existing_user() action happening which I’ll let @clavaque untangle for me :rofl::+1:

#3

Thanks for spotting it and for the extra investigation.

Yes, that Level 0 assignment is intentional. When Stripe authentication/payment is still pending, s2Member creates the account without paid access first, so the member doesn’t get access before Stripe has actually confirmed the payment. Once Stripe confirms it, the same account is upgraded to the purchased level.

The problem is what happens around the notifications in that delayed-completion path.

Because the account already exists by the time Stripe confirms the payment, part of the existing logic is treating the final activation as a membership modification. That’s why you’re getting the Modification Confirmation Email instead of the normal Signup Confirmation Email.

The Level 0 label in the admin New User notification is related too: it’s reporting the temporary holding level rather than the membership the person actually signed up for.

I’m working on fixing those notification semantics while keeping the Level 0 safety behavior intact.

:slight_smile:

1 Like
#4
  • (Framework & Pro) Fix: Corrected notifications for new Stripe Pro-Form signups that complete after delayed payment authentication. Pending accounts still remain at s2Member Level 0 until Stripe confirms payment, but new-user notifications now reflect the membership being purchased. Once payment is confirmed, the signup follows the normal confirmation and notification paths instead of being treated as a membership modification. Thanks to Gerard for reporting the issue. See thread #13644.
2 Likes
#5

Great, I’ve installed it and am awaiting someone joining at a membership level >= 1 to test it out🤞

1 Like