No email notifications, plugin ignores success/cancel URLs in form settings

[ttmwebdesign]

Hello, I am trying to set up a subscription based membership site using this plugin. I've encountered a problem I don't really understand why it is happening.

The orders are successful in both the back-end of Craft and being sent to my Stripe sandbox.

However, there are no notifications being sent. At first I didn't see the errors in the logs, but I tried different keywords and finally encountered this (url edited for privacy):

#27 {main} {"memory":7713048,"exception":"[object] (TypeError(code: 0): enupal\\stripe\\services\\Orders::getReturnUrl(): Argument #2 ($url) must be of type string, null given, called in /home/ploi/staging.thedomain.com/deploy/vendor/enupal/stripe/src/elements/PaymentForm.php on line 237 at /home/ploi/staging.thedomain.com/deploy/vendor/enupal/stripe/src/services/Orders.php:497)"} 

If I dig further, this is the URL that I think it is trying to use for the Success URL:

"success_url":"https:\/\/staging.thedomain.com\/enupal\/stripe-payments\/finish-order?session_id={CHECKOUT_SESSION_ID}"

...even though I have "/account" set in the payment form settings for this form, so it should be going there - but it is not. And of course the above URL does not truly exist for the site, so it ends up landing on the main homepage instead of where I am expecting it to be.

The rendering tag is very simple, no extra overrides:
{{ craft.enupalstripe.paymentForm('monthYear') }}

My assumption is that it is hitting this success URL issue, and not proceeding to the trigger for the mailer to send the notifications, since those never grace Mailgun's presence.

I've confirmed that Mailgun & the Craft mailer work by way of the test email function in the "Email" page of the Craft Control panel, and with a contact form on the front end that uses P&T's "Contact Form" plugin.

Please advise. I'm about at my wits end here trying to get this working.

The site is on Craft 4.15.3, and Enupal Stripe Payments is on 5.5.2 (trial version, for full disclosure).

[ttmwebdesign]

Following up to add some new information.
I was able to finally get the notifications working. I suspect there was an issue with how everything installed when I did the install+settings config in one push. I did have problems with it - it wouldn't query Stripe for the products even though I had the right keys after the code push - I ended up having to uninstall the plugin & re-install it - but on the server, not via GH code push - before it would retrieve the products from Stripe in the payment form. But, then I had the problems with the notifications not working.

I created a new server to test with, and did the install/config in separate steps. Install, deploy. Settings config, deploy. Then notifications worked after I added the new endpoint to point to the new subdomain. FWIW, on the new server I set it up on Craft 4.15.6.1, so that's a little different than the other one, but given the plugin's version didn't change, I'm not sure how much of an impact this actually had.

However, the return URL is STILL being ignored. This time I have placed it in three different locations - Global Return URL under Advanced/Defaults; Success Return URL under Pro/Checkout, and also in the Checkout Success URL in the payment form itself. It is still returning to the homepage and disregarding all of these settings. The web log still shows it is redirecting to the same URL as noted in my original opening remarks, not the one I've specified in the three settings.

Thanks.

[andrelopez]

Hi @ttmwebdesign thanks for the update. Could you please confirm what method are you using to display the form?

[ttmwebdesign]

It is the same code snippet from before:

{{ craft.enupalstripe.paymentForm('monthYear') }}

It is in a modal if that makes any difference.

[andrelopez]

Hi @ttmwebdesign Thanks for the info!

To ensure the user is redirected to the correct returnUrl, the entire payment flow must complete successfully — including receiving the Stripe webhook in your Craft CMS setup. You can find the full documentation on this here:
🔗 Stripe Webhooks in Craft CMS

If you're testing locally:
Make sure you're using the Stripe CLI to forward webhook events to your local environment. You can find a detailed guide here:
🔗 Test Webhooks Locally

If you're testing on a staging server:
Ensure your webhook URL is publicly accessible. You can verify this by opening it in an incognito window.

Also, please check your Stripe Dashboard to confirm whether the webhook was received successfully by your Craft CMS site.

Let me know if that helps or if you run into any issues!

[ttmwebdesign]

The webhook is set up and received everything OK.

It turns out that it is the default URLs that are not working as I would expect. I had forgotten to add it into the Payment form on this particular new set up, but I did have them in the other two places I mentioned:

Global Return URL under Advanced/Defaults; Success Return URL under Pro/Checkout

Once I added it into the Payment Form it started working, but it does concern me that having something in the above two sections ultimately did nothing. Should the defaults be stepping in when no return URLs are set in a Payment Form?

[ttmwebdesign]

@andrelopez On the other side of the coin regarding what I said in my previous note, the payment process has a partial failure if there is nothing in the Settings -> Defaults -> Global Return URL, too! I had started to set this up for sending to a live site and it failed at the email notification stage, Stripe was hitting 500 errors instead of successfully responding with the site on its return messages. Once I added a valid URL into the default return URL, it started to work.

In the case of the Payment Form, shouldn't what is defined in there as the cancel and return URLs be king? Why does it matter whether there is anything in the global default return URL? I haven't yet experimented to find out whether Stripe will see what is in the Global default or the Payment form for the return URL if they happen to be different.

There are other quirks I've noticed but these may be more aesthetic than show stopping. I'm going to look through the open issues and see if they're already covered in any of them or not. If not, I'll open new issues.