Thanks for the update. Hmm… There may be some syntax error… Could you zip up the file you modified, and upload it here so I take a look at what you have?
Stripe Last Payment Information not Up to Date
1 Like
Thank you! I think I found the problem. I had a syntax error with the quotes in one of the lines…
Change this one:
$stripe['s2member_log'][] = '($stripe_invoice_total = number_format(c_ws_plugin__s2member_pro_stripe_utilities::cents_to_dollar_amount($stripe_invoice->total, $stripe_invoice->currency), 2, '.', '')) > 0 = ' . (($stripe_invoice_total = number_format(c_ws_plugin__s2member_pro_stripe_utilities::cents_to_dollar_amount($stripe_invoice->total, $stripe_invoice->currency), 2, '.', '')) > 0);
to this
$stripe['s2member_log'][] = '($stripe_invoice_total = number_format(c_ws_plugin__s2member_pro_stripe_utilities::cents_to_dollar_amount($stripe_invoice->total, $stripe_invoice->currency), 2, ".", "")) > 0 = ' . (($stripe_invoice_total = number_format(c_ws_plugin__s2member_pro_stripe_utilities::cents_to_dollar_amount($stripe_invoice->total, $stripe_invoice->currency), 2, '.', '')) > 0);
Then resend the webhook and tell me what you get in the log entry, please.
1 Like
Thanks! Your solution solved the error 500 and now it all goes well. I will send you the log file in a couple of minutes.
I just sent you both stripe ipn and stripe api logs, just in case, and since I kept the logging on you’ll have even more data there 
Thanks again! 
1 Like
Thank you!
I see. The condition that’s failing is the last one, about the signup vars. One of the vars is missing in the user’s account, apparently…
Could you do an advance users export, and send me the row for one who’s payment webhook got ignored by s2 (e.g. cus_JrA7MxgsQodgwa), and one who’s payment webhook wasn’t skipped (e.g. cus_M6SZbbwYvMr0t3)? Please include the column headers, too.
1 Like
Hi! Thanks again!
I just sent you the exports (I went ahead and made 4 versions so you can also see what I see when exporting them, only 1 format is easy read while 2 should be).
Thanks!
I see what you mean.
There’s only one user in the csv: cus_JrA7MxgsQodgwa. I see that the field meta_key__dpris_s2member_ipn_signup_vars
is empty, which explains why s2 ignored that webhook.
How was this user’s subscription created? Did you use the pro-form, or was it some other way and then you added the cus/sub IDs to his WP profile?
1 Like
Manually. Like I mentioned above, I felt that the glitch could be associated to users that were manually edited, changed subscriptions, switched from PayPal to Stripe, reupgraded after being suspended due to lack of payment for a while etc.
I believe the plugin should only check the two subscription ID fields we can edit manually to find a match, since those are the fields we can update plus they seem to be enough to identify the customer and the subscription.
I use the same method with PayPal, by the way.
Got it. Yeah, you were right. I was asking to find out if you remembered whether this particular user was, but it’s most likely, if those vars are missing and you edit users regularly.
Yeah, I understand that point well. Thing is that the way s2 does it when receiving a webhook/IPN, it requires those IPN (Instant Payment Notification, the name is from PayPal’s API) vars as part of sending the payment notification emails.
The s2 code that checks the Stripe webhook, prepares those vars, to send them to s2’s IPN handler. pro/src/includes/classes/gateways/stripe/stripe-notify-in.inc.php
&& ($ipn_signup_vars = c_ws_plugin__s2member_utils_users::get_user_ipn_signup_vars(0, $stripe_subscription->id))
)
{
$processing = TRUE;
$ipn['txn_type'] = 'subscr_payment';
$ipn['txn_id'] = $stripe_invoice->id;
$ipn['txn_cid'] = $ipn_signup_vars['subscr_cid'];
$ipn['subscr_cid'] = $ipn_signup_vars['subscr_cid'];
$ipn['subscr_id'] = $ipn_signup_vars['subscr_id'];
$ipn['custom'] = $ipn_signup_vars['custom'];
$ipn['mc_gross'] = $stripe_invoice_total;
$ipn['mc_currency'] = strtoupper($stripe_invoice->currency);
$ipn['tax'] = number_format(0, 2, '.', '');
$ipn['period1'] = $ipn_signup_vars['period1'];
$ipn['period3'] = $ipn_signup_vars['period3'];
$ipn['payer_email'] = $ipn_signup_vars['payer_email'];
$ipn['first_name'] = $ipn_signup_vars['first_name'];
$ipn['last_name'] = $ipn_signup_vars['last_name'];
$ipn['option_name1'] = $ipn_signup_vars['option_name1'];
$ipn['option_selection1'] = $ipn_signup_vars['option_selection1'];
$ipn['option_name2'] = $ipn_signup_vars['option_name2'];
$ipn['option_selection2'] = $ipn_signup_vars['option_selection2'];
$ipn['item_name'] = $ipn_signup_vars['item_name'];
$ipn['item_number'] = $ipn_signup_vars['item_number'];
I can see it as an improvement to separate the last payment time update from the payment notification, or send the notification with the variables available, even if many are empty/missing. I’ll think about this.
An option for now, would be for you to add an array of IPN variables (the ones you see used above) to the users you edited manually, even if it’s a deafult array you use just so this gets processed to update the last payment time, knowing that payment details will be missing for other features (e.g. payment notifications, payment log).
The IPN vars needed there would be: subscr_cid, subscr_id, custom, period1, period3, payer_email, first_name, last_name, option_name1, option_selection1, option_name2, option_selection2, item_name, item_number.
You could create a test subscription with a test user, with values for this purpose, and then export the user (advanced), and copy its ipn vars field to use it as a template updating only its subscr_id and subscr_cid, for the users you edit manually.
You could test it with this user we were looking at first, resend the webhook, and see how it goes.
1 Like
Thanks!
I’ll do that tomorrow or the day after and let you know as soon as possible with results.
Sorry my mind is a bit tired today. 
1 Like
Hi again! I just sent you a private message with another user information that matches the test you wanted me to run (even better since it was the same user also using stripe, two subscriptions, changing only tier and sub id, everything else was the same).
Didn’t work either, plugin also ignored the webhook.
From what you said, I seem to understand that user got subscription A, then changed it to B, you changed his profile to show A’s ID, and then webhooks started being ignored.
It sounds to me that we have again a problem with the signup vars. This time, though, instead of missing in the user’s account, they don’t match. It’s likely that the signup vars now corresond to subscription B, but the ID in his profile doesn’t match with it. The subscr ID is also in the signup vars.
Could you do an advanced user export, and send me that user’s row to take a look? (including the headers, please)
Did you do the test I suggested above, to add signup vars to the user that didn’t have them, and resend the webhook for his last payment?
1 Like
No, I didn’t do the test. I understood that any signup vars would be good if the CID and SID were a match and the signup vars weren’t empty, hence why I gave you the other case, since that account was not demoted to zero, therefore subscription B’s signup vars were assigned and working.
User had subscription A, more expensive.
User didn’t pay. Received email. Instead of fixing the subscription, user subscribed again, but to a lower tier, cheaper (subscription B, which replaced subscription A on s2member’s database but did NOT cancel subscription A). Payment date was consistent with subscription B, since it was the latest.
I successfully collected the larger amount for Subscription A (the most expensive and already running, but not in s2Member’s database anymore. I edited the user on Wordpress to replace their sub id to match Subscription A.
Then I cancelled Subscription B.
Then I re-sent the webhook related to the payment for the Subscription A.
s2Member chose to ignore it, as you can see in the log.
I’ll export the entry later today and send you via private message. Thanks!
1 Like
Did did a few tests. The array must be updated so the plugin can recognize the user.
Just changing the field “meta_key__dpris_s2member_subscr_baid” which is also not updated when we update a user manually doesn’t help either.
I also notice you already keep a record of previous subscriptions and demotions somewhere, it would be nice to have that information available somewhere in the user profile (and searchable as well, if possible 
).
I hope what I did helps. Thanks again!
Thanks for the update! Well, that answers that.
I’m aware that it’s not practical when dealing with several users that need manual editing. I’m sure Jason had good reasons to implement it like that, but I’ll be looking at how to improve it.
1 Like
Thanks! Please let me know if you need more testing or even a Beta / Alpha version of the plugin to run (or a couple of files to replace via FTP to change the code).
1 Like
Will do
1 Like