11 Commits (a1e3484fbad1b00238aabe8a92cc7ce3f642e85c)

Author	SHA1	Message	Date
nexxo	a1e3484fba	Verify webhooks against the secret of the mode we are in ... Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 12:13:55 +02:00
nexxo	8ca0d4d257	Say the same thing to the customer, the register and the bank ... Five places where the product told somebody a figure that nothing behind it produced. **The invoice page showed five invoices nobody was ever issued.** A mock that outlived its purpose: CP-2026-0003 to CP-2026-0007, a prefix belonging to no configured series, all "paid", a spend curve from 179 to 198 € and a next charge of 198 € on 01.08.2026 — behind ['auth','verified','customer.active'], so every signed-in customer saw it. Their real invoices existed in `invoices`, were rendered as PDFs and mailed to them, and appeared nowhere in the portal at all. The page now lists their own documents, newest first, with the numbers, dates and totals off the frozen snapshot, a Storno marked as one, and a download. The PDF route resolves the document against the signed-in customer in the query — a URL anybody can type is not made private by not printing it. No next charge and no chart: nothing here computes what Stripe will take next cycle, and a figure nobody has worked out is worse than a blank space. **The setup fee was quoted everywhere and charged nowhere.** On the price sheet, on the booking page, set by the operator in the console — and CompanyProfile::setupFeeCents() had no reader outside the two sentences that quoted it. It is charged now, as a second non-recurring line on the same checkout session, which Stripe puts on the initial invoice only. `orders.setup_fee_cents` records how much of the charge it was, so the whole total still goes back on a withdrawal while the register holds the PACKAGE's charge against the contract price and the invoice prints the fee as a line of its own. The booking page was also quoting the fee NET under the same sentence the website quotes GROSS — 99,00 against 118,80 — and now quotes what will be taken. **An upgrade click cancelled a booked downgrade and delivered nothing.** Nothing in this application marks a cart order paid, so the customer traded a downgrade they had genuinely booked for a cart line that would never be fulfilled. The booking now stands until the upgrade actually lands on the contract, where ApplyPlanChange clears it. The fulfilment seam is reachable for every type that can be paid — a module and a storage pack book through BookAddon, which was the missing path from a paid order to a SubscriptionAddon and left AddonPrices, SyncStripeAddonItems and clupilot:end-cancelled-addons with no caller behind a payment. A paid traffic pack logs an error rather than pretending: the metered allowance is a standing count of packs while a top-up is sold for one month, and which of the two is meant is not a guess to make here. That no path to `paid` exists yet is now stated in both places rather than in one. **The proof register called correct charges wrong.** expected_gross_cents used the CUSTOMER's rate, which is zero under reverse charge, against the domestic gross Stripe actually took — so matches_catalogue was false for every EU business sale charged exactly the advertised amount, and for every renewal on a contract with a module, which was held against `price_cents` alone. It compares against TaxTreatment::chargedCents() and against the whole term now. Where no money moved, charged and the flag are null instead of the expected figure agreeing with itself, and a plan change records the terms with the pro-rata figures in the snapshot rather than money that arrives again on Stripe's proration invoice. **The seller's own VAT id was on the invoice, unlabelled**, between the register number and the court. Labelled — and the footer's composition moved out of the TCPDF method, because inside one the only way to read what it says is to render a PDF and un-subset its fonts. One test enshrined a figure the code does not produce: a reverse-charge purchase recorded with no charged amount, asserting 17900/0/17900, where OpenSubscription always passes the charged figure and a real one records 21480/0/21480. Another asserted that an upgrade click cancels a booked downgrade. Full suite: 1676 passed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 01:30:24 +02:00
nexxo	f02e86769b	Charge the price the website shows, and hand a withdrawal back in full ... Stripe was charging the catalogue's NET figure while the document added the domestic rate on top: a customer quoted 214,80 paid 179,00 and was then invoiced for VAT nobody had collected. Under para 11(12) UStG that VAT is owed to the tax office whether or not it ever arrived, so every document issued created a liability against revenue that did not contain it. The Stripe Price now carries the GROSS figure. price_cents stays net - it is frozen onto every contract and PlanChange prorates against it, so redefining it would corrupt every pro-rata sum ever computed. Only the amount at the till moved, and it is formed by the one call TaxTreatment already answers for the price sheet and for the invoice, so displayed, charged and invoiced cannot drift apart. Stripe's automatic_tax is deliberately not used. TaxTreatment is the single tax authority here, and a second rate computed by Stripe would take 19 % from a German consumer while our document said 20 %. A Stripe Price cannot be edited, so a changed figure means a new Price and the old one archived - which stops it being SOLD and leaves every subscription already on it billing the old amount for ever. stripe:reprice-subscriptions is the second half, and a command of its own because it touches live money. A withdrawing consumer is refunded in full, as the owner decided. That is more generous than FAGG para 16 requires, and it makes the express-request consent the statute hinges on irrelevant - so the gate is gone rather than left looking load-bearing. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 22:42:02 +02:00
nexxo	6d7c2bdf35	Ask whether they are a consumer, and let one change their mind ... Three things the product owed its customers and did not have. **Who is on the other side.** There was no consumer/business flag anywhere, and `vat_id` was standing in for one — which it cannot: a business without a VAT number is an ordinary small business, and a consumer with one does not exist. It is asked at sign-up now, correctable in the portal, and NULL where nobody has been asked. Unknown is read as CONSUMER everywhere it decides a right, because that mistake costs us a refund while the other one takes a statutory right away from somebody who has it. Reverse charge asks the recorded type instead of the number: an explicit consumer is charged the domestic rate whatever `vat_id` says — previously they were not, and anyone could zero their own VAT by getting a number verified. An unrecorded type still falls back to the verified number, so no contract that is already running changes rate. **The fourteen-day right of withdrawal** (FAGG, §312g BGB), for consumers only, at every door: the window is stamped on the contract when it is concluded, the customer exercises it from the portal, an operator records one that arrived by telephone or post, and both go through one action that refuses a business customer on the server rather than by hiding a card. The money follows the paperwork rather than being computed beside it. The invoice is cancelled by a Storno with its own gapless number — nothing is ever edited or deleted — a new invoice states the pro-rata value of the service actually delivered (FAGG §16, by days over the term paid for), and the refund is exactly the difference between the two documents. Where the consumer never expressly asked for the service to begin at once, they owe nothing and the whole amount goes back. `StripeClient::refund()` is new, keyed so a retry cannot send the money twice. The service ends through EndInstanceService and the `cancellation_scheduled` machinery that was already there. **The cancel button for modules.** BookAddon::cancelAtPeriodEnd() had no caller in the interface at all, so a customer could book a recurring charge in two clicks and had no way to stop it. It is on the module card now, with the date it runs until and a way back while the cancellation is still pending — and putting a module back settles nothing, because the term it was cancelled for was paid for in advance. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 21:06:06 +02:00
nexxo	0560ae743d	feat(billing): Stripe owns the billing cycle, we own capability ... A Product per plan family and a Price per priced row of a published version, plus the four subscribed webhook events that were arriving and being ignored. `stripe:sync-catalogue` mirrors the catalogue. Idempotent twice over: a stored id is skipped, and each call carries an idempotency key derived from our own row, so a crash between Stripe creating a Price and us recording its id gives back the same object rather than a second one. That matters more here than usual — a Stripe Price cannot be edited or deleted, so a duplicate is permanent. Drafts are not synced at all: a version that has promised nothing has no business in a price list. --dry-run shows what would be created. The webhook now handles invoice.paid, invoice.payment_failed, customer.subscription.updated and customer.subscription.deleted. It never re-derives an amount: the invoice is the authority for what was charged, and recomputing it from our catalogue would produce a second, disagreeing answer. A failed payment is recorded and nothing else — Stripe runs the dunning schedule, and cutting a customer off on the first failure would punish an expired card as though it were a refusal to pay. Only a cycle renewal moves the term on. Stripe also sends paid invoices for prorations and manual charges, and the checkout's own invoice — which is already in the register as the purchase, and would otherwise double every customer's first payment. Stripe does not guarantee delivery order, which is the source of most of the care here: - state changes are judged and written in one transaction with the row held, so two deliveries cannot both pass a check made on a stale copy; - an older event never overwrites a newer one, with a rank breaking ties between events sharing a second — their timestamps have one-second resolution, and a failed attempt and its successful retry routinely do; - a term is never shortened, and an ended contract is never revived; - an event for a contract that does not exist yet is HELD and replayed the moment it appears, rather than acknowledged and forgotten. A cancellation dropped that way would leave us serving someone who had already left. Held rows that never match are pruned after a week. Register entries are keyed by what they are about — the invoice, the attempt, the subscription — with a unique index doing the work, because a check two concurrent deliveries can both pass is not idempotency. PlanChange is now documented as the preview shown before someone confirms, not the invoice: Stripe's proration accounts for tax, existing credit and the exact second the change lands, and ours cannot. Not run against the live account — `stripe:sync-catalogue` creates objects that cannot be deleted, so that is the owner's call. The dry run lists 12. 457 tests green. Codex review clean after seven rounds. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 13:36:28 +02:00
nexxo	6387c747d0	feat(billing): the plan catalogue becomes three tables, and config stops selling ... Plans lived in config/provisioning.php, where the owner cannot reach them and where a plan has no history. They now live in plan_families / plan_versions / plan_prices — a name that never moves, what the plan WAS at a point in time, and a price per version and term with its own Stripe Price id. - Availability is computed on every read (available_from <= now < until, half-open, UTC) plus a per-family sales kill switch. Nothing schedules a plan into or out of sale: a job that fails to run is a plan that silently misbehaves. - Overlaps crash rather than resolve. currentVersion() uses sole(), and scheduling takes a lock on the family and rejects an overlapping window — two versions on sale at once would decide a customer's price by row order. - A version is frozen from publication, not from first sale, and so is its price: a checkout is not instant, and an amount edited between the session opening and the webhook landing would contract someone at a price they were never quoted. Repricing publishes a new version, as Stripe requires anyway. - Neither a published version, its price, nor a family with customers can be deleted, and a family key cannot be renamed. All of those would null the provenance off existing contracts. - Subscriptions and orders record plan_version_id. A historical reference resolved by plan NAME hands back today's terms, which is the split-brain one level up. A checkout that carried its version is honoured even after the window closes — they paid for what they were shown. Switched atomically and failing closed: config('provisioning.plans') and plan_features are gone, and nothing falls back to them. A fallback would resurrect a plan the owner had just switched off. The seed lives in the migration, and PlanCatalogueTest pins what the config catalogue sold as the shadow comparison. `php artisan plans:check` reports overlaps, gaps and missing prices before a customer finds them. Contract-backed displays, which were reading the live catalogue: seat limits, the cloud card, the plan card, and admin MRR — the last three now divide a yearly contract down via Subscription::monthlyPriceCents(), since all three label the figure per month. Two recovery gaps closed along the way: the order now commits before the contract is opened (so a contract failure can never erase the record of a payment), a Stripe retry repairs a missing contract and restarts a run stranded with no_subscription, and TickProvisioning sweeps runs left pending by a crash rather than only running/waiting ones. 402 tests green. Codex review clean after thirteen rounds. Verified in the browser: portal, billing and console render unchanged off the new catalogue. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 12:05:56 +02:00
nexxo	64e3ca421d	fix(engine-b): async stripe payments, capacity honesty, durable credential mail ... - Accept checkout.session.async_payment_succeeded (async methods) and dedupe on the checkout session id, not the event id. - committedGb still counts a failed instance while its VM exists (has vmid); releases quota only when no VM was created — no overcommit vs no leak. - CloudReady is queued (durable). Credential delivery is documented at-least-once (a rare duplicate welcome email beats a lost credential; exactly-once = v1.1 outbox). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-25 12:29:47 +02:00
nexxo	fffcecb152	fix(engine-b): address Codex round 3 (webhook email/replay/rotation, db secret) ... - Require a real customer email (no unknown@ fallback merging customers). - Stripe signature: enforce 5-min replay tolerance + accept any rotating v1. - DeployApplicationStack no longer persists the DB password in the run context. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-25 12:12:24 +02:00
nexxo	e6bd6c9354	fix(engine-b): address Codex round 2 (fail-closed webhook, placement lock, clone/admin idempotency) ... - Stripe webhook fails closed when the signing secret is missing (outside local/testing). - ReserveResources places + creates the instance under a per-datacenter lock so concurrent orders can't overcommit a host. - CloneVirtualMachine reserves the vmid + breadcrumb BEFORE cloning, so a crash can't mint a new vmid and orphan the first clone. - CreateCustomerAdmin checks user existence and resets the password instead of re-running user:add on retry. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-25 12:09:21 +02:00
nexxo	42fa92cf20	fix(engine-b): address Codex (paid-only stripe, guest routing, absolute disk) ... - Stripe: only checkout.session.completed with payment_status=paid (dedupes the paired payment_intent event and blocks unpaid async sessions). - Capture the guest IP (ConfigureNetwork) and point Traefik at the VM, not the Proxmox host, so ACME/HTTP-01 can reach Nextcloud. - Resize the disk to an absolute target (not '+…') so a retry can't double it. (Codex #4 timeout was a false positive — started_at resets per step.) Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-25 12:05:31 +02:00
nexxo	65ba3d6588	feat(engine-b): Stripe webhook -> idempotent customer provisioning intake ... Signed webhook (HMAC verify when secret set), CSRF-exempt route. Paid checkout creates customer+order+run (stripe_event_id unique => duplicate webhooks start one run) and dispatches. 5 tests. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-25 11:52:46 +02:00