Forum Replies Created
-
Posts
-
Thank you.
After installing this new version of your plugin we’ve found that the event is finally processed, but in our tests some subscriptions were not updated because:
“Did not find an existing record in the members table for subscriber ID: sub_aaaaa”
I’ve debugged your new code and find that the requested subscriber ID is correct, but it is not exactly the same value that the column “subscr_id” of the table “wp_swpm_members_tbl” has. In particular, some Stripe subscriptions are saved in this format:
sub_aaaaa|570
Where 570 happens to be the ID of our old Stripe subscription button. I don’t know why some subscriptions are saved like this while others are not.Anyway, I’ve modified the line 298 of the file “/ipn/swpm-stripe-subscription-ipn.php” this way:
$query_db = $wpdb->get_row( $wpdb->prepare( "SELECT * FROM {$wpdb->prefix}swpm_members_tbl WHERE subscr_id = %s OR subscr_id LIKE %s", $subscr_id, $subscr_id.'|%' ), OBJECT );So the subscr_id must match the beginning of the column value, and that worked and all subscriptions finally began updating.
As a side note, the recurring subscription payments still does not appear in the “Payments” section of your plugin. You should fix that too.
Just to confirm, are you using the new SCA compatible button option that we recently added to the plugin?
Yes, currently we have changed the subscription button for the new SCA-compatible one but indeed the previous one is still enabled in some areas of our website.
But that really doesn’t matter for the current problem, right? as all failing subscriptions come from previous years when SCA button didn’t exist.The plugin receives the webhooks from Stripe for normal transactions and for cancellations. Then it updates the profile accordingly. I need to see why it is not updating profile when the normal charge comes in.
As I explained in my first message, in my debugging I found that all Stripe webhook subscription related requests are finally processed in the “swpm-stripe-subscription-ipn.php” file:
https://plugins.trac.wordpress.org/browser/simple-membership/trunk/ipn/swpm-stripe-subscription-ipn.phpSo, unless I’m wrong, this is what your code does when Stripe sends an event:
Line #13, the webhook url has the parameter “hook”, so if clause is true
Line #31, the subscription event “customer.subscription.updated” is not one of the if clause, so it is not executed (that is correct)
Line #44, the function is exited by a return, so that event is not processed
End of the Stripe event processingWe can give you a copy of the site if you wish, but it seems the problem would be the same in any other installation of your plugin.
What is the membership level’s expiry setting that you are using?
Our setting for paid accounts is “Expire After 12 Months”
For a subscription payment, your membership level’s expiry setting should be “No Expiry”. So when the cancellation of the subscription comes in, the account will be “deactivated”, otherwise the account will keep going (meaning the subscription is still active).
So by what you say, you are confirming that your plugin does not check the Stripe subscription payment notifications, only the cancellation events?
That’s a little unfortunate, so if, for whatever reason, Stripe cannot notify a cancellation, the paid member will keep its status indefinitely?Please we need confirmation about this.
Well, we have a site with thousands of subscribers… It is quite possible that someone forgot if he has paid and tries to repeat the subscribe process. Maybe that already happened, who knows…
Anyway, thank you very much. All clear now.
Our membership “Access duration” expires after 12 months.
The membership is paid by a subscription button (stripe or paypal) associated to a payment plan in the gateway platform (recurring payment).By this setup, I suppose Stripe/Paypal will try to charge the payment 12 months after the first subscription. On success, the gateway notifies the SM plugin and it extends the subscription for another 12 months.
Now imagine an user with an active subscription (already signed in and identified) clicks again on the subscribe button and makes another payment, say, 9 months after the first subscription.
For what I understand, the plugin could do two things:a) ignore the existing user subscription and create a new subscription in the gateway platform, so the user will be charged anyway at the end of the first subscription
b) cancel the existing subscription in the gateway and create a new one, extending the subscription expiry time if the new subscription payment completes
Reading your documentation I think the second option is not possible, as programmatically you can’t cancel an active subscription, it requires a person to log in Paypal and cancel the old subscription.
So in my deduction, and reading your words on your first reply, what will surely happen is the first option.
Am I right or there is something wrong in my explanation?
Thank you very much.
Thank you very much for your complete explanation.
The same will happen if recurring SUBSCRIPTION payments are used to pay for MEMBERSHIPS; EXCEPT THAT A SECOND PAYMENT CONTRACT will be created. Depending upon whether or not the existing SUBSCRIPTION has a fixed term; conflicts may occur, in the form of double billing. The situation is kinda dependent upon how you’ve got eh membership levels and payment buttons setup.
Let me tell you our configuration. The subscriptions expire after a year unless they are renewed by the contract on Stripe or Paypal (that is automatic). There are no “Buy now” payments.
So, by what you say, if the user of an active subscription pays for it using the same subscribe button again, that will generate another payment contract on that date, but the previous contract will still be valid, so on the renewal date of the first contract, he will be billed again.Could you please confirm what I am telling is correct?
