> For the complete documentation index, see [llms.txt](https://help.peoplevine.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.peoplevine.com/status-codes-reference.md). # Status Code Reference Quick-lookup reference for every status code across the Peoplevine platform. Use this page to understand what each status means, what triggers it, and what effect it has. > The "How It Is Used" column explains what each status means operationally — for billing, access, integrations, and staff workflows. *** ## Member Card Statuses The Member Card is the individual enrollment record linking a person to a Membership Program. These statuses control portal access and check-in. | Status | Description | Triggered By | How It Is Used | | ------------- | -------------------------------------- | ------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Active** | Full membership benefits | Enrollment, payment confirmed | Member has full portal access, check-in works, auto-charges fire on billing date, perks active. Sets `isMember=Y` and pushes to connected integrations (SevenRooms, POS, PMS, etc.). | | **Pending** | Awaiting approval or future start date | Enrollment with future start, admin sets | Portal blocked (no paywall — just no access). No check-in, no perks. Billing charges on next billing date — activates upon successful payment. Used for pre-sold memberships. | | **Suspended** | Temporarily inactive | Admin manually suspends; also auto-set when application approval payment fails | Portal blocked (no paywall — just no access). No check-in, no billing, no perks. All sub-members also blocked. Used for disciplinary holds or temporary pauses. Reactivate by setting back to Active, or set a reactivate-on date. | | **Failed** | Payment failed (auto-set by system) | Dues charge fails | Failed Dues Paywall on login — overrides all other memberships. No check-in, sub-members lose access immediately (cascading). System retries Day 3 and Day 7. After Day 7, no further automatic action — admin must manually process payment or change status. | | **Expired** | Past expiration date | Term expiration date reached, admin sets | Portal blocked (no paywall — just no access). No billing, no check-in. Used for term-based memberships. Reactivation requires changing the expiry date or enrolling the member into a new membership — payment alone does not reactivate Expired status. | | **Cancelled** | Membership terminated | Admin cancels, future cancellation date reached | Portal blocked (no paywall — just no access). No payments beyond cancellation date, sub-member statuses cascade. Can set old card back to Active or re-enroll as a new card. | | **Archived** | Soft deleted | Admin archives | Hidden from customer view. Still shows on CRM profile and in reporting. No billing, no access. Admin can restore. | > **Portal login priority**: If *any* membership is Failed, the member sees the Failed Dues Paywall regardless of other memberships. If no Failed and at least one Active, access is granted. Otherwise access is blocked — Suspended, Expired, and Cancelled show no paywall, just no access. *(Updated per Kim, Mar 16 — legacy Intercom article referenced per-status paywalls but current behavior is no paywall for these statuses.)* > **Note**: The enrollment form shows 8 card status options: Active, Pending/Paused, Suspended, Upgraded, Downgraded, Expired, Cancelled, Archived. The View Members filter shows 9: Active, Pending, Suspended, Cancelled, Payment Failed, Upgraded, Downgraded, Expired, Archived. The table above lists the 7 core statuses validated from the API; Upgraded, Downgraded, and Archived appear in the UI but are primarily subscription-level reporting statuses. *** ## Subscription Statuses The Subscription is the recurring billing record. Memberships are typically linked to a subscription and should be managed through that subscription. However, a membership can exist without a subscription and its status can be changed independently. | Status | Description | Triggered By | How It Is Used | | ------------------ | ------------------------------------------- | ------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Active** | Billing is running | Enrollment, payment resolved | Auto-charges on billing date. When tied to a membership, grants portal access. When tied to a product, auto-places an order on each cycle. Auto-reactivates when payment made via credit card, ACH, or invoice. | | **Pending/Paused** | Inactive until next billing date | Admin pauses, future start date | On the next billing date, payment is charged and subscription activates upon success. Access blocked until payment processed. Used for pre-sold or paused memberships. | | **Failed** | Payment failed (auto-set by platform) | Recurring billing fails | Deactivates membership immediately. Member sees Failed Dues Paywall and can pay to reactivate. System retries Day 3 and Day 7. Stops future processing until manual payment. | | **Suspended** | All future payments stopped | Admin suspends | No charges until admin reactivates. Used for disciplinary or administrative holds. | | **Upgraded** | Reporting status — upgraded to higher tier | Admin or age-based upgrade | Old subscription marked Upgraded; new subscription created on the new tier. Optional — only use if your operation needs this reporting. | | **Downgraded** | Reporting status — downgraded to lower tier | Admin action | Old subscription marked Downgraded; new subscription created on lower tier. Optional reporting status. | | **Expired** | All future payments stopped | Admin sets, or term expiration | No future charges. Used for term-based subscriptions that have ended. | | **Cancelled** | Subscription cancelled | Admin cancels (with optional future cancellation date) | No payments beyond cancellation date. A cancellation date field appears — leave blank for immediate or set a future date. Invoiced subscriptions do not auto-cancel for non-payment. | | **Archived** | Hidden from customer view | Admin action | No billing. Hidden from the customer-facing portal view. Still visible on the CRM profile and in reporting. Used to clean up the member-facing view while retaining records. | > **Important**: Only `Active` and `Pending/Paused` subscriptions with a next billing date in the future are processed by the billing engine. Subscriptions will automatically re-activate when a person pays with credit card, ACH, or invoice. > **Note on Upgraded/Downgraded**: These are optional reporting statuses. They do not need to be used but are available if your business operation requires this level of reporting. *** ## Transaction Statuses Transaction statuses track the state of individual financial transactions (dues payments, refunds, POS charges, etc.). | Status | Description | Triggered By | How It Is Used | | ------------------- | ------------------------------------ | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Authorized** | Pre-authorization taken | Initial charge attempt (common at POS) | Funds held on card but not yet captured. If the processor is configured for **Auto Capture**, funds are captured automatically (no manual action needed) and the status updates to **Processed**. If Auto Capture is not enabled, use the `capture` payment type to finalize manually. An **Auto Capture** tag appears alongside the Authorized tag in View Transactions. | | **Processed** | Payment successful | Charge completes | Funds captured and settled. For 3DS-enabled cards during auto-billing, this status may be temporary — Stripe can update it to Declined via webhook if the cardholder does not complete authentication. This can take minutes to hours. | | **Processing** | Awaiting processor update | Charge submitted (usually GoCardless/ACH) | Intermediate state for async processors like GoCardless Direct Debit. Awaiting confirmation from the processor. | | **Declined** | Payment unsuccessful | Card declined, insufficient funds | Check transaction notes for processor reason code. Retry with a different payment method or contact the customer. For recurring billing, triggers the Failed subscription status. | | **Error** | Could not be processed | Processor error, network issue | Distinct from Declined — this is a technical/system failure, not a card rejection. Check transaction notes for details. May need to retry or escalate to support. | | **Refunded** | Refund processed | Admin processes refund | A separate refund transaction is created and linked to the original charge. Appears as its own line item in transaction history. Requires admin permission. | | **Voided** | Charge reversed or invoice voided | Processor reversal or staff voids invoice | Two triggers: (1) charge reversed via the payment processor, or (2) staff voids an incorrectly invoiced charge from the dashboard. Requires admin permission. | | **Charge Back** | Charge disputed by cardholder's bank | Cardholder initiates dispute | Funds forcibly reversed by card network. Not initiated by staff. Review transaction notes for dispute reason. May require evidence submission to the processor. | | **Invoiced** | Invoice generated | House account charge, subscription invoice | An open bill now exists. Appears in Open Invoices report. Can be paid by: (a) 5th-of-month auto sweep, (b) member in portal, (c) staff in dashboard. Invoiced subscriptions stay active — they do not auto-cancel for non-payment. | | **Invoice Payment** | Payment made toward an invoice | Member pays portion of invoice | Partial or full payment applied to an existing invoice. The invoice may not yet be fully settled. | | **Invoice Paid** | Invoice fully settled | Full payment received | Terminal state for invoice billing. The original invoice is now closed. | | **House Account** | Batch payment captured | Monthly auto-process on the 5th (or daily sweep) | Appears when the scheduled sweep processes outstanding invoices. Members must have a payment method on file. Operator can also trigger manual processing. | > **Note**: Transaction notes (including refund reasons) are now visible in the Transaction Report — not just on individual CRM profiles. *(March 2026 release)* *** ## Application Statuses Application statuses track a membership application from submission through review to enrollment. Statuses are **dynamic per tenant** — each application can define custom status values via `ApplicationSubmitStatus`. | Status | Description | Triggered By | How It Is Used | | ---------------- | -------------------------------- | ------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **In Progress** | Started but not submitted | Applicant begins filling out the form | Partial/incomplete submission. No staff action triggered. Applicant can return to complete. | | **New** | Submitted by applicant | Applicant submits (automatic) | Application is in the review queue. Confirmation email/SMS sent to applicant. No staff member has opened it yet. | | **Viewed** | Staff has opened the application | Staff views in Control Panel (automatic) | Auto-set when a staff member opens the application. Signals awareness — no decision made yet. | | **Reviewing** | Under active review | Staff sets manually | Staff is evaluating the application. May involve checking references or coordinating internally. | | **Flag** | Flagged for attention | Staff flags application | Requires escalation or additional scrutiny. Not a rejection — a hold for discussion. | | **Waiting** | On hold for external input | Staff sets to waiting | Pending additional information from the applicant, a reference response, or capacity availability. | | **Interviewing** | In interview stage | Staff sets status | Applicant has been invited to a structured interview (in-person, phone, or video). | | **Approved** | Application accepted | Staff approves (or auto-approval if configured) | Triggers enrollment automation: membership card created, welcome email sent, digital card available, payment processed using billing payment method on file. Taxes, fees, and prorations calculated at this point. | | **Rejected** | Application denied | Staff rejects | No membership created. Typically final. | | **Onboarded** | Fully enrolled post-approval | Enrollment and payment complete, or staff sets manually | Post-approval state indicating the member is fully set up and active. Can also be set manually by staff. Marks completion of the application-to-member lifecycle. | > **Note**: `New` and `Viewed` are set automatically. `In Progress` indicates an incomplete/partial submission. All other statuses are manual staff actions. Tenants can customize status names and add additional statuses via `ApplicationSubmitStatus`. When an application is submitted, the system fires configurable triggers that can send emails or start campaigns (e.g., follow-up for incomplete applications). These triggers do not appear in the CRM change log. *(Jordan, Mar 17)* > **Note**: The triggered-emails engine uses different event names than UI status names. For example, the trigger "Application is Submitted by applicant" fires when the status becomes `New`; "Application is Pending" corresponds to `In Progress`. See the full trigger list in [Email Triggers Explained](/products/control-panel-overview/communications-overview/email-triggers-explained.md). > **Note**: The View Applicants page has pill button filters that use different labels from the status dropdown. Pill buttons: ALL, IN PROCESS, NEW, PENDING APPROVAL, APPROVED, IN REVIEW, INTERVIEWING, WAITING, FLAGGED, REJECTED. The status dropdown (the canonical status set) is shown in the table above. *** ## Booking Statuses Booking statuses apply to all reservation and appointment types: Events, Dining Reservations, Hotel Stays, Workspace Bookings, Spa Appointments, and One-on-One Sessions. | Status | Description | Triggered By | How It Is Used | | --------------------- | -------------------- | --------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | **Booked** | Reservation created | Member or staff creates booking | Initial state. Slot is held. Payment may or may not have been taken yet. | | **Confirmed Booking** | Explicitly confirmed | Staff confirms, or integration confirms | Validated reservation. Fires a confirmation trigger (applies to all booking types). Confirmation notification typically sent. | | **Pending Payment** | Awaiting payment | Pre-pay not yet collected | Slot held pending payment. Staff may need to take full payment, deposit, or just hold the reservation. | | **Arrived** | Guest has arrived | Check-in scan, staff marks arrival, integration updates | Member is physically present. Used for spa, dining, events. | | **Completed** | Booking fulfilled | Time-based completion, staff marks done, integration sync | Terminal success state. The event/session/reservation has concluded. | | **Cancelled** | Booking cancelled | Member or staff cancels | Cancellation rules vary: deposit refundable or not, paid refundable or not, no payment made. Financial treatment depends on the scenario. | | **Waitlisted** | On waitlist | Staff manually adds to waitlist (currently manual only) | Person queued for availability. When a slot opens, staff can move them to Booked. | *** ## Event Statuses Event statuses control the event-level lifecycle (separate from per-registration Booking Statuses above). Set in the event editor under **Settings > Status**. | Status | Description | Member-side effect | | ------------- | ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Draft** | Event is being configured | Hidden from members. Only visible in the Control Panel. | | **Approved** | Event is live | Appears on the events page per the event's Visibility setting (Public / Direct Link / Active Members). Members can register or buy tickets. | | **Cancelled** | Event has been cancelled | Hidden from the events page. Ticket holders are not auto-notified — staff must cancel each ticket / registration individually to release inventory and refund. See: `events-bookings/cancel-refund-tickets.md`. | | **Completed** | Event has concluded | Terminal state. Past event reports and post-event campaigns can still reference the event. | *** ## Order Statuses Order statuses track commerce transactions (product purchases, event tickets, POS orders). | Status | Description | Triggered By | How It Is Used | | -------------- | ---------------------------- | -------------------------------------- | -------------------------------------------------------------------------------------------------------- | | **Processing** | Order open or not fully paid | Order created via POS or portal | Order exists but is not finalized. Used for open POS tabs and eCommerce checkouts in progress. | | **Completed** | Paid in full and closed | Payment confirmed | Terminal success state. For physical products, fulfillment workflow may follow (pull → ship → complete). | | **Refunded** | Order refunded | Admin processes refund | Full or partial refund applied. Refund transaction linked to original order. | | **Pending** | Awaiting fulfillment | Order placed, pre-shipment | Order is paid but physical product has not shipped yet. Used in ShipStation integration mapping. | | **Shipped** | Physical product shipped | ShipStation integration updates status | Tracking information added. Used with eCommerce fulfillment integrations. | | **Cancelled** | Order cancelled | Admin or system cancels | Order voided. No further fulfillment. | > **Note**: `Processing`, `Completed`, and `Refunded` are confirmed from Connect API documentation. `Pending`, `Shipped`, and `Cancelled` are confirmed from ShipStation integration mapping. Additional statuses may exist for specific use cases. *** ## Voucher Statuses Voucher statuses apply to individual issued vouchers (guest passes, offers, coupons). These are instance-level statuses — the voucher template itself has a separate Active/Inactive status on the Manage Vouchers page. | Status | Description | Triggered By | How It Is Used | | ------------- | ----------------------------- | ------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Available** | Issued and ready to use | Issued via admin, membership perk, eCommerce purchase, or API | Voucher is in the member's wallet and within its valid date range. Can be redeemed by staff (Reward > Redeem Voucher) or by the member via Apple Wallet QR scan. | | **Redeemed** | Used/claimed | Staff redeems in Control Panel, member scans QR at check-in, or auto-redeemed on booking checkout | Voucher consumed and no longer available. Appears in redemption history. | | **Expired** | Past expiration date | Date surpasses the `expires_on` value | Voucher was not used before its expiration. Expiration can be a fixed date, rolling window (e.g., 365 days from issue), or indefinite. | | **Voided** | Manually invalidated by staff | Staff action in Control Panel | Voucher cancelled — a new offer is automatically generated on the person's account. Used to correct errors. | > **Note**: Voucher templates (configured under Members > Manage Vouchers) have their own lifecycle: Active, Inactive, and Expired. The statuses above apply to individual issued voucher instances, not the template. The API also tracks a `transferred` state for vouchers that have been transferred to another person. *** ## Payment Types When processing payments via the API or integrations, these payment type codes determine how a charge is routed: | Payment Type | Description | | ------------------ | -------------------------------------------------------------- | | `auto` | Try house credits first, then card on file, then house account | | `cardonfile` | Charge the member's stored credit card | | `house` | Charge to the member's house account (generates invoice) | | `paywithbalance` | Use house credits/balance | | `balancethenhouse` | Try credits first, fall back to house account | | `balancethencard` | Try credits first, fall back to card on file | | `cardtheninvoice` | Try card on file, fall back to invoice | | `giftthencard` | Try gift card balance, fall back to card on file | | `pos` | Payment taken at point of sale (local payment) | | `creditcard` | Direct credit card entry | | `void` | Void a previous transaction | | `voucher` | Pay with voucher balance | | `wire` | Wire transfer | | `cash` | Cash payment | | `papercheck` | Paper check payment | | `rewards` | Pay with loyalty reward points | | `entry` | Manual entry payment | | `capture` | Capture a previously authorized payment | | `verify` | Verify a payment method without charging | | `comped` | Complimentary — no charge applied ($0.00 recorded as entry) | > **Note**: The Control Panel charge form shows these UI payment types: Credit Card, ACH (eCheck), Wire, Cash, Paper Check, Voucher, Entry, Invoice, Comped. *** ## Membership Webhook Activities These webhook triggers fire when membership-related events occur. Use them to notify external systems, trigger campaigns, or update integrations. | Webhook Activity | When It Fires | | -------------------------- | ---------------------------------------------------- | | **Membership** | Any membership-related change | | **MembershipID** | Membership ID is created or changed | | **MembershipTX** | Membership transaction processed | | **MembershipTX Renewed** | Membership subscription renewed | | **Membership Active** | Card status set to Active | | **Membership Archived** | Card status set to Archived | | **Membership Cancelled** | Card status set to Cancelled | | **Membership Expired** | Card status set to Expired | | **Membership Failed** | Card status set to Failed (payment failure) | | **Membership Inactive** | Card status set to Inactive | | **Membership Pending** | Card status set to Pending | | **Membership Suspended** | Card status set to Suspended | | **Membership Reactivated** | Card reactivated from non-active status | | **Membership Changed** | Membership details changed (tier, dates, etc.) | | **Membership\_Cancel** | Cancellation initiated (distinct from status change) | > **Note**: The Webhook Engine supports conditional logic (if/then rules), deferred processing (delayed triggers), and dynamic variable injection into payloads. See [Configure Webhooks](/products/integrations-overview/configure-webhooks.md) for setup instructions. *** ## Invoice Processing Rules Key rules for how the billing engine processes invoices and handles failures: * **Monthly auto-process**: A scheduled job runs on the **5th of each month** (approximately 5 AM) to process all open invoices from prior months. E.g., a June 3rd invoice processes on July 5th. The processing time is not configurable. The processing **mode** (5th of month / Daily / Manual) is configurable via Platform Settings. Note: the "Process Authorizations Daily at" setting in Platform Settings applies to **POS authorizations only**, not to the invoice sweep. * **Portal payment**: Members can pay invoices individually via the Member Portal. * **Dashboard payment**: Staff can process invoices individually or in bulk from the Control Panel. * **Failed payment retry**: If a credit card or ACH charge fails, the system retries at **Day 3** and **Day 7** after the initial failure only. Auto-billing **skips** Failed subscriptions on subsequent regular billing dates — no further automatic attempts are made after Day 7. An admin must manually process the payment or the member must update their payment method. * **Invoice billing**: If the payment type is invoice, the system generates the invoice as due and advances the next billing date — no immediate charge attempt. *** ## House Account Billing Modes House Account charges can be configured in one of three modes: | Mode | Description | | ----------- | ------------------------------------------------------------------------------------------------------------- | | **Monthly** | Club acts as bank — all house account charges consolidated and auto-charged on the 5th of the following month | | **Daily** | Combines a day's worth of bookings/spend into a single daily charge | > **Note**: You cannot run Daily and Monthly house account modes simultaneously. If House Account auto-billing is not enabled, members pay individually or admins collect manually. > **Processor routing**: During house account billing, charges are routed by category — F\&B, Spa, and PMS charges are each sent to their designated payment processor. The remainder goes to the Billing processor, or the Default processor if Billing is not configured. > **Credit limits**: House accounts do not currently support credit limits. Staff should monitor the Accounts Receivable (AR) report to manage outstanding balances. *Last updated: 2026-07-12* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://help.peoplevine.com/status-codes-reference.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.