ndeet
Forum Replies Created
-
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 functiongetallheaders()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 4 years, 7 months 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 4 years, 7 months 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 4 years, 7 months ago by ndeet.
Did you try the troubleshooting guide if it gives a “403 forbidden” http status or something else?
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.
Forum: Plugins
In reply to: [BTCPay Server - Accept Bitcoin payments in WooCommerce] What is this V2 ?marking as resolved
Can you give more details on your setup so I can reproduce? What do the logs say and which PHP version do you use?
Hi, we had that same problem recently with another user, his firewall blocked the requests to the callback. Like in your other thread this same troubleshooting guide applies if any firewall or plugin is blocking POST requests to your site:
https://docs.btcpayserver.org/WooCommerce/#the-order-states-do-not-update-although-the-invoice-has-been-paidHi, 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.