* IPN lookup by stored invoice ID instead of untrusted order ID.
* Invoice ID stored as provider_reference and checked for reuse.
* Transaction row locking prevents concurrent duplicate checkouts.
* Existing invoices are reused; expired ones are replaced safely.
* Late notifications for replaced invoices are ignored.
* Reduced sensitive webhook logging and restricted IPN to POST.
Security: the checkout controller built the BTCPay invoice from the POSTed
redirect-form data (price, currency, orderId), and the IPN never checked
the settled amount against the transaction. A buyer could therefore submit
an arbitrary price and confirm an order after paying far less. The invoice
is now built server-side from the transaction, the redirect form only
carries the reference, and the settled amount and currency returned by
BTCPay are verified before the transaction is set done.
Other fixes in the notification path:
- Fix the IPN notification URL: it was concatenated without a leading
slash (base_url + "payment/btcpay/ipn"), producing an unreachable host
so notifications never arrived. It is now built with urls.url_join.
- Handle the "expired" invoice status (cancel the transaction) instead of
leaving it pending forever, and set an error on unknown statuses.
- Let the payment framework confirm the order and send the confirmation
email via its post-processing, instead of calling
_check_amount_and_confirm_order() and _send_order_confirmation_mail()
manually, which sent the confirmation email twice.
- Fix a crsf=False typo (was disabling nothing) to csrf=False on the
return route, and drop the redundant _handle_notification_data override
that duplicated the core method.
- Guard against a missing reference instead of calling all() on it.
ndeet
SatoDri