Zum Inhalt springen

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 schneller

Darü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.

Umfang und Konditionen

Zusammenarbeit
Fester Umfang, schriftlich vereinbart, bevor die Arbeit beginnt. Kein Tagessatz gegen ein offenes Backlog.
Preis und Dauer
Beides wird je Projekt festgelegt, sobald der Umfang steht. Gemeinsam angeboten, bevor etwas gebaut wird.
Was wir von Ihnen brauchen
Eine Person, die entscheiden darf, und Zugang zu Ihrem Repository und Ticketsystem.
Nicht enthalten
Alles außerhalb des vereinbarten Umfangs. Es wird ein eigener Umfang statt eines Änderungsauftrags.
Kosten Dritter
Hosting, Lizenzen, API-Gebühren und SaaS-Abonnements schließen und zahlen Sie selbst.
Rechnungsstellung
Codefacture Yazılım A.Ş., Türkiye. EUR, USD oder GBP per Überweisung, ohne türkische Umsatzsteuer auf exportierte Leistungen.

Häufige Fragen

Warum bauen statt Shopify oder ein Paket nutzen?
Sollten Sie nicht, solange die Plattform nicht das ist, was Sie Geld kostet. Der Punkt, ab dem Bauen günstiger ist, ist konkret und erkennbar: Preisregeln, die die Plattform nicht ausdrücken kann, Bestand über Lager oder Kanäle hinweg, den sie nicht abbildet, oder ein ERP, das die Quelle der Wahrheit sein muss statt eine nachgelagerte Kopie.
Verwenden Sie ein E-Commerce-Paket?
Wo eines passt, ja, und wir sagen es Ihnen - ein gepflegtes Paket zu erben ist günstiger, als einen Warenkorb selbst zu besitzen. Die Pakete tun sich schwer, wenn der Katalog ungewöhnlich ist, wenn Preise vertraglich statt ausgezeichnet sind, oder wenn Bestand mit etwas außerhalb des Shops geteilt wird. Dafür werden wir meistens geholt.
Wer verarbeitet Kartendaten?
Der Zahlungsdienstleister, über ein gehostetes Feld oder eine Weiterleitung, und die Anwendung sieht nie eine Kartennummer. Das ist nicht nur eine Sicherheitsposition, sondern eine Scope-Entscheidung - sie hält Sie in der kleinsten verfügbaren PCI-DSS-Stufe, und die Alternative ist ein jährliches Audit, das Sie nicht bezahlen wollen.
Lässt sich das an unser ERP oder unsere Buchhaltung anbinden?
Ja, und bei diesen Projekten muss es das meistens. Die wichtige Entscheidung fällt früh und schriftlich - welches System den Bestand besitzt, welches den Preis und welches den Kundendatensatz. Zwei Systeme, die beide glauben, den Bestand zu besitzen, sind der teuerste Integrationsfehler im Handel.
Anrufen+1 848 272 7583WhatsApp+90 850 308 5436E-Mailinfo@codefacture.comKontaktseite