openreceive 0.4.8 → 0.4.10

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 91206a8fbe28b94af9d340c6d7db1b1849ebd911be129e179bdc196e5f2c57d0
-  data.tar.gz: 0f46bb14b573b49927389504953280bd7f7e7e386a06ede642dbb9ee8f6ce715
+  metadata.gz: e612d1c8beae58671f0e863dbf26622b07a689010b81c3f05abd1463b7f1a4ff
+  data.tar.gz: 68c216cd101ad1d50dd6175b4e565793f7b147a26e1d07e1cda18ffe42659ed6
 SHA512:
-  metadata.gz: '08fba34e29b203ec89bc293e1d94de23791aa14f6e4078eee78fe3ba2a018ec109a56ab52340e86d9c9fce42c5869b7c08e006a72119b248e07a2c0b3e09d713'
-  data.tar.gz: 304a736573b2e1e1e1a78dd712942b9ba9e7fe411bececc229a9f3d81e3cc8b2d63d6363e98a5fba5569655c64fe5f09ab6fbd157a0d8afe36c75521f2e7e923
+  metadata.gz: 24f0505bb26aa2b2b06f439854cf8839825c24d4b1634ecc184c86a6914269f25c621664efc7ba792e04fc644ab2107784b7b78737564669bf57e77e5a8e5452
+  data.tar.gz: a3edc8c5fdda1f703da32f6abe8e87c2ee65fe0d8957c6da7d539b64a8f5762b2a9b0ec952c4f6ef7ee9d4ee5671d8d3675f67693eeff89c5f227b9d0026e089

data/CHANGELOG.md

@@ -1,5 +1,17 @@
 # Changelog
 
+## 0.4.10 - 2026-09-16
+
+Release in lockstep with the 0.4.10 stablecoin checkout fix. The shared
+pay-in asset table (`OpenReceive::Generated::SWAP_ASSET_INFO`) gains a
+`pegged_to` key on the USDT and USDC rows. No Ruby engine or settlement
+changes.
+
+## 0.4.9 - 2026-09-14
+
+Release in lockstep with the 0.4.9 checkout method-switch fix and updated
+integration directions. No Ruby engine or settlement changes.
+
 ## 0.4.8 - 2026-09-14
 
 Version alignment with the 0.4.8 checkout loading fix; no Ruby engine or

data/lib/openreceive/generated/tables.rb

@@ -93,17 +93,17 @@ module OpenReceive
       "USDT_TRON" => {
         "pay_in_asset" => "USDT_TRON", "label" => "USDT",
         "network_label" => "Tron", "coin" => "USDT",
-        "network" => "TRX"
+        "network" => "TRX", "pegged_to" => "USD"
       }.freeze,
       "USDT_SOL" => {
         "pay_in_asset" => "USDT_SOL", "label" => "USDT",
         "network_label" => "Solana", "coin" => "USDT",
-        "network" => "SOL"
+        "network" => "SOL", "pegged_to" => "USD"
       }.freeze,
       "USDC_SOL" => {
         "pay_in_asset" => "USDC_SOL", "label" => "USDC",
         "network_label" => "Solana", "coin" => "USDC",
-        "network" => "SOL"
+        "network" => "SOL", "pegged_to" => "USD"
       }.freeze,
       "ETH_ETH" => {
         "pay_in_asset" => "ETH_ETH", "label" => "ETH",
@@ -113,12 +113,12 @@ module OpenReceive
       "USDT_ETH" => {
         "pay_in_asset" => "USDT_ETH", "label" => "USDT",
         "network_label" => "Ethereum", "coin" => "USDT",
-        "network" => "ETH"
+        "network" => "ETH", "pegged_to" => "USD"
       }.freeze,
       "USDC_ETH" => {
         "pay_in_asset" => "USDC_ETH", "label" => "USDC",
         "network_label" => "Ethereum", "coin" => "USDC",
-        "network" => "ETH"
+        "network" => "ETH", "pegged_to" => "USD"
       }.freeze,
     }.freeze
 

