OpenReceive Files

OpenReceive 0.4.31 brings the Ruby, Python and PHP engines' reconcile pass in line with the Node engine: it stops reading wallet history once every invoice it is looking for has been seen, one wallet call fewer per pass while a payer waits. The Rails engine now requires nwc-ruby 0.4, which derives a connection's encryption key once per client instead of on every wallet call. Package registries get new keywords and descriptions.

Optional swaps let payers use USDT, USDC, SOL and ETH; a configured swap provider converts them to BTC over Lightning in the merchant's connected wallet. Asset and network availability depends on the provider.

• Fixed (Ruby, Python, PHP): a reconcile pass now stops once the wallet has listed every invoice it is looking for, unpaid ones included, as the Node engine and the BTCPay Server plugin already did. While a payer waited on an unpaid invoice, each pass read three pages of wallet history: the empty settled view, the unpaid page that lists the invoice, and an empty page after it. It now reads two, one wallet call fewer per pass. A pass that stops there still closes an invoice the wallet lists as pending after expiry plus the 900-second grace, as a pass that read on to the empty page did. A new spec/test-vectors/reconcile-progress.json vector pins both in all four engines. The WordPress, PrestaShop, FOSSBilling and Paymenter plugins bundle the PHP engine, so their 0.4.31 ZIPs carry the fix; the Odoo module gets it from the openreceive Python package.
• Changed (Rails): openreceive-rails now requires nwc-ruby ~> 0.4. nwc-ruby 0.4.0 derives a connection's encryption key once per client instead of on every wallet call and notification; the pure-Ruby derivation took about 33 ms on a laptop, more on a server vCPU, twice per call. The engine keeps one client per process, so reconcile passes, wallet history pages and the openreceive:notifications worker all reuse that key. The client API and the wire format are unchanged.
• Changed (registries): new keywords and descriptions, metadata only. Every published npm package and the openreceive/openreceive and openreceive/laravel Composer packages add the keywords stablecoin, usdt, usdc, payment-gateway, self-hosted and bitcoin-payments. @openreceive/medusa adds medusa-v2 and medusa-plugin-integration, the keywords Medusa's integrations page lists plugins by. The Python package names Flask in its description, adds the Framework :: Flask classifier and the keywords flask, payment-gateway and self-hosted. The gem summaries name the optional USDT and USDC swaps, and the core gem names Rails. USDT and USDC still arrive only through a configured swap provider, as BTC over Lightning in the merchant's wallet.