A service carries its own status as it is enabled, reviewed by underwriting, and later turned off. Each feature inside a service carries a status too. For the business-level boarding flow these feed into, see Status lifecycle.

---

Service statuses

When you enable payin.card, the service reports its status on every business response at services.payin.card.status. It starts by collecting what it needs, moves into review, and ends up active, declined, or off.

graph LR
    START([Service enabled])
    REQ[PENDING_REQUIREMENTS]
    UW[PENDING_UNDERWRITING]
    PART[PARTIALLY_ENABLED]
    ON[ENABLED]
    DECL[DECLINED]
    OFF[DISABLED]

    START --> REQ
    REQ --> UW
    UW --> PART
    PART --> ON
    UW --> DECL
    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 START start
    class REQ,UW,PART,DECL,OFF step
    class ON done

While a service sits in PENDING_REQUIREMENTS or PENDING_UNDERWRITING, its missingFields, missingDocuments, and errors tell you what is still outstanding. See Underwriting exceptions.

---

Feature statuses

Each feature inside a service, such as cardNotPresent or mxAdvantage, carries its own status. A feature status is separate from the service status: a service can be ENABLED while one feature is still IN_PROGRESS.

A feature can also report PENDING_DISABLE in rare cases, while it is being turned off and PCE waits for the processor to confirm before it becomes DISABLED. It shows only on a location-level feature enabled at some of a business's locations and not others. See Status journeys.

---

Next steps

See also

• Supported services and features: the service and feature codes
• Underwriting exceptions: resolve what a service still needs