data/lib/openreceive/version.rb

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

data/skills/debug-openreceive-payment/SKILL.md

@@ -70,6 +70,14 @@ same diagnostics redacted, always exit 0 — safe to share.
 - Refunds exist only for swap deposits from `refund_required`. There is **no
   Lightning refund** — the wallet cannot spend. Do not chase one.
   https://openreceive.org/guides/swap-refunds.md
+- "Payer reports two different amounts on a stablecoin checkout" (50.05 or
+  50.03?): the deposit amount is a token quantity, `fee.pay_in_fiat` is its
+  fiat valuation. Only `swap.deposit_amount` is an instruction. From 0.4.10 the
+  packaged checkout renders a USD stablecoin's breakdown in the token and never
+  shows `pay_in_fiat`; on an older bundle, upgrade `@openreceive/*`. To verify,
+  read the row's `deposit_amount` and `fee` and confirm the UI shows only the
+  deposit amount. A custom UI must call `createSwapFeeBreakdown(fee, swap)`
+  with the swap, not the fee alone.
 
 ## 6. Checkout UI shows nothing
 

data/skills/integrate-openreceive/SKILL.md

@@ -86,6 +86,17 @@ state; do not retry-loop it, and do not build an idempotency store around it —
 that serialization is the library's job. (A hook failure while persisting an
 attempt is a **503 retryable**, deliberately distinct.)
 
+## Amounts on the deposit panel
+
+`swap.deposit_amount` is the ONLY amount a payer is ever told to send, in the
+pay-in token. `swap.fee.pay_in_fiat` / `payout_fiat` are fiat valuations that
+explain the spread (why the deposit exceeds the cart total); they are not
+instructions. For a stablecoin pegged to the fee currency (USDT, USDC) the
+packaged checkout expresses the breakdown in the token and never renders
+`pay_in_fiat` — "$50.03" under "50.05 USDC" reads as the same number with a
+typo. A custom UI gets the same rule from `createSwapFeeBreakdown(fee, swap)`;
+pass the swap, not just the fee.
+
 ## Secrets
 
 `NWC_URI` and `LSC_URI_*` are server-only. Never put them in browser code,

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

@@ -1,6 +1,6 @@
 # OpenReceive agent directions (BTCPay Server)
 
-These directions describe OpenReceive 0.4.8.
+These directions describe OpenReceive 0.4.10.
 
 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
@@ -32,7 +32,7 @@ refund path on the same checkout screen.
 
 ## Step 0 — check the deployment before you change anything
 
