Plugin Author
ndeet
(@ndeet)
Hi, you can go to the invoice details and check if the “Webhook deliveries” are present, if yes but you get a red “X”, which means delivery failed you can check the following:
We had quite some users recently having the callback endpoint being blocked by their provider of firewall. Please check if this is the case for you as well https://docs.btcpayserver.org/WooCommerce/#the-order-states-do-not-update-although-the-invoice-has-been-paid
If you do not have any Webhook deliveries the webhook might be missing?
You can check on your BTCPay Server instance in the store settings if the webhook was created. If there is no webhook you can create it automatically by going the the BTCPay Settings page and hitting save.
Thread Starter
slate
(@meanwood)
Upon hitting save, the webhook is not being created.
Plugin Author
ndeet
(@ndeet)
It will only get created if there is none yet. So please check on your BTCPay Server, Store settings -> webhook if it is already there. If yes then all good. You can check the invoices details on BTCPay to see if sending the webhook failed.
Thread Starter
slate
(@meanwood)
It shows “reusing existing webhook if i hit save in the plugin settings menu in woocommerce”: https://nextcloud.mnwd.in/s/kHrPz3KPBpY4fGb
But the webhook on BTCPayServers end does not exist, nor is being created: https://nextcloud.mnwd.in/s/epsJYZHxBoPWZKn
Plugin Author
ndeet
(@ndeet)
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?
Thread Starter
slate
(@meanwood)
If by logs you mean the plugins logs this is the full message:
2022-03-04T16:10:09+00:00 DEBUG Using cache, skipping to generate separate gateway classes.
Thread Starter
slate
(@meanwood)
Plugin Author
ndeet
(@ndeet)
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.
Thread Starter
slate
(@meanwood)
“getallheaders() CamelCases all the headers in the resulting array”: Cannot confirm that from my observations, nor is there a reference for getallheaders() acting like that https://www.php.net/manual/en/function.getallheaders.php.
Upon logging it via Logger::debug(print_r($headers,true)); you specifically get the header key to be BTCPay-Sig, not Btcpay-Sig
Furthermore it would imo be smarter to make the check for the btc pay sig header case insensitive…
-
This reply was modified 2 years, 1 month ago by
slate.
-
This reply was modified 2 years, 1 month ago by slate.
Plugin Author
ndeet
(@ndeet)
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.
Plugin Author
ndeet
(@ndeet)
Fixed it and released v0.2.4.
Thread Starter
slate
(@meanwood)
That works, thanks for the quick reaction.
