openreceive-rails 0.4.5 → 0.4.8

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 4c0caf7ce83354949800f2ccbc89f464ef29836d727119b597e171b229d55eae
-  data.tar.gz: 7f724089996083fa10d5f73482a832cea99b0a409feade661eb66e3837ecd950
+  metadata.gz: 1e77eb3df78733f90ea869d2f97bcc7a38e6d608368aa4a2eefae5e31189ba2b
+  data.tar.gz: 8a9f452271e8bb69acf0652b2a8ff40df46700853d8b946245d38746fdcdf0b0
 SHA512:
-  metadata.gz: 386c6e60be7d4dfb562b5b16f62792c46a8eee488e217174c85ce2a3daef49605b45221bd56d2d81f4ab72fd313243c97c53b362f7c835fe8fa9c06722bd61c6
-  data.tar.gz: 2dc97ae52f9d6d470384ccff786e8383619fc349abaf31e1365532f62721b3b6dcabb845b5774a4471c19a7fccc1cf8ecdff0c916cc53c6224c56810c4e17220
+  metadata.gz: 42ec6020ced1c31af6bec3e470bb62b3578e8825fbe87eda56aac0f4534014f17d7bb0b6e9c4cbcc2e7d11798a7eba6726c5f7e71b03e8d0113ecd9bf3a278e2
+  data.tar.gz: eb036319121a4b993a31da270d84b68fd385749a5c1e4e55faeb5fa4651cff0dda7bfb787fe82638a2b8ce57860f090dff1bda218441ab8893250052e4b7c0f8

data/CHANGELOG.md

@@ -1,5 +1,23 @@
 # Changelog
 
+## 0.4.8 - 2026-09-14
+
+Release alongside the custom element's Lightning invoice loading indicator.
+Rails hosts must also update their npm checkout dependencies and rebuild
+JavaScript to receive it. No Rails engine API 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
+
+Refresh installation and quickstart documentation and package metadata.
+The Rails demo places the order id and return link below payment choices and
+the Lightning wallet list on mobile, while keeping the desktop sidebar.
+Release in lockstep with openreceive 0.4.6 and its live-price request fix;
+no Rails engine API change.
+
 ## 0.4.5 - 2026-09-07
 
 Release in lockstep with the Python/PHP publishing workflow fixes and complete

data/README.md

@@ -1,17 +1,55 @@
 # openreceive-rails
 
