openreceive 0.4.5 → 0.4.8

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 34ae80bac72c06fbd721f83d77e972048e8fe5e279f837318b223fe089f63af1
-  data.tar.gz: d51e11f2c282f1816b5d86de0db98a76039f3c21cfb0190b2cf4286941d98724
+  metadata.gz: 91206a8fbe28b94af9d340c6d7db1b1849ebd911be129e179bdc196e5f2c57d0
+  data.tar.gz: 0f46bb14b573b49927389504953280bd7f7e7e386a06ede642dbb9ee8f6ce715
 SHA512:
-  metadata.gz: 241ceb79663eb4fb7ffdcc617342784521830a1e12208ffea8286d1b8b577102a3926328757647dcfccaef7955f4e5445ee16710ec8c57574db907d0ab62f7ae
-  data.tar.gz: 72b4e5ba4aadc646d46858808432558a8f7a4aec45ad7274c8ccad6603d485271a75a22d0923d29384eee88a825771592b4191e466bef7a1460f012ebd8bb87a
+  metadata.gz: '08fba34e29b203ec89bc293e1d94de23791aa14f6e4078eee78fe3ba2a018ec109a56ab52340e86d9c9fce42c5869b7c08e006a72119b248e07a2c0b3e09d713'
+  data.tar.gz: 304a736573b2e1e1e1a78dd712942b9ba9e7fe411bececc229a9f3d81e3cc8b2d63d6363e98a5fba5569655c64fe5f09ab6fbd157a0d8afe36c75521f2e7e923

data/CHANGELOG.md

@@ -1,5 +1,21 @@
 # Changelog
 
+## 0.4.8 - 2026-09-14
+
+Version alignment with the 0.4.8 checkout loading fix; no Ruby engine or
+settlement changes.
+
+## 0.4.7 - 2026-09-13
+
+Version alignment for the BTCPay plugin release; no Ruby behavior changes.
+
+## 0.4.6 - 2026-09-11
+
+Remove obsolete VEF from live price-feed requests, matching the JavaScript,
+Python and PHP engines. Refresh installation and quickstart documentation and
+package metadata. Release in lockstep with the compact checkout and publishing
+fixes in 0.4.6; no Ruby public API change.
+
 ## 0.4.5 - 2026-09-07
 
 Release in lockstep with the Python/PHP publishing workflow fixes and complete

data/README.md

@@ -1,23 +1,34 @@
 # openreceive
 
