For someone to receive bitcoin, they must provide the sender with a payment destination. They can do this by generating an address in their Bitcoin wallet application. A new address should be generated for every payment, as addresses should only be used once. This helps safeguards the receiver’s privacy.
Requesting bitcoin #
The simplest way to receive bitcoin is by generating and sharing a Bitcoin address with the sender. Receivers can share the address by either as a scannable QR code, or as plain text via any regular communication tool like email, instant messaging, SMS, etc.
There are several types of addresses. Sharing one that is incompatible with the sender’s wallet application can prevent a successful payment. Read more about address compatibility issues in the glossary.
Inputting additional payment details #
Many Bitcoin wallet applications provide only this most basic interface with an address for requesting payments. This is convenient in the short-term as it is fast and simple, but may not be in the user’s best interest longer-term. Lists of transactions without information about who they are from and their purpose make it hard to manage personal finances and future transaction privacy.
Since the Bitcoin blockchain only stores a limited amount of information, such as the amount and addresses involved, any additional information must be stored in your application. This additional information can be vital in providing context to wallet owners on their spending habits and payment histories. These details have to be manually added. It is possible for receivers to share some of these extra details with senders by encoding them in payment links.
The following are the standard properties of a payment link:
- Address – The destination of the payment
- Amount – How much is being requested (optional)
- Label – For example, the name of who is sending the payment (optional)
- Message – For example, the purpose of payment (optional)
Not all applications support storing additional information, or sharing payment links with these details. When providing this functionality, find the right balance between convenience and usefulness for your target audience. Consider ways that can make the input of these details easy, not burdensome.
Sharing the payment request #
Whether it’s just an address, or a payment link containing additional information, the two primary methods of sharing requests are via QR codes or as plain text.
Sharing a request as text is as straightforward as copying and pasting. It is also typical for Bitcoin applications to provide the receiver with a “share” button - allowing them to conveniently share addresses or payment links via other applications, with “share sheets” being offered by most mobile operating systems.
QR codes are commonly used when the sender and receiver 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:
- Complex QR codes can be difficult for devices with low-resolution cameras to read.
- Use high contrast between the QR code blocks and their background.
- Display the QR code at the largest size so that the scanner can detect it easily.
For more technical details about optimizing QR codes, see this article.
Awaiting the payment #
Once the request has been shared, the sender still has to create and broadcast their transaction, leaving room for uncertainty as to when the payment will be completed and received. Think about how to keep the receiver informed whilst they await their payment.
If your application has a list of their payment requests or transaction history, show the status and what stage of completion the transaction is at.
Once the payment has been finalized, consider what the receiver may want to do with those funds. You may want to help facilitate those follow-up activities, for example moving the funds to a shared multi-key wallet or doing a coinjoin.
Let’s go, time go dive in a bit deeper with transaction privacy.