After a business is created, you rarely change everything at once. Onboarding uses isolated updates: the business's own fields change on the root PATCH, and each child (owner, signatory, bank account, address, location) changes only on its own endpoint. This keeps every change small, auditable, and validated against the one resource it touches.

Get the exact paths for a business's children from GET /v1/businesses/{businessId}?expand=true — each child carries its own id and uri, and the response includes a top-level _links block.

Update the business's own fields

The root PATCH accepts only business-owned fields — merge semantics, so send just what changes.

PATCH /v1/businesses/{businessId}

{ "tradeName": "Acme Pay", "website": "https://acmepay.com" }

Allowed: legalName, tradeName, businessType, businessDescription, website, email, phone, taxIds, incorporations, industry, services, documents.

Sending a child collection (owners, signatories, bankAccounts, addresses, locations) on the root PATCH is rejected with 422 and a message pointing you to the child's own endpoint.

Manage sub-resources

Each collection supports create (POST), read (GET), update (PATCH), and non-destructive removal (DELETE) on its own path.

Add an owner

POST /v1/businesses/{businessId}/owners

{ "individualId": "ind_def-456", "ownershipPercentage": 25.00, "isControlPerson": false, "title": "Investor" }

Ownership is re-validated on every write — the total across owners can't exceed 100%.

Update an owner

PATCH /v1/businesses/{businessId}/owners/{ownerId}

{ "ownershipPercentage": 20.00, "title": "Minority Investor" }

Bank account: change vs. replace

purpose, isPrimary, accountType, and bankName are editable. accountNumber and routingNumber are not editable once created — add a new bank account and retire the old one.

Toggle services and features

Services are a desired-state map written whole and merged: an omitted service code is left untouched; to disable something, send it explicitly with enabled: false.

PATCH /v1/businesses/{businessId}/services

{
  "acquiring": {
    "enabled": true,
    "features": {
      "acq.amex_optblue": { "enabled": true },
      "acq.surcharge": { "enabled": false }
    }
  }
}

Read one service with GET /v1/businesses/{businessId}/services/acquiring. A location can override a service (currently acquiring) at .../locations/{locationId}/services/acquiring.

🚧

PENDING-PUBLISH

Scope: only the acquiring service is supported end-to-end in this release. The banking service appears in the underlying model but is out of scope (Treasury not enabled for onboarded entities yet). Confirm the supported acquiring feature codes against the API Reference before publish.

Close a business

Closing is a soft-close, not a hard delete. The record is retained and the business stops accepting new activity.

DELETE /v1/businesses/{businessId}

Returns 204 No Content; the business transitions to CLOSED.

🚧

PENDING-PUBLISH

Because closes are non-destructive and externalId is immutable once set, an externalId currently can't be reused after a close. Confirm the exact close behavior and whether externalId reuse is permitted before publish.

Next steps

See also

• Create a business: the composite create these updates build on
• Key concepts: what each resource represents