Go Wallet Toolbox v0.191.0 Adds Merchant Point-of-Sale Gateway

Payments Infrastructure Watch / Payments Infrastructure

In Brief

Go Wallet Toolbox v0.191.0 introduces a merchant point-of-sale gateway for BSV token payments, allowing approved cashiers to request and relay payments without holding the merchant’s private key.

The gateway signs invoices and receipts, checks payment amounts and destinations, and preserves submitted transactions to support recovery when payment handling is interrupted.

News Report

The Go Wallet Toolbox project published version 0.191.0 on October 16 at 17:51 UTC—October 17 in Thailand.

The release includes a merchant POS gateway contributed through pull request #1065, together with a dedicated container image. The image’s release workflow completed successfully for the version tag.

The gateway provides the merchant-side service behind the payment flow. Operators must supply the wallet storage, blockchain services and merchant identity needed to run it.

Cashier Access Without the Merchant’s Private Key

The merchant administrator can invite, approve and revoke cashiers.

An approved cashier can request a signed invoice and submit the corresponding customer payment. Each invoice is associated with that cashier’s identity, with a five-minute window for the initial payment submission.

The merchant can inspect all sales, while active cashiers can inspect their own.

The merchant’s private key stays on the gateway, supplied through the operator’s secret-management setup. It is not passed to cashier or customer devices.

This separates everyday payment collection from possession of the merchant’s signing key, while leaving the operator responsible for securing the gateway.

What a Signed Receipt Confirms

Before accepting a payment, the gateway derives the expected merchant output under BRC-29 and checks both its destination script and its exact amount.

It then submits the transaction to the merchant wallet through Go Wallet Toolbox. The configured wallet infrastructure handles transaction and script validation.

A signed receipt requires the wallet to report acceptance and the corresponding action to have an unproven or completed status. A pending broadcast or wallet refusal does not produce an acceptance receipt.

That distinction matters at checkout: the receipt represents the wallet’s network-acceptance policy. It does not, by itself, prove that the transaction has been confirmed in a block.

Interrupted Payments and Tip Records

The service stores the original submitted payment before asking the merchant wallet to accept it.

If a response is lost, the cashier can retry with a freshly authenticated request carrying the same invoice and transaction. Once a receipt has been stored, repeat delivery returns that same signed receipt.

The original submitted payment cannot be replaced with different transaction bytes. Recovery across restarts depends on retaining the gateway’s stored state.

The first version also has limits. Recovery for an unsettled invoice belonging to a revoked cashier is not automated, and invalid submissions may require operator intervention.

Optional subtotal and tip fields are included in the signed invoice. Both use whole satoshis, and their sum must match the exact payment total.

The tip forms part of the payment received by the merchant. Cashier attribution supports sales reporting; staff tip distribution remains a separate operational task.

Deployment Still Requires Merchant Infrastructure

The reference implementation supports one gateway process per merchant.

Running multiple instances requires a database-backed store and coordination that prevents competing instances from handling the same merchant payment independently.

Operators must also provide a full signing wallet, persistent storage, blockchain connectivity and transaction-broadcast monitoring.

Both mainnet and testnet configuration are supported, with testnet as the default. The documentation calls for initial device pairing and payment-acceptance checks against provisioned testnet services.

The dedicated container workflow runs POS tests with Go’s race detector before publishing the image. Its successful release run provides build-and-test evidence, while real merchant deployment still depends on the operator’s complete setup.

BSV TIMES Read

The practical development is the addition of merchant operating controls around BSV token payments.

Cashier enrollment, signed invoices, checks on the receiving output and recovery after interrupted requests address tasks that a shop needs beyond displaying a payment code.

Keeping the merchant’s private key off staff devices is useful, but the gateway remains part of the merchant’s security responsibility. Likewise, a signed acceptance receipt has a defined meaning that should remain clear to merchants and customers.

This release supplies a concrete component for building merchant payment services. The reviewed sources establish the software release and its successful container workflow; they do not establish commercial adoption or a completed retail rollout.

Developer Context

Darren Kellenschwiler, known publicly as Deggen, uses the GitHub account sirdeggen. His npm profile links his name to that account.

He authored the merchant POS gateway pull request. His public GitHub profile lists the BSV Association.

The contribution includes the gateway, payment-acceptance checks, persistent invoice and receipt handling, protocol tests and the dedicated container release workflow.

Source Links

Posted on October 17, 2026