Machine Payments Watch / Payments Infrastructure

pay.bsv.cx has launched a beta service offering machine-payable API access through BSV Blockchain, allowing software agents and applications to purchase individual services without creating an account, entering card details, or maintaining a subscription.

The service currently offers timestamped data, verifiable webpage retrieval, notarized PNG and PDF captures, and batched timestamping for as many as 3,000 file hashes under a single Merkle-root commitment. Pricing is measured in satoshis, with the current service table generated directly from the platform’s running configuration.

Under its native payment flow, a client requests a resource and receives an HTTP 402 Payment Required response containing a newly derived payment address, amount, invoice identifier, and submission endpoint. The client creates and signs a BSV Blockchain transaction, which the service verifies and broadcasts before returning a bearer token containing a fixed number of API calls.

The token can then be included with subsequent requests. Each completed call reduces the remaining allowance, while unsuccessful rendering requests are refunded rather than charged. The service also applies per-client concurrency limits and returns retry guidance when all available processing slots are occupied.

For clients already built around x402, pay.bsv.cx provides a separate x402 v2 interface. The client receives a machine-readable PAYMENT-REQUIRED header and repeats the request with a PAYMENT-SIGNATURE containing the transaction. A successful response returns the requested resource together with a PAYMENT-RESPONSE header carrying the settlement transaction ID.

The service identifies this as the x402 exact scheme, in which the client signs a complete BSV Blockchain transaction and the service verifies and broadcasts it. A machine-readable discovery document provides available products, prices, input requirements, and response formats so an agent can determine how to call and pay for an endpoint without service-specific manual configuration.

Its most distinctive product is verifiable fetch. The endpoint retrieves a live webpage and returns clean content together with an on-chain receipt committing to the exact bytes supplied at that moment. Verification involves checking the content hash, the receipt manifest, and the manifest identifier recorded in a BSV Blockchain OP_RETURN output.

The result is more than a paid web-retrieval service. An application can obtain information and receive a publicly checkable record of what was delivered, even if the original service later disappears. Notarized captures extend the same principle to webpage screenshots and PDF records, while the batch service allows thousands of hashes to be represented by one on-chain Merkle-root commitment.

The developer describes pay.bsv.cx as a live mainnet beta. Requests are served after mempool acceptance rather than waiting for a block confirmation, so the response should not be interpreted as final settlement. Stored webpage snapshots may also be removed later, although their on-chain commitments remain available, and unused call tokens expire.

The working x402 interface should be distinguished from the broader proposal to add formal BSV Blockchain support to the x402 Foundation’s upstream repository. That proposed specification and TypeScript implementation remain under review and have not been merged. pay.bsv.cx demonstrates that the payment pattern can operate today, but it does not by itself establish official x402 adoption of BSV Blockchain.

BSV TIMES read:
Machine commerce requires a payment model suited to software rather than conventional human checkout. An autonomous application may need one document, one timestamp, or one verified result without creating an account or entering a long-term commercial relationship. pay.bsv.cx demonstrates how small BSV Blockchain payments, HTTP 402 responses, and machine-readable service descriptions can turn that interaction into a direct exchange: request, pay, receive, and verify. Its longer-term significance will depend on reliability, wider developer use, and interoperability with emerging x402 implementations.

Posted on July 23, 2026