---
title: "List Payer Accounts"
method: GET
path: "/payables/payer_accounts"
tags: ["Payer Accounts"]
---

# List Payer Accounts

`GET /payables/payer_accounts`

## Request

- Base URL: `https://api.justifi.ai/v1`
- URL: `https://api.justifi.ai/v1/payables/payer_accounts`
- Auth: none declared. Required headers: `Authorization`
- TypeScript: <https://skmtc.dev/justifi/apis/justifi-api-documentation/docs/payables/payer_accounts/get.ts> (a function with typed inputs; its response is checked against the schema)

List the payer accounts your credentials can access — the platform-level (Tier 2) read backing the
cross-account view and account switcher; scoped credentials return only the ones they cover. Payer
accounts are provisioned when a platform onboards a business — there is no customer-facing create
endpoint.

## Query parameters

- `after_cursor` string
- `before_cursor` string
- `limit` integer
- `status` 'pending' | 'active' | 'disabled' | 'archived'
- `business` string
- `name` string
- `payer_id` string

## Headers

- `Authorization` string, required

## Response `200`

Successfully listed payer accounts

- object: the standard JustiFi response envelope for a list of records
  - `id` unknown, required
  - `type` string, required: the object type
  - `data` object[], required: the list of objects
    - `id` string: unique payer account id
    - `type` string: the object type, matching the enclosing envelope's `type`
    - `business_id` string: the JustiFi business this payer account belongs to. Requests operate *within* a payer account (see the `/v1/payables/payer_accounts/{payer_id}/…` routes); `business_id` records the owning business for reporting and cross-account grouping, it is not the request scope. Discover a business's payer accounts with `GET /v1/payables/payer_accounts?business=biz_…`.
    - `name` string: display name for the payer account
    - `mode` 'test' | 'live': whether this payer account operates against real money. Inherited from the JustiFi account it belongs to — a test account and a live account are different accounts with different ids, so a payer account is one or the other for its life and cannot be switched. In `test`, payments run against a simulated ACH network: they complete in seconds rather than banking days, and no money moves.
    - `status` 'pending' | 'active' | 'disabled' | 'archived': the payer account's Payables lifecycle state, and what each state prevents. `pending` — provisioning has begun but the risk platform has not yet reported the business Payables-ready; `active` — Payables-ready, and the only state under which anything can be created; `disabled` — was active previously, and can no longer schedule payments, create payees or register bank accounts; `archived` — the same, and permanent: an archived payer account cannot be reactivated. A payment whose payee credit is already held is not paid out while the account is not `active`. It stays held until the account is active again, rather than failing.
    - `provisioned_at` string, date-time, nullable: when the payer account was provisioned to use Payables; null until provisioning completes
    - `funding_bank_account_id` string, nullable: pointer to the payer account's active funding bank account. In this version a payer account has a single active funding account. Null until one is registered and verified.
    - `created_at` string, date-time
    - `updated_at` string, date-time
  - `page_info` object, required: cursor pagination info
    - `start_cursor` string: the encoded id of the first record in the current page
    - `end_cursor` string: the encoded id of the last record in the current page
    - `has_next` boolean: true if there are records following the current page
    - `has_previous` boolean: true if there are records ahead of the current page

## Other responses

- `400`: The request was malformed, failed validation, or referenced a resource that cannot be used in its current state — for example scheduling a payment to a payee that is not active, or creating anything under a payer account that is not active. When the failure is field-level, `error.details` carries one array of messages per rejected attribute.
- `401`: The access token is missing, expired, or invalid.
- `403`: The credentials are valid but not permitted to access this resource.
- `429`: The rate limit has been exceeded. Back off and retry after the interval indicated by the `Retry-After` header.

---

[API](https://skmtc.dev/justifi/apis/justifi-api-documentation.md) - [All operations](https://skmtc.dev/justifi/apis/justifi-api-documentation/llms.txt) - [OpenAPI document](https://skmtc.dev/justifi/apis/justifi-api-documentation/revisions/dd9f3fed7e46?raw)