OpenReceive Files

OpenReceive 0.4.28 brings OpenReceive to four more platforms. Paymenter and FOSSBilling, the open-source billing panels for hosting companies, each get an extension attached to this release as a ZIP (openreceive-paymenter-0.4.28.zip, openreceive-fossbilling-0.4.28.zip). The WordPress.org plugin now also runs on Easy Digital Downloads, with or without WooCommerce. Medusa 2 stores get a plugin and payment provider, @openreceive/medusa, on npm. The Node engine now stores payments in MySQL and MariaDB as well as Postgres and SQLite. Upgrade the WordPress plugin if you sell digital downloads, and the Node packages if your app's database is MySQL or MariaDB.

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 (WordPress): Easy Digital Downloads. The WordPress.org plugin now adds an EDD gateway beside its WooCommerce one and runs with either store, or both, so it no longer declares Requires Plugins: woocommerce, and its WordPress.org listing is now "OpenReceive – Bitcoin Lightning Payments for WooCommerce & Easy Digital Downloads", tagged for both stores. The customer picks the method at EDD's checkout; EDD records a pending order and its purchase confirmation page shows the checkout. The payment's completion marker commits with the settled payment row, then EDD completes the order with the payment hash as its transaction id, which sends the receipt and opens the downloads; interrupted completions finish on the next request or scheduled pass. EDD references are edd-<order id>, so they never meet a WooCommerce order id. The codes are the same encrypted settings, saved from Downloads → Settings → Payments → OpenReceive or with wp openreceive configure; --enable also turns the gateway on in EDD, and wp openreceive test-invoice --new mints an invoice for a pending test order. Doctor's first line is now Store: and names the active stores. On a site without Action Scheduler the reconcile pass runs on WP-Cron. The engine's warnings now reach the store's log (WooCommerce's, else EDD's debug log). Docs: the Easy Digital Downloads quickstart and agent directions (/agent-directions/edd.md, references/edd.md in the skill). The WordPress CI shop runs EDD beside WooCommerce: an EDD integration script and a guest purchase in Chromium run on every push.
• Added (Node): MySQL and MariaDB for the payment tables. createHost({ db }) takes a mysql2 Pool or Connection (promise or callback API), and knexDb, prismaDb, typeOrmDb and sequelizeDb take "mysql". npx openreceive scaffold payments --dialect mysql writes the migration for every supported ORM, and paymentsSchemaSql("mysql") / paymentsSchemaStatements("mysql") render the DDL: InnoDB tables with a binary collation. Each order is locked by a row in openreceive_meta held until commit, not by GET_LOCK, which Vitess databases such as PlanetScale restrict; PlanetScale itself is not tested. References compare exactly even in a table an ORM made with a case-insensitive collation. CI runs the repository contract on MySQL 8.4 and MariaDB 11.8 through mysql2, Knex, TypeORM and Prisma (@prisma/adapter-mariadb). Sequelize 6 on both servers was checked by hand once; CI covers its MySQL mapping with unit tests.
• Added (Paymenter): a gateway extension for Paymenter 1.5+, the open-source billing panel for hosting companies. Each GitHub release attaches openreceive-paymenter-<version>.zip, one OpenReceive folder for Paymenter's extensions/Gateways/ with the engine and the checkout script bundled. The client pays from the invoice's own payment dialog; the payment is recorded on the invoice with Paymenter's own call, in the transaction that settles it, with the payment hash as its transaction id. Artisan commands save codes from stdin (openreceive:configure), check the install (openreceive:doctor), mint a test invoice (openreceive:test-invoice) and run a reconcile pass, which Paymenter's scheduler also runs every minute. Docs: the Paymenter quickstart and agent directions (/agent-directions/paymenter.md, references/paymenter.md in the skill).
• Added (Medusa): @openreceive/medusa, a plugin and payment provider for Medusa 2 (Node 22.12+). The buyer pays at the storefront's checkout before the order is placed: the provider answers a settled payment as captured and an unsettled one as pending, so Medusa will not complete the cart before it settles. Each Medusa payment session is the payment's reference, and the plugin keeps its attempts in Medusa's own database over Medusa's own connection. A payment settled after the buyer left is placed through Medusa's process-payment workflow by the plugin's job, every minute. The checkout's routes sit under /store/openreceive behind the publishable key; npx medusa db:migrate creates the tables, and npx medusa exec ./node_modules/@openreceive/medusa/dist/enable-openreceive.js offers the provider in every region. A refund made in the Medusa admin is recorded only, as for Medusa's manual payments. Docs: the Medusa quickstart with the code for Medusa's Next.js starter, and agent directions (/agent-directions/medusa.md, references/medusa.md in the skill).
• Added (FOSSBilling): an extension for FOSSBilling 0.8+, the other open-source billing panel. Each GitHub release attaches openreceive-fossbilling-<version>.zip, which unzips into FOSSBilling's own folder: a module (modules/Openreceive: encrypted settings page, routes, console commands, a cron hook) and a payment gateway (library/Payment/Adapter/OpenReceive), with the engine and the checkout script bundled. The client pays on FOSSBilling's own payment page. A settled payment is recorded as FOSSBilling's gateways record one: a transaction with the payment hash as its id and the amount on the client's balance, in the transaction that settles it; the balance then pays the invoice. php modules/Openreceive/activate.php activates the module from a shell, and console commands save codes from stdin (openreceive:configure), check the install (openreceive:doctor), mint a test invoice (openreceive:test-invoice) and run a reconcile pass, which every FOSSBilling cron run also runs. FOSSBilling's official Docker image lacks GMP; the quickstart adds it with a two-line Dockerfile. Docs: the FOSSBilling quickstart and agent directions (/agent-directions/fossbilling.md, references/fossbilling.md in the skill). The Paymenter and FOSSBilling builds share one bundling step (tools/release/php-extension-bundle.mjs).
• Docs: a Bolt guide (/guides/bolt), agent directions for Bolt (/agent-directions/bolt.md, and references/bolt.md in the skill), and a Supabase Edge Functions recipe. Bolt apps are Vite React pages on one site with Supabase Edge Functions on another: one server function, openreceive, serves the payment routes with 0.4.27's cors option, letting through Bolt's preview hosts and bolt.host sites; the page's React <Checkout> sends the buyer's Supabase token, and authorize checks it. Because Bolt pages insert orders themselves, a trigger takes each order's price from the products table. The Supabase guide's Edge Functions section now links the recipe for its code. Agent trials run a Bolt-shaped shop on a local Supabase stack, with a real browser as the buyer. Bolt's own agent and Supabase's hosted gateway are not tested.