Recipients
Save payees in-product; discuss hygienic labeling and fraud awareness without exchanging account payloads.
Individual (mock)
Individual · recipient directory (mock)
Recipients
+ Sample addAcme Payroll (demo)
Routing shown only in-app • Payroll
Harbor Freelance cohort
Routing shown only in-app • USD
Studio rental • sample
Routing shown only in-app • Landlord
Illustrative mock • not signed-in data • not a real screenshot
- Payee nicknames resemble product copy but contain no routed account numbers.
- Add or approve recipients only behind authentication.
Overview
Recipients anchor every payment: the nickname you tap, routing metadata behind the scenes, and the rituals that catch typos before money leaves. Maintain payees strictly inside authenticated flows; Community discusses habits and fraud cues—not IBAN fragments or account digits.
Labeling and housekeeping
- Prefer unique nicknames that cannot be mistaken for similarly named freelancers or relatives.
- Archive or delete payees once relationships end so autofill can't resurrect stale rails.
- Keep business versus personal tagging meaningful for your own bookkeeping—avoid posting tax IDs verbatim.
Before saving a recipient
- Enter routing data only inside secure onboarding fields—not notepad screenshots shared to “help.”
- For meaningful amounts, verify out-of-band with a trusted contact method only you control.
- When unsure about timelines, queue a nominal test send instead of debating hypothetical wiring maps publicly.
- If onboarding errors repeat, escalate with Support—including reference labels only inside authenticated chat.
Discuss safely
Typo fears
Compare reversible vs irrevocable rails in general—you never need to post masked numbers “just in case.”
Scam impulse
If someone demands instant screenshot proof of payee edits, freeze the conversation—they may be staging social engineering.