# Receiving bitcoin

<!--

Editor's notes

This page should cover what to do when receiving bitcoin, how to share and copy addresses etc.

- What addresses to support (native segwit by default)
- How to present QR codes (allow for specifying an amount)
- Generating a new address

-->

The details required by a sender to make a payment, at minimum, is an address. You can think of an address just as you would an invoice. The receiver generates it in their Bitcoin wallet application and is presented to the sender each time a new payment is requested.

We will now dive into scenarios like when receivers may have other payment details that they may want to share and friction points for incoming payments like address compatibility.
<!--
Update glossary

Each address that a Bitcoin application generates has an accompaniying private key. This private key allows the receiver to unlock the bitcoin that is sent to the address when the receiver chooses to spend it.

Although addresses are not a problem to share publically, their accompanying private keys which typically generated from a single recovery phrase must be kept secure and private.
-->

## Entering details for the payment request
Oftentimes, to complete a payment, the sender would require some additional information like an amount. The receiver may also want to keep some notes about the payment for their future accounting.

The following are the primary properties of a payment request:
- **Address** -- the destination of the payment (automatically generated)
- **Amount** -- how much is being sent (requires user input)
- **Label** -- who is receiving (requires user input)
- **Message** -- what the payment is for (requires user input)

:::info
Although the label and message are often disregarded when sharing payment links, the amount is usually kept and auto-fills in the sender's application.
:::

<!--
Update interopability page
Since there are many Bitcoin applications for people to choose from, its likely that the sender and receiver are not using the same one and they don't have the abilitiy to exchange payment details within the application itself.

The exchange of payment details then most commonly happens outside of the wallet application. This

