WebRTPay Publishes Experimental Package for Direct BSV Wallet Payments

Payments Infrastructure / Developer Tools

In Brief

WebRTPay has been published as an experimental package in the BSV TypeScript stack, giving wallet developers a way to deliver payment data through an encrypted connection between wallets.

The package, @bsv/webrtpay, uses WebRTC data channels and BRC-100 identity keys. Version 0.2.1 is available on npm, with further testing needed across browsers, real networks and wallet implementations.

News Report

The npm publication record shows WebRTPay version 0.2.0 arriving on October 19, 2026, at 18:15 UTC, followed by version 0.2.1 at 20:39 UTC.

The initial package contribution merged into the BSV TypeScript stack on October 18 UTC. The subsequent npm publication makes the experimental library available for developers to install.

What Travels Between Wallets

WebRTPay carries the payment data that PeerPay ordinarily delivers through MessageBox: an Atomic BEEF transaction package and the BRC-29 derivation information needed by the recipient.

Both wallets authenticate the connection using their identity keys before exchanging payment data. The documented flow establishes the connection before the payer creates and broadcasts the transaction.

The BSV Blockchain still receives the transaction through the wallet’s broadcasting process. WebRTPay supplies the channel for delivering the transaction package and associated information to the receiving wallet.

How Wallets Connect

The package supports an in-person exchange of two QR codes, carrying an offer and an answer. Remote connections can use MessageBox or a small relay to exchange the information needed to establish the channel.

Both wallets must be online for this direct exchange. Where network conditions prevent a direct connection, a TURN service can relay the encrypted traffic.

Version 0.2.0 added a presence check so the calling wallet can determine whether the recipient is available before completing connection setup. It also added live MessageBox signaling, with fallback handling when that route is unavailable.

Version 0.2.1 adds health and readiness endpoints for the standalone relay, together with configuration exports for server wrappers.

Payment Recovery and Testing Limits

An interrupted connection after broadcast can leave the recipient needing the payment’s derivation information. The documentation instructs applications to retain and redeliver the same payment token. A missing acknowledgment does not establish that the transaction failed.

The project reports tests using real WebRTC connections within a local environment and a local TURN server. Its verification notes leave browser-to-browser operation, traversal of real networks, production TURN services and a real MessageBox server unverified. The tests mock the wallet operation that records an incoming payment.

Receiving can also reveal a wallet’s IP address and online status. Signaling services can observe identity keys and connection metadata. The documentation recommends opt-in receiving and identifies a limitation in which disposable identities can occupy receiving slots.

BSV TIMES Read

WebRTPay gives developers another delivery path for payment data while retaining formats already used by the BSV wallet stack.

That could help applications offer a direct exchange when both participants are available, with MessageBox remaining useful for delivery and recovery.

The immediate milestone is a published experimental developer package. Broader usefulness will depend on testing across networks and wallets, reliable recovery after interrupted transfers, and clear controls over receiving and privacy.

Developer Context

Darren Kellenschwiler, known publicly as Deggen and using the GitHub account sirdeggen, authored the initial WebRTPay contribution and the version 0.2.0 and 0.2.1 pull requests.

His public npm profile identifies his name and GitHub handle, while his GitHub profile lists the BSV Association.

Source Links

Posted on October 20, 2026 (UTC)