-1. Confirm the BTCPay Server version is 2.4.2 or later (Server Settings →
+1. Confirm the BTCPay Server version is 2.4.4 or later (Server Settings →
    About, or `GET /api/v1/server/info`). The plugin declares that minimum and
    BTCPay refuses to load it below.
 2. Check whether the plugin is installed (Server Settings → Plugins, or the
@@ -128,7 +128,7 @@ passes. The page it comes from is https://openreceive.org/guides/quickstart-btcp
 
 ## BTCPay Server quickstart
 
-Requires BTCPay Server ≥ 2.4.2.
+Requires BTCPay Server ≥ 2.4.4.
 
 The OpenReceive plugin makes a receive-only NWC wallet the Lightning node of a
 BTCPay store. BTCPay mints every Lightning invoice in that wallet and records
@@ -143,7 +143,7 @@ invoices, checkout, webhooks and Greenfield API are the host.
 
 ### 1. Prerequisites
 
-- A BTCPay Server, version 2.4.2 or later, on any network (mainnet, testnet,
+- A BTCPay Server, version 2.4.4 or later, on any network (mainnet, testnet,
   signet, regtest). The wallet must be on the same network.
 - A receive-only NWC code for the wallet you want to receive into
   ([get one here](https://openreceive.org/get_a_nwc_code_to_receive_payments)).

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

@@ -1,6 +1,6 @@
 # OpenReceive agent directions (Django)
 
-These directions describe OpenReceive 0.4.8.
+These directions describe OpenReceive 0.4.10.
 
 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
@@ -218,6 +218,8 @@ The engine serves JSON only, so the view is yours — but the drop-ins
 list is the short form of https://openreceive.org/guides/checkout-ux.md, for a UI
 built on `@openreceive/browser/headless`. Read that before writing components.
 
+- Check Bitcoin → Switch payment method → Bitcoin: the grid must hide the
+  Lightning invoice, then restore the same bolt11 without another mint.
 - `createCheckoutController` is the engine. Do not hand-roll a poll loop.
 - `createCheckoutStatusModel` for the status line. Do not draw a
   Cart → Pay → Done stepper. Read the model's `phase`, not the snapshot's.
@@ -229,6 +231,13 @@ built on `@openreceive/browser/headless`. Read that before writing components.
 - `createSwapDisplayModel` → `display.copyRows` for deposits: address, memo,
   and the bare amount each get a copy row. Render `swap.networkWarning*` as
   the model gives it.
+- `swap.deposit_amount` is the only amount a payer is told to send. Never put
+  a fiat valuation of it (`swap.fee.pay_in_fiat`) next to a stablecoin amount:
+  "$50.03" under "50.05 USDC" reads as a typo, and the payer asks which one to
+  send. The one fiat figure on a USDT/USDC deposit panel is the cart total
+  (`payout_fiat`); express "you send" and the fee in the token. Use
+  `createSwapFeeBreakdown(fee, swap)` — with the swap, not the fee alone — and
+  it applies this for you; SOL and ETH keep a fiat breakdown.
 - `createCheckoutSession` owns mint and swap start. To start swaps, pass its
   `swap` option (`selection`, `prefix`, `fetch`) together. Without it
   `startSwap` reports through `onError`.
@@ -584,6 +593,11 @@ manage.py openreceive_doctor                        # the same, for humans; neve
 
 ### Render the checkout
 
+Serve the compiled `styles.css` without Tailwind processing: import it from
+JavaScript (with a CSS-capable bundler) or use a plain `<link rel="stylesheet">`.
+Do not `@import` it into the host Tailwind entry. Its zero-specificity rules
+allow host styles to override checkout styles; scoping does not prevent that.
+
 The app serves JSON checkout routes only — rendering is your template. Any
 OpenReceive frontend package works against the `/openreceive` mount; the
 smallest is the custom element, and the Python package carries its
@@ -604,8 +618,7 @@ bundler at all:
 
 `openreceive-checkout.js` registers the `<openreceive-checkout>` tag when it
 loads (one self-contained ES module, un-minified identifiers), and the
-stylesheet is scoped to what OpenReceive renders so it sits safely next to any
-CSS framework in any order. `collectstatic` ships both with the rest of your
+stylesheet is scoped to what OpenReceive renders. `collectstatic` ships both with the rest of your
 static files; the package's `MANIFEST.json` names every file and its hash. The
 element creates the checkout for `reference`, then renders and polls itself
 (its default `prefix` is already `/openreceive`).

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

@@ -1,6 +1,6 @@
 # OpenReceive agent directions (FastAPI)
 
-These directions describe OpenReceive 0.4.8.
+These directions describe OpenReceive 0.4.10.
 
 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
@@ -215,6 +215,8 @@ This list is the short form of https://openreceive.org/guides/checkout-ux.md, fo
 UI built on `@openreceive/browser/headless`. Read that before writing
 components.
 
+- Check Bitcoin → Switch payment method → Bitcoin: the grid must hide the
+  Lightning invoice, then restore the same bolt11 without another mint.
 - `createCheckoutController` is the engine. Do not hand-roll a poll loop.
 - `createCheckoutStatusModel` for the status line. Do not draw a
   Cart → Pay → Done stepper. Read the model's `phase`, not the snapshot's.
@@ -226,6 +228,13 @@ components.
 - `createSwapDisplayModel` → `display.copyRows` for deposits: address, memo,
   and the bare amount each get a copy row. Render `swap.networkWarning*` as
   the model gives it.
+- `swap.deposit_amount` is the only amount a payer is told to send. Never put
+  a fiat valuation of it (`swap.fee.pay_in_fiat`) next to a stablecoin amount:
+  "$50.03" under "50.05 USDC" reads as a typo, and the payer asks which one to
+  send. The one fiat figure on a USDT/USDC deposit panel is the cart total
+  (`payout_fiat`); express "you send" and the fee in the token. Use
+  `createSwapFeeBreakdown(fee, swap)` — with the swap, not the fee alone — and
+  it applies this for you; SOL and ETH keep a fiat breakdown.
 - `createCheckoutSession` owns mint and swap start. To start swaps, pass its
   `swap` option (`selection`, `prefix`, `fetch`) together. Without it
   `startSwap` reports through `onError`.
@@ -486,8 +495,12 @@ import "@openreceive/react/styles.css";
 The checkout renders, polls, and settles itself. The compiled `styles.css`
 sheets (`@openreceive/react`, `@openreceive/elements`) are self-contained — a
 plain `<link rel="stylesheet">` works with no build step — and scoped: every
-rule applies only inside what OpenReceive renders, so the sheet is safe next
-to any CSS framework (Mantine, Bootstrap, your own reset) in any import order.
+rule applies only inside what OpenReceive renders.
+
+Serve the compiled `styles.css` without Tailwind processing: import it from
+JavaScript (with a CSS-capable bundler) or use a plain `<link rel="stylesheet">`.
+Do not `@import` it into the host Tailwind entry. Its zero-specificity rules
+allow host styles to override checkout styles; scoping does not prevent that.
 
 `<Checkout>` is complete as rendered: it already shows the `description` from
 `amountFor` and the collapsed transaction-details panel. Do not build a custom

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

@@ -1,6 +1,6 @@
 # OpenReceive agent directions (Fastify)
 
-These directions describe OpenReceive 0.4.8.
+These directions describe OpenReceive 0.4.10.
 
 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
@@ -198,6 +198,8 @@ This list is the short form of https://openreceive.org/guides/checkout-ux.md, fo
 UI built on `@openreceive/browser/headless`. Read that before writing
 components.
 
+- Check Bitcoin → Switch payment method → Bitcoin: the grid must hide the
+  Lightning invoice, then restore the same bolt11 without another mint.
 - `createCheckoutController` is the engine. Do not hand-roll a poll loop.
 - `createCheckoutStatusModel` for the status line. Do not draw a
   Cart → Pay → Done stepper. Read the model's `phase`, not the snapshot's.
@@ -209,6 +211,13 @@ components.
 - `createSwapDisplayModel` → `display.copyRows` for deposits: address, memo,
   and the bare amount each get a copy row. Render `swap.networkWarning*` as
   the model gives it.
+- `swap.deposit_amount` is the only amount a payer is told to send. Never put
+  a fiat valuation of it (`swap.fee.pay_in_fiat`) next to a stablecoin amount:
+  "$50.03" under "50.05 USDC" reads as a typo, and the payer asks which one to
+  send. The one fiat figure on a USDT/USDC deposit panel is the cart total
+  (`payout_fiat`); express "you send" and the fee in the token. Use
+  `createSwapFeeBreakdown(fee, swap)` — with the swap, not the fee alone — and
+  it applies this for you; SOL and ETH keep a fiat breakdown.
 - `createCheckoutSession` owns mint and swap start. To start swaps, pass its
   `swap` option (`selection`, `prefix`, `fetch`) together. Without it
   `startSwap` reports through `onError`.
@@ -488,8 +497,12 @@ import "@openreceive/react/styles.css";
 The checkout renders, polls, and settles itself. The compiled `styles.css`
 sheets (`@openreceive/react`, `@openreceive/elements`) are self-contained — a
 plain `<link rel="stylesheet">` works with no build step — and scoped: every
-rule applies only inside what OpenReceive renders, so the sheet is safe next
-to any CSS framework (Mantine, Bootstrap, your own reset) in any import order.
+rule applies only inside what OpenReceive renders.
+
+Serve the compiled `styles.css` without Tailwind processing: import it from
+JavaScript (with a CSS-capable bundler) or use a plain `<link rel="stylesheet">`.
+Do not `@import` it into the host Tailwind entry. Its zero-specificity rules
+allow host styles to override checkout styles; scoping does not prevent that.
 
 `<Checkout>` is complete as rendered: it already shows the `description` from
 `amountFor` and the collapsed transaction-details panel. Do not build a custom

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

@@ -1,6 +1,6 @@
 # OpenReceive agent directions (Laravel)
 
-These directions describe OpenReceive 0.4.8.
+These directions describe OpenReceive 0.4.10.
 
 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
@@ -203,6 +203,8 @@ The engine serves JSON only, so the view is yours — but the drop-ins
 list is the short form of https://openreceive.org/guides/checkout-ux.md, for a UI
 built on `@openreceive/browser/headless`. Read that before writing components.
 
+- Check Bitcoin → Switch payment method → Bitcoin: the grid must hide the
+  Lightning invoice, then restore the same bolt11 without another mint.
 - `createCheckoutController` is the engine. Do not hand-roll a poll loop.
 - `createCheckoutStatusModel` for the status line. Do not draw a
   Cart → Pay → Done stepper. Read the model's `phase`, not the snapshot's.
@@ -214,6 +216,13 @@ built on `@openreceive/browser/headless`. Read that before writing components.
 - `createSwapDisplayModel` → `display.copyRows` for deposits: address, memo,
   and the bare amount each get a copy row. Render `swap.networkWarning*` as
   the model gives it.
+- `swap.deposit_amount` is the only amount a payer is told to send. Never put
+  a fiat valuation of it (`swap.fee.pay_in_fiat`) next to a stablecoin amount:
+  "$50.03" under "50.05 USDC" reads as a typo, and the payer asks which one to
+  send. The one fiat figure on a USDT/USDC deposit panel is the cart total
+  (`payout_fiat`); express "you send" and the fee in the token. Use
+  `createSwapFeeBreakdown(fee, swap)` — with the swap, not the fee alone — and
+  it applies this for you; SOL and ETH keep a fiat breakdown.
 - `createCheckoutSession` owns mint and swap start. To start swaps, pass its
   `swap` option (`selection`, `prefix`, `fetch`) together. Without it
   `startSwap` reports through `onError`.
@@ -560,12 +569,16 @@ costs one relay round trip, not two.
 
 ### Render the checkout
 
+Serve the compiled `styles.css` without Tailwind processing: import it from
+JavaScript (with a CSS-capable bundler) or use a plain `<link rel="stylesheet">`.
+Do not `@import` it into the host Tailwind entry. Its zero-specificity rules
+allow host styles to override checkout styles; scoping does not prevent that.
+
 The engine serves JSON checkout routes only — rendering is your view. Any
 OpenReceive frontend package works against the `/openreceive` mount; the
 smallest is the custom element (its default `prefix` is already
 `/openreceive`, and the package ships a self-contained `styles.css`; it is
-scoped to what OpenReceive renders, so it sits safely next to any CSS
-framework in any order). Laravel ships Vite, so the package installs like any
+scoped to what OpenReceive renders). Laravel ships Vite, so the package installs like any
 other frontend dependency:
 
 ```sh

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

@@ -1,6 +1,6 @@
 # OpenReceive agent directions (Next.js)
 
-These directions describe OpenReceive 0.4.8.
+These directions describe OpenReceive 0.4.10.
 
 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
@@ -204,6 +204,8 @@ This list is the short form of https://openreceive.org/guides/checkout-ux.md, fo
 UI built on `@openreceive/browser/headless`. Read that before writing
 components.
 
+- Check Bitcoin → Switch payment method → Bitcoin: the grid must hide the
+  Lightning invoice, then restore the same bolt11 without another mint.
 - `createCheckoutController` is the engine. Do not hand-roll a poll loop.
 - `createCheckoutStatusModel` for the status line. Do not draw a
   Cart → Pay → Done stepper. Read the model's `phase`, not the snapshot's.
@@ -215,6 +217,13 @@ components.
 - `createSwapDisplayModel` → `display.copyRows` for deposits: address, memo,
   and the bare amount each get a copy row. Render `swap.networkWarning*` as
   the model gives it.
+- `swap.deposit_amount` is the only amount a payer is told to send. Never put
+  a fiat valuation of it (`swap.fee.pay_in_fiat`) next to a stablecoin amount:
+  "$50.03" under "50.05 USDC" reads as a typo, and the payer asks which one to
+  send. The one fiat figure on a USDT/USDC deposit panel is the cart total
+  (`payout_fiat`); express "you send" and the fee in the token. Use
+  `createSwapFeeBreakdown(fee, swap)` — with the swap, not the fee alone — and
+  it applies this for you; SOL and ETH keep a fiat breakdown.
 - `createCheckoutSession` owns mint and swap start. To start swaps, pass its
   `swap` option (`selection`, `prefix`, `fetch`) together. Without it
   `startSwap` reports through `onError`.
@@ -537,10 +546,13 @@ reference the current session may not see; the page can read the session and
 
 The checkout renders, polls, and settles itself. The compiled `styles.css`
 sheets (`@openreceive/react`, `@openreceive/elements`) are self-contained and
-scoped: every rule applies only inside what OpenReceive renders, so the sheet
-is safe next to any CSS framework (Tailwind, Mantine, your own reset) in any
-import order. No `transpilePackages` entry is needed; the packages ship plain
-ESM.
+scoped: every rule applies only inside what OpenReceive renders. No
+`transpilePackages` entry is needed; the packages ship plain ESM.
+
+Serve the compiled `styles.css` without Tailwind processing: import it from
+JavaScript (with a CSS-capable bundler) or use a plain `<link rel="stylesheet">`.
+Do not `@import` it into the host Tailwind entry. Its zero-specificity rules
+allow host styles to override checkout styles; scoping does not prevent that.
 
 `<Checkout>` is complete as rendered: it already shows the `description` from
 `amountFor` and the collapsed transaction-details panel. Do not build a custom

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

@@ -1,6 +1,6 @@
 # OpenReceive agent directions (Node.js)
 
-These directions describe OpenReceive 0.4.8.
+These directions describe OpenReceive 0.4.10.
 
 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
@@ -190,6 +190,8 @@ This list is the short form of https://openreceive.org/guides/checkout-ux.md, fo
 UI built on `@openreceive/browser/headless`. Read that before writing
 components.
 
+- Check Bitcoin → Switch payment method → Bitcoin: the grid must hide the
+  Lightning invoice, then restore the same bolt11 without another mint.
 - `createCheckoutController` is the engine. Do not hand-roll a poll loop.
 - `createCheckoutStatusModel` for the status line. Do not draw a
   Cart → Pay → Done stepper. Read the model's `phase`, not the snapshot's.
@@ -201,6 +203,13 @@ components.
 - `createSwapDisplayModel` → `display.copyRows` for deposits: address, memo,
   and the bare amount each get a copy row. Render `swap.networkWarning*` as
   the model gives it.
+- `swap.deposit_amount` is the only amount a payer is told to send. Never put
+  a fiat valuation of it (`swap.fee.pay_in_fiat`) next to a stablecoin amount:
+  "$50.03" under "50.05 USDC" reads as a typo, and the payer asks which one to
+  send. The one fiat figure on a USDT/USDC deposit panel is the cart total
+  (`payout_fiat`); express "you send" and the fee in the token. Use
+  `createSwapFeeBreakdown(fee, swap)` — with the swap, not the fee alone — and
+  it applies this for you; SOL and ETH keep a fiat breakdown.
 - `createCheckoutSession` owns mint and swap start. To start swaps, pass its
   `swap` option (`selection`, `prefix`, `fetch`) together. Without it
   `startSwap` reports through `onError`.
@@ -465,8 +474,12 @@ import "@openreceive/react/styles.css";
 The checkout renders, polls, and settles itself. The compiled `styles.css`
 sheets (`@openreceive/react`, `@openreceive/elements`) are self-contained — a
 plain `<link rel="stylesheet">` works with no build step — and scoped: every
-rule applies only inside what OpenReceive renders, so the sheet is safe next
-to any CSS framework (Mantine, Bootstrap, your own reset) in any import order.
+rule applies only inside what OpenReceive renders.
+
+Serve the compiled `styles.css` without Tailwind processing: import it from
+JavaScript (with a CSS-capable bundler) or use a plain `<link rel="stylesheet">`.
+Do not `@import` it into the host Tailwind entry. Its zero-specificity rules
+allow host styles to override checkout styles; scoping does not prevent that.
 
 `<Checkout>` is complete as rendered: it already shows the `description` from
 `amountFor` and the collapsed transaction-details panel. Do not build a custom

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

@@ -1,6 +1,6 @@
 # OpenReceive agent directions (PHP)
 
-These directions describe OpenReceive 0.4.8.
+These directions describe OpenReceive 0.4.10.
 
 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
@@ -216,6 +216,8 @@ The drop-in (`<openreceive-checkout>`, from the release's standalone tarball or
 of https://openreceive.org/guides/checkout-ux.md, for a UI built on
 `@openreceive/browser/headless`. Read that before writing components.
 
+- Check Bitcoin → Switch payment method → Bitcoin: the grid must hide the
+  Lightning invoice, then restore the same bolt11 without another mint.
 - `createCheckoutController` is the engine. Do not hand-roll a poll loop.
 - `createCheckoutStatusModel` for the status line. Do not draw a
   Cart → Pay → Done stepper. Read the model's `phase`, not the snapshot's.
@@ -227,6 +229,13 @@ of https://openreceive.org/guides/checkout-ux.md, for a UI built on
 - `createSwapDisplayModel` → `display.copyRows` for deposits: address, memo,
   and the bare amount each get a copy row. Render `swap.networkWarning*` as
   the model gives it.
+- `swap.deposit_amount` is the only amount a payer is told to send. Never put
+  a fiat valuation of it (`swap.fee.pay_in_fiat`) next to a stablecoin amount:
+  "$50.03" under "50.05 USDC" reads as a typo, and the payer asks which one to
+  send. The one fiat figure on a USDT/USDC deposit panel is the cart total
+  (`payout_fiat`); express "you send" and the fee in the token. Use
+  `createSwapFeeBreakdown(fee, swap)` — with the swap, not the fee alone — and
+  it applies this for you; SOL and ETH keep a fiat breakdown.
 - `createCheckoutSession` owns mint and swap start. To start swaps, pass its
   `swap` option (`selection`, `prefix`, `fetch`) together. Without it
   `startSwap` reports through `onError`.
@@ -513,6 +522,11 @@ and the browser snapshots are snake_case throughout.
 
 ### 5. Render checkout
 
+Serve the compiled `styles.css` without Tailwind processing: import it from
+JavaScript (with a CSS-capable bundler) or use a plain `<link rel="stylesheet">`.
+Do not `@import` it into the host Tailwind entry. Its zero-specificity rules
+allow host styles to override checkout styles; scoping does not prevent that.
+
 Unpack the release's `standalone-checkout-<version>.tar.gz` into a directory
 your web server serves — `public/openreceive/` here — and add two tags plus
 the element:
@@ -529,8 +543,7 @@ the element:
 
 The module registers `<openreceive-checkout>` as it loads; the element creates
 the checkout for `reference`, then renders, polls and settles itself. The
-stylesheet is scoped to what OpenReceive renders, so it sits safely next to
-any CSS framework. The checkout follows the payer's theme; on a page that is
+stylesheet is scoped to what OpenReceive renders. The checkout follows the payer's theme; on a page that is
 always one theme, lock it with `theme="dark"`. React/Vue/Svelte/Angular apps
 use the matching wrapper package instead — same attributes
 ([Frontend checkout](https://openreceive.org/guides/frontend-checkout.md)); a custom UI builds on

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

@@ -1,6 +1,6 @@
 # OpenReceive agent directions (Rails)
 
-These directions describe OpenReceive 0.4.8.
+These directions describe OpenReceive 0.4.10.
 
 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
@@ -197,6 +197,8 @@ The engine serves JSON only, so the view is yours — but the drop-ins
 list is the short form of https://openreceive.org/guides/checkout-ux.md, for a UI
 built on `@openreceive/browser/headless`. Read that before writing components.
 
+- Check Bitcoin → Switch payment method → Bitcoin: the grid must hide the
+  Lightning invoice, then restore the same bolt11 without another mint.
 - `createCheckoutController` is the engine. Do not hand-roll a poll loop.
 - `createCheckoutStatusModel` for the status line. Do not draw a
   Cart → Pay → Done stepper. Read the model's `phase`, not the snapshot's.
@@ -208,6 +210,13 @@ built on `@openreceive/browser/headless`. Read that before writing components.
 - `createSwapDisplayModel` → `display.copyRows` for deposits: address, memo,
   and the bare amount each get a copy row. Render `swap.networkWarning*` as
   the model gives it.
+- `swap.deposit_amount` is the only amount a payer is told to send. Never put
+  a fiat valuation of it (`swap.fee.pay_in_fiat`) next to a stablecoin amount:
+  "$50.03" under "50.05 USDC" reads as a typo, and the payer asks which one to
+  send. The one fiat figure on a USDT/USDC deposit panel is the cart total
+  (`payout_fiat`); express "you send" and the fee in the token. Use
+  `createSwapFeeBreakdown(fee, swap)` — with the swap, not the fee alone — and
+  it applies this for you; SOL and ETH keep a fiat breakdown.
 - `createCheckoutSession` owns mint and swap start. To start swaps, pass its
   `swap` option (`selection`, `prefix`, `fetch`) together. Without it
   `startSwap` reports through `onError`.
@@ -535,12 +544,16 @@ consoles) the client is built lazily so no live wallet is needed.
 
 ### Render the checkout
 
+Serve the compiled `styles.css` without Tailwind processing: import it from
+JavaScript (with a CSS-capable bundler) or use a plain `<link rel="stylesheet">`.
+Do not `@import` it into the host Tailwind entry. Its zero-specificity rules
+allow host styles to override checkout styles; scoping does not prevent that.
+
 The engine serves JSON checkout routes only — rendering is your view. Any
 OpenReceive frontend package works against the `/openreceive` mount; the
 smallest is the custom element (its default `prefix` is already
 `/openreceive`, and the package ships a self-contained `styles.css` a plain
-stylesheet link can serve; it is scoped to what OpenReceive renders, so it
-sits safely next to any CSS framework in any order):
+stylesheet link can serve; it is scoped to what OpenReceive renders):
 
 ```erb
 <%# app/views/orders/pay.html.erb %>
@@ -548,7 +561,7 @@ sits safely next to any CSS framework in any order):
 ```
 
 ```js
-// In your JS bundle (importmap/esbuild/webpacker):
+// In your JS bundle (esbuild/webpacker with CSS support):
 import { defineElements } from "@openreceive/elements";
 import "@openreceive/elements/styles.css"; // or link the compiled styles.css
 

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

@@ -1,6 +1,6 @@
 # OpenReceive agent directions (WordPress + WooCommerce)
 
-These directions describe OpenReceive 0.4.8.
+These directions describe OpenReceive 0.4.10.
 
 Install and configure the OpenReceive gateway in the existing WooCommerce
 store. Preserve its theme, checkout, customer accounts, order model and prices.

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: openreceive
 version: !ruby/object:Gem::Version
-  version: 0.4.8
+  version: 0.4.10
 platform: ruby
 authors:
 - OpenReceive