Better status message when payment is pending


We’re having confusing state for new patrons. They can log in, their user gets created, but they are then still shown PATREON_TEXT_OVER_BUTTON_1 (“to view, must be member”).

The usermeta cache object for these users looks like this:

campaign_lifetime_support_cents: 0
currently_entitled_amount_cents: 3500
last_charge_date: 2021-12-01T13:58:34.000+00:00
last_charge_status: Pending
lifetime_support_cents: 0
patron_status: active_patron
pledge_cadence: 1
pledge_relationship_start: 2021-12-01T13:58:32.444+00:00
amount_cents: 3500
created_at: 2021-12-01T13:58:32.444+00:00
declined_since: 2021-12-01T13:58:34.000+00:00
currently_entitled_tiers:  ... "6838495"

As you can tell, this is a bit confusing. They are entitled to the tier and are an active patreon, but the payment is still pending which is why it shows “declined_since”.

Can this state be supported with a better description? E.g. something like “The Patreon API shows your payment as pending, please check back later”?

1 Like

This may be due to any kind of caching situation - at your site (plugins etc), your host (server side), even at the user’s browser/device or the ISP. First try to confirm that no caching is set for logged in users at your site if you use any caching plugins. Then check the caching situation at your host. Some hosts like EasyWP (Namecheap’s I believe) have server-side caching that you cannot interact with, as a user.


I’ve pulled the above data straight from the wp_usermeta table, and I run the server myself, so no funy business on the backend.

Caching is disabled for logged in users, but I do use W3 Total cache’s object caching feature, could that be the cause?

Edit: actually, object cache has a lifetime of only 180 seconds, so that can’t be it. Database and page caches are definitely disabled for logged in users. I really do think the issue is with the Pending payment as outlined above, would you not agree?

1 Like

Yes, that could be the cause. W3 Total Cache can be overly aggressive. It may not be related to object cache directly. Try disabling W3 Total Cache and running a few tests.

I’ve contacted you through the Pro support page with more details, in short, it really does not look like a cache problem to me. Would appreciate if we can continue the conversation on the ticket. Thanks.

1 Like

I have the same problem!
Users become active patrons, but due to pending payment, they cannot access the page on the site.
They often complain, since on Patreon itself they have access to all posts

I’m sorry to say that the dev does not seem to care. I have conveyed the problem on a support ticket but after some weeks of back and forth, including some canned responses, I gave up.

We’ve put up some replacement text for locked content that explains the problem to new patrons, and to double check their payment status and/or to wait a day or two.

The issue with the analysis in this thread is that the plugin checks the below field when deciding whether someone should or should not see a locked content:

As long as that field has a value that is equal to or higher than the amount you gated the content for, the patron should have access. The plugin does not check for last_charge_status field at any point. It should not have an effect on the user’s patronage.

That is why I have suggested that there was something else effecting this at your server, like caching issues - which may as well be the user’s browser cache.

Also it is correct that this would not be a priority even if it was something that could actually be linked to a cause - since there are other backlog items with more priority.

One note:

The user meta cache you shared may be older than the value which the api was returning for the patron at that point in time. If you can catch that api return, that could help - if the api return is not returning a legitimate patronage for the patron in contrast to the cached user info, then the plugin can reject access for the patron. If you can catch such a case, it may lead to a clue that could help the issue. But that won’t be related to last charge status since it is never checked anywhere.

Come on man. I told you on the support ticket that I wiped the users meta cache straight in mysql and disabled all caching. I also told you what code block I commented out for it to work.

But primarily, I am just asking for a better message so Patrons aren’t authorizing through Patreon and then seeing the exact same page with no clue whatsoever why they can’t see the content.

I posted the following metadata examples:

This particular patreon has resubscribed, and as far as I can tell from this output, there was an issue with the payment. But the status message doesn’t give any hint about that, so that leaves our members very confused.

[campaign_lifetime_support_cents] => 2805
[currently_entitled_amount_cents] => 0
[last_charge_date] => 2021-12-03T15:34:54.000+00:00
[last_charge_status] => Declined
[lifetime_support_cents] => 2805
[patron_status] => declined_patron
[pledge_cadence] => 1
[pledge_relationship_start] => 2021-10-05T19:02:49.800+00:00
[amount_cents] => 0
[created_at] => 2021-10-05T19:02:49.800+00:00
[declined_since] => 2021-12-03T15:34:54.000+00:00

This patreon has paid status on his profile, but we get this [from the api]:

[campaign_lifetime_support_cents] => 13499
[currently_entitled_amount_cents] => 1400
[last_charge_date] => 2021-12-01T21:55:20.000+00:00
[last_charge_status] => Pending
[lifetime_support_cents] => 13499
[patron_status] => active_patron
[pledge_cadence] => 1
[pledge_relationship_start] => 2021-09-01T06:09:16.102+00:00
[amount_cents] => 1400
[created_at] => 2021-09-01T06:09:16.102+00:00
[declined_since] => 2021-12-01T21:55:20.000+00:00

