State machines and freezing

​

📄 Guide

Onboarding, employee creation and issuing each have their own state machine; freezing is a capability-domain switch layered on top. This page covers them all, so the status fields in later endpoints map straight onto it.

​

The application state machine

Company, employee and card applications share one state machine with three states: PENDING / SUCCEED / REJECTED. After a rejection, resubmit under the same the application ID (see Compliance and KYC).

​

The company / employee state machine

Presented as one merged status field: a life-cycle state (ACTIVE / TERMINATED) overlaid with behavioral states (FROZEN / SUSPENDED / RESTRICTED). Whether an entity can open cards or spend is judged by whether it is ACTIVE.

​

The card state machine

7 states, shared by virtual and physical cards. Every state change pushes a card-status-change notification (activation is pushed separately as CARD_ACTIVATED); see the webhook event table in the API reference for event names.

​

Freeze capability domains

5 domains, applicable to companies and employees. Adding a state freezes, removing it unfreezes — idempotent set semantics; restricted states written by risk, regulatory or judicial action cannot be lifted this way. Freezing has two granularities: freezing a card stops only that card, while freezing an employee makes every card under them decline. The endpoints are in Company status and alerts and Employee information and status.

​

Next steps

• A transaction’s full journey from hold to posting: The transaction life cycle
• KYB / KYC subjects, resubmission and uniqueness rules: Compliance and KYC