This guide gets you ready to onboard a business onto PCE through the API. It covers what onboarding is for, what it can and can't do in this release, and the credentials and base URLs you need before your first call.

If you already know the model, jump straight to Create a business. To understand the entities involved first, read Key concepts.

📘
What onboarding gives you
A successful onboarding produces a Business entity (and its owners, signatories, bank accounts, addresses, locations, and services) that underwriting can review and approve. Once approved, that business can accept payments. Onboarding does not itself move money.

Scope of this release

📘
Accept Payments only
Entities onboarded through these APIs are provisioned for Accept Payments (card acquiring). Enabling Treasury Solutions (banking accounts, money movement) for an onboarded entity is out of scope for this release. Anywhere this section mentions the acquiring service, that is the Accept Payments capability. The banking service and other capabilities may appear in examples of the underlying model but are not supported end-to-end yet — treat them as not available until this section says otherwise.

In scope: create and manage a Business and its sub-resources; enable the acquiring service; track boarding status through underwriting.
Out of scope (this release): Treasury/banking enablement, card issuing, and any money movement for the onboarded entity.

Before you begin

Ensure you have the following in place before you start.

Item	Description
Partner / platform access	Onboarding is a partner-facing surface: you onboard businesses on behalf of merchants. Contact the PCE Integration Support team to be provisioned for the boarding API.
Bearer token	Every onboarding endpoint authenticates with a bearer token (`Authorization: Bearer <token>`). Contact PCE Integration Support to obtain your credentials.
API base URLs	Use the environment that matches your integration stage: Sandbox: `https://sandbox-api.prioritycommerce.com/v1` Production: `https://api.prioritycommerce.com/v1`
HTTPS	All requests must be made over HTTPS.

🚧
PENDING-PUBLISH
Confirm the boarding auth model against the published API Reference before publish: the contract specifies a bearer token on every endpoint, and the Document endpoints require that bearer token specifically (an x-api-key is rejected there). Confirm whether partners use the same x-api-key used elsewhere in PCE, a dedicated bearer token, or both, and update this table accordingly.

Conventions

These apply to every onboarding endpoint. They are collected once here so the action pages stay short.

Convention	Rule
Response shape	A single resource returns a flat JSON object — the resource fields at the top level, no `{ data: … }` envelope. A list returns a bare JSON array.
One Business shape	`POST`, `GET`, and `PATCH` on a business all return the same object shape. Only the populated values differ by lifecycle stage.
Identifiers	IDs are opaque, type-prefixed strings — `bus_…`, `ind_…`, `own_…`, `sig_…`, `ba_…`, `addr_…`, `loc_…`, `doc_…`. PCE generates them; you never construct one.
`externalId`	Your own optional reference on any resource. Immutable once set. Resolve it via `?externalId=` on a list endpoint — never as a path segment.
Idempotency	Send an `idempotency-key` header on `POST` so a retried create isn't duplicated.
Money & numbers	Percentages, caps, and counts are plain JSON numbers (for example `ownershipPercentage: 50.00`).
Phone	E.164 where required (for example `"+15125551234"`).
Timestamps	ISO-8601 UTC strings — `createdAt`, `updatedAt`.
Sensitive fields	Written in full, returned masked: `accountNumber` → `accountNumberLast4`; `routingNumber` is not returned on read; `taxId.value` → `lastFour`; `governmentIds[].number` → `numberLastFour`.
Updates	`PATCH`, never `PUT`. The root `PATCH` changes business-owned fields only; existing children are changed on their own endpoints.
Deletes	Non-destructive. A business `DELETE` soft-closes it; owner/signatory `DELETE` end-dates the link; a bank account `DELETE` retires the instrument.

🚧
PENDING-PUBLISH
idempotency-key and identifier prefixes are drawn from the boarding contract, where the prefix decision was still marked open. Confirm both against the published API Reference before publish.

Send your first call

The smallest possible onboarding call creates a business with just a legal name. It comes back in PENDING_REQUIREMENTS with everything else still to be filled in.

POST /v1/businesses

{
  "legalName": "PCETest Downtown Coffee LLC"
}

You get back a business object with a generated bus_… id and status: PENDING_REQUIREMENTS. Store the id. From here, Create a business walks through a complete, underwriting-ready payload.

Next steps

Key concepts

The entities you'll assemble and how they relate.

Create a business

Build a complete, underwriting-ready business.

Getting Started

What onboarding gives you

Scope of this release

Accept Payments only

Before you begin

PENDING-PUBLISH

Conventions

PENDING-PUBLISH

Send your first call

Next steps

See also