@openreceive/http 0.4.11 → 0.4.13

package/dist/adapter-surface.js

@@ -7,7 +7,7 @@ import {
   isServiceErrorShape,
   mapHostRouteError,
   startNotificationWorker
-} from "./chunk-PGZAFYN6.js";
+} from "./chunk-YIN33FVH.js";
 export {
   HostError,
   HttpError,

package/dist/{chunk-PGZAFYN6.js → chunk-YIN33FVH.js}

@@ -1307,10 +1307,11 @@ function abortableDelay(milliseconds, signal) {
 }
 
 // src/reconcile-gate.ts
-var OPENRECEIVE_MIN_RECONCILE_INTERVAL_SECONDS = 2;
+var OPENRECEIVE_MIN_RECONCILE_INTERVAL_SECONDS = 3;
 var OPENRECEIVE_RECONCILE_SCAN_TIMEOUT_MS = 9e3;
+var SCAN_BACKSTOP_GRACE_MS = 500;
 var OPENRECEIVE_RECONCILE_SCAN_MAX_PAGES = 50;
-var EARLY_INVOICE_INTERVAL_SECONDS = 2;
+var EARLY_INVOICE_INTERVAL_SECONDS = 3;
 var MID_INVOICE_INTERVAL_SECONDS = 6;
 var LATE_INVOICE_INTERVAL_SECONDS = 12;
 var EARLY_INVOICE_WINDOW_SECONDS = 2 * 60;
@@ -1345,7 +1346,10 @@ async function maybeReconcilePayments(input) {
   try {
     const clock = input.clock ?? unixSeconds5;
     const now = clock();
-    const minInterval = Math.max(2, input.minIntervalSeconds ?? 2);
+    const minInterval = Math.max(
+      OPENRECEIVE_MIN_RECONCILE_INTERVAL_SECONDS,
+      input.minIntervalSeconds ?? OPENRECEIVE_MIN_RECONCILE_INTERVAL_SECONDS
+    );
     const timeout = Math.min(
       OPENRECEIVE_RECONCILE_SCAN_TIMEOUT_MS,
       input.scanTimeoutMs ?? OPENRECEIVE_RECONCILE_SCAN_TIMEOUT_MS
@@ -1370,20 +1374,19 @@ async function maybeReconcilePayments(input) {
         candidates = await input.host.payments.listReconcilableAttempts(null);
       const last = candidates.at(-1);
       scheduler.cursor = last === void 0 || candidates.length < OPENRECEIVE_RECONCILE_BATCH_SIZE ? null : { created_at: last.createdAt, payment_hash: last.paymentHash };
-      const fresh = candidates.filter((attempt) => !queued.has(attempt.paymentHash));
-      if (fresh.length > 0)
-        scheduler.windows.push(
-          createPaymentScanWindow(
-            fresh.map((attempt) => ({
-              payment_hash: attempt.paymentHash,
-              created_at: attempt.createdAt,
-              expires_at: attempt.expiresAt,
-              created_at_source: attempt.createdAtSource ?? "host"
-            })),
-            now,
-            input.overlapSeconds
-          )
+      const fresh = candidates.filter((attempt) => !queued.has(attempt.paymentHash)).map((attempt) => ({
+        payment_hash: attempt.paymentHash,
+        created_at: attempt.createdAt,
+        expires_at: attempt.expiresAt,
+        created_at_source: attempt.createdAtSource ?? "host"
+      }));
+      for (const wallet of [true, false]) {
+        const cohort = fresh.filter(
+          (attempt) => attempt.created_at_source === "wallet" === wallet
         );
+        if (cohort.length > 0 && scheduler.windows.length < 2)
+          scheduler.windows.push(createPaymentScanWindow(cohort, now, input.overlapSeconds));
+      }
     }
     const window = scheduler.windows.shift();
     if (window === void 0) {
@@ -1445,7 +1448,7 @@ async function maybeReconcilePayments(input) {
           }
         }
       }),
-      timeout,
+      timeout + SCAN_BACKSTOP_GRACE_MS,
       controller
     );
     if (slice.outcome === "continued") {

package/dist/index.d.ts

@@ -282,15 +282,16 @@ declare function startReconciler(input: {
 
 /**
  * Floor for the durable reconcile-gate interval: at most one real wallet scan
- * per two seconds across EVERY worker sharing the host database. This gate is
+ * per three seconds across EVERY worker sharing the host database. This gate is
  * the NWC rate limit for settlement scans — open tabs polling `payments/check`
  * (~3s) all share the one global pass instead of fanning out wallet walks.
  */
-declare const OPENRECEIVE_MIN_RECONCILE_INTERVAL_SECONDS: 2;
+declare const OPENRECEIVE_MIN_RECONCILE_INTERVAL_SECONDS: 3;
 /**
  * Wall-clock bound on an awaited request-path pass: a slow wallet must not
- * hang user-facing requests. A timed-out pass counts as a failed scan; the
- * gate stays claimed so the next interval retries without a stampede.
+ * hang user-facing requests. A page still in flight at the deadline is cut;
+ * the pass keeps the progress of its completed pages, and the next interval
+ * resumes there.
  */
 declare const OPENRECEIVE_RECONCILE_SCAN_TIMEOUT_MS: 9000;
 /** Page cap per wallet-history walk on the awaited request path. */
@@ -304,7 +305,7 @@ type OpportunisticReconcileResult = {
 interface MaybeReconcilePaymentsOptions {
     readonly service: OpenReceive;
     readonly host: Host;
-    /** Gate interval floor. Default (and minimum) 2 seconds. */
+    /** Gate interval floor. Default (and minimum) 3 seconds. */
     readonly minIntervalSeconds?: number;
     readonly overlapSeconds?: number;
     readonly scanTimeoutMs?: number;
@@ -315,7 +316,7 @@ interface MaybeReconcilePaymentsOptions {
 }
 /**
  * The gate interval for the current pending set: the configured floor,
- * stretched by invoice age (2s while any pending invoice is under 2 minutes
+ * stretched by invoice age (3s while any pending invoice is under 2 minutes
  * old, 6s under 5 minutes, else 12s).
  */
 declare function reconcileIntervalSeconds(attempts: readonly ReconcilableAttempt[], now: number, minIntervalSeconds?: number): number;

package/dist/index.js

@@ -34,7 +34,7 @@ import {
   startReconciler,
   typeOrmDb,
   webRequest
-} from "./chunk-PGZAFYN6.js";
+} from "./chunk-YIN33FVH.js";
 export {
   HostError,
   HttpError,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@openreceive/http",
-  "version": "0.4.11",
+  "version": "0.4.13",
   "description": "Node.js HTTP routes and payment storage for Bitcoin Lightning checkout, with optional USDT, USDC, SOL and ETH swaps.",
   "keywords": [
     "bitcoin",
@@ -17,8 +17,8 @@
   "main": "./dist/index.js",
   "types": "./dist/index.d.ts",
   "dependencies": {
-    "@openreceive/core": "0.4.11",
-    "@openreceive/node": "0.4.11"
+    "@openreceive/core": "0.4.13",
+    "@openreceive/node": "0.4.13"
   },
   "exports": {
     ".": {

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/SKILL.md

@@ -34,9 +34,10 @@ code** (`NWC_URI`).
    - BTCPay Server: [references/btcpay.md](references/btcpay.md) — a plugin,
      configured in BTCPay's store UI or Greenfield API; no application code,
      no npm packages, no gem. The rest of this file is about the library.
-3. Follow its **Step 0** first: confirm `NWC_URI` is set in the server
-   environment before writing code. Never print the value; never invent a
-   placeholder.
+3. Follow its **Step 0** first: before writing code or searching the machine,
+   ask the user for the receive-only NWC code (then the swap URI), one question
+   per message, and store each pasted code in the project's env file yourself.
+   Never print the value; never invent a placeholder.
 
 Install, per adapter — Express: `npm install @openreceive/express @openreceive/react`;
 Fastify: `npm install @openreceive/fastify @openreceive/react`; Next.js:

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

@@ -1,6 +1,6 @@
 # OpenReceive agent directions (BTCPay Server)
 
-These directions describe OpenReceive 0.4.11.
+These directions describe OpenReceive 0.4.13.
 
 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
@@ -35,10 +35,12 @@ refund path on the same checkout screen.
 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
-   store navigation shows an "OpenReceive" entry). If not, install it from the
-   BTCPay plugin directory (Server Settings → Plugins, search "OpenReceive"),
-   as the quickstart says; do not invent an installer command.
+2. Check whether the plugin is installed (the Plugins menu — the plug icon in
+   the top-right corner — under Installed Plugins, or the store navigation
+   shows an "OpenReceive" entry). If not, install it from the BTCPay plugin
+   directory (the same Plugins menu → Plugin Directory, search "openreceive",
+   then Install and Restart now), as the quickstart says; do not invent an
+   installer command.
 3. Check whether the store already has an OpenReceive connection:
    `GET /api/v1/stores/{storeId}/openreceive/settings` returns
    `lightningNodeIsOpenReceive`. If true, the wallet step is done — go to
@@ -133,15 +135,15 @@ passes. The page it comes from is https://openreceive.org/guides/quickstart-btcp
 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
-payments through its own settlement machinery. Optionally, payers can pay a
-BTCPay invoice with USDT, USDC, ETH or SOL through a Lightning Swap Connect
-provider; the swap settles into the same wallet. The store's internal node is
+BTCPay store. BTCPay creates every Lightning invoice in that wallet. It records
+payments the same way it records any other payment. You can also let payers pay
+a BTCPay invoice with USDT, USDC, ETH or SOL through a Lightning Swap Connect
+provider. The swap pays into the same wallet. The store's internal node is
 never used.
 
 This is not the Node or Rails library. There are no hooks, no
-`openreceive_payments` table and no OpenReceive HTTP routes: BTCPay's
-invoices, checkout, webhooks and Greenfield API are the host.
+`openreceive_payments` table and no OpenReceive HTTP routes. BTCPay's own
+invoices, checkout, webhooks and Greenfield API do that work.
 
 ### 1. Prerequisites
 
@@ -157,39 +159,66 @@ invoices, checkout, webhooks and Greenfield API are the host.
 
 ### 2. Install the plugin
 
-In BTCPay, open **Server Settings → Plugins**, search the plugin directory
-for **OpenReceive**, click **Install**, and restart BTCPay when prompted.
-BTCPay creates the plugin's two tables (`openreceive_invoices` and
-`openreceive_swaps`, schema `BTCPayServer.Plugins.OpenReceive`) in its own
-Postgres at startup; nothing else is created.
+Sign in as a **server administrator**. If someone else hosts your server, ask
+them to install the plugin for you.
+
+**1. Open the Plugins menu.** It is the plug icon in the top-right corner.
+
+**2. Click Plugin Directory.**
+
+**3. Search for `openreceive`** and click the **OpenReceive** result.
+
+**4. Click Install in BTCPay Server.** Confirm when prompted, then click
+**Restart now** and wait for BTCPay to come back.
+
+At startup, BTCPay creates the plugin's two tables in its own Postgres
+database: `openreceive_invoices` and `openreceive_swaps`, in the schema
+`BTCPayServer.Plugins.OpenReceive`. Nothing else is created.
 
 To build the plugin from source instead, follow
 [the .NET workspace README](https://github.com/OpenReceive/openreceive/blob/master/packages/dotnet/README.md).
 
 ### 3. Connect the wallet
 
-Follow the plugin README's illustrated walkthrough:
-[OpenReceive for BTCPay Server](https://github.com/OpenReceive/openreceive/blob/master/packages/dotnet/BTCPayServer.Plugins.OpenReceive/README.md).
-It opens the **OpenReceive** page in the store's sidebar, saves the
-receive-only NWC code, optionally saves the LSC code to turn swaps on, and
-creates a first test invoice. There is nothing else to configure: you never
-open BTCPay's Lightning node screen, and the plugin never reads the internal
-node.
+1. Select your store and open **OpenReceive** in its sidebar, under Wallets.
+2. Paste your receive-only NWC code. To see what the wallet supports first,
+   click **Test connection**.
+3. Click **Save NWC Code**.
+4. To turn swaps on, paste a Lightning Swap Connect code and click **Save swap
+   settings**.
 
-Saving fails closed if the wallet advertises a spend method such as
-`pay_invoice`. Mint a receive-only code instead; the override for a wallet
-that cannot is a deliberate, logged choice. Swaps raise the store's invoice
-expiration to 60 minutes when it is shorter, because a swap needs at least 45
-minutes of invoice life.
+The page then shows **Wallet connected**. If you set up a provider, it also
+shows **Swaps on**. There is nothing else to configure. You never open BTCPay's
+Lightning node screen, and the plugin never reads the internal node.
+
+Screenshots for each of those steps, and for creating a first test invoice,
+are in the plugin's
+[README](https://github.com/OpenReceive/openreceive/blob/master/packages/dotnet/BTCPayServer.Plugins.OpenReceive/README.md).
+
+The plugin refuses to save a code whose wallet advertises a spend method such
+as `pay_invoice`. Create a receive-only code instead. If your wallet cannot
+make one, there is an override, but using it is a deliberate choice and the
+plugin logs it.
+
+Turning swaps on raises the store's invoice expiration to 60 minutes if it is
+shorter. A swap needs the invoice to stay open for at least 45 minutes.
 
 ### 4. Check it
 
-**Run a health check** on the OpenReceive page runs every probe in place:
-the connection, the wallet preflight, payment notifications, the last wallet
-scan, the swap provider and its assets, the invoice expiration, and swaps
-that need a human. Each failing probe carries a fix link.
+Click **Run a health check** on the OpenReceive page. It runs every check
+right there:
+
+- the connection
+- the wallet preflight
+- payment notifications
+- the last wallet scan
+- the swap provider and its assets
+- the invoice expiration
+- swaps that need a human
+
+Each failing check comes with a link to the fix.
 
-Every setting, Greenfield route, swap state, log event and probe is in the
-[BTCPay plugin reference](https://openreceive.org/guides/btcpay-reference.md), including what is
-unsupported by design: every send-side feature, top-up invoices, and a bare
-`nostr+walletconnect://` string in BTCPay's Lightning node screen.
+The [BTCPay plugin reference](https://openreceive.org/guides/btcpay-reference.md) lists every setting,
+Greenfield route, swap state, log event and check. It also lists what the
+plugin does not support by design: every send-side feature, top-up invoices,
+and a bare `nostr+walletconnect://` string in BTCPay's Lightning node screen.