The MemberPress account page is where members can view their active subscriptions, payment history, and account settings. When a member logs in, they expect to see accurate information about their membership status, next payment date, and past transactions. However, sometimes the account page shows incorrect data, such as subscriptions that have already been cancelled appearing as active, or payment history missing recent transactions.
This problem can be particularly damaging for member trust and can lead to unnecessary support tickets. Members who see incorrect information may contact support believing there is a billing error, or they may cancel valid subscriptions because they appear to be inactive. The issue may affect all members or only specific ones, and it may appear after updating MemberPress or installing a caching plugin.
The most common cause of this problem is that a caching plugin is serving a cached version of the account page. Another cause is that the MemberPress database has inconsistencies between the transactions table and the subscription status, or that the member’s session data is corrupted.
Why MemberPress account page shows wrong data
MemberPress account page uses the [mepr-account-form] shortcode to display member-specific information. This shortcode queries the database for the logged-in user’s subscriptions and transactions and generates HTML dynamically. If the page is cached, the generated HTML is stored and served to all users, showing the same data to everyone regardless of their actual membership status. This is why different members may see the same (incorrect) information.
Another common cause is that the MemberPress transaction and subscription tables are out of sync. This can happen if a payment gateway webhook was not processed correctly, or if a manual change was made to the database. For example, if a subscription was cancelled at the gateway but the webhook failed, the MemberPress database may still show the subscription as active, even though payments have stopped.
Session data corruption can also cause the account page to show wrong information. If the user’s session contains outdated membership data, the account page may display that cached session data instead of querying the database for fresh information. Logging out and back in usually resolves session-related issues.
How to check if the account page is being cached
Log in as two different users (using two different browsers or incognito windows) and view the account page. If both users see the same information (e.g., both see the same subscription names or payment dates), the page is being cached and served from cache instead of being generated dynamically for each user. The account page should never be cached because it contains user-specific data.
Step by step guide to fixing MemberPress account page problems
Follow these steps in order to restore proper account page functionality in MemberPress. Start with the simplest solutions before moving to more advanced troubleshooting steps.
- Clear all caches including plugin cache, CDN cache, and browser cache completely
- Exclude the account page from all caching plugins (add /account/ to never-cache lists)
- Configure caching plugins to never cache pages for logged-in users
- Log out and log back in to refresh the user session
- Check the MemberPress transaction and subscription tables for inconsistencies
- Run the MemberPress database repair tool if available (MemberPress → Settings → Tools)
- Sync subscription statuses with payment gateways using the MemberPress webhook resend feature
- Temporarily disable all other plugins to test for conflicts with MemberPress
- Update MemberPress to the latest version available from the official website
- Contact MemberPress support with specific details about which data is incorrect
How to exclude the account page from caching plugins
In WP Rocket, navigate to Settings → WP Rocket → Advanced → Never Cache URLs and add the URL of your account page (e.g., /account/). Also enable the “Cache for logged-in users” option to ensure logged-in users bypass the cache entirely. In LiteSpeed Cache, go to Cache → Excludes → Do Not Cache URIs and add the account page URL, and enable the “Cache Logged-in Users” option. In W3 Total Cache, go to Performance → Page Cache → Advanced → Never cache the following pages and add the account page URL, and set the “Cache requests for logged-in users” option to “Disable”.
MemberPress account page troubleshooting reference table
Here is a reference table for diagnosing account page problems in MemberPress based on specific symptoms you might encounter.
| Symptom | Most likely cause | Recommended solution | Different users see same subscription data | Account page being cached | Exclude account page from all caching plugins | Cancelled subscriptions appear as active | Webhook failed to update subscription status | Resync subscription status with payment gateway | Recent payments not showing in history | Transaction not recorded or webhook failed | Check payment gateway logs and manually add transaction if needed | Account page works for some members but not others | Specific member’s data corrupted | Manually review the affected member’s subscriptions |
|---|
For more information about MemberPress account page settings, visit the MemberPress page on wpwizzy.com.
Preventing MemberPress account page problems in the future
Exclude the account page from all caching plugins as soon as the site is launched, and configure caching plugins to never cache pages for logged-in users. The account page contains dynamic, user-specific data and must always be generated fresh. Clear all caches immediately after making changes to membership or subscription settings, and test the account page with multiple test users after every update.
Regularly check the payment gateway webhook logs to ensure that subscription status updates are being processed correctly. Keep MemberPress and all other plugins updated to their latest versions on a regular schedule, and use a staging website to test major changes before applying them to the live production site. Consider using a user role editor plugin to limit which users can view the account page if needed.