Payment Method Types

Payment methods are the tokenized instruments — cards, bank accounts, and synthetic accounts — you use to accept payments, send payouts, and fund both through deposits and withdrawals.

A payment method is a secure, tokenized representation of a source or destination for funds — a credit or debit card, a bank account, or an internal synthetic balance. It can belong to an account or exist independently. Once created, Payload can store it so you can charge it, pay out to it, and reuse it across transactions without handling or re-collecting sensitive details. Payment methods can be created on their own or inline with a transaction.

Every payment method in Payload is a single polymorphic object. They share the same shape, the same endpoints, and the same core fields. The type field (card, bank_account, or synthetic) determines which type-specific details apply and how the method can be used.

This means you create, update, store, and verify every payment method the same way. Only the type-specific block and a few type-dependent fields change between them.

The Types

Card

Store credit and debit cards for instant checkout and digital wallet payments.

Bank Account

Use checking and savings accounts for payments, digital wires, payouts, and transfers.

Synthetic

Enable embedded banking with internal balances and instant fund transfers.

One Object, Many Types

The type field is the discriminator. Each type populates a nested block of the same name — a card payment method carries a card block — while sharing the common fields listed below.

`type`	Typical use
`card`	Credit and debit cards for payments, autopay
`bank_account`	Payments, payouts, and transfers
`synthetic`	Internal balances and embedded banking

Whatever the type, every payment method shares the same core fields. Because the object and its endpoints are identical across types, the same creation, storage, and verification flows apply to all of them.

Because payment methods are one object, you don't need type-specific endpoints. Create any type through the Payment Method API and set type accordingly.

Core Fields

Field	Type	Description
`id`	string	Unique identifier for the payment method.
`type`	string	Discriminator: `card`, `bank_account`, or `synthetic`.
`account_id`	string	The account that owns this payment method.
`keep_active`	boolean	Whether the method stays stored for reuse (`true`) or is single-use (`false`).
`status`	string	Current operational status of the payment method.
`verification_status`	string	Level of verification the payment method has completed.
`billing_address`	object	Billing address used for address verification and records.
`description`	string	Human-readable label for the payment method.

Using Payment Methods

Once created, a payment method is referenced by its id — the same tokenized method can be used across many transactions without re-collecting sensitive details. Common uses:

Use case	What it does
Accept payments	Charge a payment method — stored or inline — for one-time or on-demand payments.
Authorize, then capture	Hold funds first and capture the payment later, in two steps.
Recurring billing & autopay	Reuse a stored method for subscriptions and automatic payments.
Send payouts	Disburse funds to a method that can receive them (`receive_only`/`two_way`).
Fund accounts	Move funds into or out of your accounts with deposits and withdrawals.

The mechanics are the same for every type — a method's type and transfer_type determine which of these it supports.

Lifecycle & Status

Every payment method follows the same lifecycle regardless of type: it is created, optionally stored for reuse and verified, used in transactions, and eventually deactivated. A few shared fields describe where a method sits in that lifecycle.

Field	Values	Meaning
`status`	`active`, `inactive`, `declining`	Whether the method can currently be used.
`keep_active`	`true` (default), `false`	Whether the method is stored for reuse or single-use.
`used`	`true`, `false`	Whether the method has been used in at least one transaction.

A declining status means recent transaction attempts are failing and the method needs attention. Setting keep_active to false deactivates a method after a single use.

Transfer Direction

The immutable transfer_type field sets which directions a method supports — accepting payments, sending payouts, or both. Which directions apply depends on the type.

`transfer_type`	Allowed use	Common for
`send_only`	Accept payments from this method only	Cards (default)
`receive_only`	Send payouts to this method only	Bank accounts used as payout recipients
`two_way`	Accept payments and send payouts	Bank and synthetic accounts (default)

Funding

Payments and payouts are funded through funding transactions. A deposit moves funds into an account to fund a payment, and a withdraw pulls funds out to fund a payout. A payment method's default funding role is set with account_defaults.funding:

`account_defaults.funding`	Role
`deposits`	Funds `deposit` transactions — receives funds to back payments
`withdraws`	Funds `withdraw` transactions — pulls funds to back payouts
`all`	Funds both

The matching deposit and withdraw webhook events fire when these funding transactions are created.

Verification

Every type shares a verification_status field (not_verified, verified, or owner_verified), but how a method is verified differs by type — AVS and CVV for cards, Plaid or Payload's built-in verification for bank accounts, and no external verification for synthetic accounts.