Billing — admin

Who opens it: an owner (only tenant.billing sees it), usually the day a trial is ending or an event outgrew Free.

What they came to do: find out what they are on, what it would cost to be on something else, and buy it.

True when they leave: either they have paid and the plan is theirs, or they know exactly what it would cost and what it would change.

The two ways to buy

About six single events cost what a year costs, so the sixth event pays for itself — the page says so rather than leaving people to work it out.

Moving down a plan

Pressing a smaller plan does not buy it. The page first lists what exceeds that plan — how many, how many are allowed, and what happens to them — and only the second press changes anything. The same list appears on its own whenever something already exceeds the plan in force, which happens without anybody downgrading: a trial ends, or an Enterprise override expires.

Nothing is ever deleted by a plan change. Things over a limit are kept: check-in points keep scanning and attendee types keep working, they simply cannot be edited until the count is back under the limit — removing or switching one off is always allowed, because that is the way back. Webhook endpoints and reminders are paused and switch back on by themselves after an upgrade. API keys are never revoked; they answer again on a plan with API access.

Above the cap

Nothing is blocked at a gate. When an event goes over the plan's cap, the people over it are counted and charged three days after the event closes — the delay is so that cancellations in the days after are off the roster before anything is billed, and so that nobody is invoiced on the evening of their own event.

The page lists each charge with what it was for, and an owner can waive one with a note. A waived charge stays on the list with its reason: "why wasn't this billed?" should have an answer a year later. Free is the one plan with no overage at all — it closes registration at the cap instead.

When Stripe says something and nothing happens

The page lists the last few messages Stripe has sent about the organization, with a Replay button. That is there because the person who notices a payment had no effect is usually the person who made it, and the alternative is waiting for somebody with a console. Replaying asks us to read the same message again; doing it twice is harmless, because every handler is written to reach the same answer whatever it is told twice.

An operator has the same tool from the console: php artisan ew:stripe-replay evt_…, with no argument to list what is outstanding and --failed to re-run everything that failed.

Decisions already made

• Money first, then access. A plan is granted by a subscriptions row, and that row is written by Stripe's webhook — never by the browser coming back from Checkout. So the page can say "Free" for a few seconds after a payment while the webhook lands. That is the honest state; the alternative is showing a plan that might still fail.
• An abandoned checkout leaves nothing behind. Nothing is written when a checkout starts, which is also why starting one twice is harmless.
• The cap is snapshotted at purchase for a per-event plan. Prices and caps will move before GA; what somebody bought does not move with them.
• Upgrading an event charges the difference, and downgrading is refused at the till rather than accepted and then quietly not refunded (PRICING §2).
• A yearly plan is changed, never bought again. Buying a second subscription would charge twice; Stripe changes the existing one, which is what makes proration possible.
• The card, the invoices and cancelling are Stripe's portal. Rebuilding them would mean holding card state we deliberately never hold. The button is only there once there is a subscription to manage.
• Per-event is hidden while a year is running. A year already covers the event; offering to sell it again would be selling the same thing twice.
• One Stripe customer per organization, kept on the tenant. It outlives every subscription, so a tenant who cancels and comes back a year later keeps their invoice history instead of becoming a second customer.
• Past due does not take anything away. Dunning (week 16 step 5) is a banner and emails; the gate keeps scanning and the public pages keep working. Principle 3.

Open questions

• Nothing on this page shows usage against the cap yet, or what an overage would come to — that is the usage page (step 5), and until it exists an owner has to guess whether to upgrade.
• A per-event purchase for an event that is later deleted is not refunded or reused. Rare, but unowned.
• Enterprise is hidden here: it is a quote and a conversation, with entitlements as overrides. There is no "talk to us" route on the page yet.