From beea59270671918e0dbe84614803d2e61a61eb20 Mon Sep 17 00:00:00 2001 From: Marco Date: Thu, 30 Jul 2026 10:08:37 +0000 Subject: [PATCH] =?UTF-8?q?Reflect=20Orders.paymentStatus's=20new=20meanin?= =?UTF-8?q?g=20for=20=C3=9Cberweisung=20orders?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - switch-to-stripe eligibility gained paymentStatus !== "paid" — an order an admin already marked paid by hand must never also be switchable to Stripe. - PaymentStatusBadge: "Offen" now renders in the same red/subtle style as a failed status (was neutral grey) — worth visually flagging, now that it's a real tracked state rather than a permanent placeholder. --- README.md | 36 +++++++++++++++++++ .../[orderNumber]/switch-to-stripe/route.ts | 6 ++-- app/konto/bestellungen/[orderNumber]/page.tsx | 1 + app/konto/components/PaymentStatusBadge.tsx | 4 +-- 4 files changed, 43 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index befad97..b826181 100644 --- a/README.md +++ b/README.md @@ -2036,6 +2036,42 @@ Full plan for an n8n-driven blog-post content-automation pipeline (not yet built) lives in the Payload backend repo's `docs/blog-automation-plan.md`, not duplicated here since it changes independently of this frontend. +**Switching an unpaid Überweisung order to Stripe.** New "Zahlungsart +ändern" button on `/konto/bestellungen/[orderNumber]`, shown when an order +is still `paymentProvider: 'manual'`, `status: 'received'`, +`paymentStatus` not yet `'paid'`, and an active Stripe payment method +exists. `POST /api/account/orders/[orderNumber]/switch-to-stripe` creates +a real PaymentIntent (`app/lib/payments`, same code checkout itself uses) +and hands it to the backend's `switchPaymentToStripeEndpoint`. Reuses +`PaymentStep` (checkout's own Stripe collection UI) and +`/checkout/verarbeitung`'s polling page — both now take a +`returnContext`/`context` prop/param so payment confirmation lands back +on the order page instead of clearing the cart and redirecting to +`/bestellbestaetigung`, which would be wrong for an order that was +already placed and confirmed. + +Also: a payment status badge (Offen/Bezahlt/…) next to the existing +fulfillment status badge, on both the order list (`/konto/bestellungen`) +and the detail page — "Offen" renders in the same red/subtle-background +style as a failed status, not the neutral grey the fulfillment status +badge uses for its own "in progress" states, since an unpaid order is +worth visually flagging. A one-line mention of the switch option was +added to the Vorkasse unpaid notice in the order-confirmation email, +shown only when `hasOnlinePaymentOption` is true (an active Stripe method +actually exists). + +**Fixed the email-preview page** (`/email-preview/[type]`) — it rendered +the email HTML (a full `...` fragment) via +`dangerouslySetInnerHTML` into a plain `
`, nesting it inside the +page's own already-existing `` — invalid HTML the browser silently +mangled, which is why the preview looked broken (wrong background/ +padding/font). Now renders via `