OpenReceive Files

OpenReceive 0.4.32 keeps a checkout working through a slow or briefly unreachable wallet relay. A Node server that failed its wallet check at start-up now boots again on a later request instead of answering 503 until a restart, and the PHP engine, which the WordPress, PrestaShop, FOSSBilling and Paymenter plugins bundle, retries a slow relay handshake instead of failing on the first one. WooCommerce and Easy Digital Downloads no longer hide OpenReceive from checkout when a price lookup fails. The checkout shows Try again on a failed Bitcoin invoice, plain words when the wallet did not answer, and a "Total" row with the order's own amount. The WordPress.org listing now says crypto in its name, tags and short description, Vendure's package ships its own changelog, and the Odoo module is ready for the Odoo Apps store.

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 (Node): one failed wallet check at start-up no longer takes payments down until the process restarts. createStack (and so every @openreceive/express, /fastify and /next mount built from an nwc code) kept the first boot's failure for the life of the process: after one relay timeout every request answered 503 WALLET_UNAVAILABLE in no time, although the relay was fine seconds later. Now the first request after a short wait boots again and is served if the wallet answers. The wait starts at 1 s and doubles after each failure, up to 60 s; there is no timer, so an idle process makes no wallet calls. ready still reports the first boot. A service the host passes in is the host's promise and is not retried. createOpenReceive now closes the wallet client it built when the wallet check fails, so a retry leaves no relay socket open, and it reads every local setting before it touches the relay.
• Fixed (PHP): one slow relay handshake no longer fails a checkout, a swap address or a settings save. Each handshake had at most 1 s and each relay one try, so a wallet code naming one relay (Rizful's) failed whenever its handshake took longer; from a shop container, two of eight took 1.71 s and 3.24 s. A handshake now gets up to 4 s, never more than a fair share of the request's 8 s budget, and a failed one is retried, cycling the relays, after a short pause that doubles each round, until too little time is left to use. Nothing reaches the wallet before a handshake succeeds, so the retry is safe for an invoice too. A relay that is down now takes about 6 s to fail instead of about 1 s. The WordPress, PrestaShop, FOSSBilling and Paymenter plugins bundle the PHP engine and carry the fix.
• Fixed (WordPress): a failed price or wallet lookup no longer hides OpenReceive from checkout. WooCommerce's is_available and Easy Digital Downloads' gateway filter called the price feed (and, with a cold cache, the wallet) on every page that lists payment methods, and dropped the method on any error, so a store with no other gateway said "There are no payment methods available" for a while. They now check only local state: a wallet code is saved and parses, the payment tables exist, and the store currency is one the price feeds quote. A failure at pay time shows the payer the error with Try again.
• Fixed (WordPress): a settings save the wallet's relay did not answer says so: "OpenReceive settings were not saved: the wallet's relay did not answer in time. Your codes were not checked. Press Save again." It used to tell the shop owner to check codes that were fine. Other save failures now add the redacted reason, as Easy Digital Downloads already did.
• Fixed (checkout): a failed Bitcoin invoice shows a Try again button. The element showed the error as bare text over the method list, with no way forward; React showed nothing at all. Both now show the message and a Try again that requests the invoice again. When the wallet or its relay did not answer (WALLET_UNAVAILABLE, TIMEOUT), the payer reads "The payment service did not answer in time. Please try again." instead of the engine's own text ("Configured NWC relays are unavailable."), on the invoice, the swap address and the "Could not start checkout." screens. Every other server message is kept. payerErrorMessage is exported from @openreceive/browser/headless for custom UIs.
• Fixed (checkout): the swap breakdown's first row reads "Total", not "Cart total", which was wrong for a donation or an invoice, and shows the checkout's own fiat amount. It showed the swap provider's valuation of the payout, rounded on the provider's rate, so a $49.00 order could read $48.99. The fee is measured from the same total. The provider's figure is still used when the checkout's amount is in another currency. The cartTotal field and label key keep their names.
• Changed (checkout): a settled payment reads "Payment received / Thank you. Your payment is confirmed." instead of "Backend settlement verified.".
• Fixed (doctor): openreceive doctor --db <file.sqlite> on Node 22.5 to 22.12, where node:sqlite is behind a flag, reads the file with the app's own better-sqlite3 instead of failing a check the app passes.
• Docs (agent directions): a donations and pay-what-you-want rule in every library stack's directions. The amount enters through the host's own route and is saved on a row before checkout, with a floor, a cap and two decimal places, refused rather than rounded. "Both codes set, skip to step 5" no longer skips covering .env in .gitignore. The Node quickstart says a plain-HTML page installs @openreceive/elements and links its standalone build steps, the Node guides say node:sqlite needs Node 22.13, and the API reference names the pay_in_asset / pay_asset difference on /swaps/quote.
• Added (Vendure): @openreceive/vendure now ships its own CHANGELOG.md (Vendure entries only), which Vendure's plugin directory requires and displays, and the plugin class carries the @category Plugin tag the directory builds its docs from. release:prepare and release:stamp handle its headings with the gem changelogs, and check:release checks it.
• Changed (WordPress): the WordPress.org listing says what store owners search for. The plugin is now "OpenReceive – Crypto Payments for WooCommerce & Easy Digital Downloads (Bitcoin, USDT, USDC)", in both the readme and the plugin header; its tags are crypto, bitcoin, usdt, woocommerce and payment gateway; and the short description and the Plugins screen's description read "Accept crypto in WooCommerce or Easy Digital Downloads: Bitcoin, USDT and USDC, paid to your wallet in Bitcoin. No approval necessary, no API key." USDT and USDC still arrive only through a configured swap provider, as BTC over Lightning.
• Added (Odoo): the module is ready for the Odoo Apps store. It has a store page (static/description/index.html) that names the outside services it contacts, a cover image, and a 256-pixel icon. The provider form now says what the module contacts once a code is saved: the wallet through the relay in its code, the BTC price feeds, and, with a swap code, the swap provider. npm run release:odoo-apps:publish pushes each release's module to the 19.0 and 20.0 branches of OpenReceive/odoo, the repository the store scans, with the version under each Odoo series (19.0.<version>).