-Mountable receive-only OpenReceive engine. The engine owns the
-`OpenReceivePayment` attempt model (statuses `pending`, `settled`, `expired`,
-`failed`, `attention`), its per-reference commit locking, settlement write-once, and
-the reconciliation state machine. The install generator mounts the routes and
-emits the initializer plus one migration creating both engine tables
-(`openreceive_payments` and the `openreceive_meta` reconcile gate):
+**Accept Bitcoin Lightning payments in Rails. Your app, your wallet.**
+
+[OpenReceive](https://openreceive.org) adds Lightning checkout to your Rails app
+and sends payments directly to a wallet you control. Mount the engine, connect
+a receive-only Nostr Wallet Connect (NWC) wallet, and connect three hooks:
+authorize a request, look up the order amount, and handle a settled payment.
+
+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.
+
+- **Fits your app:** keep your orders, users, prices, and fulfillment in Rails.
+- **Uses your database:** payment attempts and reconciliation live alongside
+  your application data, with PostgreSQL, SQLite, and MySQL support.
+- **Handles the payment lifecycle:** invoice creation, payment checks, retry
+  coordination, and settlement reconciliation are built in.
+- **Keeps operations simple:** no separate OpenReceive database, Redis, or
+  payment service to deploy. Wallet notifications can run in an optional worker.
+
+## Get started
+
+Requires Ruby 3.2 or later and Rails 8.0 or later. Add to your Gemfile:
+
+```ruby
+gem "openreceive-rails"
+```
+
+Run `bundle install`, then install the engine:
 
 ```sh
 bin/rails generate openreceive:install
 bin/rails db:migrate
 ```
 
+The core, server, and default NWC client gems are included as dependencies.
+Follow the [Rails quickstart](https://github.com/OpenReceive/openreceive/blob/master/docs/guides/quickstart-rails.md) for native
+build prerequisites, wallet configuration, the three hooks, and the checkout UI.
+The generator creates the initializer, migration, and route mount; configure
+the wallet and hooks before accepting payments.
+
+## How it fits into Rails
+
+The engine owns the
+`OpenReceivePayment` attempt model (statuses `pending`, `settled`, `expired`,
+`failed`, `attention`), its per-reference commit locking, settlement write-once, and
+the reconciliation state machine. The install generator mounts the routes and
+emits the initializer plus one migration creating both engine tables
+(`openreceive_payments` and the `openreceive_meta` reconcile gate).
+
 The generated migration supports PostgreSQL, SQLite, and MySQL, and seeds the
 shared `schema_version`; on its first database touch the engine refuses to
 operate a database whose stored schema version is newer than the gem.
@@ -50,3 +88,13 @@ application refuses to start when the connection advertises spend methods unless
 `config.allow_spend_capable_wallet` or `OPENRECEIVE_ALLOW_SPEND_CAPABLE_NWC`
 overrides it. Keep ordinary settings such as `config.price_currencies` in
 `config/initializers/openreceive.rb`.
+
+## Links
+
+- Rails quickstart: [Connect your first checkout](https://github.com/OpenReceive/openreceive/blob/master/docs/guides/quickstart-rails.md)
+- API reference: [Configuration, hooks, and reconciliation](https://github.com/OpenReceive/openreceive/blob/master/docs/guides/api-reference.md)
+- Host testing: [Test your integration without a wallet](https://github.com/OpenReceive/openreceive/blob/master/docs/guides/host-testing.md)
+- Source and issues: <https://github.com/openreceive/openreceive>
+- Changelog: [CHANGELOG.md](CHANGELOG.md)
+
+MIT license.

data/lib/openreceive/rails/version.rb

@@ -5,6 +5,6 @@ module OpenReceive
   # top-level `::Rails` framework constant — engine code always references the framework as
   # `::Rails` to avoid shadowing.
   module Rails
-    VERSION = "0.4.5"
+    VERSION = "0.4.8"
   end
 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-rails
 version: !ruby/object:Gem::Version
-  version: 0.4.5
+  version: 0.4.8
 platform: ruby
 authors:
 - OpenReceive
@@ -15,28 +15,28 @@ dependencies:
     requirements:
     - - '='
       - !ruby/object:Gem::Version
-        version: 0.4.5
+        version: 0.4.8
   type: :runtime
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
     - - '='
       - !ruby/object:Gem::Version
-        version: 0.4.5
+        version: 0.4.8
 - !ruby/object:Gem::Dependency
   name: openreceive-server
   requirement: !ruby/object:Gem::Requirement
     requirements:
     - - '='
       - !ruby/object:Gem::Version
-        version: 0.4.5
+        version: 0.4.8
   type: :runtime
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
     - - '='
       - !ruby/object:Gem::Version
-        version: 0.4.5
+        version: 0.4.8
 - !ruby/object:Gem::Dependency
   name: rails
   requirement: !ruby/object:Gem::Requirement
@@ -85,16 +85,21 @@ dependencies:
     - - ">="
       - !ruby/object:Gem::Version
         version: '2.1'
-description: 'A mountable Rails engine that ships OpenReceive''s receive-only checkout
-  routes into a Rails app. Engine controllers inherit from the host''s ApplicationController
-  (keeping its authentication, current_user, and forgery protection; the shared handler
-  adds JSON-only and same-site gates), delegate to the openreceive-server Service,
-  and obey host-supplied authorization, amount-resolution, and settlement hooks. The
-  engine owns the OpenReceivePayment attempt model, its status state machine, settlement
-  write-once, and reconciliation (OpenReceive.reconcile!, OpenReceive::ReconcileJob,
-  rake openreceive:reconcile); its install generator emits only the migration, initializer,
-  and route mount. Receive-only: it never exposes a spend path, and boot fails closed
-  on spend-capable NWC codes.'
+description: |
+  Add Bitcoin Lightning checkout to your Rails app and receive payments directly
+  into a wallet you control. Mount the engine, connect a receive-only Nostr Wallet
+  Connect (NWC) wallet, and wire up three hooks for authorization, order amounts,
+  and fulfillment.
+
+  Optional swaps let customers pay with USDT, USDC, SOL, and ETH through a
+  configured provider; you receive BTC over Lightning in your wallet. Available
+  assets and networks depend on the provider.
+
+  OpenReceive handles invoices, payment attempts, and settlement reconciliation
+  using your existing application database. Keep your orders,
+  users, prices, and fulfillment in your app, with no separate OpenReceive database,
+  Redis, or payment service to deploy. Includes an install generator, PostgreSQL,
+  SQLite, and MySQL support, plus an optional wallet-notifications worker.
 email:
 - info@openreceive.org
 executables: []
@@ -145,7 +150,7 @@ metadata:
   source_code_uri: https://github.com/openreceive/openreceive
   changelog_uri: https://github.com/openreceive/openreceive/blob/master/packages/ruby/openreceive-rails/CHANGELOG.md
   bug_tracker_uri: https://github.com/openreceive/openreceive/issues
-  documentation_uri: https://rubydoc.info/gems/openreceive-rails
+  documentation_uri: https://github.com/openreceive/openreceive/blob/master/docs/guides/quickstart-rails.md
   rubygems_mfa_required: 'true'
 rdoc_options: []
 require_paths:
@@ -163,6 +168,5 @@ required_rubygems_version: !ruby/object:Gem::Requirement
 requirements: []
 rubygems_version: 3.6.9
 specification_version: 4
-summary: OpenReceive mountable Rails engine with engine-owned payment attempts in
-  the host database.
+summary: Accept Bitcoin Lightning payments in Rails. Your app, your wallet.
 test_files: []