Fuenf Luecken zwischen Checkout, Zahlung und Stornierung geschlossen.
1. Bestellung ohne Stripe-Sitzung blieb dauerhaft haengen
Schlug stripe.checkout.sessions.create fehl, blieb die Bestellung auf
"NEU" ohne stripeCheckoutSessionId stehen. Damit griff kein einziger
Aufraeumweg: der Abbruch-Klick braucht die Sitzungs-ID, der CronJob
filterte solche Bestellungen sogar aktiv heraus, und ein Stripe-Event
kann es ohne Sitzung nicht geben. Der reservierte Lagerbestand blieb
fuer immer blockiert, und die Oberflaeche schickte die Kundschaft dabei
auf die Erfolgsseite ("wir melden uns") — obwohl es keinen Weg gab,
diese Bestellung je zu bezahlen.
Die Route loest die Bestellung jetzt selbst auf (Bestand zurueck,
Status STORNIERT mit Notiz) und antwortet mit einem ehrlichen Fehler,
der ausdruecklich sagt, dass nichts abgebucht wurde. Laesst sich die
Sitzungs-ID nicht speichern, wird die Sitzung sofort wieder
geschlossen und derselbe Weg gegangen — eine "NEU"-Bestellung ohne
Sitzungs-ID kann so nicht mehr entstehen. Der CronJob raeumt
Altbestaende trotzdem ab (Filter entfernt).
2. Kaufabbrueche standen als Bestellungen im Kundenkonto
getOrdersForCustomer lieferte auch den Status "NEU" aus. Ein gerade
abgebrochener Kauf stand damit bis zu 45 Minuten lang mit
Bestellnummer und Summe in der Liste und sah aus wie ein zustande
gekommener Kauf. "NEU" wird dort jetzt ausgeblendet; in der
Bestellverfolgung bleibt die Bestellung auffindbar, heisst aber
"Zahlung ausstehend" statt "Neu".
3. Admin-Storno einer bezahlten Bestellung erstattete kein Geld
Status wurde gesetzt, Ware zurueckgebucht, der Betrag blieb beim Shop.
Der Storno erstattet jetzt ueber die Stripe Refunds API und setzt
Payment.status auf REFUNDED.
4. Admin-Storno schloss die offene Stripe-Sitzung nicht
Die Kundschaft konnte danach noch bezahlen; der Webhook fand die
Bestellung nicht mehr auf "NEU" und brach still ab. Die Sitzung wird
jetzt geschlossen, und der Webhook protokolliert eine Zahlung auf eine
nicht mehr offene Bestellung laut, statt sie zu verschweigen.
5. Erstattungen und Rueckbuchungen kamen im Shop nicht an
charge.refunded und charge.dispute.created werden jetzt verarbeitet:
eine volle Erstattung aus dem Dashboard setzt Payment auf REFUNDED,
eine Teilerstattung wird protokolliert, eine Rueckbuchung landet als
Vermerk an der Bestellung. preflight prueft beide Abonnements mit.
Scheitert ein Stripe-Aufruf beim Storno, wird die Stornierung nicht
zurueckgenommen — der offene Punkt erscheint als Fehlermeldung im
Admin-Bereich und als order.cancel_incomplete im Audit-Log.
tsc: 0 Fehler. vitest: 294/294 gruen (ein Regressionstest fuer den
502-Fall neu). eslint: sauber.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
91 lines
3.4 KiB
TypeScript
91 lines
3.4 KiB
TypeScript
import { prisma } from "@/lib/prisma";
|
|
import { insensitiveEquals } from "@/lib/prisma-search";
|
|
import type { Order, OrderItem, Shipment, Pickup, Invoice, Address, ReturnRequest } from "@/generated/prisma/client";
|
|
|
|
export type OrderWithDetails = Order & {
|
|
items: (OrderItem & { product: { slug: string } })[];
|
|
shipment: Shipment | null;
|
|
pickup: Pickup | null;
|
|
invoice: Invoice | null;
|
|
returnRequest: ReturnRequest | null;
|
|
};
|
|
|
|
/**
|
|
* Bestellungen eines Kontos — OHNE die noch unbezahlten.
|
|
*
|
|
* Eine Bestellung entsteht bereits beim Start des Checkouts und steht bis zur
|
|
* bestaetigten Zahlung auf "NEU". Die allermeisten dieser Datensaetze sind
|
|
* keine Bestellungen, sondern abgebrochene Kaufversuche: geschlossener Tab,
|
|
* Zurueck-Knopf, weggelegtes Handy. Sie verschwinden von selbst wieder (siehe
|
|
* lib/order-release.ts), aber bis dahin vergehen je nach Weg bis zu 45
|
|
* Minuten.
|
|
*
|
|
* In dieser Zeit standen sie hier wie vollwertige Bestellungen in der Liste —
|
|
* mit Bestellnummer, Summe und Statuskennzeichen. Wer den Kauf gerade
|
|
* abgebrochen hatte, fand ihn also im Konto trotzdem als Bestellung wieder
|
|
* und musste annehmen, dass doch etwas zustande gekommen ist.
|
|
*
|
|
* Bezahlte Bestellungen sind davon nicht betroffen: der Webhook setzt sie
|
|
* binnen Sekunden auf "BEZAHLT", danach erscheinen sie hier wie gewohnt.
|
|
* "STORNIERT" bleibt bewusst sichtbar — dort gab es einen Vorgang, den die
|
|
* Kundschaft nachvollziehen koennen muss (fehlgeschlagener Einzug, Storno
|
|
* durch die Imkerei).
|
|
*/
|
|
export async function getOrdersForCustomer(customerId: string): Promise<OrderWithDetails[]> {
|
|
return prisma.order.findMany({
|
|
where: { customerId, status: { not: "NEU" } },
|
|
include: {
|
|
items: { include: { product: { select: { slug: true } } } },
|
|
shipment: true,
|
|
pickup: true,
|
|
invoice: true,
|
|
returnRequest: true,
|
|
},
|
|
orderBy: { createdAt: "desc" },
|
|
});
|
|
}
|
|
|
|
/**
|
|
* Oeffentliche Bestellverfolgung ohne Login (auch fuer Gastbestellungen):
|
|
* Bestellnummer allein reicht nicht — die E-Mail-Adresse muss zusaetzlich
|
|
* uebereinstimmen, damit eine Bestellnummer (kryptografisch zufaellig, aber
|
|
* theoretisch in URLs/E-Mails sichtbar) allein keinen Zugriff gewaehrt.
|
|
*/
|
|
export async function getOrderForTracking(
|
|
orderNumber: string,
|
|
email: string
|
|
): Promise<OrderWithDetails | null> {
|
|
return prisma.order.findFirst({
|
|
where: { orderNumber, email: insensitiveEquals(email) },
|
|
include: {
|
|
items: { include: { product: { select: { slug: true } } } },
|
|
shipment: true,
|
|
pickup: true,
|
|
invoice: true,
|
|
returnRequest: true,
|
|
},
|
|
});
|
|
}
|
|
|
|
export async function getAddressesForCustomer(customerId: string): Promise<Address[]> {
|
|
return prisma.address.findMany({
|
|
where: { customerId },
|
|
orderBy: [{ isDefault: "desc" }, { createdAt: "desc" }],
|
|
});
|
|
}
|
|
|
|
export async function getInvoiceForCustomer(invoiceNumber: string, customerId: string) {
|
|
return prisma.invoice.findFirst({
|
|
where: { invoiceNumber, order: { customerId } },
|
|
include: { order: { include: { items: true, discountCode: { select: { code: true } } } } },
|
|
});
|
|
}
|
|
|
|
/** Ohne Besitzpruefung — nur fuer bereits als ADMIN verifizierte Aufrufer. */
|
|
export async function getInvoiceByNumber(invoiceNumber: string) {
|
|
return prisma.invoice.findUnique({
|
|
where: { invoiceNumber },
|
|
include: { order: { include: { items: true, discountCode: { select: { code: true } } } } },
|
|
});
|
|
}
|