Ein Shop verhindert doppelte oder veraltete lokale Lieferaufträge nicht durch mehr Support, sondern durch einen klaren Integrationsvertrag: Der Shop entscheidet, wann eine Bestellung lieferbereit ist, Maxmove oder das Transportsystem erhält genau eine stabile Auftragsreferenz, jeder Create-Request ist idempotent, und Webhooks lösen immer einen Statusabgleich aus statt den Shop blind zu überschreiben.
Für Operations ist das die eigentliche Frage hinter "Wie verbinde ich Shopify, WooCommerce oder Shopware mit Same-Day Delivery?": Nicht nur ob im Checkout eine Lieferoption erscheint, sondern ob Bestellung, Zahlung, Abholung, Fahrerstatus, Tracking und Zustellnachweis später denselben Vorgang beschreiben.
Die kurze Antwort
Ein belastbarer E-Commerce-Lieferfluss besteht aus sieben Entscheidungen:
| Entscheidung | Warum sie wichtig ist |
|---|---|
| Lieferfähigkeit vor Checkout | Der Shop darf lokale Lieferung nur anzeigen, wenn Gebiet, Produktdaten, Abholstandort und Zeitfenster passen. |
| Order-Readiness nach Checkout | Eine Lieferung sollte erst entstehen, wenn die Bestellung bezahlt, freigegeben oder bewusst manuell importiert ist. |
| Stabile Referenz | Bestellnummer, Fulfillment-ID oder interne Order-ID muss durch Quote, Lieferung, Tracking und Nachweis laufen. |
| Idempotency-Key | Wiederholte Requests nach Timeout dürfen keinen zweiten Fahrerauftrag erzeugen. |
| Statusmodell | Shop-Status und Transportstatus dürfen nicht beliebig ineinander gemappt werden. |
| Webhook plus Polling | Webhooks wecken das System; ein erneuter API-Abruf klärt den aktuellen Stand. |
| Proof of Delivery | Foto, Signatur oder Zeitstempel gehören an die Bestellung oder das Fulfillment, nicht in ein loses Support-Ticket. |
Wenn einer dieser Punkte fehlt, entstehen typische Fehler: doppelte Aufträge nach Retry, Lieferoptionen für ungeeignete Warenkörbe, ein Shop mit "versendet" während der Fahrer noch nicht abgeholt hat, oder ein Zustellnachweis, den niemand der Reklamation zuordnen kann.
Wo der Prozess startet: vor dem Checkout
Lokale Lieferung ist keine reine Versandart. Der Shop muss vor der Anzeige prüfen, ob der Warenkorb wirklich transportierbar ist.
Mindestens benötigt werden:
- ein aktiver Abholstandort mit vollständiger Adresse,
- Liefergebiet oder Serviceability-Prüfung,
- Produktgewicht und nach Möglichkeit Packmaß,
- Fahrzeug- oder Serviceklasse,
- Zeitfenster, Cut-off oder Mindestvorlauf,
- Entscheidung, ob Zusatzleistungen wie Tragehilfe angeboten werden.
Shopify unterscheidet etwa eigene lokale Lieferregeln und Carrier-Services für durch Drittanbieter berechnete Tarife. Die CarrierService-Dokumentation beschreibt Versanddienste, die dem Checkout Echtzeit-Tarife zurückgeben können (Shopify CarrierService). Für Maxmove heißt das praktisch: Die Lieferoption darf erst sichtbar werden, wenn der Shop genügend Daten für ein belastbares Angebot liefert.
Die Maxmove Shopify-Einrichtung spiegelt diese Logik: Abholstandort, Checkout-Tarife, Firmenkarte, Standardfahrzeug, Produktgewichte und Paketprofile müssen stimmen, bevor automatische Importe sinnvoll sind.
Wann entsteht der Transportauftrag?
Der häufigste Integrationsfehler ist ein zu früher Auftrag. Ein Kunde legt Ware in den Warenkorb, der Checkout fragt eine Lieferoption ab, und das Shopsystem erzeugt schon einen Transport. Das ist falsch. Ein Angebot ist noch keine Lieferung.
Nutzen Sie diese Trennung:
| Phase | Shop-Ereignis | Transportaktion |
|---|---|---|
| Warenkorb | Adresse und Warenkorb werden geprüft | Quote oder Lieferoption berechnen |
| Checkout | Kunde wählt lokale Lieferung | Quote referenzieren, noch keinen Fahrer beauftragen |
| Bestellung | Zahlung oder Freigabe ist erreicht | Lieferung mit Idempotency-Key anlegen |
| Fulfillment | Ware ist kommissioniert | Auftrag bestätigen oder auslösen, wenn der Prozess manuell ist |
| Ausführung | Fahrerstatus ändert sich | Status in Shop oder OMS aktualisieren |
| Abschluss | Proof of Delivery liegt vor | Bestellung mit Nachweis und Abschlussstatus verknüpfen |
WooCommerce-Integrationen arbeiten in der Praxis oft mit Hintergrundjobs, weil Zahlungsstatus, Lagerprozess und externe API nicht im selben Request sauber abgeschlossen werden sollten. Action Scheduler ist die in WooCommerce verbreitete Job-Queue für geplante und asynchrone Aktionen (Action Scheduler). Die Maxmove WooCommerce-Einrichtung beschreibt deshalb einen asynchronen Import nach einem konfigurierten Bestellstatus und verhindert doppelte Lieferungen über stabile Idempotenzdaten.
Shopware folgt einer ähnlichen Betriebslogik: Regeln entscheiden, wann eine Versandart sichtbar ist; Jobs sorgen dafür, dass ein bezahlter Auftrag genau einmal in den Lieferprozess übergeht. Die Maxmove Shopware-Einrichtung nennt dafür Zahlungsstatus, Checkout-Evidence, durable Queue und signierte Callbacks als Kernpunkte.
Die technische Leitplanke: Idempotenz
Idempotenz ist kein API-Detail für Entwickler, sondern ein Operations-Schutz. Wenn ein Plugin nach einem Timeout denselben Auftrag erneut sendet, muss das Transportsystem die bestehende Lieferung zurückgeben, nicht eine zweite Fahrt starten.
Ein guter fachlicher Schlüssel ist stabil und eindeutig:
shopify-order-58472-fulfillment-1woo-98211-local-deliveryshopware-300045-dropoff-mainerp-route-2026-08-29-berlin-17
Bei der Maxmove Partner API benötigt POST /partner/v1/deliveries einen Idempotency-Key. Derselbe Key mit demselben Body gibt die ursprüngliche Ressource zurück; derselbe Key mit verändertem Body wird abgelehnt. Das schützt vor doppelten Aufträgen und macht Fehler sichtbar, statt sie still in zwei Lieferungen aufzuteilen.
Status nicht zu grob mappen
Shop-Status wie "bezahlt", "in Bearbeitung", "versendet" oder "abgeschlossen" beschreiben den Handel. Transportstatus wie courier_assigned, at_pickup, picked_up, in_transit, at_dropoff und delivered beschreiben die Ausführung.
Eine saubere Integration mappt nicht jeden Transportstatus auf einen finalen Shopstatus. Sinnvoller ist:
| Transportstatus | Shop- oder OMS-Reaktion |
|---|---|
pending | Lieferung angelegt, noch keine Kundenbehauptung wie "unterwegs". |
courier_assigned | Interne Sicht: Fahrer ist zugeordnet; optional Kundenhinweis vorbereiten. |
at_pickup | Lager oder Filiale weiß, dass Übergabe ansteht. |
picked_up | Fulfillment kann als unterwegs markiert werden, wenn der Shop das unterscheidet. |
in_transit | Tracking-Link und ETA aktualisieren. |
at_dropoff | Support sieht, dass Zustellung unmittelbar läuft. |
delivered | Abschluss erst mit Nachweis oder definiertem Abschlussereignis setzen. |
cancelled oder expired | Bestellung nicht abschließen; manuelle Klärung oder neuer Auftrag. |
Uber Direct dokumentiert für digitale Lieferungen ein API-Modell mit Erstellung, Tracking und Webhooks (Uber Direct Developers). Lalamove positioniert API-Integrationen ebenfalls rund um automatisierte Auftragsanlage, Tracking und Geschäftsprozesse (Lalamove API Integration). Diese Beispiele zeigen die Marktlogik: Der Shop braucht einen Statusvertrag, nicht nur einen Lieferbutton.
Webhooks sind ein Signal, nicht die Wahrheit
Webhooks sind schnell, aber sie können mehrfach kommen, später ankommen oder nach einem Ausfall erneut zugestellt werden. Deshalb sollte der Empfänger:
- die Signatur prüfen,
- Event-ID deduplizieren,
- lange Verarbeitung in einen eigenen Job legen,
- bei Unsicherheit die Delivery- oder Tracking-Ressource erneut abrufen,
- nur vorwärts mappen, wenn der Zielstatus älter ist.
Onfleet beschreibt Webhooks als Ereignisse, die beim Eintreten bestimmter Aufgabenereignisse an externe Systeme gesendet werden (Onfleet Webhooks). Die Maxmove Webhook-Dokumentation folgt derselben robusten Grundregel: Webhooks benachrichtigen, der aktuelle Zustand wird bei Reconnects, Initialladung oder Unsicherheit über API-Abrufe abgeglichen.
Produktdaten entscheiden über Fahrzeug und Preis
Lokale Lieferung scheitert oft nicht an der API, sondern an fehlenden Produktdaten. Für Paketware reichen Gewicht und Standardversandregeln oft aus. Für lokale Same-Day- oder Sperrgutlieferungen braucht der Transportprozess mehr:
- Packstückzahl,
- Gewicht,
- Länge, Breite und Höhe,
- verpackt oder unverpackt,
- empfindlich, gekühlt oder genehmigungspflichtig,
- Treppe, Aufzug, Rampe oder Bordsteinkante,
- Rücknahme, Austausch oder Altgerät,
- Telefonnummer am Abhol- und Zielort.
Wenn diese Daten im Shop fehlen, sollte die Lieferoption eingeschränkt, manuell geprüft oder mit einem sicheren Standardfahrzeug kalkuliert werden. Ein "Preis live im Checkout" ist nur dann nützlich, wenn die Eingaben für Fahrzeug und Zusatzleistung realistisch sind.
Beispiel: WooCommerce-Shop mit lokalen Möbellieferungen
Ein Möbelhändler verkauft Regale und kleine Sofas regional. Der richtige Ablauf ist nicht "jede bezahlte Bestellung sofort an einen Fahrer senden".
Ein belastbarer Ablauf:
- Die Versandzone erlaubt Maxmove nur in den passenden Postleitzahlen.
- Produkte haben Gewicht und Paketprofil.
- Der Checkout zeigt lokale Lieferung nur für geeignete Warenkörbe.
- Nach Zahlung erzeugt ein Hintergrundjob genau einen Lieferauftrag.
external_idundIdempotency-Keybasieren auf Bestell- und Fulfillment-ID.- Webhooks aktualisieren Status und Tracking-Link.
- Bei Zustellung wird der Nachweis am Auftrag gespeichert und im Support sichtbar.
- Storno oder fehlgeschlagene Zustellung bleibt ein klärbarer Ausnahmefall, kein automatisch abgeschlossener Shopauftrag.
Der operative Gewinn liegt nicht in einer neuen Schaltfläche. Er liegt darin, dass Lager, Fahrer, Kunde und Support denselben Zustand sehen.
Checkliste vor dem Livegang
Prüfen Sie vor der ersten produktiven Integration:
- Welche Bestellungen dürfen automatisch importiert werden?
- Was ist die stabile externe Referenz?
- Welcher Bestellstatus löst die Lieferung aus?
- Gibt es einen Testmodus ohne echte Fahrerdisposition und ohne echte Kosten?
- Sind API- und Webhook-Secrets serverseitig gespeichert?
- Werden Wiederholungen mit Idempotency-Key abgesichert?
- Welche Webhook-Events werden benötigt?
- Was passiert bei
429, Netzwerkfehlern oder5xx? - Wo wird der Tracking-Link angezeigt?
- Wer sieht Foto, Signatur oder Zeitstempel nach der Zustellung?
- Welche Ausnahme stoppt Automatisierung und verlangt manuelle Prüfung?
Die Maxmove API-Sicherheitsseite nennt dafür konkrete Betriebsregeln: getrennte Test- und Live-Schlüssel, minimale Scopes, Rate-Limit-Beachtung, Retry mit Backoff und keine Secrets in URLs, Logs oder Support-Tickets.
Wo Maxmove passt und wo nicht
Maxmove passt für Shops und Plattformen, die lokale oder regionale Lieferungen aus einem kontrollierten Systemprozess erstellen wollen: Checkout-Tarife, manuelle oder automatische Importe, Partner API, Tracking, Webhooks und Proof of Delivery. Die öffentlichen Help-Center-Seiten zu Shopify, WooCommerce, Shopware und Partner API zeigen die jeweils passenden Einstiege.
Maxmove sollte nicht als Pauschalversprechen eingesetzt werden, wenn Produktdaten fehlen, Ware nicht transportfähig ist, Liefergebiet oder Zeitfenster ungeprüft sind, Gefahrgut betroffen ist oder ein Spezialservice wie Montage, Anschluss oder Entsorgung unklar bleibt.
Kurz gesagt
Eine gute E-Commerce-Lieferintegration beantwortet nicht nur "Kann der Kunde lokale Lieferung auswählen?", sondern "Kann dieser Auftrag genau einmal, mit richtigem Status und prüfbarem Nachweis ausgeführt werden?"
Starten Sie mit einem engen Szenario: ein Abholstandort, wenige Produktgruppen, klare Lieferzone, Testschlüssel, Idempotenz, Webhooks und ein definierter Proof-of-Delivery-Prozess. Danach lässt sich die Integration schrittweise auf weitere Standorte, Shopsysteme oder API-Flows ausbauen. Für den Einstieg: Maxmove E-Commerce oder die Partner API.
