Money
Receive by link, button or QR
Offer an easy payment path while preserving the actual recipient, payer approval and confirmed receiving result.
Create the receiving coordinate
- Open Receive
Start from the account that should receive the payment.
- Choose the link or QR
Copy the supported checkout link, website button or in-person QR. Optionally prefill an amount.
- Check the destination
Open the request as a customer and confirm the intended public recipient before sharing it.
- Confirm actual receipt
Check the receiving account/Ledger before treating an order as paid.
The customer chooses a method
The hosted payment page supports its current Card, Balance and Note methods. It preserves the selected receiving account and amount through its existing review, funding and continuation paths. The payer approves the actual financial operation. A scan, public URL, account connection or Note upload is not independent permission to spend.
| Item | What it does |
|---|---|
| Optional URL amount | Prefills an editable payment request. |
| Website button | Opens the supported hosted experience. |
| QR or NFC URL | Opens the same public payment coordinate on a compatible device. |
| Trusted merchant order | Your integration’s authoritative recipient, amount, reference and once-only fulfillment record. |
Install where it fits
Use a normal payment link on a platform that accepts URLs. A button requires an HTML/custom-code block. The existing widget requires scripts to be allowed by the website and its Content Security Policy. A platform that strips scripts cannot run that widget; use the normal hosted link. Do not put private identity files, signing keys, access tokens or session secrets into public HTML.
Receive a Note-funded payment
The payer’s Note is admitted under the existing reader and recipient rules. Offline receipt and confirmed account credit remain separate. The hosted flow waits for the supported exact credit before continuing the approved recipient payment. Back preserves unfinished credit and payment recovery; it does not cancel an operation already submitted. An unresolved payment exposes its status action without creating another transfer.
Match the merchant result
Confirm recipient, exact amount and payment reference in the merchant’s own recorded result. A customer’s screenshot, a success URL or a browser message cannot fulfill an order. An in-person QR is a phone payment entry, not a card-present terminal API. Trusted card sessions, fulfillment, refunds, subscriptions and payouts each require their own supported application contract and configured host; a checkout snippet does not grant them.
Implementation sources
Inspect the exact path.
Source links retain revision 6c5d582. Read the documented operation and assessment scope alongside its code.