E-Commerce-Entwicklung
Laravel-E-Commerce-Entwicklung
Maßgeschneiderte Commerce-Backends für Unternehmen, denen eine Plattform nicht mehr passt - Bestand ohne Überverkauf, ein Bestellzustandsautomat und Webhooks, die doppelt ankommen.
Die meisten Unternehmen sollten keinen eigenen Shop bauen. Eine gehostete Plattform ist günstiger als eine Codebasis, solange das Geschäft hineinpasst, und bei einem Katalog aus zweihundert einfachen Produkten lautet der ehrliche Rat, dass es hineinpasst.
Die Arbeit unten beginnt dort, wo es aufhört zu passen - und es hört meistens im Backoffice auf, nicht im Schaufenster.
Wo eine Plattform tatsächlich endet
Preise, die eine Regel sind und keine Zahl. Vertragspreise je Kunde, Mengenstaffeln, ein Händlerkonto mit anderen Konditionen je Produktgruppe. Die meisten Plattformen bilden einen Preis und einen Rabatt ab, und alles darüber hinaus wird zu einer Tabelle, die jemand von Hand pflegt.
Bestand an mehr als einem Ort. Zwei Lager, ein Ladengeschäft, ein Marktplatz-Kanal und ein Streckengeschäft über Lieferanten. Die Frage "wie viele können wir verkaufen" hat keine einzelne Antwort mehr, und die Antwort der Plattform ist die, die überverkauft.
Ein ERP, das die Quelle der Wahrheit ist. Wenn die Buchhaltung Preis und Bestand besitzt, liegt der Shop dahinter. Eine Plattform, die davon ausgeht, diese Felder selbst zu besitzen, kämpft die gesamte Projektlaufzeit gegen die Anbindung.
Fulfilment als Arbeitsablauf. Teillieferungen, Nachbestellungen, ein Kommissionierschritt, eine Fertigungsvorlaufzeit. Eine Bestellung, die nicht einfach bezahlt-dann-versendet ist, ist dort, wo Workflow-Engines von Plattformen enden.
Die Teile, die wir sorgfältig bauen, weil dort Geld verloren geht
Bestand, der sich nicht überverkaufen lässt. Einen Bestand zu lesen und ihn danach zu verringern, ist ein Wettlauf, und in einer Rabattaktion ist es ein Wettlauf, der hundertfach pro Sekunde stattfindet. Die Verringerung ist ein bedingtes Update, das die Datenbank entscheidet:
$claimed = Inventory::where('variant_id', $id)
->where('available', '>=', $qty)
->decrement('available', $qty); // 0 heißt, jemand anderes war schnellerDarüber sitzt eine Reservierung mit Ablauf - Bestand, der während eines laufenden Checkouts gehalten und bei Abbruch freigegeben wird - denn die Alternative ist entweder Überverkauf oder Bestand, der ewig für Warenkörbe blockiert bleibt, die niemand abgeschlossen hat.
Eine Bestellung als Zustandsautomat, nicht als Statusspalte. Welche Übergänge zulässig sind, welche unumkehrbar, und was jeder anfassen darf. Eine Statusspalte, die aus vier Controllern gesetzt wird, ist der Weg zu einer Bestellung, die versendet und erstattet ist und trotzdem auf Zahlung wartet.
Zahlungs-Webhooks, die doppelt, verspätet oder in falscher Reihenfolge ankommen. Jeder Anbieter sendet Duplikate, und die Zahlungsbestätigung kann vor der Weiterleitung eintreffen, die ihr eigentlich vorausgehen sollte. Webhooks werden verifiziert, roh gespeichert und idempotent gegen eine Referenz des Anbieters verarbeitet, damit eine Wiederholung ein Nichts ist statt einer zweiten Auslieferung.
Steuer einmal berechnet, zum richtigen Zeitpunkt, und festgehalten. Der Satz, der am Bestelltag galt, gehört zur Bestellung und ist kein erneuter Nachschlag, wenn jemand den Datensatz ein Jahr später öffnet. Wenn Sie über Grenzen hinweg verkaufen, ändern Leistungsort und Registrierungsstatus des Kunden die Antwort
- und die Regel, die jede Zeile erzeugt hat, muss neben dem Betrag gespeichert sein, denn danach fragt eine Prüfung.
Geld immer als ganze Zahl. Kleinste Einheit, mit Währung und gespeichertem Exponenten. Fließkomma in einem Handelssystem erzeugt ein Buch, das nie aufgeht, und eine Abstimmung, die niemand schließen kann.
Die Anbindungen, die das Projekt entscheiden
Commerce-Projekte sind selten ein System. Sie sind ein Shop, ein ERP oder eine Buchhaltung, ein Zahlungsdienstleister, ein Versanddienst, manchmal ein PIM und ein Marktplatz.
Was sie gelingen lässt, ist eine Eigentumsentscheidung vor der ersten Zeile Code: welches System die Bestandszahl besitzt, welches den Preis, welches den Kunden. Jede Integrationskatastrophe, in die wir gerufen wurden, begann damit, dass zwei Systeme dasselbe Feld zu besitzen glaubten, und löste sich in nächtlichen Jobs auf, die sich abwechselnd gegenseitig überschrieben.
Danach der mechanische Teil, dieselbe Disziplin wie bei jeder Integrationsarbeit: Wiederholungen mit Backoff, ein Outbox-Muster, damit nichts verloren geht, wenn die Gegenseite ausfällt, und ein Protokoll des Gesendeten, das ein Mensch lesen kann, wenn ein Kunde nach seiner Bestellung fragt.
Die Verwaltungsseite, auf die die meiste Nutzung entfällt
Das Schaufenster bekommt die Aufmerksamkeit, das Backoffice die Stunden. Bestellsuche, die mit einer Teilreferenz funktioniert, die vollständige Historie eines Kunden auf einem Bildschirm, eine Erstattung als eine Handlung statt als vier, und eine Bestandskorrektur, die festhält, wer sie warum vorgenommen hat.
Wir bauen das auf einem Admin-Panel statt von Grund auf, weil eine maßgeschneiderte CRUD-Maske nicht der Wert ist - und weil die Menschen, die acht Stunden täglich damit arbeiten, lieber etwas Konventionelles haben als etwas Cleveres.
Wie ein Projekt abläuft
Das erste Gespräch dreht sich um Geld, nicht um Code. Wo heute Bestellungen verloren gehen, was die Verwaltungsseite an Personalstunden kostet und vor welcher Integration alle Angst haben.
Daraus schreiben wir den Leistungsumfang: die Phasen, die Integrationsliste, was mit Ihren bestehenden URLs passiert, und den Preis. Vor der Unterschrift unter dieses Dokument wird nichts gebaut, denn im Handel werden die teuren Fehler in Woche eins gemacht und in Monat sechs gefunden.
Der Bau läuft dann in Phasen, die jeweils deployt enden. Der Checkout ist nie das Erste, was wir anfassen, und nie das Letzte, was wir testen.
Was Sie bekommen
Ein Commerce-Backend mit aufgeschriebenen und an einer Stelle durchgesetzten Regeln, ein Bestellmodell, das seine eigene Geschichte erklären kann, Anbindungen mit einem Eigentümer je Feld, und Tests über die Pfade, die Geld bewegen - Checkout unter gleichzeitigem Bestandsdruck, doppelte Webhooks, Teilerstattungen, Steuer an den Grenzfällen.
Wenn Sie noch nicht sicher sind, ob Bauen die richtige Antwort ist, ist es das meistens nicht, und ein Audit dessen, was Sie heute haben, sagt Ihnen das schneller und günstiger als ein Angebot.
