Perfect - Thanks Matt!

Hi Paul,

This likely will be related yea as those URL's previously contained /umbraco in them so they have been updated to use the umbraco back office mvc area. Not quite sure why it's not triggering though so let me do some further tests.

What exactly is the Umbraco.Core.Path app setting set to?

Ok, that should be fine. I was just checking if there was a casing difference as the callback handler does a URL hash comparison to make sure it wasn't tampered with 🤔

In terms of the URL not working, do you know if this is a 404 error? or a bad request 400 response? or a 500 error response?

Unfortunately not - the only feedback I get from the provider is:

We failed to deliver a webhook for a successful payment.

Error details 16 attempts made %{"1" => "closed", "10" => "closed", "11" => "closed", "12" => "closed", "13" => "closed", "14" => "closed", "15" => "closed", "16" => "closed", "2" => "closed", "3" => "closed", "4" => "closed", "5" => "closed", "6" => "closed", "7" => "closed", "8" => "closed", "9" => "closed"}

If I attempt to browse the callback URL I get a 400 error.

Ok, so if that is the issue then it would suggest the URL hash comparison failed or it couldn't locate a payment provider with that alias

Just gonna double check the routing is working as expected first

Ok, so I've just tested with your exact path config and everything seems to be working as expected. The URL's are being generated with your prefix, and the route handling is correctly triggering to handle the callback.

The fact that you see a 400 does mean the routing is working, but it's failing some of the checks, which is the hash on the end of the URL has been altered, or it can't find the payment provider with that alias, or it can't find the order with that order id, or the orders payment method id is null

Could any of these be the case? Is this a fresh order you've created after upgrading? or could it be one that was created prior to the upgrade and so could have some old info affecting any of these?

And again, if you run call that URL yourself, you are still seeing a 400 bad request response?

PS No, stripe being listed twice is fine. It's a known bug. Essentially the stripe payment provider has two payment provider instances in it, so it's being shown twice in the list. We just need to call Distinct on that list :)

Yes, when I browse that url I get 400 response.

I have removed the payment method and recreated it, and still the same issue.

🤔 I'm not sure what else to suggest atm, other than getting you to zip up the project (removing any personal data) and then I can debug into the method call and see which element is causing the 400

Hmm, quite possible. You might need to add another entry for hoi-admin-protected/vendr

<rule name="Ignore" stopProcessing="true">
  <match url="^(?:hoi-admin-protected/api|hoi-admin-protected/surface|hoi-admin-protected/vendr)/" />
  <action type="None" />
</rule>

But given you get a 400 error and not a 404, I am thinking it is actually hitting the route, but, if something in a rewrite rule is messing with the URL, that could be an issue so worth adding that rule.

That was the issue. Adding the /vendr rule means that the provider can now post the data back and it is working again.

I guess before the v1.6 upgrade you were posting to /umbraco... which isn't IP restricted on my site, so there was no issue with it being blocked.

Sorry for wasting your time!! 😬

Haha, no worries. I'd much rather know if there is a potential issue in Vendr so it can be fixed.

Just glad it's all now up and running 👍

Matt