> 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/products/control-panel-overview/billing-payments-hub.md). # Subscriptions & Dues *** ## Contents * [Overview](#overview) * [Billing Lifecycles](#billing-lifecycles) * [1. Membership Dues (Subscription Billing)](#membership-dues-subscription-billing) * [2. Failed Dues Cycle](#failed-dues-cycle) * [3. House Account Billing](#house-account-billing) * [4. Invoice Processing Opportunities](#invoice-processing-opportunities) * [Payment Processor Routing](#payment-processor-routing) * [Transaction Status Reference](#transaction-status-reference) * [Interdependency and Impact Reference](#interdependency-and-impact-reference) *** ## Overview **Billing & Payments** covers how Peoplevine processes charges — recurring membership dues, one-time charges, house account sweeps, and invoice collection. Membership billing (subscriptions) and house account billing are **separate payment engines** with different logic and rules. > For membership card statuses and their effect on billing, see: [Membership Management Hub](/products/control-panel-overview/membership-management-hub.md). For all status codes, see: [Status Code Reference](/status-codes-reference.md). For key terms, see: [Glossary](/glossary.md). *** ## Billing Lifecycles ### Membership Dues (Subscription Billing) How recurring dues are charged — the standard billing cycle for active memberships. #### Recurring Billing Cycle ```mermaid stateDiagram-v2 [*] --> Active : Subscription created Active --> Active : Next Billing Date reached & payment OK Active --> Failed : Payment fails (auto-set) Active --> PendingPaused : Admin pauses Failed --> Active : Retry OK or manual payment PendingPaused --> Active : Next billing date reached note right of Active : Charges payment method assigned to the subscription note right of Failed : Retry Day 3 and Day 7 note right of PendingPaused : Paused until next bill date ``` > For subscription tier changes (Upgraded/Downgraded), see: [Membership Management Hub — Changes and Lifecycle Events](/products/control-panel-overview/membership-management-hub.md#changes-and-lifecycle-events). #### Auto-Triggers | Trigger | When It Fires | What It Does | | -------------------- | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | | **Dues Auto-Charge** | Next Billing Date reached | Charges the payment method assigned to the subscription; sends receipt. If subscription auto-charge is enabled (default: yes). | | **Payment Retry** | Dues charge fails | Retries at Day 3 and Day 7 after initial failure. Card status auto-set to `Failed`. | *** ### Failed Dues Cycle What happens when a recurring payment fails — the retry sequence and resolution paths. ```mermaid stateDiagram-v2 state "Payment Fails" as Fail state "Card → Failed" as FailStatus state "Day 3 Retry" as D3 state "Day 7 Retry" as D7 state "Manual Resolution" as Manual [*] --> Fail : Billing date charge declined Fail --> FailStatus : Auto-set by system FailStatus --> D3 : Day 3 D3 --> Active : Retry succeeds D3 --> D7 : Retry fails D7 --> Active : Retry succeeds D7 --> Manual : Retry fails Manual --> Active : Staff processes payment or member pays via portal Manual --> Suspended : Admin suspends Manual --> Cancelled : Admin cancels note right of FailStatus : Member sees Failed Dues Paywall — check-in & POS blocked note right of Manual : No further automatic retries — admin must act ``` > **Note**: After Day 7, the system stops retrying. The membership remains in Failed status indefinitely until an admin resolves it — it does **not** auto-transition to Cancelled or Suspended. Day 3 and Day 7 retries also apply to the initial enrollment/approval payment, not just recurring dues — if the first charge fails at approval, the system retries on the same schedule. > **Member Portal**: Members with a Failed status see the Failed Dues Paywall on login. They can pay outstanding dues via the portal if the pay-now option is enabled (configurable — contact Peoplevine to enable/disable). #### Resolution Paths | Path | How | What Happens | | --------------------------------- | ---------------------------------------------------------------- | --------------------------------------------------- | | **Member pays via portal** | Member Portal → Failed Dues Paywall → pay now | Card auto-reactivates to Active | | **Staff processes payment** | CRM Profile → Subscription → process payment | Staff manually changes card to Active after payment | | **Generate invoice + reactivate** | Generate invoice, set card back to Active, collect payment later | Member regains access while payment is pending | | **Admin suspends** | Change card status to Suspended | Set a reactivate-on date to auto-restore later | | **Admin cancels** | Change card status to Cancelled | Set a future cancellation date if needed | *** ### House Account Billing House accounts are a **separate payment engine** from membership dues. They handle charges from integrated platforms (POS, PMS, Spa) that are posted to a member's running tab and settled periodically. #### Billing Modes | Mode | Description | | ----------- | ----------------------------------------------------------------------------------------- | | **Monthly** | All house account charges consolidated and auto-charged on the 5th of the following month | | **Daily** | House account charges processed daily | > You cannot run Daily and Monthly modes simultaneously. If House Account auto-billing is not enabled, members pay individually via the portal or admins collect manually in CP. #### Processor Routing for House Accounts During house account billing, charges are routed by category: * **F\&B charges** → POS processor * **Spa charges** → Spa processor * **PMS charges** → PMS processor * **Everything else** → Billing processor, or Default processor if Billing is not configured *** ### Invoice Processing Opportunities How invoices are generated, processed, and collected. #### How Invoices Get Processed * **Automated processing**: A scheduled job runs on the **5th of each month** to process all open invoices from prior months. E.g., a June 3rd invoice processes on July 5th. Can also be configured as a **daily** job. *(Configurable via Platform Settings)* * **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, or via a CRM profile's **Unpaid Balance** page. #### Invoice Billing (Subscription Set to Invoice) When a subscription's payment type is set to **Invoice**, the system generates the invoice as due and advances the next billing date — no immediate charge attempt. Just like CC or ACH, it advances the billing date from the subscription (either automated at next billing date or manually triggered by admin). *** ## Payment Processing Flow What happens after a payment is attempted — from charge through to final status. ```mermaid flowchart TD A[Payment Attempted] --> B{Payment Source?} B --> C[Member Portal] B --> D[Control Panel] B --> E[Peoplevine Forms] B --> F[GoCardless] C --> G{Payment Result} D --> G E --> G F --> G G -->|Success| H[Status: Processing] G -->|Failed / Denied| I[Status: Declined] G -->|ChargedBack| J[Status: ChargedBack] H --> K{Confirmed?} K -->|Yes| L[Status: Processed] K -->|GoCardless PaidOut| M[Status: Processed & Matched] L --> N{Is Subscription?} M --> N N -->|Yes| O[Update Next Billing Date] N -->|No| P{Is House Account?} P -->|Yes| Q[Update all connected invoices to Processed] P -->|No| R[Generate Invoice] I --> S{Is Subscription?} S -->|Yes| T[Set Subscription to Failed Billing] S -->|No| U[Transaction remains Declined] T --> V{Already Failed?} V -->|No| W[Fire membership_failed or service_failed trigger] V -->|Yes| X[Frequency-based retry — Day 3 & Day 7] ``` > **Negative statuses**: voided, refunded, error, declined, chargedback. If a transaction already has a negative status, it will not be moved to Processing. > **House Account invoices**: If house account payment on invoices, status is set to Payment when Submitted, Confirmed, or Paid Out. Cancelled transactions change to Voided; if house account, all connected invoices update to open. #### Identifying transaction sources Not all transactions on the View Transactions page ran through Stripe. Peoplevine also receives historical data from integrations where payment was taken on-property. | What you see | What it means | | -------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | | **PV payment on file** tag + PI\_ ID + card type/last 4 digits | Ran through Peoplevine → Stripe. Reconcilable via Payment Intent ID. | | **via POS** or **via spa** with no PI\_ ID | Historical data only — payment settled on-property (physical card, cash). Not in Stripe. | | **Invoiced** status | Added to house account. Payment pending collection. | | **Matched** tag + Batch ID (PO\_) | Reconciled with a Stripe bank payout. Use Batch ID to match to bank deposit. | | **Payment** type | House Account sweep payment — the single batch charge that closes multiple invoices. | > **Important**: When exporting transaction reports, exclude the **Payment** type to avoid double-counting revenue. The Payment record represents the single batch charge from the house account sweep, while the individual invoices it covers are separate line items. Including both counts the same funds twice. #### Transaction Date Filters The View Transactions page has four date filters. Using the wrong filter can cause report totals to not match expectations. | Filter | What It Shows | When to Use | | --------------- | -------------------------------------------------------- | ------------------------------------- | | **Charged On** | Date the charge was initiated (default) | "When was the charge created?" | | **Paid On** | Date payment was confirmed/collected | "When did we actually get the money?" | | **Matched On** | Date reconciled with a payment batch (Stripe payout) | "When did it hit our bank?" | | **Modified On** | Date last updated (refunds, chargebacks, status changes) | "What changed recently?" | **When are Charged On and Paid On the same?** * **Direct charges** (Stripe, GoCardless, paper check, cash): Charged On = Paid On (same moment) * **Invoice payments**: Charged On is when the invoice was created, Paid On is when payment was collected — these can be days or weeks apart * **Open invoices** (unpaid): Paid On is blank until payment is collected > **Common support issue**: If a client says their report total is wrong, check which date filter they're using. Filtering by Paid On excludes open invoices (correct — they're unpaid). Filtering by Charged On includes everything regardless of payment status. > **GoCardless note**: For GoCardless payments, Paid On is set when the payment is initiated/authorized, not when funds settle in the bank account. See: [How to View a Member's Transactions](/products/control-panel-overview/transactions-overview/view-member-transactions.md) #### Integration Payment Failures When a connected system (POS, PMS, Spa) attempts to charge a card on file and the payment fails, the charge automatically falls to the member's House Account as an invoice. | Integration | Card failure behavior | | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Micros** | Card-on-file charges are validated in real time — the POS shows a decline alert. If the Auto tender is used and the card fails, an invoice is created instead. | | **Toast** | Auto-generates an invoice. No fail-safe error message is displayed at the POS — the order closes on the Toast side and the invoice appears in Peoplevine silently. | | **Book4Time** | Charges are not processed in real-time — they are processed the **next day**. If the charge fails, it generates an invoice in Peoplevine. | > **Important**: For integrations that don't offer real-time payments (Toast, Book4Time), if a member is not assigned to the check, house account payments can go unmatched. Always ensure a member is attached to the ticket before closing. #### Gift Card Partial Payments at POS | Integration | Insufficient gift card balance | | ----------- | ------------------------------------------------------------------------- | | **Micros** | Leaves a balance due — staff must choose another payment option | | **Toast** | Remaining balance is automatically invoiced to the member's House Account | > **Important**: When approving a membership application, the system uses the payment method set as billing (or default if no billing method is assigned). Staff cannot select which payment method to use during approval. *** ## Payment Processor Routing Peoplevine supports multiple payment processors (Stripe, GoCardless) assigned to different areas of the business. | Slot | What It Handles | | -------------------------------------------- | -------------------------------------------------------------------------------- | | **Default Payment Provider** | Required. All payments unless a more specific slot is assigned | | **Membership Billing** | Subscriptions, renewals, and membership dues billing | | **Virtual POS + 3rd Party POS Integrations** | POS integrations (Toast, Micros, Lightspeed, Silverware — pilot) and Virtual POS | | **3rd Party PMS Integrations** | Property management charges (Opera, Mews) | | **3rd Party Spa/Activity Integrations** | Spa integration charges (Book4Time) | | **Additional Payment Provider** | Backup processor and fallback | > **Pre-selection behavior**: When staff charge through Virtual POS, the system pre-selects the POS processor, but staff can switch to any other processor on the payment screen. > **Force Payment**: Supported on POS, PMS, and Spa slots — not on Default. Restricts all charges in that category to the designated processor. > A default payment provider is **mandatory** — missing defaults cause payment failures. ### Payment Method Assignment ("Use For") When staff add a payment method to a CRM profile, the **Use For** selector assigns the card to a specific purpose — linking it to the corresponding processor slot above. | Use For | Routes to | | ----------------------- | -------------------------------------------- | | Default Payment Method | Default processor | | Membership Dues Billing | Membership Billing processor | | Food & Beverage | POS processor | | Spa and Activities | Spa processor | | Hotel Stays | PMS processor | | Add to Wallet | Saves to profile without specific assignment | **Example**: If a card is assigned to "Membership Dues Billing," it will be used for recurring membership billing — but not for POS or Spa charges. Those will use the card assigned to the corresponding "Use For" category, or fall back to Default if none is assigned. House account charges are routed according to the **House Account Routing** setting in Platform Settings. #### Two payment flows | Flow | "Use For" enforced? | How it works | | --------------------------------------------- | ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Staff-side / automated** (Enterprise rails) | Yes | System automatically selects the payment method matching the charge context. Membership billing, house account sweeps, POS/Spa/Hotel integration charges all use the assigned card. | | **Member Portal checkout** (cart-based) | No | All saved payment methods are shown. The member chooses which one to use. "Use For" is ignored. | > **Processor limitation**: Not all payment processors support context-based routing. Enterprise rails (the standard Peoplevine payment flow) support "Use For" assignment. Some alternative processor integrations do not — payment methods behave as a simple list with no context-based selection. See: [How to Update a Member's Payment Method](/products/control-panel-overview/charging-payments-overview/update-member-payment-method.md). *** ## Member Portal Billing View Members access their billing information at **Account > Billing** in the Member Portal. The page has four tabs: | Tab | What it shows | | ---------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Statements** | Monthly summaries of all transaction data. Downloadable as PDF. | | **Dues** | Itemized view of membership due charges. Downloadable as PDF. | | **Orders** | All transactions including bookings, reservations, events, and integration transactions. | | **Invoices / House Account** | If House Account is enabled: tab is titled "House Account." If not: titled "Invoices." Each invoice has options to Pay Invoice and Send Invoice to Email. | > **Important**: The House Account tab does **not** include the Pay Invoice option. Members on House Account cannot pay individual invoices through the portal — charges are settled through the house account billing sweep. *** ## Transaction Status Reference | Status | What It Means | | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Processed** | Payment successfully captured. For 3DS cards, 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. | | **Invoiced** | Invoice generated, payment not yet received | | **Refunded** | Full or partial refund issued | | **Voided** | Charge reversed by processor or staff | | **Failed** | Payment attempt declined | > For the complete transaction status reference with triggers and rules, see: [Status Code Reference](/status-codes-reference.md#transaction-statuses). *** ## Interdependency and Impact Reference When billing configuration changes, these are the downstream effects: ### High-Impact Changes | If You Change... | Impacted Area | What Happens | | ----------------------------- | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Payment Processor Config** | Billing & Transactions | Wrong processor = failed charges. Default processor is mandatory. | | **Program Price** | Billing & Transactions | Future enrollments adopt new pricing. Existing members are **not** auto-repriced — requires [batch update](/products/control-panel-overview/billing-payments-hub/manage-subscription-billing.md). Members do not see new price at renewal unless batch/manually updated. | | **Subscription Payment Type** | Invoice Processing | Switching to Invoice stops auto-charging and generates invoices instead. | | **House Account Mode** | Member Experience | Changing from Monthly to Daily (or vice versa) affects when members see charges on their account. | --- # 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/products/control-panel-overview/billing-payments-hub.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.