A Bitcoin developer has presented a collection of tools aimed at making merchant payments easier to operate, combining checkout software with plugins for Electrum. The October 22 project discussion describes work developed over roughly two years, rather than a single newly launched payment service.
TL;DR: BareBits and the related plugins address invoices, connectivity and incoming Lightning capacity. Their convenience still comes with software, fee and custody decisions.
A checkout page is only one part of accepting Bitcoin
The developer describes an Electrum plugin using CLINK and Nostr to route payment requests without requiring the merchant to expose a router port or manually prepare each invoice. Other components cover swap services and liquidity management.
That addresses a practical mismatch: a merchant may want a simple checkout button, while the receiving wallet needs a way to accept the payment and communicate its result. Reducing the steps visible to a customer does not remove the underlying work; it moves more of it into software.
The BareBits repository describes a PHP gateway suitable for shared web hosting and a local Windows point-of-sale setup. It advertises compatibility with the BTCPay Greenfield API and a 1% fee for its self-installed gateway. Those are the project’s stated features, not independently tested performance or compatibility findings.
The documentation says its default design sends payments outside the checkout server’s control. An optional Cashu fallback changes that arrangement by holding smaller receipts at a mint until they are swept. It also says on-chain confirmation checks rely on block explorers.
These choices matter when comparing services. Running checkout code on a merchant’s own server does not answer every custody question, particularly when an optional payment route introduces another party or relies on external confirmation data.
Automating liquidity also delegates decisions
The accompanying Electrum liquidity plugin can manage channels and swaps to adjust receiving capacity. Its documentation warns that automatic mode can move funds without asking for confirmation and advises against using significant amounts during experimentation.
The plugin provides settings for targets, costs and limits. Their importance follows from the task itself: receiving Lightning payments consumes a particular side of a channel’s available capacity, while restoring that capacity can require another transaction and another fee.
Automation can reduce repeated manual work, but a badly chosen target or limit could still produce an unwanted result. The useful comparison is total operating cost and reliability, including swap charges, downtime and exception handling, rather than the apparent simplicity of the checkout screen.
The toolkit offers a specific approach for merchants willing to run and assess their own software. Its next test is operational evidence: dependable payment reconciliation, understandable failure states and clear records of how money moves between the available routes. The announcement establishes the proposed tools and their documented limits; it does not establish widespread merchant adoption.
Written by the News Desk and edited by Samuel Rae.