[WIth both of these examples.] user goes to the website, clicks the Login with Patreon button, and gets redirected - only to be shown the exact same page “… you must be a member…”.

As for not checking last_charge_status, you might want to re-read your code:

        public function fetch_user() {
                                        if ( $api_return['included'][0]['attributes']['last_charge_status'] != 'Paid' ) {
                                                $api_return['included'][0]['attributes']['declined_since'] = $api_return['included'][0]['attributes']['last_charge_date'];
        public static function getUserPatronage( $user = false ) {

                if ( isset( $pledge['attributes']['declined_since'])  && !is_null( $pledge['attributes']['declined_since'] ) ) {
                        do_action('ptrn/declined_since', $pledge, $pledge['attributes']['declined_since']);
                        return false;
        public static function isPatron( $user = false ) {
                $user_patronage = self::getUserPatronage();

                if( is_numeric( $user_patronage ) && $user_patronage > 0 ) {
                        return self::$current_user_is_patron = true;
                else {
                        return self::$current_user_is_patron = false;

If you want to reproduce it yourself, just take the serialized data i sent on the ticket and insert in mysql and override some code so that it doesn’t update that userid through the API - I’m sure you could find a way.

And again - all I’m asking is for a more descriptive message after the patron is logged into wordpress. I fully understand the complexities of trying to determine if the patron has actually paid for the current period. On that point specifically, I have found through debugging with half a dozen users that they all had either a pending charge, a declined charge, or some other issue with the payment method, which leads me to believe that the Patron API is actually more correct than their website. But I can’t be 100% sure about that, hence the request for a better message when encountering these states.

Is any of the above is actual, live api return which you got for that patron?

which leads me to believe that the Patron API is actually more correct than their website

You shouldnt assume that since there may be cases where the api follows the site from behind.

I’ll just repeat for the third time then, whilst you ignore the core points of my replies, and quote me on the one thing I mentioned I’m not sure about. But whatever.

I cleared the users metadata from mysql and had the user access the site. So yes, it is fresh data fetched from the API. All examples of it. Please refer to the support ticket on the paid subscription we bought out of goodwill (because we use none of the paid features).

Now, do you care to respond to the actual problem or is deflecting by irrelevant comments and ignoring the core issue all you do, just like on the support ticket? I’ve been handing you the issue on a silver platter for weeks now and you do absolutely nothing about it.

Sorry if you feel that things are ‘moving slow’ from your perspective. There is a certain accumulated knowledge base regarding the issues which plugin users may experience, and troubleshooting of any issue follows those steps, even if some may feel that things are moving slow.

If you are not using pro plugin’s any feature, just post your payment email or your payment id on a ticket so I can refund it.

I’ve been handing you the issue on a silver platter for weeks

Thank you for providing more info than majority of the cases, which definitely did help.

But the solution to this is not what you are asking since what you ask triggers various other things related to the interface, and its more complicated than how it looks.

However there is a workable solution to this, and it is making the plugin not check for anything related to patron’s payment, but instead its patron status. Since that is how behaves, it would be better to make the behavior the same. Which should fix your problem since your patrons would be able to access the content as long as they are qualified at

This can make it into the plugin in the next few releases.

Here’s a new variation from another user:

                            [campaign_lifetime_support_cents] => 3500
                            [currently_entitled_amount_cents] => 0
                            [last_charge_date] => 2022-02-01T19:46:38.000+00:00
                            [last_charge_status] => Refunded
                            [lifetime_support_cents] => 3500
                            [patron_status] => active_patron
                            [pledge_cadence] => 1
                            [pledge_relationship_start] => 2022-02-01T07:36:09.036+00:00
                            [amount_cents] => 0
                            [created_at] => 2022-02-01T07:36:09.036+00:00
                            [declined_since] => 2022-02-01T19:46:38.000+00:00

Same problem on refunds - user is an active patron but cannot access content.

Any ETA on this?

1-1.5 weeks for the solution I mentioned in my last message to go out.

1.8.3 just went out, and it removes declined payment checks. This should match the behavior to the one at and it should prevent patrons in declined state from losing access until payment retries are completed. It also removes the need for any declined patron text message.

= 1.8.3 =
* Removed declined payment related checks to match behavior to the behavior at []( Patrons should keep access until declined payment retries are completed
* Made custom page name sanitization more strict per request from WP org repo

You can just update from your WP admin.

Thank you. We won’t have much feedback until the beginning of the new month, so if anything does come up, i’ll post here in April.