@openreceive/vue 0.4.9 → 0.4.11

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@openreceive/vue",
3
- "version": "0.4.9",
3
+ "version": "0.4.11",
4
4
  "description": "Vue component for Bitcoin Lightning checkout and optional USDT, USDC, SOL and ETH swaps.",
5
5
  "keywords": [
6
6
  "bitcoin",
@@ -19,8 +19,8 @@
19
19
  "main": "./dist/index.js",
20
20
  "types": "./dist/index.d.ts",
21
21
  "dependencies": {
22
- "@openreceive/browser": "0.4.9",
23
- "@openreceive/elements": "0.4.9"
22
+ "@openreceive/browser": "0.4.11",
23
+ "@openreceive/elements": "0.4.11"
24
24
  },
25
25
  "peerDependencies": {
26
26
  "typescript": ">=5.0.0",
@@ -70,6 +70,14 @@ same diagnostics redacted, always exit 0 — safe to share.
70
70
  - Refunds exist only for swap deposits from `refund_required`. There is **no
71
71
  Lightning refund** — the wallet cannot spend. Do not chase one.
72
72
  https://openreceive.org/guides/swap-refunds.md
73
+ - "Payer reports two different amounts on a stablecoin checkout" (50.05 or
74
+ 50.03?): the deposit amount is a token quantity, `fee.pay_in_fiat` is its
75
+ fiat valuation. Only `swap.deposit_amount` is an instruction. From 0.4.10 the
76
+ packaged checkout renders a USD stablecoin's breakdown in the token and never
77
+ shows `pay_in_fiat`; on an older bundle, upgrade `@openreceive/*`. To verify,
78
+ read the row's `deposit_amount` and `fee` and confirm the UI shows only the
79
+ deposit amount. A custom UI must call `createSwapFeeBreakdown(fee, swap)`
80
+ with the swap, not the fee alone.
73
81
 
74
82
  ## 6. Checkout UI shows nothing
75
83
 
@@ -86,6 +86,17 @@ state; do not retry-loop it, and do not build an idempotency store around it —
86
86
  that serialization is the library's job. (A hook failure while persisting an
87
87
  attempt is a **503 retryable**, deliberately distinct.)
88
88
 
89
+ ## Amounts on the deposit panel
90
+
91
+ `swap.deposit_amount` is the ONLY amount a payer is ever told to send, in the
92
+ pay-in token. `swap.fee.pay_in_fiat` / `payout_fiat` are fiat valuations that
93
+ explain the spread (why the deposit exceeds the cart total); they are not
94
+ instructions. For a stablecoin pegged to the fee currency (USDT, USDC) the
95
+ packaged checkout expresses the breakdown in the token and never renders
96
+ `pay_in_fiat` — "$50.03" under "50.05 USDC" reads as the same number with a
97
+ typo. A custom UI gets the same rule from `createSwapFeeBreakdown(fee, swap)`;
98
+ pass the swap, not just the fee.
99
+
89
100
  ## Secrets
90
101
 
91
102
  `NWC_URI` and `LSC_URI_*` are server-only. Never put them in browser code,
@@ -1,6 +1,6 @@
1
1
  # OpenReceive agent directions (BTCPay Server)
2
2
 
3
- These directions describe OpenReceive 0.4.9.
3
+ These directions describe OpenReceive 0.4.11.
4
4
 
5
5
  Connect a BTCPay Server store to a receive-only NWC wallet with the OpenReceive
6
6
  plugin, and optionally let payers pay BTCPay invoices with USDT, USDC, ETH or
@@ -32,7 +32,7 @@ refund path on the same checkout screen.
32
32
 
33
33
  ## Step 0 — check the deployment before you change anything
34
34
 
35
- 1. Confirm the BTCPay Server version is 2.4.2 or later (Server Settings →
35
+ 1. Confirm the BTCPay Server version is 2.4.4 or later (Server Settings →
36
36
  About, or `GET /api/v1/server/info`). The plugin declares that minimum and
37
37
  BTCPay refuses to load it below.
38
38
  2. Check whether the plugin is installed (Server Settings → Plugins, or the
@@ -119,6 +119,8 @@ enough; drop the `.md` for the same page a person would read.
119
119
  Questions, or a problem with the plugin itself:
120
120
  https://openreceive.org/contact
121
121
 
122
+ - https://openreceive.org/guides/payment-safety-upgrade.md — coordinated upgrades and reviewed repair of existing attempts
123
+
122
124
  ---
123
125
 
124
126
  ## The quickstart, in full
@@ -128,7 +130,7 @@ passes. The page it comes from is https://openreceive.org/guides/quickstart-btcp
128
130
 
129
131
  ## BTCPay Server quickstart
130
132
 
131
- Requires BTCPay Server ≥ 2.4.2.
133
+ Requires BTCPay Server ≥ 2.4.4.
132
134
 
133
135
  The OpenReceive plugin makes a receive-only NWC wallet the Lightning node of a
134
136
  BTCPay store. BTCPay mints every Lightning invoice in that wallet and records
@@ -143,7 +145,7 @@ invoices, checkout, webhooks and Greenfield API are the host.
143
145
 
144
146
  ### 1. Prerequisites
145
147
 
146
- - A BTCPay Server, version 2.4.2 or later, on any network (mainnet, testnet,
148
+ - A BTCPay Server, version 2.4.4 or later, on any network (mainnet, testnet,
147
149
  signet, regtest). The wallet must be on the same network.
148
150
  - A receive-only NWC code for the wallet you want to receive into
149
151
  ([get one here](https://openreceive.org/get_a_nwc_code_to_receive_payments)).
@@ -157,9 +159,9 @@ invoices, checkout, webhooks and Greenfield API are the host.
157
159
 
158
160
  In BTCPay, open **Server Settings → Plugins**, search the plugin directory
159
161
  for **OpenReceive**, click **Install**, and restart BTCPay when prompted.
160
- BTCPay creates the plugin's one table (`openreceive_swaps`, schema
161
- `BTCPayServer.Plugins.OpenReceive`) in its own Postgres at startup; nothing
162
- else is created.
162
+ BTCPay creates the plugin's two tables (`openreceive_invoices` and
163
+ `openreceive_swaps`, schema `BTCPayServer.Plugins.OpenReceive`) in its own
164
+ Postgres at startup; nothing else is created.
163
165
 
164
166
  To build the plugin from source instead, follow
165
167
  [the .NET workspace README](https://github.com/OpenReceive/openreceive/blob/master/packages/dotnet/README.md).
@@ -1,6 +1,6 @@
1
1
  # OpenReceive agent directions (Django)
2
2
 
3
- These directions describe OpenReceive 0.4.9.
3
+ These directions describe OpenReceive 0.4.11.
4
4
 
5
5
  Add OpenReceive to a Django project — the app you are already working in. You
6
6
  do not need a copy of the OpenReceive source: the Python package is on PyPI
@@ -130,7 +130,7 @@ itself, and they hold for every integration.
130
130
  a placeholder that allows everything (`manage.py check` warns
131
131
  `openreceive.W002` while it is set) — replace it with this app's real
132
132
  ownership check, same as `on_paid`.
133
- - `on_paid` must be idempotent. It runs once per `reference` — your order
133
+ - `on_paid` must be idempotent. Its database fulfillment commits once per `reference` — your order
134
134
  id, one per thing you fulfill, created before checkout, kept across retries,
135
135
  never reused. A fresh id per page load lets one order be paid twice.
136
136
  - Receive-only NWC is required; a spend-capable code fails closed at boot unless
@@ -231,6 +231,13 @@ built on `@openreceive/browser/headless`. Read that before writing components.
231
231
  - `createSwapDisplayModel` → `display.copyRows` for deposits: address, memo,
232
232
  and the bare amount each get a copy row. Render `swap.networkWarning*` as
233
233
  the model gives it.
234
+ - `swap.deposit_amount` is the only amount a payer is told to send. Never put
235
+ a fiat valuation of it (`swap.fee.pay_in_fiat`) next to a stablecoin amount:
236
+ "$50.03" under "50.05 USDC" reads as a typo, and the payer asks which one to
237
+ send. The one fiat figure on a USDT/USDC deposit panel is the cart total
238
+ (`payout_fiat`); express "you send" and the fee in the token. Use
239
+ `createSwapFeeBreakdown(fee, swap)` — with the swap, not the fee alone — and
240
+ it applies this for you; SOL and ETH keep a fiat breakdown.
234
241
  - `createCheckoutSession` owns mint and swap start. To start swaps, pass its
235
242
  `swap` option (`selection`, `prefix`, `fetch`) together. Without it
236
243
  `startSwap` reports through `onError`.
@@ -300,6 +307,8 @@ enough; drop the `.md` for the same page a person would read.
300
307
  Questions, or a problem with the library itself:
301
308
  https://openreceive.org/contact
302
309
 
310
+ - https://openreceive.org/guides/payment-safety-upgrade.md — coordinated upgrades and reviewed repair of existing attempts
311
+
303
312
  ---
304
313
 
305
314
  ## The quickstart, in full
@@ -473,7 +482,7 @@ The host class needs three things: authorization, the trusted price, and
473
482
  fulfillment. All three receive the `reference` — a string you choose, and the
474
483
  fulfillment identity: your order id, one per thing you fulfill, created before
475
484
  checkout, kept across retries, never reused. OpenReceive never looks inside
476
- it, but `on_paid` runs once per reference, a new checkout under a reference
485
+ it, but `on_paid` commits fulfillment once per reference, a new checkout under a reference
477
486
  that already settled is refused with 409, and a fresh id per page load lets
478
487
  one order be paid twice.
479
488
 
@@ -1,6 +1,6 @@
1
1
  # OpenReceive agent directions (FastAPI)
2
2
 
3
- These directions describe OpenReceive 0.4.9.
3
+ These directions describe OpenReceive 0.4.11.
4
4
 
5
5
  Add OpenReceive to a FastAPI application — the app you are already working in.
6
6
  You do not need a copy of the OpenReceive source: the engine is on PyPI
@@ -116,7 +116,7 @@ itself, and they hold for every integration.
116
116
  - `authorize` runs on every request, and the `resource` it receives is a CLAIM
117
117
  the payer made, not proof. Read the Starlette request's session, cookie or
118
118
  auth dependency; never trust a body field.
119
- - `on_paid` must be idempotent. It runs once per `reference` — your order id, one
119
+ - `on_paid` must be idempotent. Its database fulfillment commits once per `reference` — your order id, one
120
120
  per thing you fulfill, created before checkout, kept across retries, never
121
121
  reused. A fresh id per page load lets one order be paid twice.
122
122
  - Receive-only NWC is required; a spend-capable code fails closed at boot unless
@@ -228,6 +228,13 @@ components.
228
228
  - `createSwapDisplayModel` → `display.copyRows` for deposits: address, memo,
229
229
  and the bare amount each get a copy row. Render `swap.networkWarning*` as
230
230
  the model gives it.
231
+ - `swap.deposit_amount` is the only amount a payer is told to send. Never put
232
+ a fiat valuation of it (`swap.fee.pay_in_fiat`) next to a stablecoin amount:
233
+ "$50.03" under "50.05 USDC" reads as a typo, and the payer asks which one to
234
+ send. The one fiat figure on a USDT/USDC deposit panel is the cart total
235
+ (`payout_fiat`); express "you send" and the fee in the token. Use
236
+ `createSwapFeeBreakdown(fee, swap)` — with the swap, not the fee alone — and
237
+ it applies this for you; SOL and ETH keep a fiat breakdown.
231
238
  - `createCheckoutSession` owns mint and swap start. To start swaps, pass its
232
239
  `swap` option (`selection`, `prefix`, `fetch`) together. Without it
233
240
  `startSwap` reports through `onError`.
@@ -294,6 +301,8 @@ enough; drop the `.md` for the same page a person would read.
294
301
  Questions, or a problem with the library itself:
295
302
  https://openreceive.org/contact
296
303
 
304
+ - https://openreceive.org/guides/payment-safety-upgrade.md — coordinated upgrades and reviewed repair of existing attempts
305
+
297
306
  ---
298
307
 
299
308
  ## The quickstart, in full
@@ -468,7 +477,7 @@ the `reference`. OpenReceive never prices from payer input.
468
477
  The `reference` is a string you choose, and it is the fulfillment identity:
469
478
  your order id — one per thing you fulfill, created before checkout, kept
470
479
  across retries, never reused. OpenReceive never looks inside it, but `on_paid`
471
- runs once per reference, a new checkout under a reference that already
480
+ commits fulfillment once per reference, a new checkout under a reference that already
472
481
  settled is refused with 409, and a fresh id per page load lets one order be
473
482
  paid twice.
474
483
 
@@ -517,7 +526,7 @@ Content-Security-Policy has a strict `img-src`, allow `data:`
517
526
  ([Provider registry](https://openreceive.org/guides/provider-registry.md#assets)).
518
527
 
519
528
  That is the whole loop: your server owns the price and the order, the payer gets
520
- an invoice, and `onPaid` runs once inside the settlement transaction.
529
+ an invoice, and `onPaid` runs inside the settlement transaction. Rolled-back transactions may retry the callback; use a host outbox for external delivery.
521
530
 
522
531
  A page without a bundler renders the same checkout as a custom element:
523
532
  `<openreceive-checkout reference="…" prefix="/openreceive">` from
@@ -1,6 +1,6 @@
1
1
  # OpenReceive agent directions (Fastify)
2
2
 
3
- These directions describe OpenReceive 0.4.9.
3
+ These directions describe OpenReceive 0.4.11.
4
4
 
5
5
  Add OpenReceive to a Fastify application — the app you are already working in.
6
6
  You do not need a copy of the OpenReceive source: the packages are on npm, and
@@ -107,7 +107,7 @@ itself, and they hold for every integration.
107
107
  payer-supplied amounts.
108
108
  - `authorize` runs on every request, and the `resource` it receives is a CLAIM
109
109
  the payer made, not proof. Read a framework session; never trust a body field.
110
- - `onPaid` must be idempotent. It runs once per `reference` — your order id, one
110
+ - `onPaid` must be idempotent. Its database fulfillment commits once per `reference` — your order id, one
111
111
  per thing you fulfill, created before checkout, kept across retries, never
112
112
  reused. A fresh id per page load lets one order be paid twice.
113
113
  - Receive-only NWC is required; a spend-capable code fails closed at boot unless
@@ -211,6 +211,13 @@ components.
211
211
  - `createSwapDisplayModel` → `display.copyRows` for deposits: address, memo,
212
212
  and the bare amount each get a copy row. Render `swap.networkWarning*` as
213
213
  the model gives it.
214
+ - `swap.deposit_amount` is the only amount a payer is told to send. Never put
215
+ a fiat valuation of it (`swap.fee.pay_in_fiat`) next to a stablecoin amount:
216
+ "$50.03" under "50.05 USDC" reads as a typo, and the payer asks which one to
217
+ send. The one fiat figure on a USDT/USDC deposit panel is the cart total
218
+ (`payout_fiat`); express "you send" and the fee in the token. Use
219
+ `createSwapFeeBreakdown(fee, swap)` — with the swap, not the fee alone — and
220
+ it applies this for you; SOL and ETH keep a fiat breakdown.
214
221
  - `createCheckoutSession` owns mint and swap start. To start swaps, pass its
215
222
  `swap` option (`selection`, `prefix`, `fetch`) together. Without it
216
223
  `startSwap` reports through `onError`.
@@ -277,6 +284,8 @@ enough; drop the `.md` for the same page a person would read.
277
284
  Questions, or a problem with the library itself:
278
285
  https://openreceive.org/contact
279
286
 
287
+ - https://openreceive.org/guides/payment-safety-upgrade.md — coordinated upgrades and reviewed repair of existing attempts
288
+
280
289
  ---
281
290
 
282
291
  ## The quickstart, in full
@@ -470,7 +479,7 @@ the `reference`. OpenReceive never prices from payer input.
470
479
  The `reference` is a string you choose, and it is the fulfillment identity:
471
480
  your order id — one per thing you fulfill, created before checkout, kept
472
481
  across retries, never reused. OpenReceive never looks inside it, but `onPaid`
473
- runs once per reference, a new checkout under a reference that already
482
+ commits fulfillment once per reference, a new checkout under a reference that already
474
483
  settled is refused with 409, and a fresh id per page load lets one order be
475
484
  paid twice.
476
485
 
@@ -519,7 +528,7 @@ Content-Security-Policy has a strict `img-src`, allow `data:`
519
528
  ([Provider registry](https://openreceive.org/guides/provider-registry.md#assets)).
520
529
 
521
530
  That is the whole loop: your server owns the price and the order, the payer gets
522
- an invoice, and `onPaid` runs once inside the settlement transaction.
531
+ an invoice, and `onPaid` runs inside the settlement transaction. Rolled-back transactions may retry the callback; use a host outbox for external delivery.
523
532
 
524
533
  A runnable illustration of this boundary — not a template to copy models from —
525
534
  is Buy a Button
@@ -1,6 +1,6 @@
1
1
  # OpenReceive agent directions (Laravel)
2
2
 
3
- These directions describe OpenReceive 0.4.9.
3
+ These directions describe OpenReceive 0.4.11.
4
4
 
5
5
  Add OpenReceive to a Laravel application — the app you are already working in.
6
6
  You do not need a copy of the OpenReceive source: the package is on Packagist
@@ -121,7 +121,7 @@ itself, and they hold for every integration.
121
121
  scaffolds `use AllowAllAuthorize;`, a placeholder trait that allows
122
122
  everything (the engine warns at boot while it is there) — replace it with
123
123
  this app's real ownership check, same as `onPaid`.
124
- - `onPaid` must be idempotent. It runs once per `reference` — your order
124
+ - `onPaid` must be idempotent. Its database fulfillment commits once per `reference` — your order
125
125
  id, one per thing you fulfill, created before checkout, kept across retries,
126
126
  never reused. A fresh id per page load lets one order be paid twice.
127
127
  - Receive-only NWC is required; a spend-capable code fails closed at boot unless
@@ -216,6 +216,13 @@ built on `@openreceive/browser/headless`. Read that before writing components.
216
216
  - `createSwapDisplayModel` → `display.copyRows` for deposits: address, memo,
217
217
  and the bare amount each get a copy row. Render `swap.networkWarning*` as
218
218
  the model gives it.
219
+ - `swap.deposit_amount` is the only amount a payer is told to send. Never put
220
+ a fiat valuation of it (`swap.fee.pay_in_fiat`) next to a stablecoin amount:
221
+ "$50.03" under "50.05 USDC" reads as a typo, and the payer asks which one to
222
+ send. The one fiat figure on a USDT/USDC deposit panel is the cart total
223
+ (`payout_fiat`); express "you send" and the fee in the token. Use
224
+ `createSwapFeeBreakdown(fee, swap)` — with the swap, not the fee alone — and
225
+ it applies this for you; SOL and ETH keep a fiat breakdown.
219
226
  - `createCheckoutSession` owns mint and swap start. To start swaps, pass its
220
227
  `swap` option (`selection`, `prefix`, `fetch`) together. Without it
221
228
  `startSwap` reports through `onError`.
@@ -284,6 +291,8 @@ enough; drop the `.md` for the same page a person would read.
284
291
  Questions, or a problem with the library itself:
285
292
  https://openreceive.org/contact
286
293
 
294
+ - https://openreceive.org/guides/payment-safety-upgrade.md — coordinated upgrades and reviewed repair of existing attempts
295
+
287
296
  ---
288
297
 
289
298
  ## The quickstart, in full
@@ -449,7 +458,7 @@ variable as set/unset only.
449
458
  price, and fulfillment. All three receive the `reference` — a string you
450
459
  choose, and the fulfillment identity: your order id, one per thing you
451
460
  fulfill, created before checkout, kept across retries, never reused.
452
- OpenReceive never looks inside it, but `onPaid` runs once per reference, a new
461
+ OpenReceive never looks inside it, but `onPaid` commits fulfillment once per reference, a new
453
462
  checkout under a reference that already settled is refused with 409, and a
454
463
  fresh id per page load lets one order be paid twice.
455
464
 
@@ -1,6 +1,6 @@
1
1
  # OpenReceive agent directions (Next.js)
2
2
 
3
- These directions describe OpenReceive 0.4.9.
3
+ These directions describe OpenReceive 0.4.11.
4
4
 
5
5
  Add OpenReceive to a Next.js App Router application — the app you are already
6
6
  working in. You do not need a copy of the OpenReceive source: the packages are
@@ -109,7 +109,7 @@ itself, and they hold for every integration.
109
109
  payer-supplied amounts.
110
110
  - `authorize` runs on every request, and the `resource` it receives is a CLAIM
111
111
  the payer made, not proof. Read a framework session; never trust a body field.
112
- - `onPaid` must be idempotent. It runs once per `reference` — your order id, one
112
+ - `onPaid` must be idempotent. Its database fulfillment commits once per `reference` — your order id, one
113
113
  per thing you fulfill, created before checkout, kept across retries, never
114
114
  reused. A fresh id per page load lets one order be paid twice.
115
115
  - Receive-only NWC is required; a spend-capable code fails closed at boot unless
@@ -217,6 +217,13 @@ components.
217
217
  - `createSwapDisplayModel` → `display.copyRows` for deposits: address, memo,
218
218
  and the bare amount each get a copy row. Render `swap.networkWarning*` as
219
219
  the model gives it.
220
+ - `swap.deposit_amount` is the only amount a payer is told to send. Never put
221
+ a fiat valuation of it (`swap.fee.pay_in_fiat`) next to a stablecoin amount:
222
+ "$50.03" under "50.05 USDC" reads as a typo, and the payer asks which one to
223
+ send. The one fiat figure on a USDT/USDC deposit panel is the cart total
224
+ (`payout_fiat`); express "you send" and the fee in the token. Use
225
+ `createSwapFeeBreakdown(fee, swap)` — with the swap, not the fee alone — and
226
+ it applies this for you; SOL and ETH keep a fiat breakdown.
220
227
  - `createCheckoutSession` owns mint and swap start. To start swaps, pass its
221
228
  `swap` option (`selection`, `prefix`, `fetch`) together. Without it
222
229
  `startSwap` reports through `onError`.
@@ -283,6 +290,8 @@ enough; drop the `.md` for the same page a person would read.
283
290
  Questions, or a problem with the library itself:
284
291
  https://openreceive.org/contact
285
292
 
293
+ - https://openreceive.org/guides/payment-safety-upgrade.md — coordinated upgrades and reviewed repair of existing attempts
294
+
286
295
  ---
287
296
 
288
297
  ## The quickstart, in full
@@ -489,7 +498,7 @@ the `reference`. OpenReceive never prices from payer input.
489
498
  The `reference` is a string you choose, and it is the fulfillment identity:
490
499
  your order id — one per thing you fulfill, created before checkout, kept
491
500
  across retries, never reused. OpenReceive never looks inside it, but `onPaid`
492
- runs once per reference, a new checkout under a reference that already
501
+ commits fulfillment once per reference, a new checkout under a reference that already
493
502
  settled is refused with 409, and a fresh id per page load lets one order be
494
503
  paid twice.
495
504
 
@@ -569,7 +578,7 @@ Content-Security-Policy has a strict `img-src`, allow `data:`
569
578
  ([Provider registry](https://openreceive.org/guides/provider-registry.md#assets)).
570
579
 
571
580
  That is the whole loop: your server owns the price and the order, the payer gets
572
- an invoice, and `onPaid` runs once inside the settlement transaction.
581
+ an invoice, and `onPaid` runs inside the settlement transaction. Rolled-back transactions may retry the callback; use a host outbox for external delivery.
573
582
 
574
583
  A runnable illustration of this boundary — not a template to copy models from —
575
584
  is Buy a Button
@@ -1,6 +1,6 @@
1
1
  # OpenReceive agent directions (Node.js)
2
2
 
3
- These directions describe OpenReceive 0.4.9.
3
+ These directions describe OpenReceive 0.4.11.
4
4
 
5
5
  Add OpenReceive to a Node application — the app you are already working in. You
6
6
  do not need a copy of the OpenReceive source: the packages are on npm, and the
@@ -104,7 +104,7 @@ itself, and they hold for every integration.
104
104
  payer-supplied amounts.
105
105
  - `authorize` runs on every request, and the `resource` it receives is a CLAIM
106
106
  the payer made, not proof. Read a framework session; never trust a body field.
107
- - `onPaid` must be idempotent. It runs once per `reference` — your order id, one
107
+ - `onPaid` must be idempotent. Its database fulfillment commits once per `reference` — your order id, one
108
108
  per thing you fulfill, created before checkout, kept across retries, never
109
109
  reused. A fresh id per page load lets one order be paid twice.
110
110
  - Receive-only NWC is required; a spend-capable code fails closed at boot unless
@@ -203,6 +203,13 @@ components.
203
203
  - `createSwapDisplayModel` → `display.copyRows` for deposits: address, memo,
204
204
  and the bare amount each get a copy row. Render `swap.networkWarning*` as
205
205
  the model gives it.
206
+ - `swap.deposit_amount` is the only amount a payer is told to send. Never put
207
+ a fiat valuation of it (`swap.fee.pay_in_fiat`) next to a stablecoin amount:
208
+ "$50.03" under "50.05 USDC" reads as a typo, and the payer asks which one to
209
+ send. The one fiat figure on a USDT/USDC deposit panel is the cart total
210
+ (`payout_fiat`); express "you send" and the fee in the token. Use
211
+ `createSwapFeeBreakdown(fee, swap)` — with the swap, not the fee alone — and
212
+ it applies this for you; SOL and ETH keep a fiat breakdown.
206
213
  - `createCheckoutSession` owns mint and swap start. To start swaps, pass its
207
214
  `swap` option (`selection`, `prefix`, `fetch`) together. Without it
208
215
  `startSwap` reports through `onError`.
@@ -269,6 +276,8 @@ enough; drop the `.md` for the same page a person would read.
269
276
  Questions, or a problem with the library itself:
270
277
  https://openreceive.org/contact
271
278
 
279
+ - https://openreceive.org/guides/payment-safety-upgrade.md — coordinated upgrades and reviewed repair of existing attempts
280
+
272
281
  ---
273
282
 
274
283
  ## The quickstart, in full
@@ -447,7 +456,7 @@ the `reference`. OpenReceive never prices from payer input.
447
456
  The `reference` is a string you choose, and it is the fulfillment identity:
448
457
  your order id — one per thing you fulfill, created before checkout, kept
449
458
  across retries, never reused. OpenReceive never looks inside it, but `onPaid`
450
- runs once per reference, a new checkout under a reference that already
459
+ commits fulfillment once per reference, a new checkout under a reference that already
451
460
  settled is refused with 409, and a fresh id per page load lets one order be
452
461
  paid twice.
453
462
 
@@ -496,7 +505,7 @@ Content-Security-Policy has a strict `img-src`, allow `data:`
496
505
  ([Provider registry](https://openreceive.org/guides/provider-registry.md#assets)).
497
506
 
498
507
  That is the whole loop: your server owns the price and the order, the payer gets
499
- an invoice, and `onPaid` runs once inside the settlement transaction.
508
+ an invoice, and `onPaid` runs inside the settlement transaction. Rolled-back transactions may retry the callback; use a host outbox for external delivery.
500
509
 
501
510
  A runnable illustration of this boundary — not a template to copy models from —
502
511
  is Buy a Button
@@ -1,6 +1,6 @@
1
1
  # OpenReceive agent directions (PHP)
2
2
 
3
- These directions describe OpenReceive 0.4.9.
3
+ These directions describe OpenReceive 0.4.11.
4
4
 
5
5
  Add OpenReceive to a PHP application — the app you are already working in. You
6
6
  do not need a copy of the OpenReceive source: the engine is on Packagist
@@ -125,7 +125,7 @@ itself, and they hold for every integration.
125
125
  is a placeholder that allows everything (the engine warns at boot while a
126
126
  host uses it) — replace it with this app's real ownership check, same as
127
127
  `onPaid`'s `Hosts\LoggingOnPaid`.
128
- - `onPaid` must be idempotent. It runs once per `reference` — your order id, one
128
+ - `onPaid` must be idempotent. Its database fulfillment commits once per `reference` — your order id, one
129
129
  per thing you fulfill, created before checkout, kept across retries, never
130
130
  reused. A fresh id per page load lets one order be paid twice.
131
131
  - Receive-only NWC is required; a spend-capable code fails closed at boot unless
@@ -229,6 +229,13 @@ of https://openreceive.org/guides/checkout-ux.md, for a UI built on
229
229
  - `createSwapDisplayModel` → `display.copyRows` for deposits: address, memo,
230
230
  and the bare amount each get a copy row. Render `swap.networkWarning*` as
231
231
  the model gives it.
232
+ - `swap.deposit_amount` is the only amount a payer is told to send. Never put
233
+ a fiat valuation of it (`swap.fee.pay_in_fiat`) next to a stablecoin amount:
234
+ "$50.03" under "50.05 USDC" reads as a typo, and the payer asks which one to
235
+ send. The one fiat figure on a USDT/USDC deposit panel is the cart total
236
+ (`payout_fiat`); express "you send" and the fee in the token. Use
237
+ `createSwapFeeBreakdown(fee, swap)` — with the swap, not the fee alone — and
238
+ it applies this for you; SOL and ETH keep a fiat breakdown.
232
239
  - `createCheckoutSession` owns mint and swap start. To start swaps, pass its
233
240
  `swap` option (`selection`, `prefix`, `fetch`) together. Without it
234
241
  `startSwap` reports through `onError`.
@@ -294,6 +301,8 @@ enough; drop the `.md` for the same page a person would read.
294
301
  Questions, or a problem with the library itself:
295
302
  https://openreceive.org/contact
296
303
 
304
+ - https://openreceive.org/guides/payment-safety-upgrade.md — coordinated upgrades and reviewed repair of existing attempts
305
+
297
306
  ---
298
307
 
299
308
  ## The quickstart, in full
@@ -505,7 +514,7 @@ prices with exact decimal math, and returns the order id the page will pass as
505
514
  the `reference`. OpenReceive never prices from payer input. The `reference` is
506
515
  a string you choose, and it is the fulfillment identity: your order id — one
507
516
  per thing you fulfill, created before checkout, kept across retries, never
508
- reused. `onPaid` runs once per reference, a new checkout under a reference
517
+ reused. `onPaid` commits fulfillment once per reference, a new checkout under a reference
509
518
  that already settled is refused with 409, and a fresh id per page load lets
510
519
  one order be paid twice.
511
520
 
@@ -1,6 +1,6 @@
1
1
  # OpenReceive agent directions (Rails)
2
2
 
3
- These directions describe OpenReceive 0.4.9.
3
+ These directions describe OpenReceive 0.4.11.
4
4
 
5
5
  Add OpenReceive to a Rails application — the app you are already working in. You
6
6
  do not need a copy of the OpenReceive source: the gem is on RubyGems, the
@@ -116,7 +116,7 @@ itself, and they hold for every integration.
116
116
  body field. The generator installs `OpenReceive::ALLOW_ALL_AUTHORIZE`, a
117
117
  placeholder that allows everything (the engine warns at boot while it is
118
118
  set) — replace it with this app's real ownership check, same as `on_paid`.
119
- - `config.on_paid` must be idempotent. It runs once per `reference` — your order
119
+ - `config.on_paid` must be idempotent. Its database fulfillment commits once per `reference` — your order
120
120
  id, one per thing you fulfill, created before checkout, kept across retries,
121
121
  never reused. A fresh id per page load lets one order be paid twice.
122
122
  - Receive-only NWC is required; a spend-capable code fails closed at boot unless
@@ -210,6 +210,13 @@ built on `@openreceive/browser/headless`. Read that before writing components.
210
210
  - `createSwapDisplayModel` → `display.copyRows` for deposits: address, memo,
211
211
  and the bare amount each get a copy row. Render `swap.networkWarning*` as
212
212
  the model gives it.
213
+ - `swap.deposit_amount` is the only amount a payer is told to send. Never put
214
+ a fiat valuation of it (`swap.fee.pay_in_fiat`) next to a stablecoin amount:
215
+ "$50.03" under "50.05 USDC" reads as a typo, and the payer asks which one to
216
+ send. The one fiat figure on a USDT/USDC deposit panel is the cart total
217
+ (`payout_fiat`); express "you send" and the fee in the token. Use
218
+ `createSwapFeeBreakdown(fee, swap)` — with the swap, not the fee alone — and
219
+ it applies this for you; SOL and ETH keep a fiat breakdown.
213
220
  - `createCheckoutSession` owns mint and swap start. To start swaps, pass its
214
221
  `swap` option (`selection`, `prefix`, `fetch`) together. Without it
215
222
  `startSwap` reports through `onError`.
@@ -278,6 +285,8 @@ enough; drop the `.md` for the same page a person would read.
278
285
  Questions, or a problem with the library itself:
279
286
  https://openreceive.org/contact
280
287
 
288
+ - https://openreceive.org/guides/payment-safety-upgrade.md — coordinated upgrades and reviewed repair of existing attempts
289
+
281
290
  ---
282
291
 
283
292
  ## The quickstart, in full
@@ -425,7 +434,7 @@ The initializer needs three things: authorization, the trusted price, and
425
434
  fulfillment. All three receive the `reference` — a string you choose, and the
426
435
  fulfillment identity: your order id, one per thing you fulfill, created before
427
436
  checkout, kept across retries, never reused. OpenReceive never looks inside
428
- it, but `on_paid` runs once per reference, a new checkout under a reference
437
+ it, but `on_paid` commits fulfillment once per reference, a new checkout under a reference
429
438
  that already settled is refused with 409, and a fresh id per page load lets
430
439
  one order be paid twice.
431
440
 
@@ -1,6 +1,6 @@
1
1
  # OpenReceive agent directions (WordPress + WooCommerce)
2
2
 
3
- These directions describe OpenReceive 0.4.9.
3
+ These directions describe OpenReceive 0.4.11.
4
4
 
5
5
  Install and configure the OpenReceive gateway in the existing WooCommerce
6
6
  store. Preserve its theme, checkout, customer accounts, order model and prices.
@@ -73,6 +73,8 @@ flows; a receive-only NWC wallet cannot send payments.
73
73
  - [Agent Directions: BTCPay Server](https://openreceive.org/guides/agent-directions-btcpay.md)
74
74
  - [WordPress + WooCommerce Quickstart](https://openreceive.org/guides/quickstart-woocommerce.md)
75
75
 
76
+ - https://openreceive.org/guides/payment-safety-upgrade.md — coordinated upgrades and reviewed repair of existing attempts
77
+
76
78
  ---
77
79
 
78
80
  ## The quickstart, in full