[Resolved] 403 Error – Redirect to Paid Registration Link

Because you’re also using the SWPM Full Page Protection addon, temporarily disable that addon and repeat the payment test. This will help determine whether the 403 is being triggered by page protection or by something external.

If your host provides page caching or server-level security, ask whether any rules are returning a 403 on the registration URL after Stripe redirects back to your site.

The developer has been notified.

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.

Thanks for the update, and thanks for reporting back that it was the firewall’s bad query string / XSS rules causing the 403. That’s a useful detail, because it’s very likely relevant to the PayPal issue too.

Your PayPal log shows exactly where the flow stops

A complete PayPal subscription checkout produces this sequence in the debug log:

1. swpm_pp_create_subscription ajax request received for createSubscription… ✔ you have this
2. PayPal Subscription ID: I-XXXXXXXX ✔ you have this
3. Webhook event type: BILLING.SUBSCRIPTION.CREATED ✔ you have this
4. Webhook event type: BILLING.SUBSCRIPTION.ACTIVATED ✔ you have this
5. OnApprove ajax request received for createSubscription… ✘ missing

Step 5 is the one that matters. The onApprove step is a browser-side callback: once PayPal approves the subscription, the button’s JavaScript sends one final AJAX request from the customer’s browser back to your site’s admin-ajax.php. That request is what creates the payment/member record, sends the registration email, and returns the URL the customer should be redirected to.

Your log has no OnApprove entry at all, which matches your symptoms precisely: PayPal takes the payment (hence the PayPal emails and the ACTIVATED webhook), but the popup never hands control back to your page — so no registration email and no redirect. The webhooks alone do not create the member account; the onApprove request does.

Most likely cause

Since your firewall was already returning 403s on this site, the first thing to rule out is whether it’s still blocking that second AJAX request. The onApprove request POSTs a JSON payload (subscription details, PayPal URLs, etc.) to admin-ajax.php — exactly the kind of thing that “bad query string” and XSS filter rules tend to trip on. The first AJAX call (create subscription) is a much smaller payload, which would explain why that one gets through and this one doesn’t.
To confirm, please do this:

– Open your Join page in a browser where you are not logged in as admin.
– Open Developer Tools → Network tab (tick “Preserve log”), and also open the Console tab.
– Complete a test payment.
– Look for a POST to admin-ajax.php with action=swpm_onapprove_process_subscription. Tell us whether it appears at all — and if it does, what status code and response body it returns.
– Note any red errors in the Console.

That one check tells us whether the request is being blocked (firewall/WAF), is failing (server error), or is never sent, which would point to a JavaScript conflict instead.
https://simple-membership-plugin.com/forums/topic/test-for-plugin-and-theme-conflict-before-posting-an-issue-or-a-bug/