3 Commits (f49f1dca09d2a36969ab2efa0920c7337833b54d)

Author	SHA1	Message	Date
nexxo	e0c109c449	Ask for the express request to begin, and send it to Stripe ... The withdrawal machinery has always read `immediate_start` off the checkout session's metadata — StripeWebhookController stamps `immediate_start_consent_at` from it, WithdrawalRight refunds pro rata when it is there and in full when it is not. The checkout never put it there. So every contract concluded through this application carried no consent, and a withdrawal on day thirteen of a running cloud took back the whole amount however many days the machine had run. That is the lawful outcome without the consent, and it was the only outcome available. Now the checkout asks. The box is required — validated `accepted`, not `present`, because an empty field is what an unticked checkbox sends and a consent that can be produced by leaving something blank is not a consent — and the metadata carries exactly the string '1' the webhook compares against. One box for the page rather than one per card: the sentence is the statutory wording and four copies of it is a wall nobody reads. The forms carry it as a hidden field bound to that box, and the buy buttons stay disabled until it is ticked. With JavaScript off the field arrives empty and the server refuses with the sentence explaining why — the safe direction to fail in. Ticking a box in a browser was never the record anyway: the record is the timestamp taken when the payment lands. Tested at both seams and along the whole chain: refused without it, refused for '', '0' and a word that is not yes, carried to Stripe as '1', and a webhook carrying it lands as a timestamp on the order while one without it lands as null. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 21:19:03 +02:00
nexxo	6b8412f0c3	Write an invoice for work that came off no price list ... Not everything we are paid for is a package. Somebody asks whether their data can be moved into Nextcloud; we look at it, we say what it costs, we do it. That is a real invoice with no order and no contract behind it, and the only way to produce one was to write it somewhere else — which puts it outside the series. A numbered series with a document missing from it is worth nothing at an audit. So it goes through the same door as every other invoice: IssueInvoice::forService() draws from the same series and therefore the same consecutive number, applies the same TaxTreatment (a verified business in another member state gets its reverse charge and the note that makes a zero-rated document lawful), freezes the same immutable snapshot and dispatches the same archive jobs. The page under Rechnungen writes what the operator typed and nothing else. Amounts are in euro because it is a form — 12,95 becomes 1295 by round(), not by a cast that would make it 1294 — and quantities go to a thousandth because hours are billed in quarters. The total beside the lines is the same InvoiceMath the document uses; a preview doing its own arithmetic would be a second answer, and the first one anybody notices differs is on a document that cannot be changed. There is no draft: a "save as draft" that draws a number is an issued invoice with a friendlier name. The website's buy buttons go to the sign-in now, not to /order. Booking belongs in the panel, where the account exists and its address has been confirmed — which matters because that address is where the finished cloud's credentials are sent. Sending an anonymous visitor at a page behind auth worked, but only via a middleware bounce off a page they never asked for. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 20:12:26 +02:00
nexxo	f85f57152e	Let the customer buy it themselves, and tab the integrations page ... Every path on the site ended in "anfragen": a mailto: link and a promise to answer the same working day. That is an afternoon of somebody's time per customer, for a product whose whole point is that the machine does the work — and it scales exactly as far as one inbox does. Now: sign in, pick a package, pay, and provisioning starts by itself. The pieces were already there — Stripe holds a Price per plan version (the catalogue sync writes the ids), the webhook opens the contract, the pipeline builds the VM — and what was missing was the checkout session between them. CheckoutController opens one and gets out of the way; the purchase becomes real on the webhook, which stays the only place allowed to believe a payment happened. The success URL is a redirect target and therefore a URL anybody can type, so it says "we are building it", not "you have paid". Nothing in the request may decide the price. The plan key arrives from a form and everything else is re-derived from the catalogue, including the plan VERSION, so a version published while the customer types their card number cannot change what they were quoted. Two cases that are not errors: no capacity is a parked order (already built), and an existing customer is sent to the plan change rather than sold a second, empty cloud that bills twice. The site says what it can keep. "danach wissen Sie … wie Ihre Daten sicher umziehen" was a promise made before seeing the thing it is about: we do not know where a visitor's data is, what shape it is in, or whether it can be moved at all. Migration is named as its own question, looked at first and quoted afterwards. The integrations page gets the settings page's treatment for the same reason: it was one narrow column of six cards, so an operator connecting DNS scrolled past Stripe to reach it and the raw .env editor sat at the bottom of everything. Three tabs by what a section is FOR — services we buy from outside, our own machines, the file underneath — the same axis the page was rebuilt around when it stopped being split by storage mechanism. The tab is in the query string; unlocking survives a switch, because a confirmed password is a session fact and not a property of a tab. The .env tab is Owner-only, like the editor it holds. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 19:42:28 +02:00