Payments

On BSV, the sender hands the transaction directly to the recipient, together with the proof needed to check it. The recipient verifies it, accepts it, and makes sure it reaches the network.

That shapes what a wallet has to design for. The recipient knows a payment arrived the moment it is handed over, without waiting for the chain. Every payer can get a fresh address without the recipient managing thousands of keys. And there is no fee to bid and no "stuck" state to explain.

The recommended flow: peer-to-peer payments

The default is the peer-to-peer payment flow (BRC-29). In outline:

1. Find the recipient. The sender's wallet looks up the recipient, for example by handle, and learns their public identity key and how they want to be paid.
2. Derive a fresh address. Using both parties' keys, the sender's wallet derives a one-time address for this payment only (BRC-42 key derivation). Nobody else can link it to the recipient.
3. Hand over the payment. The sender's wallet builds and signs the transaction, then sends it to the recipient as BEEF, a format that carries the proofs needed to check it. The transport can be a web request, a message box or Paymail.
4. Check and accept. The recipient's wallet verifies the transaction against block headers (SPV, simplified payment verification), imports it, and replies "accepted" or "rejected".

For users, this collapses to: pick a contact or enter a handle, enter an amount, confirm.

What the recipient sees

Incoming payments arrive as messages, not as chain events, so a wallet can name who paid and why at the moment they pay. See Activity.

Why fresh addresses matter

Each payment goes to an address derived for that payer and that payment. Addresses are never reused, so outside observers cannot group a user's payments by address. Users never need to see these addresses.

Handles

A handle is a readable name that resolves to someone's key and where to pay them. Two schemes exist: Paymail, written anna@example.com, and the newer @anna@example.com (BRC-169), which adds certificate-backed resolution and message boxes.

A wallet looks up the handle's domain to learn what it supports: the owner's public key, profile name and avatar, and where to send payments. See Paying by handle for the design.

Paying apps and APIs: HTTP 402

For apps that charge per use, such as an article, an API call or a file download, BSV supports payment directly inside a web request (BRC-121):

1. The app requests the resource.
2. The server replies "402 Payment Required" with a price in satoshis.
3. The user's wallet builds a payment to the server and repeats the request with the payment attached.
4. The server checks the payment and returns the resource.

No account, card or API key is needed. With a spending allowance (see Permissions and allowances), users can pay small amounts without a prompt every time. See Charging per use for how to show that honestly.

Fees

BSV fees are less than 1p, so wallets don't need fee pickers, fee estimates or "high fees" warnings. If you show the fee at all, make it a small detail line in local currency. See Send fees.

Other formats

Some exchanges and services accept only a plain address, or a Paymail destination without the peer-to-peer flow. A wallet should still be able to pay them. These formats and their trade-offs are covered in Legacy compatibility.

Related

• Transactions
• Identity
• Paying by handle
• Charging per use
• Legacy compatibility