Onboarding isn't instant. You create a business and add the people, bank account, location, and documents it needs. You then enable a service, and that service goes through underwriting before the business can use it. This page is the shared reference for that lifecycle. Every action page links here instead of repeating it.

The business record itself carries no status. Progress lives on each service you enable: read its status, for example services.payin.card.status or services.treasury.fbo.status, to see where the business is in boarding. See Service lifecycle for the full service and feature status enums.

The boarding lifecycle

graph LR
    CREATE([Create business])
    PARTS[Add owners, bank account, location, documents]
    ENABLE[Enable a service]
    REQ[PENDING_REQUIREMENTS]
    UW[PENDING_UNDERWRITING]
    LIVE([ENABLED])
    DECL[DECLINED]

    CREATE --> PARTS --> ENABLE --> REQ
    REQ --> UW
    UW --> LIVE
    UW --> DECL

    classDef start fill:#003E29,stroke:#01271A,color:#FFFFFF,font-weight:bold
    classDef step fill:#FFFFFF,stroke:#003E29,color:#01271A
    classDef done fill:#E7E5AA,stroke:#003E29,color:#01271A

    class CREATE,ENABLE start
    class PARTS,REQ,UW,DECL step
    class LIVE done

The states on each service (for example services.payin.card.status) are:

1. PENDING_REQUIREMENTS: a service is enabled, but the business is still missing data or documents. What's outstanding is surfaced inline (see below).
2. PENDING_UNDERWRITING: requirements are complete and the service is waiting on a decision.
3. ENABLED: approved and active. The business can use the service.
4. DECLINED: the application was not approved.

A service can also be DISABLED, meaning it is turned off. Card processing can also report PARTIALLY_ENABLED, meaning some locations are enabled while others are still in PENDING_REQUIREMENTS or PENDING_UNDERWRITING. Treasury and payout services never report PARTIALLY_ENABLED.

How underwriting works

Underwriting is asynchronous. Once a service has everything it needs, PCE submits it for review and keeps its status in sync, so allow a short delay. A few things worth knowing:

• Progress lives on the service. Before you enable a service, the business simply saves your data. Once enabled, the service sits in PENDING_REQUIREMENTS while you complete it, moves to PENDING_UNDERWRITING when it's done, and reaches ENABLED on approval.
• Read the business to see the outcome. There are no status webhooks.

Before you can enable a service

A service can't go to underwriting until the business has the basics attached. For Accept Payments (services.payin.card), that means:

• The business is created.
• At least one owner or signatory, with exactly one marked as the control person.
• At least one location with its processing profile.
• A funding and a billing bank account. See Bank accounts for a location.
• The signed merchant agreement, and any other required documents.

For Treasury and payout services, the business needs its type, tax ID, incorporation date, registered address, and owners. No location or bank account is needed. A business-owned deposit account (treasury.owned) also needs the account agreement.

When these are in place, enable the service. PCE then tells you if anything is still missing (see below) before moving the service to review.

What's still needed

Onboarding has no separate "requirements" resource to poll. Instead, the service object on the business carries three read-only fields that tell you what's outstanding:

Read them with a GET request to /v1/businesses/{businessId} (add ?expand=true) and inspect services.payin.card.

curl "https://sandbox-api.prioritycommerce.com/v1/businesses/{businessId}?expand=true" \
  -H "x-api-key: <your-key>"

Response: 200 OK (the services.payin.card subtree).

{
  "services": {
    "payin": {
      "card": {
        "enabled": true,
        "status": "PENDING_UNDERWRITING"
      }
    }
  }
}

The three fields are left out when there is nothing to report. A service with status: PENDING_UNDERWRITING and none of them has everything it needs and is waiting on a decision. When they appear, they tell you precisely what to fix or add.

Status by resource

Status lives on the resources that have one, and the business's overall readiness is the combination. The business, location, individuals, owners, and signatories carry no status of their own; a location's status is shown through its services and features.

Statuses are written in upper snake case (ENABLED, ACCEPTED). The API returns document statuses in lowercase (for example accepted).

Status journeys

Each resource that carries a status moves through a fixed set of states. The service's journey is the boarding lifecycle shown above; its features and documents move as follows.

Feature

graph LR
    IP[IN_PROGRESS]
    ON([ENABLED])
    OFF[DISABLED]

    IP --> ON
    ON --> OFF

    classDef start fill:#003E29,stroke:#01271A,color:#FFFFFF,font-weight:bold
    classDef step fill:#FFFFFF,stroke:#003E29,color:#01271A
    classDef done fill:#E7E5AA,stroke:#003E29,color:#01271A

    class IP start
    class OFF step
    class ON done

A feature is requested and set up (IN_PROGRESS), becomes ENABLED, and moves to DISABLED when it is turned off.

PENDING_DISABLE is a rare fourth feature status, kept out of the flow above. It means the feature has been turned off but is not fully off yet. PCE is waiting for the processor to confirm, then the feature becomes DISABLED. You see it only on a location-level feature that is enabled at some of a business's locations and not others. It shows only on a location's full detail: expand the location on the business read (?expand=true), or read the location directly.

Document

graph LR
    PU[PENDING_UPLOAD]
    AC([ACCEPTED])
    RJ[REJECTED]

    PU --> AC
    PU --> RJ

    classDef start fill:#003E29,stroke:#01271A,color:#FFFFFF,font-weight:bold
    classDef step fill:#FFFFFF,stroke:#003E29,color:#01271A
    classDef done fill:#E7E5AA,stroke:#003E29,color:#01271A

    class PU start
    class RJ step
    class AC done

A document waits for its file (PENDING_UPLOAD), then becomes ACCEPTED, or REJECTED if the file fails the security scan.

Tracking a business

Make a GET request to /v1/businesses/{businessId} again to follow status changes as you complete requirements and as underwriting decides. Re-reading the business is the way to see a change; there are no status webhooks.

Poll on a gentle cadence and let the work set how often you read:

• While you complete requirements, read the business back after each change to confirm missingFields, missingDocuments, and errors cleared.
• While you wait on the decision, poll on an interval and apply exponential backoff between reads rather than tight-looping.
• Stop polling once the service reaches a terminal state (ENABLED, DECLINED, or DISABLED).

Onboarding does not emit status webhooks, so polling is the only way to follow status.

Next steps

See also

• Service lifecycle: the full service and feature status enums
• Create a business: where the lifecycle begins
• Underwriting exceptions: in-flight requirements and rejections