Payments & Billing
Payment processors, manual payment verification, card holds, refunds, invoices, failed payments, gift cards and Financial Command Center sync.
What this category does
These settings protect revenue, reduce unpaid balances, and control how Jarvix charges customers. Stripe and Square are processor-verified. Cash, Zelle, Venmo, checks and other manual methods must be verified in Jarvix before they count as collected revenue.
Payment Source of Truth Rule
Card payments: Stripe or Square webhook events decide paid, failed, authorized, refunded, disputed and chargeback statuses. Manual payments: Cash, Zelle, Venmo, Check, Cash App and bank transfer stay pending until office verification. Financial Command Center must not count them as collected revenue until marked paid or check cleared.
Default Payment Processor & Event Sync
Select whether Stripe, Square or Manual Only controls payment events. This determines which processor Jarvix listens to for card charges, holds, refunds, disputes and payment failures.
Select whether Stripe, Square or Manual Only controls payment events. This determines which processor Jarvix listens to for card charges, holds, refunds, disputes and payment failures.
Why this existsJarvix cannot guess payment results. The processor must confirm card events, then Jarvix normalizes the status and syncs the result across every command center.
What uses this settingAccepted Payment Methods
Choose which payment methods the company accepts. Customer booking, office booking and customer portal should only show enabled payment methods.
Choose which payment methods the company accepts. Customer booking, office booking and customer portal should only show enabled payment methods.
Why this existsEvery company accepts different payment types. Jarvix must know which are processor-verified and which require manual verification so invoices, balances and revenue stay accurate.
What uses this settingCard Hold & Preauthorization Rules
Control when card holds are placed, how much is held, and what happens if the hold fails. These rules protect the company before dispatching workers.
Control when card holds are placed, how much is held, and what happens if the hold fails. These rules protect the company before dispatching workers.
Why this existsCard holds reduce no-shows and unpaid balances. If a hold fails, Jarvix must warn or block the booking depending on company policy.
What uses this settingFailed Payment Workflow
Control what Jarvix does when Stripe, Square or manual verification reports a failed or declined payment.
Control what Jarvix does when Stripe, Square or manual verification reports a failed or declined payment.
Why this existsFailed payments must not sit unnoticed. Jarvix should retry when allowed, notify customers, alert staff, create follow-up work, and show the risk in Payment Command Center.
What uses this settingManual Payment Verification Rules
Control how Cash, Zelle, Venmo, Check, Cash App and bank transfer are verified. These payments remain pending until marked received or cleared.
Control how Cash, Zelle, Venmo, Check, Cash App and bank transfer are verified. These payments remain pending until marked received or cleared.
Why this existsManual payments do not send reliable processor confirmations. Jarvix must hold them in Accounts Receivable and Pending Verification until a manager confirms the money was actually received.
What uses this settingRefund & Price Change Behavior
Control how Jarvix handles refunds, decreased booking totals, payment method changes, and previous refund logs.
Control how Jarvix handles refunds, decreased booking totals, payment method changes, and previous refund logs.
Why this existsRefund rules protect cash flow and prevent double refunds. If a booking total changes or a refund already exists, Jarvix must know whether to auto-refund, require approval, or hold for review.
What uses this settingInvoice, Open Balance & Collections Rules
Control invoice terms, partial payments, invoice reminders, late fees and collections notices.
Control invoice terms, partial payments, invoice reminders, late fees and collections notices.
Why this existsInvoices must stay connected to customer balances and Financial Command Center. Open balances should remain visible until payment is processor-confirmed or manually verified.
What uses this settingGift Cards
Control gift cards, codes, sender/recipient messages, balances and bonus promotions. Gift cards never expire.
Control gift cards, codes, sender/recipient messages, balances and bonus promotions. Gift cards never expire.
Why this existsGift cards are prepaid customer value. Jarvix must generate codes, track balances, store sender/recipient details, and make them redeemable without expiration.
What uses this settingPayment Command Center Visibility
Choose which payment risks and pending payment items appear in the Payment Command Center.
Choose which payment risks and pending payment items appear in the Payment Command Center.
Why this existsOwners need one place to see failed cards, pending manual payments, open balances, refunds and disputes. Nothing money-related should disappear from operations.
What uses this settingTest Payment Sync
Use this internal test to verify how a payment event would affect Financial Command Center. Manual payments should not increase collected revenue until verified.