@openreceive/node 0.4.5 → 0.4.8
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/README.md +44 -1
- package/package.json +3 -3
- package/skills/integrate-openreceive/references/btcpay.md +1 -1
- package/skills/integrate-openreceive/references/django.md +20 -6
- package/skills/integrate-openreceive/references/fastapi.md +20 -6
- package/skills/integrate-openreceive/references/fastify.md +20 -6
- package/skills/integrate-openreceive/references/laravel.md +20 -6
- package/skills/integrate-openreceive/references/next.md +20 -6
- package/skills/integrate-openreceive/references/node.md +20 -6
- package/skills/integrate-openreceive/references/php.md +20 -6
- package/skills/integrate-openreceive/references/rails.md +20 -6
- package/skills/integrate-openreceive/references/woocommerce.md +24 -1
package/README.md
CHANGED
|
@@ -1,7 +1,50 @@
|
|
|
1
1
|
# @openreceive/node
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
Accept Bitcoin Lightning payments directly into a wallet you control from
|
|
4
|
+
your Node.js application. This package connects to your receive-only Nostr
|
|
5
|
+
Wallet Connect (NWC) wallet, creates invoices, checks settlement, and provides
|
|
6
|
+
the swap service and command-line tools.
|
|
7
|
+
|
|
8
|
+
OpenReceive supports optional swaps from **USDT, USDC, SOL, and ETH** through
|
|
9
|
+
a configured swap provider. The provider converts the payment to **BTC over
|
|
10
|
+
Lightning**, which settles into the merchant's connected wallet. Available
|
|
11
|
+
assets and networks depend on the provider; swaps are optional.
|
|
12
|
+
|
|
13
|
+
## Install
|
|
4
14
|
|
|
5
15
|
This package is ESM-only and requires Node >= 22.
|
|
6
16
|
|
|
17
|
+
```sh
|
|
18
|
+
npm install @openreceive/node
|
|
19
|
+
```
|
|
20
|
+
|
|
21
|
+
Start with the [integration quickstart](https://github.com/openreceive/openreceive/blob/master/docs/guides/quickstart-node.md)
|
|
22
|
+
and the [payment storage guide](https://github.com/openreceive/openreceive/blob/master/docs/guides/storage.md).
|
|
23
|
+
|
|
7
24
|
Part of [OpenReceive](https://openreceive.org). Start with the [Node quickstart](https://github.com/openreceive/openreceive/blob/master/docs/guides/quickstart-node.md); the full API is in the [API reference](https://github.com/openreceive/openreceive/blob/master/docs/guides/api-reference.md).
|
|
25
|
+
|
|
26
|
+
## Choose your integration
|
|
27
|
+
|
|
28
|
+
For a web checkout, install `@openreceive/express`, `@openreceive/fastify`, or
|
|
29
|
+
`@openreceive/next`. They use this service and add payment persistence,
|
|
30
|
+
authorization, and mounted routes. For a custom Node.js host, compose the
|
|
31
|
+
service with `@openreceive/http`.
|
|
32
|
+
|
|
33
|
+
Use this package directly when you need the service or its types as part of
|
|
34
|
+
that integration. The service does not persist payment attempts on its own.
|
|
35
|
+
The normal HTTP integration records them in your existing database before
|
|
36
|
+
exposing payment instructions.
|
|
37
|
+
|
|
38
|
+
- **Connect your wallet:** set `NWC_URI` on the server to a receive-only NWC
|
|
39
|
+
connection. Startup checks reject spend-capable connections by default.
|
|
40
|
+
- **Enable optional swaps:** configure your provider through `LSC_URI_PRIMARY`
|
|
41
|
+
and optionally `LSC_URI_BACKUP`.
|
|
42
|
+
- **Keep your business logic:** the host controls orders, prices,
|
|
43
|
+
authorization, and fulfillment.
|
|
44
|
+
|
|
45
|
+
## Guides
|
|
46
|
+
|
|
47
|
+
- [Environment and wallet configuration](https://github.com/openreceive/openreceive/blob/master/docs/guides/environment-variables.md)
|
|
48
|
+
- [Optional swaps](https://github.com/openreceive/openreceive/blob/master/docs/guides/automated-swaps.md)
|
|
49
|
+
- [Test with a fake wallet](https://github.com/openreceive/openreceive/blob/master/docs/guides/host-testing.md)
|
|
50
|
+
- [Deploy and reconcile payments](https://github.com/openreceive/openreceive/blob/master/docs/guides/deploying.md)
|
package/package.json
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@openreceive/node",
|
|
3
|
-
"version": "0.4.
|
|
4
|
-
"description": "
|
|
3
|
+
"version": "0.4.8",
|
|
4
|
+
"description": "Accept Bitcoin Lightning payments in Node.js with your own wallet and optional USDT, USDC, SOL and ETH swaps.",
|
|
5
5
|
"keywords": [
|
|
6
6
|
"bitcoin",
|
|
7
7
|
"lightning",
|
|
@@ -17,7 +17,7 @@
|
|
|
17
17
|
"types": "./dist/index.d.ts",
|
|
18
18
|
"dependencies": {
|
|
19
19
|
"@getalby/sdk": "^8.0.3",
|
|
20
|
-
"@openreceive/core": "0.4.
|
|
20
|
+
"@openreceive/core": "0.4.8"
|
|
21
21
|
},
|
|
22
22
|
"bin": {
|
|
23
23
|
"openreceive": "./bin/openreceive.mjs"
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
# OpenReceive agent directions (BTCPay Server)
|
|
2
2
|
|
|
3
|
-
These directions describe OpenReceive 0.4.
|
|
3
|
+
These directions describe OpenReceive 0.4.8.
|
|
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
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
# OpenReceive agent directions (Django)
|
|
2
2
|
|
|
3
|
-
These directions describe OpenReceive 0.4.
|
|
3
|
+
These directions describe OpenReceive 0.4.8.
|
|
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
|
|
@@ -245,11 +245,25 @@ built on `@openreceive/browser/headless`. Read that before writing components.
|
|
|
245
245
|
"switch payment method".
|
|
246
246
|
- No "Open wallet" button on desktop.
|
|
247
247
|
- Wallet suggestions: `getPaymentWizardRoutes()` +
|
|
248
|
-
`createWizardRouteDisplays`. Lightning only.
|
|
249
|
-
|
|
250
|
-
|
|
251
|
-
|
|
252
|
-
|
|
248
|
+
`createWizardRouteDisplays`. Lightning only. Logos are data URIs; tutorial
|
|
249
|
+
images load from a JavaScript chunk. For a custom headless UI, load it when
|
|
250
|
+
a tutorial opens and look up the returned table by the tutorial's `path`:
|
|
251
|
+
|
|
252
|
+
```js
|
|
253
|
+
import { loadPayTutorialImages } from "@openreceive/browser/headless";
|
|
254
|
+
|
|
255
|
+
const images = await loadPayTutorialImages();
|
|
256
|
+
const src = images[tutorial.path]; // data URI for the selected tutorial
|
|
257
|
+
```
|
|
258
|
+
|
|
259
|
+
Render `src` as the image source and update your UI after loading. Existing
|
|
260
|
+
display objects do not update: their `tutorial.image` stays `undefined` if
|
|
261
|
+
created before loading. Alternatively, await the loader, recreate the displays
|
|
262
|
+
with `createWizardRouteDisplays`, and render the new `tutorial.image`.
|
|
263
|
+
Show the caption while loading or if loading fails; never use an empty image
|
|
264
|
+
source. Deploy all JavaScript chunks and allow `data:` in CSP `img-src`.
|
|
265
|
+
For missing images, check CSP errors, failed chunks, and stale displays.
|
|
266
|
+
Registry paths are lookup keys; there is no asset option or image route.
|
|
253
267
|
The registry answers ~37 wallets: pass
|
|
254
268
|
`providerPreviewLimit` and build "show all" from `display.providerCount`,
|
|
255
269
|
or they push the QR off the screen.
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
# OpenReceive agent directions (FastAPI)
|
|
2
2
|
|
|
3
|
-
These directions describe OpenReceive 0.4.
|
|
3
|
+
These directions describe OpenReceive 0.4.8.
|
|
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
|
|
@@ -242,11 +242,25 @@ components.
|
|
|
242
242
|
"switch payment method".
|
|
243
243
|
- No "Open wallet" button on desktop.
|
|
244
244
|
- Wallet suggestions: `getPaymentWizardRoutes()` +
|
|
245
|
-
`createWizardRouteDisplays`. Lightning only.
|
|
246
|
-
|
|
247
|
-
|
|
248
|
-
|
|
249
|
-
|
|
245
|
+
`createWizardRouteDisplays`. Lightning only. Logos are data URIs; tutorial
|
|
246
|
+
images load from a JavaScript chunk. For a custom headless UI, load it when
|
|
247
|
+
a tutorial opens and look up the returned table by the tutorial's `path`:
|
|
248
|
+
|
|
249
|
+
```js
|
|
250
|
+
import { loadPayTutorialImages } from "@openreceive/browser/headless";
|
|
251
|
+
|
|
252
|
+
const images = await loadPayTutorialImages();
|
|
253
|
+
const src = images[tutorial.path]; // data URI for the selected tutorial
|
|
254
|
+
```
|
|
255
|
+
|
|
256
|
+
Render `src` as the image source and update your UI after loading. Existing
|
|
257
|
+
display objects do not update: their `tutorial.image` stays `undefined` if
|
|
258
|
+
created before loading. Alternatively, await the loader, recreate the displays
|
|
259
|
+
with `createWizardRouteDisplays`, and render the new `tutorial.image`.
|
|
260
|
+
Show the caption while loading or if loading fails; never use an empty image
|
|
261
|
+
source. Deploy all JavaScript chunks and allow `data:` in CSP `img-src`.
|
|
262
|
+
For missing images, check CSP errors, failed chunks, and stale displays.
|
|
263
|
+
Registry paths are lookup keys; there is no asset option or image route.
|
|
250
264
|
|
|
251
265
|
## More documentation
|
|
252
266
|
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
# OpenReceive agent directions (Fastify)
|
|
2
2
|
|
|
3
|
-
These directions describe OpenReceive 0.4.
|
|
3
|
+
These directions describe OpenReceive 0.4.8.
|
|
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
|
|
@@ -225,11 +225,25 @@ components.
|
|
|
225
225
|
"switch payment method".
|
|
226
226
|
- No "Open wallet" button on desktop.
|
|
227
227
|
- Wallet suggestions: `getPaymentWizardRoutes()` +
|
|
228
|
-
`createWizardRouteDisplays`. Lightning only.
|
|
229
|
-
|
|
230
|
-
|
|
231
|
-
|
|
232
|
-
|
|
228
|
+
`createWizardRouteDisplays`. Lightning only. Logos are data URIs; tutorial
|
|
229
|
+
images load from a JavaScript chunk. For a custom headless UI, load it when
|
|
230
|
+
a tutorial opens and look up the returned table by the tutorial's `path`:
|
|
231
|
+
|
|
232
|
+
```js
|
|
233
|
+
import { loadPayTutorialImages } from "@openreceive/browser/headless";
|
|
234
|
+
|
|
235
|
+
const images = await loadPayTutorialImages();
|
|
236
|
+
const src = images[tutorial.path]; // data URI for the selected tutorial
|
|
237
|
+
```
|
|
238
|
+
|
|
239
|
+
Render `src` as the image source and update your UI after loading. Existing
|
|
240
|
+
display objects do not update: their `tutorial.image` stays `undefined` if
|
|
241
|
+
created before loading. Alternatively, await the loader, recreate the displays
|
|
242
|
+
with `createWizardRouteDisplays`, and render the new `tutorial.image`.
|
|
243
|
+
Show the caption while loading or if loading fails; never use an empty image
|
|
244
|
+
source. Deploy all JavaScript chunks and allow `data:` in CSP `img-src`.
|
|
245
|
+
For missing images, check CSP errors, failed chunks, and stale displays.
|
|
246
|
+
Registry paths are lookup keys; there is no asset option or image route.
|
|
233
247
|
|
|
234
248
|
## More documentation
|
|
235
249
|
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
# OpenReceive agent directions (Laravel)
|
|
2
2
|
|
|
3
|
-
These directions describe OpenReceive 0.4.
|
|
3
|
+
These directions describe OpenReceive 0.4.8.
|
|
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
|
|
@@ -230,11 +230,25 @@ built on `@openreceive/browser/headless`. Read that before writing components.
|
|
|
230
230
|
"switch payment method".
|
|
231
231
|
- No "Open wallet" button on desktop.
|
|
232
232
|
- Wallet suggestions: `getPaymentWizardRoutes()` +
|
|
233
|
-
`createWizardRouteDisplays`. Lightning only.
|
|
234
|
-
|
|
235
|
-
|
|
236
|
-
|
|
237
|
-
|
|
233
|
+
`createWizardRouteDisplays`. Lightning only. Logos are data URIs; tutorial
|
|
234
|
+
images load from a JavaScript chunk. For a custom headless UI, load it when
|
|
235
|
+
a tutorial opens and look up the returned table by the tutorial's `path`:
|
|
236
|
+
|
|
237
|
+
```js
|
|
238
|
+
import { loadPayTutorialImages } from "@openreceive/browser/headless";
|
|
239
|
+
|
|
240
|
+
const images = await loadPayTutorialImages();
|
|
241
|
+
const src = images[tutorial.path]; // data URI for the selected tutorial
|
|
242
|
+
```
|
|
243
|
+
|
|
244
|
+
Render `src` as the image source and update your UI after loading. Existing
|
|
245
|
+
display objects do not update: their `tutorial.image` stays `undefined` if
|
|
246
|
+
created before loading. Alternatively, await the loader, recreate the displays
|
|
247
|
+
with `createWizardRouteDisplays`, and render the new `tutorial.image`.
|
|
248
|
+
Show the caption while loading or if loading fails; never use an empty image
|
|
249
|
+
source. Deploy all JavaScript chunks and allow `data:` in CSP `img-src`.
|
|
250
|
+
For missing images, check CSP errors, failed chunks, and stale displays.
|
|
251
|
+
Registry paths are lookup keys; there is no asset option or image route.
|
|
238
252
|
The registry answers ~37 wallets: pass
|
|
239
253
|
`providerPreviewLimit` and build "show all" from `display.providerCount`,
|
|
240
254
|
or they push the QR off the screen.
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
# OpenReceive agent directions (Next.js)
|
|
2
2
|
|
|
3
|
-
These directions describe OpenReceive 0.4.
|
|
3
|
+
These directions describe OpenReceive 0.4.8.
|
|
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
|
|
@@ -231,11 +231,25 @@ components.
|
|
|
231
231
|
"switch payment method".
|
|
232
232
|
- No "Open wallet" button on desktop.
|
|
233
233
|
- Wallet suggestions: `getPaymentWizardRoutes()` +
|
|
234
|
-
`createWizardRouteDisplays`. Lightning only.
|
|
235
|
-
|
|
236
|
-
|
|
237
|
-
|
|
238
|
-
|
|
234
|
+
`createWizardRouteDisplays`. Lightning only. Logos are data URIs; tutorial
|
|
235
|
+
images load from a JavaScript chunk. For a custom headless UI, load it when
|
|
236
|
+
a tutorial opens and look up the returned table by the tutorial's `path`:
|
|
237
|
+
|
|
238
|
+
```js
|
|
239
|
+
import { loadPayTutorialImages } from "@openreceive/browser/headless";
|
|
240
|
+
|
|
241
|
+
const images = await loadPayTutorialImages();
|
|
242
|
+
const src = images[tutorial.path]; // data URI for the selected tutorial
|
|
243
|
+
```
|
|
244
|
+
|
|
245
|
+
Render `src` as the image source and update your UI after loading. Existing
|
|
246
|
+
display objects do not update: their `tutorial.image` stays `undefined` if
|
|
247
|
+
created before loading. Alternatively, await the loader, recreate the displays
|
|
248
|
+
with `createWizardRouteDisplays`, and render the new `tutorial.image`.
|
|
249
|
+
Show the caption while loading or if loading fails; never use an empty image
|
|
250
|
+
source. Deploy all JavaScript chunks and allow `data:` in CSP `img-src`.
|
|
251
|
+
For missing images, check CSP errors, failed chunks, and stale displays.
|
|
252
|
+
Registry paths are lookup keys; there is no asset option or image route.
|
|
239
253
|
|
|
240
254
|
## More documentation
|
|
241
255
|
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
# OpenReceive agent directions (Node.js)
|
|
2
2
|
|
|
3
|
-
These directions describe OpenReceive 0.4.
|
|
3
|
+
These directions describe OpenReceive 0.4.8.
|
|
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
|
|
@@ -217,11 +217,25 @@ components.
|
|
|
217
217
|
"switch payment method".
|
|
218
218
|
- No "Open wallet" button on desktop.
|
|
219
219
|
- Wallet suggestions: `getPaymentWizardRoutes()` +
|
|
220
|
-
`createWizardRouteDisplays`. Lightning only.
|
|
221
|
-
|
|
222
|
-
|
|
223
|
-
|
|
224
|
-
|
|
220
|
+
`createWizardRouteDisplays`. Lightning only. Logos are data URIs; tutorial
|
|
221
|
+
images load from a JavaScript chunk. For a custom headless UI, load it when
|
|
222
|
+
a tutorial opens and look up the returned table by the tutorial's `path`:
|
|
223
|
+
|
|
224
|
+
```js
|
|
225
|
+
import { loadPayTutorialImages } from "@openreceive/browser/headless";
|
|
226
|
+
|
|
227
|
+
const images = await loadPayTutorialImages();
|
|
228
|
+
const src = images[tutorial.path]; // data URI for the selected tutorial
|
|
229
|
+
```
|
|
230
|
+
|
|
231
|
+
Render `src` as the image source and update your UI after loading. Existing
|
|
232
|
+
display objects do not update: their `tutorial.image` stays `undefined` if
|
|
233
|
+
created before loading. Alternatively, await the loader, recreate the displays
|
|
234
|
+
with `createWizardRouteDisplays`, and render the new `tutorial.image`.
|
|
235
|
+
Show the caption while loading or if loading fails; never use an empty image
|
|
236
|
+
source. Deploy all JavaScript chunks and allow `data:` in CSP `img-src`.
|
|
237
|
+
For missing images, check CSP errors, failed chunks, and stale displays.
|
|
238
|
+
Registry paths are lookup keys; there is no asset option or image route.
|
|
225
239
|
|
|
226
240
|
## More documentation
|
|
227
241
|
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
# OpenReceive agent directions (PHP)
|
|
2
2
|
|
|
3
|
-
These directions describe OpenReceive 0.4.
|
|
3
|
+
These directions describe OpenReceive 0.4.8.
|
|
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
|
|
@@ -243,11 +243,25 @@ of https://openreceive.org/guides/checkout-ux.md, for a UI built on
|
|
|
243
243
|
"switch payment method".
|
|
244
244
|
- No "Open wallet" button on desktop.
|
|
245
245
|
- Wallet suggestions: `getPaymentWizardRoutes()` +
|
|
246
|
-
`createWizardRouteDisplays`. Lightning only.
|
|
247
|
-
|
|
248
|
-
|
|
249
|
-
|
|
250
|
-
|
|
246
|
+
`createWizardRouteDisplays`. Lightning only. Logos are data URIs; tutorial
|
|
247
|
+
images load from a JavaScript chunk. For a custom headless UI, load it when
|
|
248
|
+
a tutorial opens and look up the returned table by the tutorial's `path`:
|
|
249
|
+
|
|
250
|
+
```js
|
|
251
|
+
import { loadPayTutorialImages } from "@openreceive/browser/headless";
|
|
252
|
+
|
|
253
|
+
const images = await loadPayTutorialImages();
|
|
254
|
+
const src = images[tutorial.path]; // data URI for the selected tutorial
|
|
255
|
+
```
|
|
256
|
+
|
|
257
|
+
Render `src` as the image source and update your UI after loading. Existing
|
|
258
|
+
display objects do not update: their `tutorial.image` stays `undefined` if
|
|
259
|
+
created before loading. Alternatively, await the loader, recreate the displays
|
|
260
|
+
with `createWizardRouteDisplays`, and render the new `tutorial.image`.
|
|
261
|
+
Show the caption while loading or if loading fails; never use an empty image
|
|
262
|
+
source. Deploy all JavaScript chunks and allow `data:` in CSP `img-src`.
|
|
263
|
+
For missing images, check CSP errors, failed chunks, and stale displays.
|
|
264
|
+
Registry paths are lookup keys; there is no asset option or image route.
|
|
251
265
|
|
|
252
266
|
## More documentation
|
|
253
267
|
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
# OpenReceive agent directions (Rails)
|
|
2
2
|
|
|
3
|
-
These directions describe OpenReceive 0.4.
|
|
3
|
+
These directions describe OpenReceive 0.4.8.
|
|
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
|
|
@@ -224,11 +224,25 @@ built on `@openreceive/browser/headless`. Read that before writing components.
|
|
|
224
224
|
"switch payment method".
|
|
225
225
|
- No "Open wallet" button on desktop.
|
|
226
226
|
- Wallet suggestions: `getPaymentWizardRoutes()` +
|
|
227
|
-
`createWizardRouteDisplays`. Lightning only.
|
|
228
|
-
|
|
229
|
-
|
|
230
|
-
|
|
231
|
-
|
|
227
|
+
`createWizardRouteDisplays`. Lightning only. Logos are data URIs; tutorial
|
|
228
|
+
images load from a JavaScript chunk. For a custom headless UI, load it when
|
|
229
|
+
a tutorial opens and look up the returned table by the tutorial's `path`:
|
|
230
|
+
|
|
231
|
+
```js
|
|
232
|
+
import { loadPayTutorialImages } from "@openreceive/browser/headless";
|
|
233
|
+
|
|
234
|
+
const images = await loadPayTutorialImages();
|
|
235
|
+
const src = images[tutorial.path]; // data URI for the selected tutorial
|
|
236
|
+
```
|
|
237
|
+
|
|
238
|
+
Render `src` as the image source and update your UI after loading. Existing
|
|
239
|
+
display objects do not update: their `tutorial.image` stays `undefined` if
|
|
240
|
+
created before loading. Alternatively, await the loader, recreate the displays
|
|
241
|
+
with `createWizardRouteDisplays`, and render the new `tutorial.image`.
|
|
242
|
+
Show the caption while loading or if loading fails; never use an empty image
|
|
243
|
+
source. Deploy all JavaScript chunks and allow `data:` in CSP `img-src`.
|
|
244
|
+
For missing images, check CSP errors, failed chunks, and stale displays.
|
|
245
|
+
Registry paths are lookup keys; there is no asset option or image route.
|
|
232
246
|
The registry answers ~37 wallets: pass
|
|
233
247
|
`providerPreviewLimit` and build "show all" from `display.providerCount`,
|
|
234
248
|
or they push the QR off the screen.
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
# OpenReceive agent directions (WordPress + WooCommerce)
|
|
2
2
|
|
|
3
|
-
These directions describe OpenReceive 0.4.
|
|
3
|
+
These directions describe OpenReceive 0.4.8.
|
|
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.
|
|
@@ -90,6 +90,29 @@ Requirements: WordPress 6.6+, WooCommerce 9+, 64-bit PHP 8.2+ with GMP and sodiu
|
|
|
90
90
|
and MySQL 8 or MariaDB 10.5+. Activation creates payment-attempt tables in the
|
|
91
91
|
existing WordPress database. No separate database or application is required.
|
|
92
92
|
|
|
93
|
+
### Get the installable archive
|
|
94
|
+
|
|
95
|
+
Use `openreceive-wordpress-<version>.zip` from the selected
|
|
96
|
+
[OpenReceive GitHub release](https://github.com/OpenReceive/openreceive/releases)
|
|
97
|
+
when that asset is listed. A GitHub source-code zip is not the plugin archive.
|
|
98
|
+
If the release does not yet provide a built zip, build it on a development
|
|
99
|
+
machine with Node 22+, PHP 8.2+, Composer and WP-CLI:
|
|
100
|
+
|
|
101
|
+
```sh
|
|
102
|
+
git clone https://github.com/OpenReceive/openreceive.git
|
|
103
|
+
cd openreceive
|
|
104
|
+
git checkout <release-tag>
|
|
105
|
+
npm ci
|
|
106
|
+
npm run build:packages
|
|
107
|
+
composer install --working-dir=packages/php/wordpress
|
|
108
|
+
npm run release:wordpress:build
|
|
109
|
+
```
|
|
110
|
+
|
|
111
|
+
Upload the resulting `dist/openreceive-wordpress-<version>.zip`. WP-CLI must be
|
|
112
|
+
on `PATH`, or set `OPENRECEIVE_WP_CLI` to the absolute path of its phar. The
|
|
113
|
+
WordPress server needs neither Node nor Composer: dependencies and checkout
|
|
114
|
+
assets are bundled inside the built plugin.
|
|
115
|
+
|
|
93
116
|
### Configure the wallet
|
|
94
117
|
|
|
95
118
|
Open **WooCommerce → Settings → Payments → OpenReceive**. Enter a receive-only
|