-Pure Ruby exact-money, NWC normalization, and settlement-authority primitives
-for [OpenReceive](https://openreceive.org). It has no persistence dependency.
-Settlement requires `settled_at` or state `settled`; a preimage alone does not
-settle a payment.
-
-OpenReceive adds receive-only Bitcoin Lightning payments to a website or app:
-your server creates and verifies BOLT11 invoices through a wallet you control
-via a receive-only Nostr Wallet Connect (NWC / NIP-47) connection. This gem is
-the dependency-free core; most applications want one of the gems built on it:
-
-- [`openreceive-server`](https://rubygems.org/gems/openreceive-server) — the
-  storage-free Service and framework-agnostic Rack app for the shipped HTTP
-  routes.
+**Bitcoin Lightning payments for Ruby. Your app, your wallet.**
+
+[OpenReceive](https://openreceive.org) helps you accept payments directly into
+a wallet you control. Keep your orders, prices, and fulfillment in your own
+application, with receive-only Nostr Wallet Connect (NWC) connecting your
+server to your wallet.
+
+OpenReceive supports optional swaps from **USDT, USDC, SOL, and ETH** through
+a configured swap provider. The provider converts the payment to **BTC over
+Lightning**, which settles into the merchant's connected wallet. Available
+assets and networks depend on the provider; swaps are optional.
+
+This gem is the lightweight Ruby foundation: exact money conversion, exchange
+rates, wallet adapters, and shared settlement rules, with no database
+dependency. Most applications should start with one of the integrations
+built on it:
+
 - [`openreceive-rails`](https://rubygems.org/gems/openreceive-rails) — the
-  mountable Rails engine with host-owned payment scaffolding.
+  complete Rails integration, with payment storage in your existing database,
+  reconciliation, and three application hooks. [Start with Rails](https://github.com/OpenReceive/openreceive/blob/master/docs/guides/quickstart-rails.md).
+- [`openreceive-server`](https://rubygems.org/gems/openreceive-server) — invoice
+  creation, payment checks, and a Rack handler for custom Ruby integrations
+  that provide their own payment persistence. [Explore the server gem](https://github.com/OpenReceive/openreceive/blob/master/packages/ruby/openreceive-server/README.md).
 
 ## Install
 
+Requires Ruby 3.2 or later. Choose this gem directly when you need the payment
+primitives rather than a mounted checkout integration.
+
 ```sh
 gem install openreceive
 ```
@@ -39,6 +50,8 @@ gem "openreceive"
   (`OpenReceive::Nwc.normalize_wallet_error`,
   `OpenReceive::Nwc.normalize_transaction`).
 - Settlement-authority rules: what counts as settled, and what never does.
+  Settlement requires `settled_at` or state `settled`; a preimage alone does
+  not settle a payment.
 - The built-in price feed (`OpenReceive::Rates`): a static provider and the
   cached live feed with primary/fallback failover, fail-closed windows, and
   the shared currency list.
@@ -49,13 +62,14 @@ gem "openreceive"
   (`subscribe_notifications`, forwarded to that gem's
   `subscribe_to_notifications`).
 
-The behavior is pinned to the same test vectors as the Node engine
-(`spec/test-vectors` in the repository), so both engines make identical
-decisions.
+Money, wallet normalization, and settlement rules are tested against shared
+cross-language vectors in `spec/test-vectors`.
 
 ## Links
 
-- Documentation: <https://openreceive.org>
+- Rails quickstart: [Add checkout to your app](https://github.com/OpenReceive/openreceive/blob/master/docs/guides/quickstart-rails.md)
+- API reference: [Ruby and Rails APIs](https://github.com/OpenReceive/openreceive/blob/master/docs/guides/api-reference.md)
+- Website: <https://openreceive.org>
 - Source: <https://github.com/openreceive/openreceive>
 - Changelog: [CHANGELOG.md](CHANGELOG.md)
 

data/lib/openreceive/rates.rb

@@ -40,7 +40,7 @@ module OpenReceive
     # The fixed fiat list both live feeds price Bitcoin against. Hard-coded so
     # the primary and fallback URLs always request the same currencies.
     PRICE_FEED_VS_CURRENCIES =
-      "usd,aed,ars,aud,bdt,bhd,bmd,brl,cad,chf,clp,cny,czk,dkk,eur,gbp,gel,hkd,huf,idr,ils,inr,jpy,krw,kwd,lkr,mmk,mxn,myr,ngn,nok,nzd,php,pkr,pln,rub,sar,sek,sgd,thb,try,twd,uah,vef,vnd,zar"
+      "usd,aed,ars,aud,bdt,bhd,bmd,brl,cad,chf,clp,cny,czk,dkk,eur,gbp,gel,hkd,huf,idr,ils,inr,jpy,krw,kwd,lkr,mmk,mxn,myr,ngn,nok,nzd,php,pkr,pln,rub,sar,sek,sgd,thb,try,twd,uah,vnd,zar"
 
     PRICE_FEED_CURRENCIES = PRICE_FEED_VS_CURRENCIES.split(",").freeze
 

data/lib/openreceive/version.rb

@@ -1,5 +1,5 @@
 # frozen_string_literal: true
 
 module OpenReceive
-  VERSION = "0.4.5"
+  VERSION = "0.4.8"
 end

data/skills/integrate-openreceive/references/btcpay.md

@@ -1,6 +1,6 @@
 # OpenReceive agent directions (BTCPay Server)
 
-These directions describe OpenReceive 0.4.5.
+These directions describe OpenReceive 0.4.8.
 
 Connect a BTCPay Server store to a receive-only NWC wallet with the OpenReceive
 plugin, and optionally let payers pay BTCPay invoices with USDT, USDC, ETH or

data/skills/integrate-openreceive/references/django.md

@@ -1,6 +1,6 @@
 # OpenReceive agent directions (Django)
 
-These directions describe OpenReceive 0.4.5.
+These directions describe OpenReceive 0.4.8.
 
 Add OpenReceive to a Django project — the app you are already working in. You
 do not need a copy of the OpenReceive source: the Python package is on PyPI
@@ -245,11 +245,25 @@ built on `@openreceive/browser/headless`. Read that before writing components.
   "switch payment method".
 - No "Open wallet" button on desktop.
 - Wallet suggestions: `getPaymentWizardRoutes()` +
-  `createWizardRouteDisplays`. Lightning only. Every image ships inside
-  the JavaScript — logos as data URIs, tutorials once `loadPayTutorialImages()`
-  resolves (`image` is `undefined` until then) — so serve nothing and set no
-  asset option. When it works, the logos and payment icons render; a missing
-  image means a CSP `img-src` that blocks `data:`, and the console names it.
+  `createWizardRouteDisplays`. Lightning only. Logos are data URIs; tutorial
+  images load from a JavaScript chunk. For a custom headless UI, load it when
+  a tutorial opens and look up the returned table by the tutorial's `path`:
+
+  ```js
+  import { loadPayTutorialImages } from "@openreceive/browser/headless";
+
+  const images = await loadPayTutorialImages();
+  const src = images[tutorial.path]; // data URI for the selected tutorial
+  ```
+
+  Render `src` as the image source and update your UI after loading. Existing
+  display objects do not update: their `tutorial.image` stays `undefined` if
+  created before loading. Alternatively, await the loader, recreate the displays
+  with `createWizardRouteDisplays`, and render the new `tutorial.image`.
+  Show the caption while loading or if loading fails; never use an empty image
+  source. Deploy all JavaScript chunks and allow `data:` in CSP `img-src`.
+  For missing images, check CSP errors, failed chunks, and stale displays.
+  Registry paths are lookup keys; there is no asset option or image route.
   The registry answers ~37 wallets: pass
   `providerPreviewLimit` and build "show all" from `display.providerCount`,
   or they push the QR off the screen.

data/skills/integrate-openreceive/references/fastapi.md

@@ -1,6 +1,6 @@
 # OpenReceive agent directions (FastAPI)
 
-These directions describe OpenReceive 0.4.5.
+These directions describe OpenReceive 0.4.8.
 
 Add OpenReceive to a FastAPI application — the app you are already working in.
 You do not need a copy of the OpenReceive source: the engine is on PyPI
@@ -242,11 +242,25 @@ components.
   "switch payment method".
 - No "Open wallet" button on desktop.
 - Wallet suggestions: `getPaymentWizardRoutes()` +
-  `createWizardRouteDisplays`. Lightning only. Every image ships inside
-  the JavaScript — logos as data URIs, tutorials once `loadPayTutorialImages()`
-  resolves (`image` is `undefined` until then) — so serve nothing and set no
-  asset option. When it works, the logos and payment icons render; a missing
-  image means a CSP `img-src` that blocks `data:`, and the console names it.
+  `createWizardRouteDisplays`. Lightning only. Logos are data URIs; tutorial
+  images load from a JavaScript chunk. For a custom headless UI, load it when
+  a tutorial opens and look up the returned table by the tutorial's `path`:
+
+  ```js
+  import { loadPayTutorialImages } from "@openreceive/browser/headless";
+
+  const images = await loadPayTutorialImages();
+  const src = images[tutorial.path]; // data URI for the selected tutorial
+  ```
+
+  Render `src` as the image source and update your UI after loading. Existing
+  display objects do not update: their `tutorial.image` stays `undefined` if
+  created before loading. Alternatively, await the loader, recreate the displays
+  with `createWizardRouteDisplays`, and render the new `tutorial.image`.
+  Show the caption while loading or if loading fails; never use an empty image
+  source. Deploy all JavaScript chunks and allow `data:` in CSP `img-src`.
+  For missing images, check CSP errors, failed chunks, and stale displays.
+  Registry paths are lookup keys; there is no asset option or image route.
 
 ## More documentation
 

data/skills/integrate-openreceive/references/fastify.md

@@ -1,6 +1,6 @@
 # OpenReceive agent directions (Fastify)
 
-These directions describe OpenReceive 0.4.5.
+These directions describe OpenReceive 0.4.8.
 
 Add OpenReceive to a Fastify application — the app you are already working in.
 You do not need a copy of the OpenReceive source: the packages are on npm, and
@@ -225,11 +225,25 @@ components.
   "switch payment method".
 - No "Open wallet" button on desktop.
 - Wallet suggestions: `getPaymentWizardRoutes()` +
-  `createWizardRouteDisplays`. Lightning only. Every image ships inside
-  the JavaScript — logos as data URIs, tutorials once `loadPayTutorialImages()`
-  resolves (`image` is `undefined` until then) — so serve nothing and set no
-  asset option. When it works, the logos and payment icons render; a missing
-  image means a CSP `img-src` that blocks `data:`, and the console names it.
+  `createWizardRouteDisplays`. Lightning only. Logos are data URIs; tutorial
+  images load from a JavaScript chunk. For a custom headless UI, load it when
+  a tutorial opens and look up the returned table by the tutorial's `path`:
+
+  ```js
+  import { loadPayTutorialImages } from "@openreceive/browser/headless";
+
+  const images = await loadPayTutorialImages();
+  const src = images[tutorial.path]; // data URI for the selected tutorial
+  ```
+
+  Render `src` as the image source and update your UI after loading. Existing
+  display objects do not update: their `tutorial.image` stays `undefined` if
+  created before loading. Alternatively, await the loader, recreate the displays
+  with `createWizardRouteDisplays`, and render the new `tutorial.image`.
+  Show the caption while loading or if loading fails; never use an empty image
+  source. Deploy all JavaScript chunks and allow `data:` in CSP `img-src`.
+  For missing images, check CSP errors, failed chunks, and stale displays.
+  Registry paths are lookup keys; there is no asset option or image route.
 
 ## More documentation
 

data/skills/integrate-openreceive/references/laravel.md

@@ -1,6 +1,6 @@
 # OpenReceive agent directions (Laravel)
 
-These directions describe OpenReceive 0.4.5.
+These directions describe OpenReceive 0.4.8.
 
 Add OpenReceive to a Laravel application — the app you are already working in.
 You do not need a copy of the OpenReceive source: the package is on Packagist
@@ -230,11 +230,25 @@ built on `@openreceive/browser/headless`. Read that before writing components.
   "switch payment method".
 - No "Open wallet" button on desktop.
 - Wallet suggestions: `getPaymentWizardRoutes()` +
-  `createWizardRouteDisplays`. Lightning only. Every image ships inside
-  the JavaScript — logos as data URIs, tutorials once `loadPayTutorialImages()`
-  resolves (`image` is `undefined` until then) — so serve nothing and set no
-  asset option. When it works, the logos and payment icons render; a missing
-  image means a CSP `img-src` that blocks `data:`, and the console names it.
+  `createWizardRouteDisplays`. Lightning only. Logos are data URIs; tutorial
+  images load from a JavaScript chunk. For a custom headless UI, load it when
+  a tutorial opens and look up the returned table by the tutorial's `path`:
+
+  ```js
+  import { loadPayTutorialImages } from "@openreceive/browser/headless";
+
+  const images = await loadPayTutorialImages();
+  const src = images[tutorial.path]; // data URI for the selected tutorial
+  ```
+
+  Render `src` as the image source and update your UI after loading. Existing
+  display objects do not update: their `tutorial.image` stays `undefined` if
+  created before loading. Alternatively, await the loader, recreate the displays
+  with `createWizardRouteDisplays`, and render the new `tutorial.image`.
+  Show the caption while loading or if loading fails; never use an empty image
+  source. Deploy all JavaScript chunks and allow `data:` in CSP `img-src`.
+  For missing images, check CSP errors, failed chunks, and stale displays.
+  Registry paths are lookup keys; there is no asset option or image route.
   The registry answers ~37 wallets: pass
   `providerPreviewLimit` and build "show all" from `display.providerCount`,
   or they push the QR off the screen.

data/skills/integrate-openreceive/references/next.md

@@ -1,6 +1,6 @@
 # OpenReceive agent directions (Next.js)
 
-These directions describe OpenReceive 0.4.5.
+These directions describe OpenReceive 0.4.8.
 
 Add OpenReceive to a Next.js App Router application — the app you are already
 working in. You do not need a copy of the OpenReceive source: the packages are
@@ -231,11 +231,25 @@ components.
   "switch payment method".
 - No "Open wallet" button on desktop.
 - Wallet suggestions: `getPaymentWizardRoutes()` +
-  `createWizardRouteDisplays`. Lightning only. Every image ships inside
-  the JavaScript — logos as data URIs, tutorials once `loadPayTutorialImages()`
-  resolves (`image` is `undefined` until then) — so serve nothing and set no
-  asset option. When it works, the logos and payment icons render; a missing
-  image means a CSP `img-src` that blocks `data:`, and the console names it.
+  `createWizardRouteDisplays`. Lightning only. Logos are data URIs; tutorial
+  images load from a JavaScript chunk. For a custom headless UI, load it when
+  a tutorial opens and look up the returned table by the tutorial's `path`:
+
+  ```js
+  import { loadPayTutorialImages } from "@openreceive/browser/headless";
+
+  const images = await loadPayTutorialImages();
+  const src = images[tutorial.path]; // data URI for the selected tutorial
+  ```
+
+  Render `src` as the image source and update your UI after loading. Existing
+  display objects do not update: their `tutorial.image` stays `undefined` if
+  created before loading. Alternatively, await the loader, recreate the displays
+  with `createWizardRouteDisplays`, and render the new `tutorial.image`.
+  Show the caption while loading or if loading fails; never use an empty image
+  source. Deploy all JavaScript chunks and allow `data:` in CSP `img-src`.
+  For missing images, check CSP errors, failed chunks, and stale displays.
+  Registry paths are lookup keys; there is no asset option or image route.
 
 ## More documentation
 

data/skills/integrate-openreceive/references/node.md

@@ -1,6 +1,6 @@
 # OpenReceive agent directions (Node.js)
 
-These directions describe OpenReceive 0.4.5.
+These directions describe OpenReceive 0.4.8.
 
 Add OpenReceive to a Node application — the app you are already working in. You
 do not need a copy of the OpenReceive source: the packages are on npm, and the
@@ -217,11 +217,25 @@ components.
   "switch payment method".
 - No "Open wallet" button on desktop.
 - Wallet suggestions: `getPaymentWizardRoutes()` +
-  `createWizardRouteDisplays`. Lightning only. Every image ships inside
-  the JavaScript — logos as data URIs, tutorials once `loadPayTutorialImages()`
-  resolves (`image` is `undefined` until then) — so serve nothing and set no
-  asset option. When it works, the logos and payment icons render; a missing
-  image means a CSP `img-src` that blocks `data:`, and the console names it.
+  `createWizardRouteDisplays`. Lightning only. Logos are data URIs; tutorial
+  images load from a JavaScript chunk. For a custom headless UI, load it when
+  a tutorial opens and look up the returned table by the tutorial's `path`:
+
+  ```js
+  import { loadPayTutorialImages } from "@openreceive/browser/headless";
+
+  const images = await loadPayTutorialImages();
+  const src = images[tutorial.path]; // data URI for the selected tutorial
+  ```
+
+  Render `src` as the image source and update your UI after loading. Existing
+  display objects do not update: their `tutorial.image` stays `undefined` if
+  created before loading. Alternatively, await the loader, recreate the displays
+  with `createWizardRouteDisplays`, and render the new `tutorial.image`.
+  Show the caption while loading or if loading fails; never use an empty image
+  source. Deploy all JavaScript chunks and allow `data:` in CSP `img-src`.
+  For missing images, check CSP errors, failed chunks, and stale displays.
+  Registry paths are lookup keys; there is no asset option or image route.
 
 ## More documentation
 

data/skills/integrate-openreceive/references/php.md

@@ -1,6 +1,6 @@
 # OpenReceive agent directions (PHP)
 
-These directions describe OpenReceive 0.4.5.
+These directions describe OpenReceive 0.4.8.
 
 Add OpenReceive to a PHP application — the app you are already working in. You
 do not need a copy of the OpenReceive source: the engine is on Packagist
@@ -243,11 +243,25 @@ of https://openreceive.org/guides/checkout-ux.md, for a UI built on
   "switch payment method".
 - No "Open wallet" button on desktop.
 - Wallet suggestions: `getPaymentWizardRoutes()` +
-  `createWizardRouteDisplays`. Lightning only. Every image ships inside
-  the JavaScript — logos as data URIs, tutorials once `loadPayTutorialImages()`
-  resolves (`image` is `undefined` until then) — so serve nothing and set no
-  asset option. When it works, the logos and payment icons render; a missing
-  image means a CSP `img-src` that blocks `data:`, and the console names it.
+  `createWizardRouteDisplays`. Lightning only. Logos are data URIs; tutorial
+  images load from a JavaScript chunk. For a custom headless UI, load it when
+  a tutorial opens and look up the returned table by the tutorial's `path`:
+
+  ```js
+  import { loadPayTutorialImages } from "@openreceive/browser/headless";
+
+  const images = await loadPayTutorialImages();
+  const src = images[tutorial.path]; // data URI for the selected tutorial
+  ```
+
+  Render `src` as the image source and update your UI after loading. Existing
+  display objects do not update: their `tutorial.image` stays `undefined` if
+  created before loading. Alternatively, await the loader, recreate the displays
+  with `createWizardRouteDisplays`, and render the new `tutorial.image`.
+  Show the caption while loading or if loading fails; never use an empty image
+  source. Deploy all JavaScript chunks and allow `data:` in CSP `img-src`.
+  For missing images, check CSP errors, failed chunks, and stale displays.
+  Registry paths are lookup keys; there is no asset option or image route.
 
 ## More documentation
 

data/skills/integrate-openreceive/references/rails.md

@@ -1,6 +1,6 @@
 # OpenReceive agent directions (Rails)
 
-These directions describe OpenReceive 0.4.5.
+These directions describe OpenReceive 0.4.8.
 
 Add OpenReceive to a Rails application — the app you are already working in. You
 do not need a copy of the OpenReceive source: the gem is on RubyGems, the
@@ -224,11 +224,25 @@ built on `@openreceive/browser/headless`. Read that before writing components.
   "switch payment method".
 - No "Open wallet" button on desktop.
 - Wallet suggestions: `getPaymentWizardRoutes()` +
-  `createWizardRouteDisplays`. Lightning only. Every image ships inside
-  the JavaScript — logos as data URIs, tutorials once `loadPayTutorialImages()`
-  resolves (`image` is `undefined` until then) — so serve nothing and set no
-  asset option. When it works, the logos and payment icons render; a missing
-  image means a CSP `img-src` that blocks `data:`, and the console names it.
+  `createWizardRouteDisplays`. Lightning only. Logos are data URIs; tutorial
+  images load from a JavaScript chunk. For a custom headless UI, load it when
+  a tutorial opens and look up the returned table by the tutorial's `path`:
+
+  ```js
+  import { loadPayTutorialImages } from "@openreceive/browser/headless";
+
+  const images = await loadPayTutorialImages();
+  const src = images[tutorial.path]; // data URI for the selected tutorial
+  ```
+
+  Render `src` as the image source and update your UI after loading. Existing
+  display objects do not update: their `tutorial.image` stays `undefined` if
+  created before loading. Alternatively, await the loader, recreate the displays
+  with `createWizardRouteDisplays`, and render the new `tutorial.image`.
+  Show the caption while loading or if loading fails; never use an empty image
+  source. Deploy all JavaScript chunks and allow `data:` in CSP `img-src`.
+  For missing images, check CSP errors, failed chunks, and stale displays.
+  Registry paths are lookup keys; there is no asset option or image route.
   The registry answers ~37 wallets: pass
   `providerPreviewLimit` and build "show all" from `display.providerCount`,
   or they push the QR off the screen.

data/skills/integrate-openreceive/references/woocommerce.md

@@ -1,6 +1,6 @@
 # OpenReceive agent directions (WordPress + WooCommerce)
 
-These directions describe OpenReceive 0.4.5.
+These directions describe OpenReceive 0.4.8.
 
 Install and configure the OpenReceive gateway in the existing WooCommerce
 store. Preserve its theme, checkout, customer accounts, order model and prices.
@@ -90,6 +90,29 @@ Requirements: WordPress 6.6+, WooCommerce 9+, 64-bit PHP 8.2+ with GMP and sodiu
 and MySQL 8 or MariaDB 10.5+. Activation creates payment-attempt tables in the
 existing WordPress database. No separate database or application is required.
 
+### Get the installable archive
+
+Use `openreceive-wordpress-<version>.zip` from the selected
+[OpenReceive GitHub release](https://github.com/OpenReceive/openreceive/releases)
+when that asset is listed. A GitHub source-code zip is not the plugin archive.
+If the release does not yet provide a built zip, build it on a development
+machine with Node 22+, PHP 8.2+, Composer and WP-CLI:
+
+```sh
+git clone https://github.com/OpenReceive/openreceive.git
+cd openreceive
+git checkout <release-tag>
+npm ci
+npm run build:packages
+composer install --working-dir=packages/php/wordpress
+npm run release:wordpress:build
+```
+
+Upload the resulting `dist/openreceive-wordpress-<version>.zip`. WP-CLI must be
+on `PATH`, or set `OPENRECEIVE_WP_CLI` to the absolute path of its phar. The
+WordPress server needs neither Node nor Composer: dependencies and checkout
+assets are bundled inside the built plugin.
+
 ### Configure the wallet
 
 Open **WooCommerce → Settings → Payments → OpenReceive**. Enter a receive-only

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: openreceive
 version: !ruby/object:Gem::Version
-  version: 0.4.5
+  version: 0.4.8
 platform: ruby
 authors:
 - OpenReceive
@@ -23,7 +23,19 @@ dependencies:
     - - ">="
       - !ruby/object:Gem::Version
         version: '0'
-description: Vector-backed Ruby helpers for OpenReceive receive-checkout contracts.
+description: |
+  Build Bitcoin Lightning payments into your Ruby application with OpenReceive.
+  Work with exact money amounts, normalize wallet responses, and apply consistent
+  settlement rules while keeping control of your wallet and application.
+
+  This lightweight core provides money conversion, exchange rates, Nostr Wallet
+  Connect (NWC) adapters, and swap-address validation without a database dependency.
+  For a complete Rails integration, install openreceive-rails. For a custom Ruby
+  or Rack integration, use openreceive-server.
+
+  OpenReceive integrations support optional swaps from USDT, USDC, SOL, and ETH
+  through a configured provider, settling as BTC over Lightning into your wallet.
+  Available assets and networks depend on the provider.
 email:
 - info@openreceive.org
 executables: []
@@ -61,7 +73,7 @@ metadata:
   source_code_uri: https://github.com/openreceive/openreceive
   changelog_uri: https://github.com/openreceive/openreceive/blob/master/packages/ruby/openreceive/CHANGELOG.md
   bug_tracker_uri: https://github.com/openreceive/openreceive/issues
-  documentation_uri: https://rubydoc.info/gems/openreceive
+  documentation_uri: https://github.com/openreceive/openreceive/blob/master/packages/ruby/openreceive/README.md
   rubygems_mfa_required: 'true'
 rdoc_options: []
 require_paths:
@@ -79,5 +91,5 @@ required_rubygems_version: !ruby/object:Gem::Requirement
 requirements: []
 rubygems_version: 3.6.9
 specification_version: 4
-summary: OpenReceive Ruby core helpers
+summary: Bitcoin Lightning payment primitives for Ruby. Your app, your wallet.
 test_files: []