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 it can accept payments. 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 the service you enable: read services.payin.card.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 payin.card]
    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 the service (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 process payments.
4. DECLINED: the application was not approved.

A service can also report two other states. PARTIALLY_ENABLED means some locations are enabled while others are still in PENDING_REQUIREMENTS or PENDING_UNDERWRITING. DISABLED means the service is turned off.

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.
• At least one bank account attached (where settled funds land, fees are paid, or both).
• Any required documents provided.

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",
        "missingFields": [],
        "missingDocuments": [],
        "errors": []
      }
    }
  }
}

Empty arrays with status: PENDING_UNDERWRITING mean the service has everything it needs and is waiting on a decision. Non-empty arrays 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