GridMagik uses one Stripe account for its own subscriptions and Stripe Connect for money a venue collects from guests. Hosted checkout, server-driven Stripe Terminal, multi-tender, and Stripe refunds have tested sandbox workflows. Square OAuth, locations, Terminal checkout, signed webhooks, and reservation settlement have a provider-mocked foundation; real Square hardware is not validated.
Platform subscription checkout, invoices, and the billing portal use GridMagik's Stripe account. Persisted attempts, concurrent-click protection, customer binding, event ordering, and provider-mocked reconciliation are implemented. A real Stripe test-mode hosted subscription was completed, reconciled, canceled, and cleaned up; no live subscription or charge is claimed.
Tenant → GridMagik platform Stripe account
Guest → venue connected Stripe account
Separate merchant relationships, separate webhooks, and separate reconciliation responsibilities.
Connected-account checkout is implemented as a direct-charge flow with an optional GridMagik application fee. Account onboarding, hosted checkout, immutable attempts, signed webhooks, partial refunds, and multiple tenders have focused sandbox and concurrency coverage. Production enablement still requires venue-specific provider and operational approval.
GridMagik has a server-driven Stripe Terminal workflow for registered smart readers. Square now has encrypted OAuth credentials, merchant/location discovery, Terminal checkout, signed webhook processing, and reservation-ledger settlement exercised against mocked provider responses. Neither path is presented as a full retail register or hardware-certified live deployment.
We publish the status explicitly so a venue can distinguish implemented sandbox capability from production-ready money movement.
Connected-account Checkout sessions and application fees are implemented in test mode.
Server-driven smart-reader processing is implemented; recovery and reconciliation remain gated.
Account, amount, currency, duplicate-delivery, claim leasing, and event-order regressions protect current provider flows.
Connected-account partial refunds use provider idempotency and webhook-confirmed success; Square refunds fail closed.
Payments and refunds derive reservation balance from immutable rows; disputes, payouts, and settlement reports remain planned.
Partial cash, external, gift, and provider attempts use immutable tenders, locks, and idempotent balance calculation.
OAuth, encrypted credentials, locations, Terminal checkout, signed webhooks, and settlement pass mocked E2E; real hardware and refunds do not.
A venue is enabled only after its account, webhooks, refund path, and reconciliation suite pass.
Not through an unverified GridMagik workspace. Stripe Connect, Terminal, multi-tender, and refunds are implemented in sandbox, but live-money activation stays gated until that venue's account and operating checks pass.
The target architecture uses Stripe Connect direct charges, so the venue is the merchant for guest payments. GridMagik's own subscription billing is a separate platform charge.
Not for live service yet. The Square OAuth, location, Terminal checkout, signed webhook, and reservation-settlement foundation passes mocked end-to-end tests, but no real Square credentials, reader, or live payment has been validated and Square refunds are unavailable.
They are controlled beta workflows. Multiple immutable tenders can contribute to one reservation balance, and authorized Stripe Connect refunds wait for provider-confirmed success. They are not yet approved for live money, and Square or gift-value reinstatement refunds fail closed.
30-minute walkthrough. Your pricing, your calendar, your receipts — running live in a sandbox on your data. No slides.
