Reüel

is there a way to just put it on cancelled or successful

To put ‘what’ on Cancelled or Successful exactly? MemberPress determines the subscription status based on the transactions for that subscription, which are already updated correctly as mentioned (updated to ‘Refunded’ on refunds and chargebacks, which results in the subscription being deactivated).

It actually sounds as if your MemberPress add-on doesn’t integrate very well and does not act upon changes in the MemberPress subscription status. Therefore, I’d advise contacting the developers of that add-on for further support. I’m afraid we can’t help you any further with this.

If a refund by the merchant or chargeback by the customer occurs, the MemberPress transaction status will be updated to ‘Refunded’ and MemberPress will determine the membership status accordingly.

For chargebacks, the corresponding Pronamic Pay subscription is put ‘On Hold’ so merchants can manually resolve the payment issue with the customer and to prevent future payments from being started automatically (which could in turn also be charged back by the customer, which is costly). Merchants can either choose to reactivate or cancel the subscription, depending on the situation. Chargebacks do not automatically result in cancelled subscriptions, as that is not always the desired outcome. It’s advised to always keep an eye on chargebacks (subscriptions ‘On Hold’) to resolve payment issues promptly.

Thank you for your review! Your feedback regarding the status pages is noted for our developers, we might indeed be able to simplify this in the future.

To manually prolong a subscription, you would need to update the expiration date of the last MemberPress transaction of the subscription and the ‘Next payment date’ of the corresponding Pronamic Pay subscription.

Any update on this, @gpetrova?

I’m also unable to save options on a subsite. It appears the logged in user cannot be determined correctly when saving options only if the SiteGround Optimizer plugin is network activated (no issues when the plugin is activated for each site individually).

The issue is that the /wp-includes/pluggable.php file is loaded in SuperCacher::purge_on_options_save(), before the cookie constants are defined (they are defined by calling wp_cookie_constants() in wp-settings.php, just after the network plugins are loaded). Therefore, the cookies can not be used to determine the logged in user. That’s an issue and also results in PHP warnings in the logs:

PHP Warning:  Use of undefined constant SECURE_AUTH_COOKIE - assumed 'SECURE_AUTH_COOKIE' (this will throw an Error in a future version of PHP) in /home/customer/www/example.com/public_html/wp-includes/pluggable.php on line 929

PHP Warning:  Use of undefined constant LOGGED_IN_COOKIE - assumed 'LOGGED_IN_COOKIE' (this will throw an Error in a future version of PHP) in /home/customer/www/example.com/public_html/wp-includes/pluggable.php on line 925

Call stack leading to the unauthenticated user when saving options:

# wp_get_current_user() called at /wp-includes/pluggable.php:2317
# wp_verify_nonce() called at /wp-content/plugins/sg-cachepress/core/Supercacher/Supercacher.php:318
# SiteGround_Optimizer\Supercacher\Supercacher->purge_on_options_save() called at /wp-content/plugins/sg-cachepress/core/Loader/Loader.php:722
# SiteGround_Optimizer\Loader\Loader->add_caching_hooks() called at /wp-content/plugins/sg-cachepress/core/Loader/Loader.php:660
# SiteGround_Optimizer\Loader\Loader->add_supercacher_hooks()
# SiteGround_Optimizer\Loader\Loader->add_hooks() called at /wp-content/plugins/sg-cachepress/core/Loader/Loader.php:119
# SiteGround_Optimizer\Loader\Loader->__construct() called at /wp-content/plugins/sg-cachepress/sg-cachepress.php:72
# include_once(/wp-content/plugins/sg-cachepress/sg-cachepress.php) called at /wp-settings.php:418
# require_once(/wp-settings.php) called at /wp-config.php:106
# require_once(/wp-config.php) called at /wp-load.php:50
# require_once(/wp-load.php) called at /wp-admin/admin.php:34
# require_once(/wp-admin/admin.php) called at /wp-admin/options.php:19

I hope this will be resolved soon!

If the payment gateway has been removed in MemberPress AND another payment gateway exists for the same method during renewal, the MemberPress subscription should be updated automatically by Pronamic Pay to use the new gateway so payments will continue for the subscriptions.

Oke but idk about the last thing you said because i did had to adjust all things manual

I checked this and this seems to apply only to cards and not for SEPA Direct Debit methods.

it got removed because i did a litespeed clean in toolbox strange shit that it cleaned all memberpress settings to default

That sounds like an issue with your database / object cache. Unfortunately, I cannot help you with that but you might want to contact your hosting provider for hosting issues.

for next time if this problem occurs again

I’d advise to prevent letting the issue occur again ?? It is not recommended to remove payment methods which are actively in use for the payments on your site.

why not just change the memberpress payment gateaway ID

I don’t think MemberPress lets you update the ID of a gateway and Pronamic Pay also does not add this functionality to MemberPress.

If the payment gateway has been removed in MemberPress AND another payment gateway exists for the same method during renewal, the MemberPress subscription should be updated automatically by Pronamic Pay to use the new gateway so payments will continue for the subscriptions.

We do support the latest version of MemberPress. Please see https://www.ads-software.com/support/topic/after-recurring-payment-paid-the-subscription-cancelled-after-1-day/page/2/#post-17511519, where I replied about the same issue.

memberpress_subscription #274

This is normal when a payment is started, except that usually we will create a MemberPress transaction too and then update the source of the payment. However, as you know, we were unable to create the MemberPress transaction, as your gateway was not available anymore.

Once these Pronamic Pay payments update to ‘Success’, we won’t be able to update a corresponding MemberPress transaction to extend the membership. It’s best to manually update the expiration date of the last MemberPress transaction. Future payments will work just normal.

The mp-sub-*** subscriptions are the ones that need to be corrected, as your MemberPress gateway (payment method) with ID S1sva4-67 doesn’t seem to exist anymore. You can update the transactions too, but if I’m not mistaken that is not necessary for future payments (as you mentioned you had already discovered, you also need to manually update the expiration date of the last transaction to regain access with a subscription — Pronamic Pay was unable to create the renewal payment with the MemberPress gateway, as it did not exist anymore at the time of renewal).

There is a row action Edit on the MemberPress → Subscriptions page for each subscription. On the subscription edit page, you can update the “Gateway” to the payment method of the corresponding Pronamic Pay subscription.

It is not recommended to remove payment methods which are in use. MemberPress also warns before doing that:

WARNING: Do not remove this Payment Method if you have active subscriptions using it. Doing so will prevent you from being notified of recurring payments for those subscriptions, which means your members will lose access to their paid content. Are you sure you want to delete this Payment Method?

I’d advise manually updating the MemberPress subscriptions which do not contain “Pronamic Pay” anymore in the “Gateway” column on the MemberPress → Subscriptions page to the correct payment method. I expect that to resolve your issues (also the ability to cancel subscriptions, which is also tied to the payment gateway integration).

Ok, thanks for the screenshots. Based on this information, could it be that the payment method has been removed from MemberPress → Settings → Tab ‘Payments’ (and that there is no other MemberPress payment method for the same method)?

If that is not the case, can you share some details about which Pronamic Pay payment methods you have configured in the MemberPress settings and which method was used for the first payment of these subscriptions?

If you look at MemberPress → Subscriptions in the WordPress admin, is there a subscription with ID 228? Are you also experiencing the same issue with other Pronamic Pay subscriptions, or only this one?