Customer replies to order-confirmation and resend-verification mail now
route to the seller's real address via Reply-To, and the From display
name reflects sellerName — but the From address itself stays
admin@mk360.de since sellerEmail's domain isn't confirmed SPF-authorized
on the Hostinger account yet (see the "SMTP From address pending SPF"
memory note for the follow-up). Also cleans up README references left
over from the previous footer rewrite (stale "company line" wording, a
dangling cross-reference to a renamed section).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Order confirmation, resend-verification, and the internal critical-alert
mail now render name, street, ZIP/city, email, and VAT ID from
company-settings instead of a bare "<sellerName> · <sellerEmail>" line,
so every email this app sends meets business-correspondence footer
requirements rather than just the customer-facing ones.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Password reset uses Payload's built-in forgot/reset-password flow,
customized to link to this app instead of the Payload admin. Order
confirmation email and the password-reset email's wording both come from
a new Payload email-templates collection, editable without a deploy and
previewable via Live Preview at /email-preview/[type] (same mechanism as
Posts/LegalPages/Testimonials, sample data instead of a real document).
Also: order numbers get a random suffix (prevents guessing, motivated by
a considered-and-deferred guest order-lookup feature); the discount code
field only shows in the cart when a code is actually active (codes now
apply via a ?code= link instead of manual entry); and three navigation
gaps found while testing — no reachable login link with an empty cart, no
logout link anywhere, no way back from profile to order history.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Complements Payload's per-account login lockout with per-IP rate limiting
on auth routes; proxy.ts silently refreshes an active customer's session
via Payload's built-in refresh-token endpoint instead of a long-lived
token. Registration now sends a non-blocking email-verification link
(doesn't gate login, since checkout registers and immediately logs in
mid-purchase). /konto/profil gets GDPR export/delete; order detail pages
get self-service cancel/return-request, backed by a Payload hook that
closes a real gap (a customer's JWT could previously PATCH any field of
their own order, not just status). Checkout failures now email an alert
independent of Payload's own health, since Kuma's uptime checks can't see
an order silently failing to persist.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Marco