Payments for humans, including Lightning

Begin with an agreement

A useful payment begins with people agreeing what is being exchanged. For an art commission, that includes the work, price, delivery, permitted use, revisions and refund terms. Paying in bitcoin does not by itself explain those terms or transfer copyright.

Consider an imaginary illustrator and buyer. The illustrator describes the work and sends a request for an agreed amount. The buyer checks that it came from the right person. A payment method should support that relationship, not make either party guess what they agreed to.

On-chain and Lightning take different paths

An on-chain Bitcoin transaction is broadcast to the network and can be included in a block. The recipient chooses an appropriate confirmation policy before treating it as settled. A broadcast is not the same as a confirmation.

Lightning uses payment channels anchored to Bitcoin. It can make quick payments possible without putting every individual payment on-chain. A usable route and sufficient liquidity are still needed; a payment attempt can fail. Wallets may also differ in custody and availability.

Use the payment method the recipient actually supports. Bitcoin, Litecoin and an Ethereum-style address are not interchangeable destinations. This lesson does not require you to scan a code or send anything.

Read the source: Bitcoin developer guide · Payment processing · Lightning Labs · Network overview

Read before you scan

Check the recipient, asset/network, amount, units, fees and expiry. An invoice may quote local currency and translate it to a bitcoin amount for a limited time. If the quote expires, ask for a current request rather than assuming an old amount is still valid.

A QR code is simply a way to carry information. It does not establish who created the request or whether it is fair. Review what your wallet displays before approving any real transaction, and use a known contact route when the details disagree.

Read the source: BTCPay Server · Invoice states and settlement

Look at the outcome, not a screenshot

A payment request can be awaiting payment, paid but awaiting settlement conditions, or settled. An on-chain payment may need confirmations. Lightning normally settles without waiting for an on-chain confirmation for each payment, but an attempted payment is not automatically a completed one.

If an attempt is pending or times out, inspect its status before trying again. A timeout can leave the result uncertain. A failed attempt, an expired invoice and a settled payment call for different next steps. A screenshot saying “sent” does not replace the recipient’s own settlement check.

Read the source: BTCPay Server · Invoice states and settlement · BTCPay Server · Greenfield API payment status

Use the tool without losing the relationship

Kalakar.x proposes direct artist payments with clear terms and a verified receiving setup. It does not currently promise a live marketplace, escrow or guaranteed payout. An artist’s optional contribution to Langar would be a separate choice, never a hidden deduction.

When you can explain the request, identify who receives it and tell what happened afterward, you have learned more than how to press a payment button.

Read an imaginary invoice

A sample invoice says “20,000 sats · Bitcoin Lightning · expires at 15:00.” At 15:02 the payer has a “pending” screen. What should the payer and artist verify before another attempt or delivery?

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.