---
layout: guide
title: Payments
description: Diving into the user experience of moving bitcoin
nav_order: 4
has_children: true
permalink: /guide/payments/
---

# Payments and transactions

At its core, the bitcoin protocol enables transactions between people without middlemen, regardless of where in the world they are.

This chapter is meant to give an overview of bitcoin transactions, including sending, receiving and transaction privacy with advice and best practices. After this chapter, you should be able to design payment solutions that are well suited to your product’s use case, and understand best-practices for the implementation of it.

We have already established that [Bitcoin is money](https://bitcoin.design/guide/getting-started/why-bitcoin-is-unique/#its-money-but-digital), so let's dive into how it can be used to facilitate payments.

---

#### [Transactions overview](#Transactions-overview1)
An overview of bitcoin payments, common concepts and the transaction lifecycle.

#### [Sending bitcoin](#Sending-bitcoin1)

An introduction to how sending bitcoin works.

#### [Receiving bitcoin](/guide/payments/receive)

An introduction to how receiving and requesting bitcoin works.

#### [Transaction privacy](/guide/payments/privacy)

An overview of how to help users maintain their financial privacy while using bitcoin.

#### [Managing funds](/guide/payments/manage-funds)

How to help users organize and manage their transaction data and holdings.

#### [Case studies](#Case-Studies--Sending-bitcoin)

We demonstrate how the conecpts we've learned can be put together to create a payment expereince.

---

# Transactions Overview

Bitcoin is a peer-to-peer push-payment system. This means that you are able to send, or *push*, bitcoin to any address at your will, at any time, without passing through a third party.

This is radically different from the legacy financial system where it is often possible for others to *pull* and withdraw money from your account (utility companies, financial institutions, merchants etc.). When you make a payment it will pass through systems that might delay, control or block the payment.
## Bitcoin Transactions

The most common bitcoin transactions simply contain instructions to move funds from one address to another. Other types of transactions include creating multi-sig wallets or recording data on the blockchain.

Once created, a transaction needs to be signed with the private key(s) of the sender(s), submitted to a node on the network for validation and propagation to other nodes. It then waits to be verified and included in a newly mined block, after which point it will be recorded on the blockchain. For this service, the sender will pay a fee for every transaction which goes to the node who mined the block as a reward.

Technically, the transaction is data that contains the necessary information to execute on the blockcain. The principal properties are:

- Amount - the amount of bitcoin, in satoshis
- Inputs - the source(s)
- Outputs - the destination(s)
- Version - the code version this transaction follows
- Lock time - time until the transaction should be executed, optional

### Input and Outputs

In a Bitcoin wallet, funds are often not held in a single address, but more commonly in one address per transaction where you received bitcoin. When you are making a transaction you need to specify which of your addresses should be the source of the funds. If you need to spend more than what a single address holds, you can specify several. These are called *inputs* to the transaction.

Likewise, you need to specify the destination address, or addresses for the transaction. These are called *outputs*. Should there be more bitcoin in the inputs than are needed for the transaction, a new address will be created in your wallet for the change, often called a *change output*.

### Transaction Fee

Every transaction needs to pay a fee to incentivises miners to include it in a block. There is no fixed fee for making a transaction as it depends on the amount of data it includes, the amount of other transactions that are trying to get verified, and how much each submitter is prepared to pay at any given time. Miners typically pick the transactions that will earn them the highest reward to include in a block.

Blocks are limited in size and new ones are created every 10 minutes on average. This means that if you want a transaction to be confirmed in the next block you might have to pay a high price.

When submitting a transaction you can optimize for fast confirmation, or lower fee. It is good practice to give the user some control of this.

## Transaction Lifecycle

Let's lay out the entire payment process.


#### 1. Get Recipient Address
You need a valid address to send bitcoin. This can be shared by the recipient as a QR code, in plain text or as a payment link.

#### 2. Transaction Creation
The wallet application guides the user through collected the required information (address and amount), and any optional information (what coins to send, fee options).

#### 3. Transaction Signing
The transactoin needs to be signed by the private key(s) of the input address(es) to be valid. The signing is often done in the same application and at the same time as the creation, but this does not have to be the case.

#### 4. Transaction Broadcasting
The transaction is broadcasted to a Bitcoin node, normally the one the wallet is connected to.

#### 5. Transaction Validation
The receiving node checks that the transaction is valid. In practice this means confirming that it was signed by the private key of the relevant address.

#### 6. Transaction Propagation
Once validated, the node passes the transaction on to other nodes in the network - returning a success message to the originator. The transaction is now in the *memory pool*, and remains there until confirmed.

#### 7. First Transaction Confirmation
At some point the transaction is included in a block that is added to the blockchain. This counts as a first confirmation. The recipient can be confident that they will receive the bitcoin, and may even receive a pre-emptive notification from their wallet. How long the first confirmation takes is dependent on many factors, principally - how many other transactions are waiting to be confirmed and how big a fee the transaction will pay. A new block is confirmed roughly every ten minutes.

#### 8. Final Confirmation
Each additional block that is accepted by the network counts as an extra confirmation, making the transaction more secure by making it harder to undo. When a transaction has 6 confirmations, it is considered final.

---

# Sending Bitcoin

Sending bitcoin is probably the most basic feature of a bitcoin application. Users may be sending bitcoin to a known contact, moving it between their own wallets on different devices, or paying for goods through a [payment processor](https://bitcoin.design/guide/getting-started/software/#payment-processors). Regardless of where the bitcoin is being sent, there are some basic requirements that an application needs to help the user with:

- Recipient address - where to send the bitcoin
- Amount - how much to send
- Fee settings - prioritize fast confirmation or low cost (optional)
- Coin selection - Which coins/outputs to use (optional)

The order of the user actions can be tailored to the use case, for example whether the address or the amount is the first input.

## Get the Recipient Address
To send bitcoin we need a recipient address. If you are moving funds to another of your own wallets, this is easily accomplished by generating a new address in the receiving wallet application, then sharing it with the sending wallet application.

Bitcoin [addresses](https://bitcoin.design/guide/glossary/#address) are long and random, they are best shared by copying and pasting in plain text, as a [payment link](https://bitcoin.design/guide/foundations/wallet-interoperability/#payment-links), or as a scannable [QR Code](https://bitcoin.design/guide/foundations/wallet-interoperability/#qr-codes).

If you are sending to someone else, you will have to ask them for their address. If you are together at the time, scanning their address as a QR code will be easy, but if you are not they can send the address as text in any regular communication tool like email, sms etc.

When paying a merchant for goods and services you will normally be presented with a QR code.

:::info
There are different types of Bitcoin addresses. This can have implications for compatability when sending bitcoin. A modern wallet application is likely to use native segwit addresses, that enable cheaper transactions and other functionality. Find more information on [address types](https://bitcoin.design/guide/glossary/#address) in the glossary.
:::

## Input an address

You input an address by pasting a text string, or scanning a QR code. Bitcoin transactions are irreversible so both the sender and receiver should take great care in correctly inputing addresses.

Upon address input, the user should be clearly informed if a valid address was detected or not in the interface. If the address is invalid, or incompatible, sending should be disabled to avoid mistakes that could lead to a loss of funds.


### Input options

#### QR Code

<img src="https://i.imgur.com/B5MlGKt.png" style="float:left;margin-right: 2rem;" width="100">

A QR code is an effective way to encode data that is not easily read by humans (like long bitcoin addresses). They can be scanned and decoded by most mobile phone cameras. Once the camera detects a valid address in the QR Code, it can be automatically input. The user will need to approve your application to have access to the camera in order to be able to scan QR Codes.

#### Copy Paste

<img src="https://i.imgur.com/gnMTFpb.png" style="float:left;margin-right: 2rem;" width="100">

When a QR code is not practical, the sender and receiver will have to exchange the address in text format. Wallet applications often cater to this by copying to, and pasting. The actual sharing can be done via a message, email, or another communication channel of choice. For added security, both sender and receiver should double check that addresses have been copied correctly between devices.

:::info
Most platforms allow applications to read the contents of the device's clipboard to enable convenient copy/paste. While most users find this helpful, some may perceive it as a privacy infringment. You may want to consider giving them an option to disable automatic reading of the clipboard.
:::

### Do's

- Indicate clearly if the address is valid or invalid
- Ideally show the whole address to help with verification
- If space is a constraint, truncate the address in the middle so that both the beginning and end are visible for verification

### Don'ts

- Don't allow a transaction to be sent if the address is invalid

## Inputing an amount

Depending on their familiarity with bitcoin, your users may have a preference to which denomination the amount should be specified in. Common options include:

- **bitcoin** — most common *(i.e. 0.00019376 btc)*
- **local currency** — more familiar *(i.e. $10)*
- **sats / satoshis** — more knowledgable *(i.e. 19376 sats)*

Allowing the amount to be inputed in different denominations should be readily available. Read more about why and changing units contextually in [Units, symbols and amount display](https://deploy-preview-63--sad-borg-390916.netlify.app/guide/payments/units-and-symbols/).

Since an amount specified in bitcoin or sats often involve many characters, and don't correspond easily to a local currency amount ($10 as 0.00019376 bitcoin for example), applications can help by specifing the amount in fractions. Most common is *max*, which makes it easy for the user to send all of the available coins.

:::info
Payment links and QR codes can contain an amount — when they do, the amount should be populated automatically.
:::


### Do's

- Allow different denominations to be used for the amount
- Show the total balance available to send
- Allow selecting max amount (subtracting the required fee)

### Don'ts

- Don't allow entering more than the available balance

## Transaction fee

The application can automatically estimate a fee and set it for the sender. This would normally prioritise the transaction to be included in a block as soon as possible. Since the fee rate may vary if the network is busy, you can give senders more fine grained fee controls so they choose to optimize for faster confirmation, or lower fees.

#### Variations
- Automatically set fee rate
- Allow user to choose from presets
- Allow user to enter a custom fee rate (advanced)

#### How are transaction fees calculated?

The total fee is dependent upon the data size of the transaction multiplied by the fee rate, not the amount being sent. The fee rate is expressed as satoshi's per vByte (sat/vB). Be mindful that not all bitcoin users are familiar with terms such as sat/vB, so it may be necessary to also express the value in their local currencies.

:::warning
#### Fee Estimation
Fee estimations are largly inaccurate — this is because the fee rate is impacted by everyone else who are trying to get their transactions into a block. The rate is constantly changing so it is difficult to make an accurate prediction of.

The fee recomendation in your application can cause senders to end up over paying in fees, or waiting long periods of time to get their transactions confirmed.
:::

### Setting the transaction fee manually


When allowing users to set their own fee, it is important to clearly communicate the estimated cost and confirmation time, along with some details on how the fee gets calculated ([see below](#How-are-transaction-fees-calculated)).

Human error with fee selection can lead to [costly mistakes](https://www.coindesk.com/dumb-mistakes-costly-bitcoin-losses). Someone can set a fee rate that's way too high, overpaying in fees or having transactions stuck for long periods of time if the fee is too low. For these reasons you should carefully consider if and how to expose transaction fees to users depending on the usecase.

### Do's

- Clearly communicate infomation related to the fee rate options
- Display the fee rate and estimated transaction confirmation time
- Display bitcoin and local currency denominations for cost reference
- Include an option to adjust this rate with either:
- Select from priority pre-set options (high, medium, low priority)
- Manually entering a fee rate for their transaction
- Display a warning if the user enters an amount far beyond the recommened rate
- Consider offering a [replace by fee]() option to speed up stuck transactions

### Don'ts

- Allow for confusion between total fee and fee rate
- Allow users to overpay in transaction fees

## Reviewing and Approving the Payment

A valid transaction that is broadcast to the network cannot be reversed, so it is critical that the sender is given a chance to double check the payment details (amount, recipient address, total fee, etc) before submitting the transaction.


:::info
// Should this be a do/don't? (needs more info on how spending limit is set etc.)
If transaction exceeds a daily spending limit make sure users go through some security check (enter PIN, 2FA password, etc).
:::

### Do's

- Allow users to review payment details and adjust if necessary, before submitting the transaction
- Show amount and fee in both bitcoin and local currency denominations

### Don'ts

- Assume the user has got all the details correct, give them the chance to look over the information before broadcasting the transaction

## Transaction processing and confirmation

Once a transaction has been signed by the sender and submitted by the application, the transaction goes through the following steps before being confirmed by miners on the network:

<img src="https://i.imgur.com/t8WHLp6.png" style="float:left;margin-right: 2rem;" width="100">

#### Broadcasting

The transaction is broadcast to a node, usually the one the wallet is connected to.

...

<img src="https://i.imgur.com/Ey6hMoA.png" style="float:left;margin-right: 2rem;" width="100">

#### Validation

The node checks to see if the transaction is valid. If **Yes**, the node propagates the transaction to other nodes in the network. If **No**, the transaction is rejected.

...

<img src="https://i.imgur.com/DEsVUFj.png" style="float:left;margin-right: 2rem;" width="100">

#### Propagation

Once the transaction is valid it is now in the *memory pool*, and is available for including in a block by miners. When in the *memory pool*, the sender can see the transaction in their wallet as unconfirmed.


### Do's
// Maybe these can be combined, they say almost the same thing
- Notify the user which stage of the process their transaction is in:
- Awaiting broadcast
- Broadcast, awaiting validation
- Validated, awaiting propagation
- Awaiting confirmation
- Or, simply show the transaction as pending, perhaps with a time estimate if applicable

### Don'ts
- Show a the transaction as confirmed until it has received ***at least*** one confirmation, but preferably six

## Transaction confirmation
At some point the transaction is included in a block that is added to the blockchain. This counts as a first confirmation. The recipient can be confident that they will receive the bitcoin, and may even receive a pre-emptive notification from their wallet. How long the first confirmation takes is dependent on many factors, principally - how many other transactions are waiting to be confirmed and how big a fee the transaction will pay. A new block is confirmed roughly every ten minutes.

Each additional block that is accepted by the network counts as an extra confirmation. When a block (and therefore the transaction within) has 6 confirmations, it is considered final.


### Error States

// Maybe write some explanatory text here?

### Do's
- Notify users of confirmed outgoing/incoming payments
- Show the amount of confirmations a transaction has received
- Provide information on transaction/block ID for receipt purposes

### Don'ts
// This is doubling up with the ones in Transaction processing (maybe they can be cut and moved here?)

---

---

# Transaction privacy

<!--
This page should inform about what information is made public when sending or receiving, how the application can help minimize unnecessary privacy leaks, basic application functionality to help, and when we can, more advanced options.

- Single use addresses (avoiding address reuse)
- Coin selection / labelling
- Coin join / Pay join
-->

This page should inform about what information is made public when sending or receiving, how the application can help minimize unnecessary privacy leaks, basic application functionality to help, and when we can, more advanced options.

Sensitive information in wallet applications include the wallet balance, addresses, private keys and previous transactions information.

- Wallet Balance - shows how much you own
- Addresses - can be used to track your transaction history
- Private keys - can be used to access and transfer your bitcoins

- Single use addresses (avoiding address reuse)
- Coin selection / labelling
- Coin join / Pay join

//

- It becomes more important to quickly execute a transaction than protecting the money involved from as many attack vectors as possible

The bitcoin you use in a payment can leak information to the previous entities you have received payments from. Because of this structure, choosing to optimise for privacy, lower transaction fees, or speed are things you need to consider when designing a payment experience.

- Privacy by design
Privacy in bitcoin payments goes far beyond hiding balances and other sensitive information, the privacy by design framework states that privacy should be incorporated and built into products by default. This way, whether or not the user is concerned with their data privacy, they would always be protected through good UX.

- Privacy physical
Imagine this scenario. You are in a public place, and you need to make a payment using your bitcoin wallet. You open your wallet on your phone, but you don’t feel comfortable having your address and balance information clearly visible to strangers who may be looking over your shoulder, persons lurking or video surveillance . Hence by giving users the ability to hide sensitive information in their wallet if desired, they gain an added sense of physical privacy when using the app in public.
- Someoen has my device
- Privacy on-chain
- chain analysitics
- solutions
- limitations of to solutions

Privacy Spectrum

# Managing funds

// Editor's notes

Summarize what this page should cover.

//

Its not just sotring through a list of things.
See where money goes.

- methods to identitfy the payments income and outcomes (labels)

Since there is no registry for merchants and identities, payment data tends is limited as it has to be manually inputed by the sender and reciver individually. The information is not shared between the two parties only the address is.

We will explore some of the components required for managing Bitcoin within the application and how to help users organize and manage their transaction data and holdings.

## Transaction History
The transaction history represents the current state of your bitcoins at any point in time. It allows you track how many bitcoins have been sent and received.

The transaction history as displayed on various wallet applications is usually made up of how many bitcoins was sent/received and when it was sent/received.


When a transaction history is tapped on or selected, usually the full details come into view. these include:

- The Input and Output addresses
- The number of confirmations
- Transaction ID
- Date it was received
- you could also save or export the transaction note

An importance of transaction history can be seen in wallet account scanning. Account scanning refers to the process whereby a wallet scans through a user’s account in search of payment requests with transactions, to sum the user’s bitcoin balance.

The wallet scans the account for addresses that contain payment requests, then it further scans the addresses for payment requests that were fulfilled / have transactions made on them. By identifying these tranactions, the wallet can then add up all transactions to get the users balance from the previous wallet.

### Variations
Some applications may choose to show a coin list instead of a transaction history.

- Coinlist vs Transaction List (like wasabi wallet)
- Listing the UTXOs
- Showing the Transactions containing the UTXOs

### Do's
- ...
### Don'ts
- ...

## Balance
Knowing how much bitcoin a wallet controls.
itHere too you would want to allow users to be able to hide the balance. See hide sensitve infromation...

### Do's
- ...
### Don'ts
- ...

## Labeling
- Why labels?

### Do's
- ...
### Don'ts
- ...

---

----

// Moved from higher up, could be a section on 'Advanced transactions', or similar.

## Comparing Day-to-Day Spending vs Large Amounts


- Private Key Management / Shared scheme
- Day-to-day spending [#](https://bitcoin.design/guide/getting-started/personal-finance/#day-to-day-spending)
- > From a portability perspective, many of these payments happen outside of our homes. This makes mobile wallet applications ideally suited, which allow us to take advantage of the unique benefits of smartphones
>
> Convenient camera access allows for quick scanning of QR payment code and NFC support ([Near-Field Communication](https://en.wikipedia.org/wiki/Near-field_communication)) lets us pay just by holding our phone next to a card reader
- Spending larger amounts / Using a shared scheme
- Sharing PSBT / Transaction Signing (out of scope?)
> When making larger payments or transfers, cold storage devices such as hardware wallets are often employed for increased security. This usually takes place within desktop applications.

# Case Studies / Sending bitcoin

// Editor's notes

Summarize what this page should cover.

//

Bitcoin wallets don't have a balance in the conventional sense. Instead it keeps track of all the previously received [UTXOs](https://bitcoin.design/guide/glossary/#unspent-transaction-output-utxo). The balance applications usually show is actually a total of those UTXOs available to spend.

Choosing if you are optimising for privacy, lower transaction fees, or speed are things you also need to factor into the design into the payment expereince. Your choice will directly impact the amount of steps the user needs to make.

You will also need to consider what enviroment the application will be used in. If you are paying a vendor at your local market you probably won't have their contact details to exchange a payment request via chat. Scanning a QR Code to get an address would likely make more sense in this situation also than manually typing it.

## Simple send

### How it works

Usually on a send screen, the user enters an amount they wish to send, then pastes in the address where they want to direct the payment to.

The application can sometimes detect if an address has been copied to the clipboard and automatically paste it into the address field.

### Pros

- Low friction, it easy for end user, as they don't have to select coins to fund the transaction with manually.
- Wallets can decide automatically if to optimise the transaction for cost, speed, or the change that would be returned depending on the targeted user group.

### Cons

- Does not provide the level of control for more privacy concious users.

### Best practices

#### When to use

- New Users or introductory wallets
- Wallets that wish to prioritise cost or transaction speed

#### When not to use

- When privacy is a concern to users

#### Products that use this scheme

- Bread Wallet + Electrum (FIFO)
- Mycelium (Pruned FIFO)
- BitcoinJ and Bitcoin Wallet for Android (High Priority First)
- Electrum *Private Mode (Target Sized Change)
- Bitcoin Core (Branch and Bound)
- Hexa (Blackjack, with Accumulative Fallback)

## Coin Control

Coin selection is the process of choosing which UTXOs to fund a bitcoin transaction with (i.e a transaction's inputs) when making an on-chain payment. There are two categories of coin selection strategies that are used in bitcoin applications:

**1. Automatic Coin Selection**
Wallets are delegated control over coin selection, using an algorithm to retrieve UTXOs to fulfill a payment amount.

**2. Manual Coin Selection**
Wallet owners take control over coin selection, manually choosing UTXOs themselves to fulfill the payment amount.

### Controlling the automatic algorithm

Wallets could give users the ability to toggle between multiple coin selection algorithms, selecting to optimise for cost, speed, or privacy.

<iframe style="border: 1px solid rgba(0, 0, 0, 0.1);" width="800" height="450" src="https://www.figma.com/embed?embed_host=share&url=https%3A%2F%2Fwww.figma.com%2Fproto%2F0pgxMzs3IriAp73BTJFjgk%2FCase-Study-Rwandan-BTC-Wallet%3Fnode-id%3D700%253A0%26viewport%3D1552%252C1177%252C0.6608505845069885%26scaling%3Dmin-zoom" allowfullscreen></iframe>

...

Alternatively, wallets could present users with a **Private Mode** which changes the automatic coin selection algorithm to optimise for privacy...

<iframe style="border: 1px solid rgba(0, 0, 0, 0.1);" width="800" height="450" src="https://www.figma.com/embed?embed_host=share&url=https%3A%2F%2Fwww.figma.com%2Fproto%2F0pgxMzs3IriAp73BTJFjgk%2FCase-Study-Rwandan-BTC-Wallet%3Fnode-id%3D700%253A1464%26viewport%3D2247%252C2989%252C1%26scaling%3Dmin-zoom" allowfullscreen></iframe>

### Allowing for Full Coin Control

This option uses automatic coin selection as the default feature, however it also allows wallet owners to override automatic selection and manually choose which UTXOs to fund a transaction with. Note the use of labels, giving wallet owners information as to which addresses will become exposed to the payee.

<iframe style="border: 1px solid rgba(0, 0, 0, 0.1);" width="800" height="450" src="https://www.figma.com/embed?embed_host=share&url=https%3A%2F%2Fwww.figma.com%2Fproto%2F0pgxMzs3IriAp73BTJFjgk%2FCase-Study-Rwandan-BTC-Wallet%3Fnode-id%3D1139%253A3400%26viewport%3D1050%252C898%252C0.25%26scaling%3Dmin-zoom" allowfullscreen></iframe>

### Design Considerations

- Entry level wallets might opt for Automatic coin selection to avoid confusing or overwhelming new users
- Show sufficient warnings of privacy leaks with both automatic and manual coin selection (e.g "UTXOs selected expose Bob to Alice")
- Coin labelling features greatly assist with informed coin selection (avoiding cross contamination of UTXOs and contacts)

### Technical Considerations

- Transactions must have sufficient funding
- In order to send X, the transaction inputs must at least equate to X.
- Blockspace and Fees
- As blockspace is limited, miners prioritise transactions by *fee per byte* to maximise revenue
- Transactions must be accompanied by the minimum relay fee for confirmation (therefore inputs must equal X + fee).
- No Dust
- Transactions that create dust outputs are not relayed and confirmed by most nodes and miners in the network.