[admin]

Thanks for the detailed log.

Your webhooks are working correctly

Looking at the log, the Stripe webhooks are being received, validated, and processed successfully (invoice.payment_succeeded). The line “Ignoring unused stripe webhook event. Webhook type: customer.subscription.created” is normal, expected behavior — our plugin only acts on the events it needs and ignores the rest with a 200 response. It never returns a 403 for any webhook. So the 403 you’re seeing is not coming from our plugin’s webhook handling.

The 403 is a server-level block

“The server sent back an error: 403 Forbidden” is a response from your server (or a security/firewall layer in front of it), not from our plugin. Since you’ve already ruled out the SWPM Full Page Protection addon and ModSecurity, the next step is to identify exactly which request is being blocked:

Open your browser’s Developer Tools → Network tab, then run the payment test again. Find the request returning 403 and note its URL. That tells us what’s being blocked (e.g. admin-ajax.php, a REST API endpoint, or the return/registration page).
Check for any other security layer: Cloudflare or another CDN/WAF, Wordfence or a similar security plugin, or host-level firewall rules beyond ModSecurity. Any of these can return a 403 on a specific URL or query string.

Regarding XML-RPC

No, our plugin does not require XML-RPC to create registration pages or to process Stripe payments. You can leave it disabled; it’s unrelated to this issue.

Worth double-checking your setup

While you investigate the 403, it’s also worth confirming your Stripe button and webhooks were configured per our documentation:

Stripe subscription button: https://simple-membership-plugin.com/sca-compliant-stripe-subscription-button/
Creating the webhook: https://simple-membership-plugin.com/create-a-webhook-in-your-stripe-account/
Webhook signing secret (recommended): https://simple-membership-plugin.com/configuring-the-stripe-webhook-signing-secret/

Once you’ve identified the blocked request from the Network tab, reset the log file, run another test, and share both the 403 request URL and the new log data. That will pinpoint the source.

[admin]

Good to hear that you got it sorted out. Thank you for sharing your solution.

[admin]

Hi hapo, Since switching the export format didn’t fix it, the issue is most likely one of these:

Hidden BOM character in the file — Excel/Numbers on Mac often adds an invisible “byte order mark” at the very start of the file even when you export as plain CSV. This gets prepended to your first column header, so it’s technically not user_name anymore even though it looks correct. Fix: Open the CSV in a plain text editor (TextEdit in “Plain Text” mode, or VS Code/Sublime) instead of Excel/Numbers, and check the very first characters of the file.
Wrong delimiter, depending on your Mac’s regional settings, “Comma Separated” exports can still use a semicolon (;) instead of a comma. Open the file in a text editor and confirm the header row actually uses commas: user_name,email,password,…
Extra/renamed header cell — double-check there’s no trailing space, hidden character, or renamed cell (e.g., Username instead of user_name) in that first column header. The column name must match exactly, case-sensitive.

Quickest way to isolate it: Download the plugin’s official sample CSV template from Simple Membership > Import Members, and only replace the data rows — don’t retype or rebuild the header row. If that imports fine, the header row in your original file is the problem.

[admin]

Since you already have a dedicated thread for this question, I’ll continue the discussion and provide my response there:
https://simple-membership-plugin.com/forums/topic/how-to-enable-search-of-country/

[admin]

Update: We have added the option to search by country for the directory listing addon.

——
I’ll take another look at this over the next few days and get back to you with an update.

Since this issue relates to a premium add-on, please submit a support request via the following page so I can follow up with you by email:
https://simple-membership-plugin.com/premium-addon-support/

• This reply was modified 2 months, 2 weeks ago by admin.

[admin]

Let me add some more context.

This thread is referring to the Member Directory Listing Addon:
https://simple-membership-plugin.com/simple-membership-member-directory-listing-addon/

The search feature in the Directory Listing Addon can search the following fields:

Username
First Name
Last Name
Email
Company Name
Custom Fields (text-based fields work best)

Is your question related to the Directory Listing Addon?

[admin]

Hi, No you don’t need form builder addon for that.

Translation strings missing mean it hasn’t been translated in that specific language yet. The following translation documentation should be helpful:
https://simple-membership-plugin.com/translate-simple-membership-plugin/

[admin]

We don’t have a built-in feature for post allowance.

[admin]

Thank you for submitting the ticket. We have responded to your inquiry.

[admin]

Thank you for reporting this. Looks like Stripe has updated their UI. I have just updated the documentation to so it matches closely with the current Stripe UI:

https://simple-membership-plugin.com/sca-compliant-stripe-subscription-button/#create-a-webhook-in-your-stripe-account

Here is the documentation for creating a Stripe webhook:
https://simple-membership-plugin.com/create-a-webhook-in-your-stripe-account/

Here is the documentation for configuring webhook signing secret:
https://simple-membership-plugin.com/configuring-the-stripe-webhook-signing-secret/

Let me know if this is helpful.

[admin]

@Naovaczid, It will be an issue with the site’s setup. Do you have debug log data similar to what the previous poster shared?

[admin]

If you only created this button a couple of months ago, there’s no need to create a new one. Just update the Stripe webhook API version to the latest from the Developers menu in your Stripe account. After that, reset the debug log file and monitor new transactions for a few days to see if any issues come up.

[admin]

That looks fine to me. Everything executed as expected, and the recurring payment was processed correctly (membership level retained, account remained active).

One thing worth noting: the Stripe webhook events in your log are coming through with api version: 2018-05-21, which is quite old. This indicates the subscription button was likely created some time ago. You can upgrade the API version from the Developers menu in your Stripe account.

Since the button has been around for a while, it’s a good idea to review the current Stripe subscription button documentation and make sure all the steps are still valid for your setup:
https://simple-membership-plugin.com/sca-compliant-stripe-subscription-button/

You can also follow the documentation to create a new Stripe subscription button and replace the old one on your site. Existing subscriptions will continue running without interruption. Only new subscribers will use the new button. This is a good way to ensure that going forward, all new subscriptions are using the latest API version and the most up-to-date setup.

[admin]

Every site is different, and the original poster’s situation may include background details that don’t apply to yours.

The feature being discussed in this thread is documented here:
https://simple-membership-plugin.com/giving-wordpress-admin-user-access-protected-content/

There is no known bug with this feature. If it’s not working on your site, it’s most likely due to a conflict with another plugin/theme or a configuration issue.

If you’d like help troubleshooting, please describe your specific setup — what you’ve configured so far, what you expected to happen, and what’s actually happening. With that context, we can provide useful guidance.

[admin]

Thank you for sharing the log data. Unfortunately, this particular log doesn’t contain any recurring payment-related entries, so I’m unable to identify the issue from it. For us to troubleshoot effectively, the log file needs to cover the exact time when the issue occurs. I’d recommend resetting the debug log just before a recurring payment is due, so it captures only the relevant data from that event without unrelated noise.

A couple of clarifying questions to help us narrow this down:

1) When you mention “first invoice”, do you mean the very first checkout (when the user clicks the subscription button to create the subscription agreement), or the first recurring payment that occurs after the initial checkout?

2) From the timeframe covered by the current log, can you confirm whether the account was created correctly with the right membership level during the user’s registration/checkout attempt?

Also, since you’re using the WooCommerce addon as well, please go to that addon’s settings and make sure a value is set in the “Default Membership Level” field under the auto-create member account option. Missing this configuration can sometimes cause unexpected level assignments.

Once you’re able to share a fresh log covering a recurring payment event, we’ll take another look.

[Author]

Posts