Skip to content
Satnam SatoshiIn service of humanityFind your place ↗
Menu

Sikh Bitcoin · Beginner · Lesson 5 of 21

Follow a payment from request to receipt

Understand why a payment has several stages.

About 10 minutes with practice. You only need something to take notes with. No real wallet details or payments are part of this lesson.

Course contents · Lesson 5 of 21
  1. Bitcoin without jargon
  2. Keys, custody and keeping control
  3. Payments for humans, including Lightning
  4. Money, prices and units
  5. Follow a payment from request to receipt
  6. Addresses, networks and QR codes
  7. Confirmations and patience
  8. Fees buy scarce block space
  9. Backups before dependence
  10. Scams, urgency and trusted routes
  11. Privacy is a practice
  12. Custody is a relationship
  13. Reading a Lightning invoice
  14. Exchanges and access to bitcoin
  15. Volatility and practical planning
  16. A fair invoice for creative work
  17. Donations with accountable purpose
  18. Proof of work and honest energy questions
  19. Bitcoin and Litecoin: related ideas, separate networks
  20. Read Bitcoin news with a source trail
  21. Capstone: welcome a newcomer safely

What you will learn

  • Describe authorization, broadcast and settlement.
  • Identify the recipient’s evidence of payment.

A request is not a transfer

An invoice states what a recipient would like to receive. It may contain an amount, destination, expiry and order reference. Opening or copying it does not move money. A wallet can construct a proposed transaction from spendable outputs; an authorized signer must then approve the transaction. The application’s appearance is not evidence that authorization occurred.

Broadcast is the beginning of a network journey

Once broadcast, an on-chain transaction can propagate between nodes and may be selected by a miner for a block. Different wallets and services can observe it at different times. A delay can reflect connectivity, policy, fees or competing transactions. A transaction identifier helps locate a particular record, but its presence on an explorer does not establish that the recipient’s settlement conditions have been met.

Close the loop with the recipient

For a fictional design commission, the artist checks the invoice in their own receiving system and follows the agreed confirmation policy before delivery. A buyer’s screenshot is useful context, not the authoritative receipt. Keep the order reference and payment state separate from the file-delivery record. If something disagrees, compare those records through a known contact route before attempting another payment.

Practice on paper

Arrange these fictional events: the buyer approves; the artist creates an invoice; a block includes the transaction; the wallet broadcasts; the artist records settlement under their policy.

Reveal the worked answer

Invoice → approval → broadcast → block inclusion → settlement check. A particular policy can require more confirmations. The invoice and approval alone do not prove that the artist received usable funds.

Check your understanding

Choose an answer in your head or on paper, then reveal the explanation. Retry whenever you like. Answers are not submitted or scored; completion marks are your own learning notes.

1. Does opening an invoice transfer funds?

  • Yes
  • No
Reveal answer 1

No. A request and authorization are separate.

2. Which record should an artist verify?

  • Only the buyer’s screenshot
  • Their own receiving record and settlement conditions
Reveal answer 2

Their own record. Screenshots can be mistaken or fabricated.

Take this with you

Track a payment’s state before deciding what happens next.

Your learning, at your pace

Read every lesson freely. Optional progress tracking needs JavaScript and browser storage; it does not require an account or wallet.