OpenReceive Files

OpenReceive 0.4.30 adds three store integrations: a native PrestaShop module, an Odoo payment provider (Odoo 19 and 20, self-hosted or Odoo.sh) and @openreceive/vendure, a Vendure 3 payment plugin. The PrestaShop and Odoo pages on openreceive.org now lead with the native modules; the BTCPay Server route stays documented as its own guide. It also fixes the Medusa storefront's stylesheet route in production builds and corrects the guides after a review of openreceive.org.

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.

• Added (PrestaShop): a native payment module for PrestaShop 9, built as a release ZIP, openreceive-prestashop-<version>.zip, with one openreceive folder for the back office's Upload a module or for modules/ and php bin/console prestashop:module install openreceive. Its dependencies are prefixed inside the module's vendor.phar, and the checkout's script ships in views/assets. The customer picks the option at checkout; PrestaShop creates the order in the module's "Awaiting Bitcoin payment" state and its order confirmation page shows the checkout, as do the order's page in the customer's account and guest order tracking. A settled payment is recorded as an order payment whose transaction id is the payment hash, in the settlement transaction on PrestaShop's own database connection; after the commit the order moves to "Payment accepted", with PrestaShop's invoice and email, and every checkout request and reconcile pass finishes an order that missed that step. Only the order's customer, or a browser PrestaShop showed the order's page to, may pay it, and every write needs the page's token. Codes are saved on the module's Configure page or from stdin with bin/console openreceive:configure, encrypted with the shop's key; openreceive:doctor, openreceive:test-invoice [--new] and openreceive:reconcile (a cron line every five minutes, since PrestaShop has no scheduler) complete the commands. PrestaShop's integration page now shows this module; the BTCPay Server route stays as its own guide.

• Added (Vendure): @openreceive/vendure, a plugin and payment method handler for Vendure 3.3+ (Node 22.12+, PostgreSQL, MySQL or MariaDB). Add OpenReceivePlugin from @openreceive/vendure/plugin to vendure-config. The buyer pays at the storefront's checkout before the order is placed: POST /openreceive/order, with the buyer's Vendure session, moves the active order to ArrangingPayment and answers its reference, the order's code, currency and amount due, so a changed cart gets a new invoice. Only that session, or the signed-in customer who owns the order, may pay it. Once the payment settles, the plugin adds a settled Vendure payment (the payment hash as transaction id) under a lock on the order, and Vendure places it; the Shop API's addPaymentToOrder cannot add one. A scheduled task on the worker, every minute, places orders whose buyer left. The plugin keeps its attempts in Vendure's database over Vendure's own connection, and a migration creates the two tables when the server runs its migrations. dist/enable-openreceive.js creates the payment method through the Admin API. A refund made in the dashboard stays pending. Docs: the Vendure quickstart with the code for Vendure's Next.js starter, and agent directions (/agent-directions/vendure.md, references/vendure.md in the skill). A trial platform (trials/platforms/vendure) runs Vendure 3.8, its worker and the Next.js starter, and a CI lane runs the plugin against a real Vendure server on PostgreSQL.

• Added (Odoo): a payment provider module for Odoo 19 and 20, self-hosted or on Odoo.sh. Each release attaches openreceive-odoo-<version>.zip, the module folder payment_openreceive; its Python side is the openreceive package at the same version. The customer picks OpenReceive on Odoo's payment step, at checkout or on an invoice's payment link, and pays on the module's checkout page; only the browser session that started the payment may pay it. The amount is the payment transaction's, read on the server. Settlement marks Odoo's transaction done and runs Odoo's post-processing in the same database transaction, so the order is confirmed when the checkout reports the payment; a post-processing failure leaves the transaction done for Odoo's cron. The payment tables live in Odoo's own PostgreSQL, through a repository on Odoo's cursors that switches each transaction to READ COMMITTED for the per-reference lock. Codes are saved from the provider form or odoo openreceive configure (stdin), in the module's own table, only after the wallet answers as receive-only. odoo openreceive doctor, test-invoice and reconcile, and a one-minute scheduled action for customers who left. Odoo's integration page is now this module; Odoo through BTCPay Server stays a guide that the quickstart links. Tested on Odoo 19 and 20 with the live payment checks; a trial platform, odoo, and a CI lane on both series.

• Changed (Python): openreceive accepts cryptography 41 and newer (was 42), so it installs beside the system packages of Odoo's official Docker image, whose Ubuntu ships 41. The library uses nothing newer.
• Fixed (Medusa): the quickstart's storefront route for the Next.js starter now serves the checkout's stylesheet in a production build. Next's webpack build replaced the route's imported createRequire, so next build gave a route that answered 500 and an unstyled checkout; the route now imports node:module natively. Existing storefronts: replace the route file with the quickstart's. CI now runs @openreceive/medusa in a real Medusa 2 on every push, and the trials have a Medusa shop.
• Docs: a review of openreceive.org corrected the guides. The WordPress hosting page covers Easy Digital Downloads; the BTCPay plugin's safety upgrade link works (branch master); the deploying guide installs the WordPress plugin from WordPress.org and lists every integration's runtime; the BTCPay plugin reference names version 0.4.13 and the setup page's real buttons; the authorization and automated-swaps guides cover Python and PHP; the FastAPI quickstart's API links land on their sections; the Security guide says what to search browser bundles for; the Vercel guide has a path for an existing Next.js app without v0, and v0 no longer carries a Tested badge earned on Vercel; the guide index lists every integration.