Read payout capabilities for one recipient
What a payout to this recipient would be allowed to do: one option per bank rail of the user’s that could reach them, each carrying its limits, fees, memo and purpose-code rules, and the blockers that stand in the way. Reads the provider’s live channel catalogue where one exists (Due), falling back to our declarations otherwise. Takes either a saved contactId or raw account requisites; books, quotes and writes nothing.
Authorizations
Bearer authentication header of the form Bearer <token>, where <token> is your auth token.
Headers
Body
Ask what a payout to one recipient would be allowed to do.
Either end of the client's flow answers the same question, so the request
takes either: contactId for a recipient already saved, account for
the form that has not been submitted yet. amount is optional and only
has the rail limits checked against it — nothing is quoted or booked.
SEPA bank contact input.
- SepaAccountInput
- SwiftAccountInput
- AchAccountInput
- UaeAccountInput
- UkFpsAccountInput
- PixAccountInput
Address schema for user.
Canonical field names: street_address, address_line_2, city, state, country, zip. Accepts legacy Align/IBAN field names (street_line_1, street_line_2, postal_code) for backward compatibility with existing JSONB data.
How a payout contact relates to the user.
The vocabulary mirrors Swipelux's recipient relationships so the common
values project onto their API unchanged, but this is our own domain type:
SELF marks a first-party payout to the user's own account at another
bank and has no Swipelux counterpart. Providers own that projection — see
SwipeluxRecipients._recipient_relationship — so nothing here depends on
a provider, and no provider enum has to carry a value it cannot accept.
employee, contractor, vendor, subsidiary, merchant, customer, landlord, family, other, self x > 0Response
Successful Response