ndeet

Hi @tehcook,

as you can see in the video the setup process should be pretty straight forward https://www.youtube.com/watch?v=ULcocDKZ1Mw

So the “BTCPay Server URL” is the hostname of YOUR BTCPay instance, e.g. https://testnet.demo.btcpayserver.org/

”This site can’t be reached btcpayserver.myurl.com’s DNS address could not be found. Diagnosing the problem.
Try running Windows Network Diagnostics.
DNS_PROBE_STARTED”.

I assume this error message is happening after the redirect started and shown your Desktop? If yes, looks like your home network has problems with resolving the URL/host of the BTCPay Server instance. You should not be able to reach your BTCPay Server instance (https://btcpayserver.myurl.com) by directly entering it into another browser tab either. Please check any spelling mistake of the URL. Best to copy and paste it from your browser tab where you have BTCPay Server open, to avoid any typos.

And lastly, I tried to manually sync the shop to btcpay but no webhooks were created either. So I’m stuck here trying to figure what is going on.

This process is described in the docs here. But here again it is important that your BTCPay Server URL is correct, otherwise it won’t work.

Please double check that your BTCPay Server instance is reachable and you entered the correct URL into the field. Also check for whitespaces in front and after the URL and make sure there are none.

Let me know if it still does not work. You can also come to https://chat.btcpayserver.org and ping me there and give me your shop and BTCPay Server URL so I can check. My name in the chat is @ndeet

• This reply was modified 2 years, 11 months ago by ndeet.

Fyi, this was also changed with v0.2.4

Fixed it and released v0.2.4.

It seems that this function does only work for PHP-FPM from PHP 7.3.0 (see manual entry above). Maybe the FPM implementation is different than the existing ones? Also I have Nginx so maybe this is messing with headers, not sure.

This old comment mentions that per RFC the headers are case insensitive, lol.

Like you suggested best would be to lower case the array keys before processing to be sure whatever it does it will work.

A miracle that you even found out that this was messing things up. I assume there is no way you can mark certain things to not get messed up/cached at all. Thanks for sharing how to work around that problem.

No not really, the new plugin is completely new codebase and therefore not just an update of the old one. It is based on the Greenfield API which allows much more features like refunds than the old BitPay compatible API. Some things were done differently also because of learnings from limitations of the old API.

With the above mentioned event it should be doable to get that same functionality back but there needs to be some upgrade functionality as we currently do not subscribe to that event, so the webhook needs to get updated with the installation the new release the plugin.

Ok, this has nothing todo with litespeed-cache. This only logged because of debugging mode enabled. Logs of type DEBUG are not a problem but verbose information. The idea of debugging mode is to understand to where it fails in detail and it should always switched off again after investigation of a problem is finished. But yes in that case it seems the code is hit multiple times per request because it also hits for each Ajax request and is a bit annoying, I will remove it on the next release to not clutter the debug log.

As mentioned in the other thread you linked, the headers are always CamelCase and it should be no problem. But as you also stated in the follow up post it seems the problem was caused by CDN afaiu.

Good question, at the time of working on this part there was only InvoiceExpired and InvoiceSettled (among other events), which did not cover that case as the invoice would expire and not change or fire any event afterwards.

But since a few releases there is an InvoicePaymentSettled event that fires even when an invoice is expired. In the payload it provides a boolean if the payment settled after expiration. We could use this to reproduce that status. I will work on that next week and update you here when it is ready.

Thanks a lot for debugging!

The redirect from BTCPay Authorization page back to store does hit a different endpoint (your-domain.com/?btcpay-settings-callback) than the webhook where no signature check is done at all.

The signature validation runs on every AbstractGateway::processWebhook() call. For some weird reason the PHP function getallheaders() CamelCases all the headers in the resulting array, so no matter if the signature header is called “BTCPay-Sig”, “BTCPAY-SIG”, “btcpay-sig” the array key will always get end up as “Btcpay-Sig”.

So to sum up the CDN (stackpath) was messing things up? Did they cut out the header? Anything we can leave here for other users that may run into same problem?

Will keep discussion ongoing on Mattermost Chat if anything arises.

• This reply was modified 3 years ago by ndeet.

Yeah, discussing on Mattermost is always better than here. I will try to reproduce on a fresh install with that caching plugin installed.

If the setup wizard does not work I assume you followed the manual steps here https://docs.btcpayserver.org/WooCommerce/#22-connect-by-manually-creating-the-api-key-and-permissions

That said it is really strange that it shows you that the webhook already exists. I will need to debug this too. Will be afk now but will check later today and reach out to you. What you could do in the meantime is to delete the webhook options “btcpay_gf_webhook” in “wp_options” table, after that it should try to create one for sure. BUT, if you have no clue how to do it then better not do anything and wait until I debugged but I can only do it later, will be afk now for some time.

• This reply was modified 3 years ago by ndeet.

Thanks that is helpful to reproduce, will try that plugin. You said it spams the logs, what do the logs say? Error message?

Thats interesting. On save it normally queries the BTCPay instance and compares the registered webhook URL for the store id provided and the url. So if you manually delete the webhook it should get recreated. Are you sure you are looking on the store with the ID also set in the BTCPay Settings on your site?

That looks good, the request validation fails but there is no “403 forbidden” status. So this means nothing is blocking requests where the webhooks send data to and this is good.

A bit difficult to follow along with the other two open threads. Does this mean on your BTCPay settings page you do NOT have the api key and store id prefilled currently? Or did that work in the meantime?

• This reply was modified 3 years ago by ndeet.

Did you try the troubleshooting guide if it gives a “403 forbidden” http status or something else?