ich folge diesem Guide, um Zahlarten zu implementieren: https://docs.shopware.com/en/shopware-platform-dev-en/how-to/payment-plugin
Konkret mit dem AsynchronousPaymentHandlerInterface. Der Happy case funktioniert einwandfrei wie man sich das vorstellt, geht allerdings etwas schief ist das Handling etwas unglücklich. Wirft man, wie dokumentiert, eine AsyncPaymentProcessException, ist zwar die Zahlung als cancelled markiert, die Bestellung an sich geht allerdings trotzdem durch. So weit ich das sehe, ist die Bestellung schon fertig und die Bestellbestätigungsmail geht raus bevor überhaupt meine finalize-Methode aufgerufen wird, die checken kann ob mit der Zahlung alles stimmt.
Es wäre schön, die Möglichkeit zu haben, den Benutzer zurück auf die confirm-Seite zu werfen mit dem Fehler, der bei der Bezahlung aufgetreten ist, damit man ihm anbieten kann, eine andere Zahlart zu wählen. Im aktuellen Fal sieht der Benutzer gar nicht, dass etwas schiefgegangen ist, man muss dann händisch hinterhertelefonieren.
Es wird explizit immer zuerst die Bestellung angelegt und bspw. Sprünge bei Bestellnummern zu umgehen und auch zu ermöglichen die Bestellnummer zu übertragen. So wird auch sichergestellt, dass es immer eine Bestellung im System gibt und nicht irgendwann eine Zahlung, aber keine Bestellung. Das ist erstmal so gewollt.
Mit 6.2 kann man über die finish Seite und auch den Account bei Bestellungen die den Zahlungsstatus “offen” haben nochmal die Zahlungsart wechseln oder es nochmal probieren. Quasi eine bereits getätigte Bestellung nochmal bezahlen. Damit erschlägt man zum einen dein Problem, dem Kunden kannst du dann auf der FInish-Seite alles anzeigen (Zahlung fehlgeschlagen, Bestellung angelegt, wechsel zu Vorkasse, probier es nochmal oder probiere was anderes) und er kann bequem nochmal bezahlen. Der zweite Vorteil ist, dass man damit auch direkt als Kunde eine Bestellung nachträglich noch von Vorkasse zu Paypal usw. ändern kann. Und er wird die da auch stornieren können, wenn er das Produkt doch nicht will (optional deaktivierbar).
ich hab das ganze in der Preview Version der 6.2 mal getestet. Wirft man aber aus der pay() Methode eine AsyncPaymentProcessException oder aus der finalize() Methode eine AsyncPaymentFinalizeException dann resultiert beides in der Standard-Fehlermeldung “Leider ist etwas schief gelaufen”. Bei ersterem bekommt man im log einen error:
Uncaught PHP Exception Shopware\Core\Checkout\Payment\Exception\AsyncPaymentProcessException: “The asynchronous payment process was interrupted due to the following error: broken”
bei zweiterem einen etwas cryptischeren critical error
Uncaught PHP Exception InvalidArgumentException: “Cannot redirect to an empty URL.” at /var/www/sw6/62rc1/vendor/symfony/http-foundation/RedirectResponse.php line 91 {“exception”:"[object] (InvalidArgumentException(code: 0): Cannot redirect to an empty URL. at /var/www/sw6/62rc1/vendor/symfony/http-foundation/RedirectResponse.php:91)"}
Am besten machst du mal ein Ticket auf, bei einem Abbruch oder Fehler sollte der auf die Bestellabschluss-Seite redirekten und dort kann man dann eine erneute Zahlung anstoßen. Vielleicht fehlt da der Case noch oder ähnliches. Issues.shopware.com