Draft Order Unterstützung in Medusa selbst implementieren
Medusa kann zwar sogenannte Draft Orders anlegen – klingt schick, klappt aber nur in der Cloud. Wir betreiben für unseren Kunden jedoch die selbst gehostete Version. Also blieb nur Plan B: selber machen!
Für unseren Kunden haben wir bereits einen Webshop mit Medusa umgesetzt.
Nun wollte unser Kunde eine neue Zahlungsart anbieten: Vorkasse. Doch da trat ein neues Problem im Zusammenhang mit Medusa auf:
Das Problem:
Der normale Medusa-Prozess sieht vor, dass eine Bestellung erst dann erzeugt wird, wenn der Kunde seinen Warenkorb bezahlt hat.
Bei der Zahlung per Vorkasse funktioniert das nicht, da der Bezahlprozess mehrere Tage dauern kann. Während dieser Wartezeit soll die Bestellung aber trotzdem schon einmal „geparkt“, in der Adminansicht aufgelistet und nicht mehr im Warenkorb angezeigt werden.
Der Vorkasse-Workflow soll also so funktionieren: Der Kunde will seinen Einkaufsprozess abschließen und wird zum Zahlungsdienstleister geleitet, wo ihm die Bankdaten angezeigt werden. Erst nachdem der Kunde den Betrag überwiesen hat und der Zahlungseingang vom Zahlungsdienstleister bestätigt wurde, ist die Bestellung final aufgegeben, sodass sie intern weiterverarbeitet werden kann.
Draftorders als Lösung:
Medusa hat in den Daten die Möglichkeit, eine Bestellung als Entwurf zu markieren. Dieser Zustand ist jedoch nicht in die regulären E-Commerce-Prozesse eingebunden und wird nur genutzt, wenn das Draft-Orders-Plugin der Cloud-Version verwendet wird.
Es ist zwar möglich, diese Draft Order anzulegen und in eine normale Order umzuwandeln, jedoch wird dabei lediglich der Status von „draft“ auf „pending“ gesetzt.
So mussten wir uns also selbst darum kümmern, dass die Produkte richtig reserviert werden, wenn die Draft Order umgewandelt wird, und dass die Draft Orders im Backend angezeigt werden.
Die Umsetzung:
Bei jeder Bestellung mit Vorkasse legen wir direkt eine Draft Order an, der die Payment Session zugewiesen wird. Die Order bleibt also so lange im Draft-Status, bis wir vom Zahlungsdienstleister die Meldung erhalten, dass die Zahlung eingegangen ist. Danach wird die Draft Order in eine normale Order konvertiert. Dazu mussten wir Medusa-Funktionen nutzen, um die Produkte zu reservieren und den Bestand korrekt zu aktualisieren. Nachdem der Bestand aktualisiert wurde, wird die Order als „completed“ markiert und kann nun weiterbearbeitet und versendet werden.
Beim Konvertieren der Draft Order in eine normale Order haben wir uns am „Complete-Cart“-Workflow orientiert. Hier war es wichtig, gründlich zu testen und den Workflow exakt nachzubauen, da sonst Bestellungen nicht korrekt abgeschlossen oder Produkte nicht richtig reserviert werden.
Fazit:
An diesem Beispiel zeigt sich schön, wie die Arbeit mit Standardsoftware laufen kann. Ein Feature ist zwar vorhanden, passt aber nicht genau zum aktuellen Use Case. Aufgrund der modularen Struktur von Medusa und durch die Möglichkeit, sich den Medusa-Quellcode anzuschauen, konnten wir den Standard nun so weit erweitern, dass er zu den geforderten Anforderungen passt.
)
)
)
)
)
)
)
)