OpenReceive Files

OpenReceive 0.4.20 fixes two checkout bugs found while testing on Replit. In apps styled with Tailwind v4 (Replit Agent, v0 and Lovable all build this way) the stablecoin network picker never opened, so a payer could not pay with USDT or USDC. And Start over on an expired invoice did nothing unless the host passed onStartOver. Upgrade if your checkout runs in a Tailwind app.

Optional swaps let payers use USDT, USDC, SOL and ETH; a configured swap provider converts them to BTC over Lightning in the merchant's connected wallet. Asset and network availability depends on the provider.

• Fixed: in an app styled with Tailwind v4, the stablecoin network picker never opened. The payer clicked USDT or USDC and nothing happened. The host's own .hidden{display:none} sat in the same utilities cascade layer as the checkout's sheet, loaded after it, and had the same specificity, so it beat the checkout's container-query rule that shows the picker. Replit Agent, v0 and Lovable all build apps this way; the Express and WordPress shops have no Tailwind. Inside the checkout's root, the shipped styles.css now scopes rules with [data-openreceive-root] instead of :where([data-openreceive-root]): one attribute of specificity, so a host utility of the same name cannot rearrange the checkout. On the root element itself nothing changed, so --root-bg and padding overrides work as before. The picker also no longer carries a bare hidden class, so an unlayered host .hidden (Tailwind v3, Bootstrap 3's !important) cannot hide it either. A new browser test loads a Tailwind v4 host sheet, compiled from every class the checkout uses, after the checkout's own and expects no layout change and a working USDT network step. Computed styles in the demo shop are unchanged: 0 differences across 1.8 million values in 16 states (React and Vue, light and dark, desktop and phone width).

• Fixed: Start over on an expired invoice did nothing unless the host passed onStartOver, and no agent direction mentioned it. A payer who came back to an expired QR had to think of reloading the page. Now a checkout created from a reference (React <Checkout>, <openreceive-checkout>, and the Vue, Svelte and Angular wrappers) prepares the same order again by itself. It does not reopen the expired attempt. A host onStartOver still replaces the default. On the element, openreceive-start-over is now cancelable; a raw listener that wants to replace the default calls event.preventDefault(). A React snapshot-mode checkout with no handler no longer shows a dead button.

• New recipe: TanStack Start. A server route under /openreceive/ loads a .server.ts handler over createStack, and the page uses <Checkout> from @openreceive/react. Because of Cloudflare Workers, each request builds and closes its own pool and stack. Checked with an app built by Lovable's Vite config (cloudflare-module, Node compatibility) and run under workerd with a real wallet. The page rendered on the server, and in Chromium the Bitcoin option showed a real invoice. The routes answered: invoice 201, the same invoice on retry, prepare and payments/check 200, a stranger 403. The Next.js directions link it.

• New guide: Bitcoin checkout with Supabase, for Node and Python servers. It covers the transaction pooler for the app and the session pooler for migrations, and trusting Supabase's own certificate authority. pg reads sslmode=require as verify-full and fails with "self-signed certificate in certificate chain", and that includes the POSTGRES_URL that Vercel's Supabase integration sets. The guide also locks OpenReceive's tables away from the Data API. On Supabase's image, new public tables were readable and writable with the anon key until row level security was on and the grants were revoked. Last, Supabase Auth in authorize. The Node and Python directions link it. Not yet tested against a live Supabase project.

• examples/next-postgres-starter no longer offers Supabase's POSTGRES_URL as a fallback. pg refuses it without Supabase's certificate authority, and the Supabase guide shows that setup.

• CI: a Cloudflare Workers lane (npm run test:workers). A Worker runs under wrangler dev with Node compatibility, the runtime of Lovable's TanStack Start apps. It reaches a fake receive-only wallet over a TLS relay, and PostgreSQL through PgBouncer in transaction mode. It checks four things: an invoice for the buyer, a refusal for a stranger, one live attempt under concurrent creates, and settlement with onPaid. On Workers, the database pool and the wallet connection must be built inside each request and closed before it ends. A stack in module scope is refused its wallet check at import, and its sockets hang on a later request.

• New guide: Bitcoin checkout on Replit, with screenshots of a real run on Replit: Secrets first, then one prompt for Replit Agent that fetches the Express directions, Power mode (Free mode stops partway), and publishing on Autoscale with the Secrets linked to the published app. Replit moves from planned to Tested on /platforms/replit.

• New: examples/express-postgres-starter, a one-product Express shop on Postgres for Replit, with a .replit for Autoscale and a replit.md for Replit Agent. No build step: the server sends the standalone checkout straight from @openreceive/elements. Checked against Postgres 16 with the published 0.4.19 packages and a real wallet: a buyer's order got an invoice, and a stranger and another visitor were refused.
• Directions eval: a replit platform. The shop is Express on Postgres 16, and the codes are the app's Secrets. Replit has no deploy API, so the harness plays a publish locally: an empty production database, a rebuild, a restart, then the live checks the Vercel eval uses (now shared in harness/live.ts). A local pass does not earn a Tested badge.
• The Vercel and v0 guide has screenshots, from a real run of both paths: the starter's Deploy button (repository, Neon, NWC_URI), v0's Import from GitHub and its connection to the existing project, and adding checkout to a plain v0 shop with the guide's prompt (v0 finished in about five minutes; the checkout issued a real invoice). Corrected from the run: v0's Environment Variables panel now only links to Vercel, where the codes are added as Secrets for all three environments; the Deploy button already sets NWC_URI for Development; and v0's preview pane can drop the shop's cookie, so the guide tests checkout in a new tab.
• Directions eval, Vercel and Replit: no file in the test shop names the platform's variables any more. In three Replit runs the agent found the codes unset in its own shell, followed compose.yml to the variables file and listed it. They now load through a Compose override beside the shop that COMPOSE_FILE merges into every docker compose, the agent's included. Reading either file still fails the run.
• Site contract v8: platform pages and Tested badges. docs/site/platforms.json lists where people build and host apps: Vercel and v0 now, with Replit, Lovable and Supabase planned. The contract publishes the rows as platforms[] for a /platforms index and one /platforms/<id> page each. Every framework row gains tested: the date and release of its latest passing live eval, from the new evals/directions/passed.json. For an AI builder the copied prompt is the guide's platform-prompt block, which the eval also sends, so the published prompt is the tested one. docs/internal/site-build.md has the layout.
• The Vercel and v0 guide moved from /guides/v0 to /guides/vercel, with 301 redirects for the page and its markdown twin. New guide: How we test platforms, what a Tested badge means and what it does not.
• Directions eval: a vercel platform. The shop is Next.js on Postgres, and the codes are project variables the agent must not ask for. After the agent finishes, the harness deploys the result to Vercel and checks the live site: a real invoice for the buyer, a refusal for a stranger. It passed 21 of 21 checks on 0.4.19. The harness now refuses a truncated NWC code before it starts a run.
• Release tooling: the Composer publish pushes both split repositories before it waits for Packagist, and waits up to 20 minutes for each. In 0.4.19 Packagist took longer than the old 10-minute wait, so the job failed after publishing.