Payments
Metrognome uses Stripe as its payment platform. All charges are created on Metrognome's platform account and revenue is transferred to each location's connected Stripe account. The system supports card, ACH (bank transfer), and credits as payment methods.
Payment Methods
Card — standard credit/debit card payment. Charges settle immediately. Higher processing fee than ACH, with an additional flat per-transaction fee. Apple Pay and Google Pay are available through the Stripe Payment Element and behave as card payments.
ACH (bank transfer) — lower fees than card, no flat fee. Bank transfers take 2-3 days to clear. For lockouts and waitlist deposits, members receive access optimistically before the transfer completes.
Cash App — available for monthly lockout and organization dedicated room subscriptions only. Not available for hourly bookings, credits, or waitlist deposits.
Credits — Metrognome's internal currency. One credit equals one dollar. Credits are purchased in packages (one-time or subscription), stored as balances, and spent on hourly reservations. Credits do not flow through Stripe at spend time — only the initial purchase does. See Credits.
Stripe Connect
Metrognome operates as a Stripe platform. Each location has its own connected Stripe account. When a charge succeeds, the system transfers funds to the location:
- Lockout charges — Stripe's processing fee is deducted first (by Stripe), then the platform billing surcharge is deducted, and the remainder is transferred to the location. The billing surcharge is Metrognome's revenue on lockout subscriptions.
- Hourly charges — the full net (after Stripe processing fees) is transferred to the location. No platform fee is retained.
- Credit redemptions — when credits are spent at a location, 90% of the credit value is transferred to the location and 10% is retained as a platform fee.
- Waitlist deposits — the net amount (after Stripe processing fees) is transferred to the location when the member converts to a lockout. No platform fee.
Each charge generates exactly one transfer — duplicates are prevented automatically. Customer balance credits applied to an invoice are transferred separately (see "Customer balance provenance" below).
Customer balance provenance
Money lands on a member's Stripe customer balance only after the platform actually holds the corresponding cash. Every credit is tagged with where it came from, and the tag decides whether the location delivering later service gets paid:
- Refund credits (hourly cancellation, reschedule downcharge, discretionary waitlist deposit refund) — the original location's transfer is reversed at issuance, so the money is platform-held. Compensable. For waitlist deposits, a failed reversal blocks the credit entirely (ruling 2026-07-17): the credit is only issued when the platform holds the cash, so the platform never pays out money it does not have.
- Goodwill credits (staff-issued) — platform-funded gifts. Compensable.
- Remediation credits (staff-issued) — return money a location over-received. The amount is clawed back from that location's transfers at issuance, so by the time it sits on the member's balance it is ordinary platform-held money. Compensable.
- Untagged credits (Stripe dashboard edits, credits issued before provenance tagging) — unknown provenance. Never compensable.
When balance money pays part of a lockout invoice (first payment, renewal, or mid-cycle change), the location delivered full service but the card charge — and therefore the automatic charge transfer — is smaller. The platform separately transfers the compensable share of the applied balance to the location, minus the card-fee equivalent, so locations receive exactly what a card payment would have paid. Untagged money drains first when a balance holds a mix, so compensation never fires while unknown-provenance money is on the balance. Balance money spent on hourly bookings already settles to the hosting location the same way.
Platform-absorbed fees
The platform Stripe balance carries Metrognome's accumulated platform P&L — revenue retained from the billing surcharge and credit redemption fee, minus Stripe fees that Metrognome absorbs:
- Stripe Billing (subscription processing) — Stripe charges 0.7% of invoice billing volume. The lockout billing surcharge is sized to match this, but sales tax on the billing fee is absorbed by Metrognome (typically ~9% of the billing fee itself).
- Connections Verification — quarterly Stripe fee for verifying connected location accounts. Absorbed by Metrognome; not offset by any per-charge fee.
- Sigma analytics — monthly Stripe fee for running analytics queries. Absorbed.
- Invoicing — per-invoice flat fees on specific invoicing workflows. Absorbed.
These fees accumulate against Metrognome's retained margin over time.
Transactions
Every financial event creates a transaction record. Transactions have a type (debit or credit), an amount, a unit (USD cents or credits), a reason, and optional notes. Transactions capture both Stripe-backed events (a paid invoice, a refund) and purely internal ledger entries that have no Stripe counterpart (a credit grant, a credit consumption, a credit restoration).
The reason is a standardized label — one of a fixed set of values — and is what appears in the staff ledger and account dashboard. Common reasons include:
| Reason | What It Represents |
|---|---|
| Reservation purchase | Hourly reservation paid by card or ACH |
| Lockout initial purchase | First payment when a lockout starts |
| Lockout monthly renewal | Recurring subscription charge for a lockout |
| Lockout proration | Mid-cycle charge from adding insurance or transferring rooms |
| Credit purchase | One-time credit package bought |
| Credit subscription renewal | Recurring monthly credit subscription charge |
| Credit usage | Credits spent on an hourly reservation |
| Credit grant | Credits issued at purchase (subscription) |
| Credit grant (renewal) | Credits issued on a subscription renewal |
| Credit restoration | Credits returned on a cancelled reservation |
| Promo redemption | Credits from a promotional code |
| Cancellation refund | Stripe customer balance credit issued on cancellation |
| Refund | Other refund |
| Staff adjustment | Manual balance adjustment (goodwill or remediation) |
| Waitlist deposit | Deposit paid when joining the waitlist |
| Organization dedicated room | Organization dedicated room subscription charge |
| Completion credit | Credit applied at end of period |
Notes carry any supplemental free-form context (for example, the reason a staff adjustment was made).
Checkout Initialization
Payment records are created up front, before Stripe charges. When a member commits to a purchase — hourly booking, lockout, credit package, waitlist deposit, or organization dedicated room — the system creates the business entity (reservation, credit purchase, waitlist entry) and a Pending payment record in a single database transaction. The Stripe charge is sent last. See Checkout for the full initialization flow.
Payment Records
Every Stripe payment event has a corresponding payment record, regardless of what was purchased. A payment record tracks:
- Status — Pending, Retrying, Failed, or Paid
- Amount — what the member is charged
- Billing date — when the charge is scheduled
- Purchase link — exactly one of: a reservation, a credit balance purchase, or a waitlist deposit
Payment records are created at checkout initialization in Pending status, before Stripe attempts the charge. When Stripe confirms the charge, the record transitions to Paid and a transaction is attached. If the charge fails, the record transitions to Failed or Retrying.
Status meanings:
- Pending — charge created but not yet confirmed (future-dated lockouts, ACH waiting to clear, subscriptions awaiting first invoice, credit purchases awaiting payment)
- Retrying — charge failed but Stripe will retry (dunning in progress)
- Failed — all retry attempts exhausted, or the underlying subscription has been cancelled by Stripe
- Paid — charge succeeded
For monthly lockouts and other subscriptions, each billing cycle creates a new payment record. Payment records accumulate over the life of the tenancy while the reservation itself persists with the same identity.
Payment Failure and Dunning
Dunning (retry logic for failed payments) is handled entirely by Stripe. The system observes outcomes and updates payment records accordingly. No dunning emails are sent from the application — Stripe communicates directly with the member.
For monthly lockouts, physical access is not revoked during Stripe's retry cycle — the member keeps access through the retry window. When Stripe exhausts retries and the subscription enters a terminal failed state, the payment record is marked Failed, staff receive a notification, access is revoked, and the lockout is ended. See Physical Access.
For hourly reservations, a failed payment cancels the reservation and revokes the access code for that booking. For credit purchases, a failed payment leaves the balance ungranted (credits are never issued on a failed charge).
Refund Rules
Refund behavior depends on reservation type:
Hourly reservations — refundable if cancelled at least 24 hours before start time. The refund is issued as a Stripe customer balance credit (not a direct refund to the original payment method), applied to future charges. Within 24 hours of start time, no refund is issued.
Credit-paid hourly reservations — credits are restored to the original credit balance on cancellation.
Monthly lockouts — no per-payment refund on cancellation. The subscription is cancelled at Stripe (immediately or at period end). Proration credits from mid-cycle changes are handled by Stripe's proration system.
Tours — always free, no refund applicable.
Waitlist deposits — non-refundable (ruling 2026-07-17): a cancelled waitlist entry forfeits its deposit to the platform. Staff retain a discretionary refund option, issued as a Stripe customer balance credit, but it is only granted when the platform actually holds the cash — if the deposit was already transferred to the location, the transfer reversal must succeed first; a failed reversal means no credit is issued.
Idempotency
Stripe payment notifications are processed exactly once — duplicate deliveries are automatically detected and ignored. Post-payment actions (access code provisioning, emails, calendar syncing) run in the background after the payment is recorded.
Invoice Lifecycle
Invoices are generated by Stripe for subscription payments (lockouts, organization dedicated rooms, recurring credit packages):
- Finalized — triggers activation of future-dated reservations whose billing period has begun
- Paid — records a Paid payment for the billing cycle and, for new subscriptions, runs fulfillment (lockout access, credit balance creation)
- Failed — marks the payment as Retrying or Failed depending on whether Stripe will retry again