Onboarding assembles a small graph of resources around one Business. Understanding these resources — and which are standalone entities versus links between them — makes every request on the following pages read clearly.

---

The entity graph

A Business is the root. Everything else either belongs to it or is linked to it.

graph TD
    B[Business<br/>bus_…]
    B --> O[Owners<br/>own_…]
    B --> S[Signatories<br/>sig_…]
    B --> BA[Bank Accounts<br/>ba_…]
    B --> A[Addresses<br/>addr_…]
    B --> L[Locations<br/>loc_…]
    B --> SVC[Services<br/>acquiring, …]
    B --> D[Documents<br/>doc_…]
    O -.links.-> I[Individual<br/>ind_…]
    S -.links.-> I
    L --> LP[Processing profile<br/>+ location services]

---

Resources

Business

The legal entity being onboarded — the root resource, addressed at /v1/businesses/{businessId}. It carries the legal name, trade name, tax IDs, incorporation details, industry, contact details, and the services it wants. Its businessType sets the KYB rules that apply (see below).

businessType is one of: c_corporation, s_corporation, llc, single_member_llc, llp, partnership, sole_proprietor, government, nonprofit, tax_exempt_501c3.

Individual

A person, addressed at /v1/individuals/{individualId}. Individuals are shared and standalone — the same person can be an owner of one business and a signatory of another. You create an Individual once (or inline while creating an owner/signatory) and link it wherever needed.

An Individual carries two deliberately separate identity fields:

taxId.type is ssn, itin, or foreign. governmentIds[].type is drivers_license, passport, national_id, or state_id.

Owner (a link)

A beneficial owner of a business — a link between an Individual and a Business at /v1/businesses/{businessId}/owners. An owner carries:

• ownershipPercentage — the person's ownership stake (a number, up to two decimals).
• isControlPerson — whether this person also holds significant managerial control (the KYB/CDD control prong). This is independent of ownership: a majority owner need not be the control person, and the control person need not own the most.

Exactly one owner or signatory across the business must be marked as the control person.

Signatory (a link)

An authorized signer for the business — a link at /v1/businesses/{businessId}/signatories. Carries isPrimary, isGuarantor, and a title. Like owners, signatories link to a shared Individual.

Bank Account

A funding, billing, or settlement instrument at /v1/businesses/{businessId}/bank-accounts. purpose[] is one or more of funding, billing, reserves, chargeback, recovery, sweep; accountType is checking or savings. On read, the account number is masked to accountNumberLast4 and the routing number is not returned.

Address

A business address at /v1/businesses/{businessId}/addresses. type is one of registered, mailing, physical, headquarters, home, work. Addresses supplied inline on create come back with generated addr_… ids.

Location

A site where the business operates, at /v1/businesses/{businessId}/locations. A location carries its own address plus a processing profile — estimated monthly volume, average/high ticket, and a cardMix (swiped / MOTO / eCommerce percentages that must total 100) — and an industry (its MCC code and description). Volume and card mix live on the location because they are per-site facts, not company-wide ones.

Service and Feature

The capabilities a business turns on, expressed as a desired-state map keyed by service code. For this release the relevant code is acquiring (Accept Payments). A service can carry features one level down (for example acq.surcharge, acq.card_not_present, acq.amex_optblue).

You write the whole services map with PATCH /v1/businesses/{businessId}/services; PCE returns each service's status plus what it still needs — missingFields, missingDocuments, and errors — read-only fields it computes for you.

🚧

PENDING-PUBLISH

The underlying model also exposes a banking service code. It is out of scope for this release (Accept Payments only) and appears here only to explain the map shape. Do not document banking as available until Treasury enablement ships. Confirm the full feature-code list for acquiring against the API Reference before publish.

Document

A file bound to a business — for example a signed merchant_agreement. A document is uploaded, then bound to the business by reference (doc_…).

🚧

PENDING-PUBLISH

Documents are only partially implemented: a business create/GET accepts and returns a documents[] binding today, but the standalone Document resource (upload store, download) is planned, and the upload mechanism (multipart vs. pre-signed URL) is not finalized. Document examples in this section are tagged where they depend on unreleased behavior.

---

Identifiers and references

• Every resource has a type-prefixed id (bus_…, ind_…, own_…, sig_…, ba_…, addr_…, loc_…, doc_…) that PCE generates.
• On a business GET, every embedded child also carries a fully-qualified uri, and the response includes a top-level _links block for collection navigation — so you always have the exact path to update or read a child.
• You may attach your own externalId to any resource and resolve it later with ?externalId= on a list endpoint.

---

KYB rules that shape a payload

businessType drives several validations enforced at create time. The common ones:

See Error handling for the exact messages these produce.

---

Next steps

See also

• Create a business: composite create and per-business-type scenarios
• Manage an entity: change resources after creation