Since bitcoin is a open system and has many payment applications built ontop of it, there is a [standard format](https://bitcoin.design/guide/foundations/wallet-interoperability/#payment-links) of "payment links" that most bitcoin applications use to share payment details.
-->

## Choosing the type of address
There are currently [three different versions](https://bitcoin.design/guide/glossary/#address) of bitcoin addresses, in order of oldest to newest they are; Legacy, Script, and SegWit. It is best practice for new applications to support the latest, SegWit by default.

The most commonly used addresses are still the "legacy" addresses since Segwit addresses are only a few years old, and some older applications have yet to update.

Suppose the sender is using a legacy wallet and paying to a receiver who gave them a SegWit address. In this case, their wallet may incorrectly warn them that the address is invalid or not supported. This can confuse the sender's end, leading them to think that the receiver provided an incorrect address.


Suppose the sender is using a legacy wallet and paying to a receiver using a SegWit address. In that case, their wallet may incorrectly warn them that the address is invalid or not supported. This can confuse the sender's end, leading them to think that the receiver provided an incorrect address.

The receiver should then have the ability to choose a Script address that does not have all the benefits of SegWit, like cheaper transactions. Still, it will be recognized by the sender's outdated application.

<!--
On /guide/payments/send/#inputting-an-address
Add below as Do's & Don'ts

> Besides pushing wallets to adopt Bech32, wallets should provide better and clearer error messages to the end-user. Merchants could use P2SH to mitigate. In my opinion P2SH is just a patch not a solution. A solution where Bech32 invoice can fallback to P2SH would be a good balance.
> @pavelenex
-->

## Sharing the payment details
Payment links can be shared as text in separate messaging applications like email or chat. This is a straightforward process, where the payment link is just copied and pasted.

You can provide the receiver with a button to share in other applications, with "share sheets," which most mobile operating systems offer.

QR Codes are also a common way to exchange payment details when the two devices are near one another. It is not without its faults, though, as some people may not be familiar with QR Codes, and lower-end phones may have difficulty reading them.

Here are some constraints to consider when displaying QR Codes:

- QR Codes with more blocks (modules) are challenging to read for devices with low-resolution cameras.
- There should be sufficient contrast between the blocks in a QR Code and the background. Ideally, keeping the blocks black and background white would be the most optimal.
- Size matters. You won't know the distance the devices will be from one another when the scan is happening, so you should design assuming the longest scan distance.

## Waiting and transaction processing
After the payment details are shared with the sender, it would take time for them to deceide to pay, approve the payment and, and for the transaction to be [processed](https://bitcoin.design/guide/payments/send/#transaction-processing-and-confirmation). This uncertainty of when the payment would be completed gives you an opportunity to design how you keep the receiver informed of the statuses in the process the payment is at.

Here are the states of this waiting period once the payment details have been shared:
1. **Awaiting payment** -- no transactions detected, the sender has not broadcasted a transaction with the payment
2. **Pending/Unconfirmed**
3. **First confirmation**
4. **Sixth confirmation**

If your application has an area where the user can see a list of payment requests, this would be a good place to use to also indicate which specific stage the payment is in.

Then once the payment has been finalised, you should also consider what the receiver may want to do with those funds. You may want to help faciliate those follow up activties.

---
---
---
---
---
---
---
---
---
---
---
---
---
---
---
---
---
---
---
---
---
---
---
---
---
---
---
---
---
---
---
---
---
---
---
---
---
---

There are also several methods the reciever can use to share these payment details with the sender.

Lets first start off with some fundimentals.

- Addresses are to only be used once
-
-

There are some standards which wallet applications use like payment links and QR Codes.

Lets get into some of the proper

1. Generate address
2. Set the amount
3. Choose address type (its best practice to use the version 2 or 3 addresses also known as Segwit addresses)

To receive bitcoin,

Address Types
- It is best practice to provide Segwit addressses by default.
- Legacy addressses are more widly adopted, but create a larger transaction size so could result in higher fees for the sender as well as higher fees when the receiver wants to spend it.

The address, and amount being requested, although the latter is optional.

Properties of a payment request

- Address (required)
- Amount
- Contact/Observer (label who knows about the coin)
- Memo (what is the purpose)

---

**Payment Requests** hold more information to describe a payment. A payment request does not represent an account. Instead, think of it as an invoice, and ideally, recipients should only use payment requests once.

Whether you are making an On-chain or Lightning Payment, the user flow is typically the same.The receiver generates a payment request, shares it with the payer via some out-of-band method (QR code, text message, etc.), then the payer approves the payment in their wallet.

At the core, they contain the destination (address or invoice) and other pieces of data required to identify who and what is being paid for, like the amount, payer’s name, and memo.

## Payment Requests / Addresses

Do we need to consider different types of addresses?

- Example Muun, default to bech32 (v3 addresss) but allowing to fall back to legacy address.
- Describe types of secure way to send addresses when you are not in the same physical location.
- Difference between payment request and invoice / an addresss is not a payment requesst but it is a good way to describe this to a user.

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

## Single use / one-time addresses

There is no forced limit on how many times you can use an address, but it is critical for your privacy to use it only once per transaction. You should generate a new one everytime you need to receive some bitcoin, even if it's from an already known sender. Read more on addresss reuse and it's privacy implications in Transaction privacy.

---

On-chain the core of a payment request is an address. While not strictly enforced, you should recommend users only to use them once as all transactions are public. By receiving multiple payments to a single address leaks more information about the users’ funds in future transactions.

It’s also possible to have an online service generating a Payment Request on-demand, for instance, online shops that accept bitcoin. They usually have a hot wallet (see glossary), which can generate payment requests as needed for customers at checkout.

There is no forced limit, but you should only send a payment request to one payer to safeguard your privacy, as using payment requests with multiple payers will expose your other funds to them. You should also note that on-chain payment requests can have numerous payments made to them, while bitcoin Lightning Payment requests only accept a single payment, which must be paid in full.

---

### Dos

- ...

### Don'ts

- ...

This helps you safeguard your privacy as as reusing addresses with multiple payers will expose how you spend the change that is returned to your wallet -- they will be able to see the previous transactions including their new transaction to you.

:::info
When a payment request is created it should be stored until it is fulfilled so the user does not acciedntly share the same address to multiple persons.
:::

## Sharing

Allowing the user to share in some out of band method.

### Dos

- ...

### Don'ts

- ...

## Notifications

- Types of statuses
- ...
- When to notify about payment status change?


### Dos

- ...

### Don'ts

- ...

----
## For futher reading on advanced topics checkout
- ...