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.
Staff fees: the full net (after Stripe's processing fee) is transferred to the location that hosted the reservation. No platform fee or billing surcharge is retained.

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
Staff fee	A fee staff charged against a reservation (for example cleanup)

Notes carry any supplemental free-form context (for example, the reason a staff adjustment was made).

Staff Fees

A staff fee is a fixed-amount charge staff put on a member's saved card, tied to one of the member's reservations. The reservation supplies the member, the studio and the location. Any member can be charged a fee, whether they hold a lockout or book hourly.

Fee Type	Amount
Cleanup	$20.00

The amount is fixed per fee type and staff cannot change it. A staff fee is not rent, and it never counts as rent in bookkeeping.

Staff can only charge a member who has a saved card on file. A saved bank account is not used for staff fees. Each fee type can be charged once per reservation. A declined attempt does not count, so staff can try again after the member updates their card. The member gets an email receipt naming the fee, the amount and the note staff entered explaining the charge.

Staff fees are never charged from the Stripe dashboard directly. A charge made there would not be recorded or transferred by Metrognome and the location would never receive its share. A mistaken staff fee is refunded through the staff refund tool, which claws back the location's transfer the same way any other refund does.

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, a waitlist deposit, an organization dedicated room, or a staff fee

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

There are two paths: automatic refunds that follow from a member action, and discretionary refunds a staff member issues.

Automatic refunds

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 rather than a return 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 — cancelling does not refund the current period. The subscription is cancelled at Stripe (immediately or at period end). Proration credits from mid-cycle changes are handled by Stripe's proration system. A member who needs money back for a monthly charge is served by the staff-issued path below, not by cancellation.

Tours — always free, no refund applicable.

Waitlist deposits — non-refundable (ruling 2026-07-17): a cancelled waitlist entry forfeits its deposit to the platform. Any return of a deposit is a staff-issued refund and follows the rules below.

Staff-issued refunds

Ruled 2026-08-09. The Terms make all payments non-refundable except hourly cancellations, so every refund below is discretionary.

No entitlement. Every staff-issued refund is discretionary; members are not entitled to refunds.
Any un-realized payment is refundable, except already-applied waitlist deposits and partly spent credit balances.
Staff choose where the refund goes: original payment method or customer balance, which is the default.
Refunds may be full or partial.
The member is made whole before anything is reconciled on our side.
The refund is recovered from that location's next transfer or transfers until it is fully funded, taking the whole of each transfer if that is what it takes.
A refund-caused receivable may sit unrecovered across a month boundary.
No cap on a location's owed-refund balance. Aging or large owed balances send an alert; they never block a refund.
A partial refund recovers proportionally from the transfer.
Who pays the Stripe fee is staff judgment by fault: the platform absorbs it when the error is ours, the member bears it when the refund is their request.
Staff may only refund for their own locations.

Credit purchases (ruled 2026-09-08) follow the same rules with one mechanical difference: the credits and the cash are two records, so the refund removes the credits in the same action it returns the money. An untouched package (every credit still there, none ever drawn) is refundable to the original payment method; a partly spent one is refused under rule 2. The Stripe processing fee comes off the refund under rule 10 unless the error was ours. No revenue is booked either way: the purchase was deferred, and the deferral ends when the cash goes back.

On rule 2, "un-realized" is a presumption rather than a hard gate. Where the member has already taken some or all of the value, staff are warned and shown how much was realized, and may still proceed; a member who used their session and had a bad time is exactly the case goodwill exists for. The two exceptions are different in kind and are refused outright, because refunding either would give the same value away twice.

On rule 3, customer balance is the default because it keeps the money inside the relationship and costs nothing in processing fees. A return to the original payment method serves the cases balance cannot: a member charged on the wrong payment method who is re-paying another way, a duplicate charge, or someone leaving who will never spend a balance.

On rule 6, Metrognome cannot reach into a location's Stripe balance on demand, because locations control their own payout timing. Locations see what they earned, what they owe, and the net amount sent. Where an owed balance exceeds a transfer, that transfer sends nothing and the remainder carries forward, so a location can receive no payment for a cycle. Staff are alerted before that happens and tell the location, because an unexplained missed payment reads as an error rather than a recovery.

On rule 10, the deducted amount is the actual processing cost on the original charge, read from Stripe rather than estimated, and it differs between card and bank payments. It is presented to the member as a smaller refund, not as a separate fee.

Rules 5 and 7 supersede the reversal-gating condition attached to the 2026-07-17 waitlist ruling, which held a deposit refund until the location transfer had been reversed and issued nothing if that reversal failed. That condition existed because a failed reversal meant the money was simply gone. Under netting the claim against the location survives the failure, so the member is no longer held behind our recovery. The deposit itself stays non-refundable by default; only the gating changes.

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