@openreceive/svelte 0.4.12 → 0.4.14

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@openreceive/svelte",
-  "version": "0.4.12",
+  "version": "0.4.14",
   "description": "Svelte component for Bitcoin Lightning checkout and optional USDT, USDC, SOL and ETH swaps.",
   "keywords": [
     "bitcoin",
@@ -20,8 +20,8 @@
   "types": "./dist/index.d.ts",
   "svelte": "./dist/index.js",
   "dependencies": {
-    "@openreceive/browser": "0.4.12",
-    "@openreceive/elements": "0.4.12"
+    "@openreceive/browser": "0.4.14",
+    "@openreceive/elements": "0.4.14"
   },
   "peerDependencies": {
     "svelte": ">=5.0.0"

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

@@ -49,7 +49,7 @@ same diagnostics redacted, always exit 0 — safe to share.
 ## 4. Paid but never settles
 
 - Settlement is opportunistic: any OpenReceive request runs one reconcile pass
-  through a durable gate (min 2s between wallet scans, stretched by invoice
+  through a durable gate (min 3s between wallet scans, stretched by invoice
   age). A quiet server settles on the next request — or run the optional
   notification worker. No timer is missing; that is the design.
 - An unpaid attempt closes only after a successful wallet scan at/after expiry

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

@@ -1,6 +1,6 @@
 # OpenReceive agent directions (BTCPay Server)
 
-These directions describe OpenReceive 0.4.12.
+These directions describe OpenReceive 0.4.14.
 
 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

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

@@ -1,6 +1,6 @@
 # OpenReceive agent directions (Django)
 
-These directions describe OpenReceive 0.4.12.
+These directions describe OpenReceive 0.4.14.
 
 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
@@ -167,15 +167,19 @@ itself, and they hold for every integration.
   late becomes `refund_required`, and the payer claims it on a SECOND VISIT,
   after leaving your page to fetch an address from another wallet. Three things
   must exist or that money is unreachable through your UI: a per-order URL your
-  server serves (`/checkout/:reference` — `syncUrl` on the drop-ins), your own
-  order-summary route to restore the order from, and the ATTEMPT.
+  server serves (`/checkout/:reference` — `syncUrl` on `<Checkout>`, `sync-url`
+  or `resumable` on `<openreceive-checkout>`), your own order-summary route to
+  restore the order from, and the ATTEMPT.
   `/checkouts/prepare` returns no attempts, so a checkout rebuilt from the
   reference alone opens on the method grid. Re-picking the same coin
   (`POST /swaps`) re-serves the committed attempt — but only while it is live,
   and the shadow invoice behind a swap lasts about half an hour, after which the
   same click mints a NEW deposit address and the refund is off-screen. Keep the
   `payment_hash` and reopen the attempt with `POST /swaps/status`, which has no
-  such window. https://openreceive.org/guides/swap-refunds.md
+  such window. On the drop-ins: `resumePaymentHash`, fed from `onState`, on
+  `<Checkout>`; the `resume-payment-hash` attribute, fed from the
+  `openreceive-state` event (`event.detail.state.payment_hash`), on
+  `<openreceive-checkout>`. https://openreceive.org/guides/swap-refunds.md
 - Show the payer WHAT THEY ARE BUYING. Return an optional `description` beside
   the price from `amount_for` and both drop-ins render it above the
   amount. Without it the checkout is a QR and "$1.00" with no sign of what the

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

@@ -1,6 +1,6 @@
 # OpenReceive agent directions (FastAPI)
 
-These directions describe OpenReceive 0.4.12.
+These directions describe OpenReceive 0.4.14.
 
 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
@@ -157,15 +157,19 @@ itself, and they hold for every integration.
   late becomes `refund_required`, and the payer claims it on a SECOND VISIT,
   after leaving your page to fetch an address from another wallet. Three things
   must exist or that money is unreachable through your UI: a per-order URL your
-  server serves (`/checkout/:reference` — `syncUrl` on the drop-ins), your own
-  order-summary route to restore the order from, and the ATTEMPT.
+  server serves (`/checkout/:reference` — `syncUrl` on `<Checkout>`, `sync-url`
+  or `resumable` on `<openreceive-checkout>`), your own order-summary route to
+  restore the order from, and the ATTEMPT.
   `/checkouts/prepare` returns no attempts, so a checkout rebuilt from the
   reference alone opens on the method grid. Re-picking the same coin
   (`POST /swaps`) re-serves the committed attempt — but only while it is live,
   and the shadow invoice behind a swap lasts about half an hour, after which the
   same click mints a NEW deposit address and the refund is off-screen. Keep the
   `payment_hash` and reopen the attempt with `POST /swaps/status`, which has no
-  such window. https://openreceive.org/guides/swap-refunds.md
+  such window. On the drop-ins: `resumePaymentHash`, fed from `onState`, on
+  `<Checkout>`; the `resume-payment-hash` attribute, fed from the
+  `openreceive-state` event (`event.detail.state.payment_hash`), on
+  `<openreceive-checkout>`. https://openreceive.org/guides/swap-refunds.md
 - Show the payer WHAT THEY ARE BUYING. Return an optional `description` beside
   the price from `amount_for` and both drop-ins render it above the amount.
   Without it the checkout is a QR and "$1.00" with no sign of what the dollar

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

@@ -1,6 +1,6 @@
 # OpenReceive agent directions (Fastify)
 
-These directions describe OpenReceive 0.4.12.
+These directions describe OpenReceive 0.4.14.
 
 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
@@ -149,15 +149,19 @@ itself, and they hold for every integration.
   late becomes `refund_required`, and the payer claims it on a SECOND VISIT,
   after leaving your page to fetch an address from another wallet. Three things
   must exist or that money is unreachable through your UI: a per-order URL your
-  server serves (`/checkout/:reference` — `syncUrl` on the drop-ins), your own
-  order-summary route to restore the order from, and the ATTEMPT.
+  server serves (`/checkout/:reference` — `syncUrl` on `<Checkout>`, `sync-url`
+  or `resumable` on `<openreceive-checkout>`), your own order-summary route to
+  restore the order from, and the ATTEMPT.
   `/checkouts/prepare` returns no attempts, so a checkout rebuilt from the
   reference alone opens on the method grid. Re-picking the same coin
   (`POST /swaps`) re-serves the committed attempt — but only while it is live,
   and the shadow invoice behind a swap lasts about half an hour, after which the
   same click mints a NEW deposit address and the refund is off-screen. Keep the
   `payment_hash` and reopen the attempt with `POST /swaps/status`, which has no
-  such window. https://openreceive.org/guides/swap-refunds.md
+  such window. On the drop-ins: `resumePaymentHash`, fed from `onState`, on
+  `<Checkout>`; the `resume-payment-hash` attribute, fed from the
+  `openreceive-state` event (`event.detail.state.payment_hash`), on
+  `<openreceive-checkout>`. https://openreceive.org/guides/swap-refunds.md
 - Show the payer WHAT THEY ARE BUYING. Return an optional `description` beside
   the price from `amountFor` and both drop-ins render it above the amount.
   Without it the checkout is a QR and "$1.00" with no sign of what the dollar
@@ -375,7 +379,9 @@ there is nothing else to generate. Details:
 No ORM? You can pass a bare driver handle (`pg`, `node:sqlite`,
 `better-sqlite3`) as the `db` in step 4. The scaffold has no flavor for it.
 Instead of scaffolding, run the same DDL once yourself, using
-`paymentsSchemaSql(dialect)` from `@openreceive/http`.
+`paymentsSchemaSql(dialect)` from `@openreceive/http`. Your adapter already
+pulls that package in, but this import is yours, so install it too:
+`npm install @openreceive/http`.
 
 ### 3. Add wallet credentials
 

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

@@ -1,6 +1,6 @@
 # OpenReceive agent directions (Laravel)
 
-These directions describe OpenReceive 0.4.12.
+These directions describe OpenReceive 0.4.14.
 
 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
@@ -158,15 +158,19 @@ itself, and they hold for every integration.
   late becomes `refund_required`, and the payer claims it on a SECOND VISIT,
   after leaving your page to fetch an address from another wallet. Three things
   must exist or that money is unreachable through your UI: a per-order URL your
-  server serves (`/checkout/:reference` — `syncUrl` on the drop-ins), your own
-  order-summary route to restore the order from, and the ATTEMPT.
+  server serves (`/checkout/:reference` — `syncUrl` on `<Checkout>`, `sync-url`
+  or `resumable` on `<openreceive-checkout>`), your own order-summary route to
+  restore the order from, and the ATTEMPT.
   `/checkouts/prepare` returns no attempts, so a checkout rebuilt from the
   reference alone opens on the method grid. Re-picking the same coin
   (`POST /swaps`) re-serves the committed attempt — but only while it is live,
   and the shadow invoice behind a swap lasts about half an hour, after which the
   same click mints a NEW deposit address and the refund is off-screen. Keep the
   `payment_hash` and reopen the attempt with `POST /swaps/status`, which has no
-  such window. https://openreceive.org/guides/swap-refunds.md
+  such window. On the drop-ins: `resumePaymentHash`, fed from `onState`, on
+  `<Checkout>`; the `resume-payment-hash` attribute, fed from the
+  `openreceive-state` event (`event.detail.state.payment_hash`), on
+  `<openreceive-checkout>`. https://openreceive.org/guides/swap-refunds.md
 - Show the payer WHAT THEY ARE BUYING. Return an optional `description` beside
   the price from `amountFor` and both drop-ins render it above the
   amount. Without it the checkout is a QR and "$1.00" with no sign of what the

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

@@ -1,6 +1,6 @@
 # OpenReceive agent directions (Next.js)
 
-These directions describe OpenReceive 0.4.12.
+These directions describe OpenReceive 0.4.14.
 
 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
@@ -149,15 +149,19 @@ itself, and they hold for every integration.
   late becomes `refund_required`, and the payer claims it on a SECOND VISIT,
   after leaving your page to fetch an address from another wallet. Three things
   must exist or that money is unreachable through your UI: a per-order URL your
-  server serves (`/checkout/:reference` — `syncUrl` on the drop-ins), your own
-  order-summary route to restore the order from, and the ATTEMPT.
+  server serves (`/checkout/:reference` — `syncUrl` on `<Checkout>`, `sync-url`
+  or `resumable` on `<openreceive-checkout>`), your own order-summary route to
+  restore the order from, and the ATTEMPT.
   `/checkouts/prepare` returns no attempts, so a checkout rebuilt from the
   reference alone opens on the method grid. Re-picking the same coin
   (`POST /swaps`) re-serves the committed attempt — but only while it is live,
   and the shadow invoice behind a swap lasts about half an hour, after which the
   same click mints a NEW deposit address and the refund is off-screen. Keep the
   `payment_hash` and reopen the attempt with `POST /swaps/status`, which has no
-  such window. https://openreceive.org/guides/swap-refunds.md
+  such window. On the drop-ins: `resumePaymentHash`, fed from `onState`, on
+  `<Checkout>`; the `resume-payment-hash` attribute, fed from the
+  `openreceive-state` event (`event.detail.state.payment_hash`), on
+  `<openreceive-checkout>`. https://openreceive.org/guides/swap-refunds.md
 - Show the payer WHAT THEY ARE BUYING. Return an optional `description` beside
   the price from `amountFor` and both drop-ins render it above the amount.
   Without it the checkout is a QR and "$1.00" with no sign of what the dollar
@@ -381,7 +385,9 @@ there is nothing else to generate. Details:
 No ORM? You can pass a bare driver handle (`pg`, `node:sqlite`,
 `better-sqlite3`) as the `db` in step 4. The scaffold has no flavor for it.
 Instead of scaffolding, run the same DDL once yourself, using
-`paymentsSchemaSql(dialect)` from `@openreceive/http`.
+`paymentsSchemaSql(dialect)` from `@openreceive/http`. Your adapter already
+pulls that package in, but this import is yours, so install it too:
+`npm install @openreceive/http`.
 
 ### 3. Add wallet credentials
 

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

@@ -1,6 +1,6 @@
 # OpenReceive agent directions (Node.js)
 
-These directions describe OpenReceive 0.4.12.
+These directions describe OpenReceive 0.4.14.
 
 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
@@ -146,15 +146,19 @@ itself, and they hold for every integration.
   late becomes `refund_required`, and the payer claims it on a SECOND VISIT,
   after leaving your page to fetch an address from another wallet. Three things
   must exist or that money is unreachable through your UI: a per-order URL your
-  server serves (`/checkout/:reference` — `syncUrl` on the drop-ins), your own
-  order-summary route to restore the order from, and the ATTEMPT.
+  server serves (`/checkout/:reference` — `syncUrl` on `<Checkout>`, `sync-url`
+  or `resumable` on `<openreceive-checkout>`), your own order-summary route to
+  restore the order from, and the ATTEMPT.
   `/checkouts/prepare` returns no attempts, so a checkout rebuilt from the
   reference alone opens on the method grid. Re-picking the same coin
   (`POST /swaps`) re-serves the committed attempt — but only while it is live,
   and the shadow invoice behind a swap lasts about half an hour, after which the
   same click mints a NEW deposit address and the refund is off-screen. Keep the
   `payment_hash` and reopen the attempt with `POST /swaps/status`, which has no
-  such window. https://openreceive.org/guides/swap-refunds.md
+  such window. On the drop-ins: `resumePaymentHash`, fed from `onState`, on
+  `<Checkout>`; the `resume-payment-hash` attribute, fed from the
+  `openreceive-state` event (`event.detail.state.payment_hash`), on
+  `<openreceive-checkout>`. https://openreceive.org/guides/swap-refunds.md
 - Show the payer WHAT THEY ARE BUYING. Return an optional `description` beside
   the price from `amountFor` and both drop-ins render it above the amount.
   Without it the checkout is a QR and "$1.00" with no sign of what the dollar
@@ -366,7 +370,9 @@ there is nothing else to generate. Details:
 No ORM? You can pass a bare driver handle (`pg`, `node:sqlite`,
 `better-sqlite3`) as the `db` in step 4. The scaffold has no flavor for it.
 Instead of scaffolding, run the same DDL once yourself, using
-`paymentsSchemaSql(dialect)` from `@openreceive/http`.
+`paymentsSchemaSql(dialect)` from `@openreceive/http`. Your adapter already
+pulls that package in, but this import is yours, so install it too:
+`npm install @openreceive/http`.
 
 ### 3. Add wallet credentials
 

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

@@ -1,6 +1,6 @@
 # OpenReceive agent directions (PHP)
 
-These directions describe OpenReceive 0.4.12.
+These directions describe OpenReceive 0.4.14.
 
 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
@@ -171,7 +171,9 @@ itself, and they hold for every integration.
   and the shadow invoice behind a swap lasts about half an hour, after which the
   same click mints a NEW deposit address and the refund is off-screen. Keep the
   `payment_hash` and reopen the attempt with `POST /swaps/status`, which has no
-  such window. https://openreceive.org/guides/swap-refunds.md
+  such window. On the element: the `resume-payment-hash` attribute, fed from
+  the `openreceive-state` event (`event.detail.state.payment_hash`).
+  https://openreceive.org/guides/swap-refunds.md
 - Show the payer WHAT THEY ARE BUYING. Return an optional `description` beside
   the price from `amountFor` and the drop-in renders it above the amount.
   Without it the checkout is a QR and "$1.00" with no sign of what the dollar
@@ -651,7 +653,7 @@ use registry `icon_path` / tutorial `path` keys as browser URLs.
 
 Settlement runs on the request path. Every payment route first runs one bounded
 reconcile pass through the durable `openreceive_meta` gate. The gate allows at
-most one real wallet scan every 2 seconds, shared by every PHP process. You do
+most one real wallet scan every 3 seconds, shared by every PHP process. You do
 not need a cron job. Tune or disable it with `Engine`'s
 `opportunisticReconcile` (`false`, or `['min_interval_seconds' => …]`).
 

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

@@ -1,6 +1,6 @@
 # OpenReceive agent directions (Rails)
 
-These directions describe OpenReceive 0.4.12.
+These directions describe OpenReceive 0.4.14.
 
 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
@@ -153,15 +153,19 @@ itself, and they hold for every integration.
   late becomes `refund_required`, and the payer claims it on a SECOND VISIT,
   after leaving your page to fetch an address from another wallet. Three things
   must exist or that money is unreachable through your UI: a per-order URL your
-  server serves (`/checkout/:reference` — `syncUrl` on the drop-ins), your own
-  order-summary route to restore the order from, and the ATTEMPT.
+  server serves (`/checkout/:reference` — `syncUrl` on `<Checkout>`, `sync-url`
+  or `resumable` on `<openreceive-checkout>`), your own order-summary route to
+  restore the order from, and the ATTEMPT.
   `/checkouts/prepare` returns no attempts, so a checkout rebuilt from the
   reference alone opens on the method grid. Re-picking the same coin
   (`POST /swaps`) re-serves the committed attempt — but only while it is live,
   and the shadow invoice behind a swap lasts about half an hour, after which the
   same click mints a NEW deposit address and the refund is off-screen. Keep the
   `payment_hash` and reopen the attempt with `POST /swaps/status`, which has no
-  such window. https://openreceive.org/guides/swap-refunds.md
+  such window. On the drop-ins: `resumePaymentHash`, fed from `onState`, on
+  `<Checkout>`; the `resume-payment-hash` attribute, fed from the
+  `openreceive-state` event (`event.detail.state.payment_hash`), on
+  `<openreceive-checkout>`. https://openreceive.org/guides/swap-refunds.md
 - Show the payer WHAT THEY ARE BUYING. Return an optional `description` beside
   the price from `config.amount_for` and both drop-ins render it above the
   amount. Without it the checkout is a QR and "$1.00" with no sign of what the

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

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