@openreceive/http 0.4.10 → 0.4.12

package/dist/index.d.ts

@@ -1,7 +1,7 @@
 import { OpenReceive, PaymentCheck } from '@openreceive/node';
 export { Checkout, CreateCheckoutAmount, OpenReceive, PaymentCheck, SwapCheckout } from '@openreceive/node';
-import { H as Host, R as ReconcilableAttempt, S as SqlAdapter } from './adapter-surface-DHngkTKQ.js';
-export { A as AttemptStatus, a as Authorize, b as AuthorizeAction, c as AuthorizeContext, d as AuthorizeResource, C as CheckoutCreatedHook, e as CheckoutCreatedInput, f as CreateHostDbOptions, g as CreateHostOptions, h as CreateHostRepositoryOptions, i as CreateHttpHandlerOptions, j as CreateStackOptions, k as HostCheckoutPrice, l as HostError, m as HttpError, n as HttpHandler, I as IpRateLimitConfig, N as NotificationListener, o as NotificationWorker, O as OPENRECEIVE_RECONCILE_BATCH_SIZE, P as PaymentInsert, p as PaymentRecord, q as PaymentRepository, r as PaymentSettlement, s as PaymentSettlementHook, t as RateLimit, u as ReconciliationTransition, v as ResolveCheckoutContext, w as ResolveCheckoutHook, x as ResolvedHostCheckout, y as ServiceErrorShape, z as SettlementEvent, B as SettlementEventHook, D as SettlementRecord, E as SqlClient, F as SqlDatabase, G as SqlPaymentRepository, J as SqlPaymentsOptions, K as SqlQuery, L as Stack, M as StackStorage, Q as StackWallet, T as createHost, U as createHttpHandler, V as createIpRateLimit, W as createProxyRateLimitingConfig, X as createRequestId, Y as createSqlPayments, Z as createStack, _ as errorResponse, $ as hostError, a0 as isServiceErrorShape, a1 as isStackOptions, a2 as jsonResponse, a3 as mapHostRouteError, a4 as paymentsSchemaSql, a5 as resolveClientIp, a6 as startNotificationListener, a7 as startNotificationWorker } from './adapter-surface-DHngkTKQ.js';
+import { H as Host, R as ReconcilableAttempt, S as SqlAdapter } from './adapter-surface-Cs4g29Ez.js';
+export { A as AttemptStatus, a as Authorize, b as AuthorizeAction, c as AuthorizeContext, d as AuthorizeResource, C as CheckoutCreatedHook, e as CheckoutCreatedInput, f as CreateHostDbOptions, g as CreateHostOptions, h as CreateHostRepositoryOptions, i as CreateHttpHandlerOptions, j as CreateStackOptions, k as HostCheckoutPrice, l as HostError, m as HttpError, n as HttpHandler, I as IpRateLimitConfig, N as NotificationListener, o as NotificationWorker, O as OPENRECEIVE_RECONCILE_BATCH_SIZE, P as PaymentInsert, p as PaymentRecord, q as PaymentRepairCandidate, r as PaymentRepository, s as PaymentSettlement, t as PaymentSettlementHook, u as RateLimit, v as ReconcileCursor, w as ReconcileGateClaim, x as ReconcileScheduler, y as ReconciliationTransition, z as ResolveCheckoutContext, B as ResolveCheckoutHook, D as ResolvedHostCheckout, E as ServiceErrorShape, F as SettlementContext, G as SettlementEvent, J as SettlementEventHook, K as SettlementRecord, L as SqlClient, M as SqlDatabase, Q as SqlPaymentRepository, T as SqlPaymentsOptions, U as SqlQuery, V as Stack, W as StackStorage, X as StackWallet, Y as createHost, Z as createHttpHandler, _ as createIpRateLimit, $ as createProxyRateLimitingConfig, a0 as createRequestId, a1 as createSqlPayments, a2 as createStack, a3 as errorResponse, a4 as hostError, a5 as isServiceErrorShape, a6 as isStackOptions, a7 as jsonResponse, a8 as mapHostRouteError, a9 as paymentsSchemaSql, aa as resolveClientIp, ab as startNotificationListener, ac as startNotificationWorker } from './adapter-surface-Cs4g29Ez.js';
 export { OPENRECEIVE_ATTEMPT_EXPIRY_GRACE_SECONDS, OPENRECEIVE_PAYMENTS_SCHEMA_VERSION } from '@openreceive/core';
 
 /** The pieces of a framework request the bridge needs, framework-agnostic. */
@@ -255,6 +255,8 @@ declare function reconcileHostPayments(input: {
      * which is the request path.
      */
     readonly attempts?: readonly ReconcilableAttempt[];
+    /** Results from the gate-owned bounded slice; no additional wallet walk. */
+    readonly checks?: readonly PaymentCheck[];
 }): Promise<readonly PaymentCheck[]>;
 /**
  * Poll and reconcile only the pending attempts in the ledger. Every pass goes
@@ -341,18 +343,19 @@ type SqlDialect = SqlAdapter["dialect"];
 /** The raw-query slice of a Knex instance or transaction. */
 interface KnexExecutorLike {
     raw(sql: string, bindings: readonly unknown[]): Promise<unknown>;
+    client?: {
+        acquireConnection(): Promise<unknown>;
+        releaseConnection(connection: unknown): Promise<unknown>;
+    };
 }
 /** Structural view of a Knex instance. */
 interface KnexLike extends KnexExecutorLike {
     transaction<T>(run: (trx: KnexExecutorLike) => Promise<T>): Promise<T>;
 }
 /**
- * Wrap a Knex instance. Knex hands the SQL and bindings to the driver
- * verbatim (`?` is already the sqlite placeholder, and `$n` postgres SQL
- * contains no `?` for Knex to rewrite); only the RESULT shape differs per
- * driver. The sqlite3 driver resolves the rows array itself; pg wraps them in
- * `{ rows }` — reaching into `result[0]` would return the first ROW on
- * sqlite, which breaks every repository read.
+ * PostgreSQL SQL goes directly to the native driver, on the owning executor's
+ * connection. A transaction executor returns its own connection and retains it
+ * until commit/rollback. SQLite keeps Knex's raw-query path.
  */
 declare function knexDb(knex: KnexLike, dialect: SqlDialect): SqlAdapter;
 /** The raw-query slice of a PrismaClient or interactive-transaction client. */

package/dist/index.js

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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@openreceive/http",
-  "version": "0.4.10",
+  "version": "0.4.12",
   "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.10",
-    "@openreceive/node": "0.4.10"
+    "@openreceive/core": "0.4.12",
+    "@openreceive/node": "0.4.12"
   },
   "exports": {
     ".": {

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.10.
+These directions describe OpenReceive 0.4.12.
 
 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
@@ -119,6 +121,8 @@ enough; drop the `.md` for the same page a person would read.
 Questions, or a problem with the plugin itself:
 https://openreceive.org/contact
 
+- https://openreceive.org/guides/payment-safety-upgrade.md — coordinated upgrades and reviewed repair of existing attempts
+
 ---
 
 ## The quickstart, in full
@@ -131,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
 
@@ -155,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 one table (`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.