Account Types

Accounts model the parties on your platform — all one object, distinguished by its type.

An account represents a party on your platform: one you collect payments from, or one that accepts payments and sends payouts. Payload models both as a single polymorphic object under one /accounts endpoint. The type field — customer or processing — determines what an account can do and what it requires.

Because every account shares the same object and endpoints, you create, query, filter, and manage them the same way, and new types can be added without new endpoints.

The Types

Type	`type`	What it does	Requires
Customer	`customer`	A payer or recipient — collect payments from it or send payouts to it.	Entity optional
Processing	`processing`	Receives payments, sends payouts, and manages funding.	Entity (KYC) + onboarding

Every transaction requires a processing account — on the sender or receiver side, depending on the transaction type. Customer accounts are optional: use them to model payers and recipients when it fits your use case, but many integrations don't need them.

Customer

Customer accounts represent the payers and recipients you transact with, and are optional — depending on your use case you may not need them at all. They have no inherent processing capability and need no KYC for basic use — a customer account can pay an invoice, be charged with a stored payment method, or receive a payout. A customer account can be nested under a processing account with parent_id, inheriting its access and acting against it as the default opposing party.

Processing

Processing accounts accept payments and send payouts on your platform, and every transaction involves one — on the sender or receiver side, depending on the transaction type. They require an attached entity for KYC/KYB and go through onboarding before they can process. Beyond receiving payments, a processing account can also send payments, receive payouts, and act as the payer on payment links or invoices. Processing-specific configuration — funding, pricing, agreement, and status — lives under the account's processing object.

Generic accounts (coming soon): A flexible account type for internal use cases, testing, or custom workflows that don't fit the customer or processing patterns.

Shared Fields

Whatever the type, every account shares the same core fields:

Field	Type	Description
`id`	string	Unique identifier, prefixed `acct_`.
`type`	string	Discriminator: `customer` or `processing`.
`name`	string	Business or person name; appears on invoices and payment pages. Required for processing accounts; optional for customer accounts when `email` is set.
`email`	string	Primary contact email.
`entity_id`	string	The legal entity for KYC/KYB (required for processing accounts).
`parent_id`	string	Parent processing account, for nested customer accounts.
`profile_id`	string	The organization profile that owns the account.
`payment_methods`	array	Payment methods used to pay or to receive payouts.
`processing`	object	Processing-only configuration (funding, pricing, agreement, status).
`contact_details`	object	Phone, website, and address.
`keep_active`	boolean	Whether the account is retained for reuse or one-time.
`attrs`	object	Custom key-value attributes.

An account has no single top-level status field. For processing accounts, operational state lives under processing.status — paying (active / disabled) and funding (pending / active / disabled / on_hold).

Accounts and Entities

An entity is a separate legal-identity object — an individual or a business — used for KYC/KYB compliance. An account references one through entity_id, or you can create it inline. Entities are required for processing accounts and optional for customer accounts, though recommended for any account handling high-value transactions. One entity can be reused across multiple accounts. See Managing Entities.

Creating Accounts

Every type is created through the same /accounts endpoint, via one of three methods:

Accounts API — create accounts programmatically. You control compliance and terms capture, so creating processing accounts this way is an advanced path.
Enrollment Link — a secure, Payload-hosted onboarding page shared by URL, email, or SMS. Compliance, consent, and terms are handled for you.
Enrollment Plugin — the same hosted onboarding embedded directly in your app as a modal or inline form.

Once created, configure which payment methods an account uses by default with Default Methods.