CE 6.4 & PayPal Checkout 2.1 - Troubleshooting

@Mario_Lorenz nachdem ich in mehrere Screen-Sessions meinen Kunden die Frontend Integration und den onBoarding Prozess vorgeführt habe und selbst einige Test-Bestellungen im Sandbox Modus ausgeführt habe. Sind folgende Dinge an mich herangetragen wurden bzw. Erfahrungswerte welche ich gesammelt habe:

  1. Es wird bemängelt, dass bei den Zahlungsarten Kreditkarten und Rechnungskauf (Bestätigung Bestellschritt) die Daten innerhalb des Shops abgefragt werden und nicht wie früher im PayPal Popup.

Das versprochene Ziel von PayPal Checkout ist es die Benutzerfreundlichkeit zu erhöhen und dadurch die Conversions zu steigern. Aber die Abfrage solcher sensiblen Daten in einem für den Endkunden zu Beginn fremden Shop erreicht wahrscheinlich eher das Gegenteil.

Dann ist halt wie bereits erwähnt unschön, dass beim Anmeldungsschritt im Bestellvorgang und im Mini-Basket die PayPal Express Buttons nicht mehr da sind.

  1. Nächstes Problem ist, dass das neue Amazon Pay Modul sich anscheinend mit PayPal Checkout Modul in die Quere kommt, sobald das neue Amazon Pay Modul aktiviert und noch nicht konfiguriert verschwindet z.B. der PayPal Express Button auf der Produktdetailseite.

  2. PayPal Checkout Modul, wenn die Anrede als Pflichtfeld definiert im Admin unter Grundeinstellungen, dann kommt bei einem PayPal Express Gast-Besteller die blöde Fehlermeldung, dass sein Lieferland nicht beliefert wird. Dies stimmt nicht. Der wahre Grund ist, dass der Gast-Benutzer nicht angelegt werden kann weil eine Prüfung fehlt schlägt.

  3. Ebenfalls bei PayPal Express Gast-Besteller (E-Mail neu im Shop) wenn ein Produkt nicht lieferbar, dadurch wahrscheinlich nicht in den Warenkorb gelegt werden kann und dadurch keine Session angelegt wurden ist - was auch dazu führt, dass der Gast-Besteller nicht anleget werden kann und eine Fehlermeldung auf der Produktdetailseite erscheint.

  4. Was noch aufgefallen ist, bei Produktdetailseiten mit Variantenauswahl wird der PayPal Express Button schon angezeigt wenn noch keine Variante gewählt. Dort muss ich noch prüfen ob das ein shopspezifisches Problem ist oder generell wünschenswert wenn Modul dies löst.

  5. Der onBoarding Prozess wirkt für viele überfordernd, am meisten Leiden die Händler*innen welche nicht so technikaffine sind und sich unsicher sind.

Zusatz

Eine Sache welche sich auf das Shop Framework bezieht ist der Wunsch, dass als Anrede neben Herr und Frau noch die rechtlich erforderliche Divers angeboten wird.

Anmerkung

Wer als Händler*in auf die Zahlungsarten Kreditkarte und Rechnungskauf verzichten kann sich aber bei der technischen Einrichtung unsicher ist - hat die Option Lassen Sie Ihren Entwickler die Arbeit erledigen - Entwickler hinzufügen (Screenshot). Dies unter https://paypal.com unter dem Reiter App-Center vorm Fußbereich der Webseite ersichtlich. Darüber sollte es einen Entwickler möglich sein den erforderlichen Webhook manuell anzulegen.

Das kann man dem Checkoutmodul nicht anlasten! Ich habe “Divers” oder “keine Angabe” statt “bitte auswählen” in den Sprachvariablen ausgetauscht.

Deswegen ist es auch ein Zusatz, welcher sich auf das Shop Framework bezieht.

1 Like

Dort habe ich einen Vorschlag als Pull-Request eingereicht feat: add page details variants handling by Indianer3c · Pull Request #37 · OXID-eSales/paypal-module · GitHub leider mein erster Ansatz mit onInit JavaScript SDK reference zu arbeiten schlug leider fehl, weil actions.disable mir ein false zurück liefert.

@Mario_Lorenz dabei ist mir noch folgende Zeile aufgefallen https://github.com/OXID-eSales/paypal-module/blob/b-6.3.x/src/Core/ViewConfig.php#L139

  1. Müsste es dort nicht lauten:
if ($this->getServiceFromContainer(ModuleSettings::class)->isAcdcEligibility()) {
    if (isset($params['enable-funding'])) {
        $params['enable-funding'] .= ',card';
    } else {
        $params['enable-funding'] = 'card';
    }
} else {
    $params['disable-funding'] .= ',card';
}

Kann es sein das dort die Logik verdreht ist?

Dies hätte den Vorteil, dass wenn ich PayPal JavaScript SDK richtig verstehe bei aktiver Kreditkarte auch noch der Kreditkarten Button angezeigt werden würde.

  1. Beim Debuggen folgender Zeile https://github.com/OXID-eSales/paypal-module/blob/b-6.3.x/src/Core/ViewConfig.php#L129

hat er dort bei nicht den Controller details sondern den Widget Controller oxwarticledetails aber der Default Wert buttons sorgt anscheinend dafür das Buttons angezeigt.

Bei läuft jetzt alles, was der Grund war bleibt unklar. Habe es es einmal aktiviert und deaktiviert.

Icons zu den Zahlungsarten fände ich auch schön. Könnte man das per CSS über die input-ID realisieren?
z.B. input id=“payment_oscpaypal_giropay”

1 Like

Hmm eine Erklärung kann sein, dass Du das Modul in der Zwischenzeit über Composer aktualisiert hattest und ein Update eingespielt. Durch die Reaktivierung ggfs. eine Funktion hinzugekommen bzw. Bugfix was Dein Problem mit Weiterleitung auf die Startseite gelöst hat.

Deine Erfahrungen mit Rechnungskauf kann ich im Sandbox Modus bestätigen, diese Meldung soll wahrscheinlich bedeuten, dass man diese Zahlungsweise vom Anbieter welcher sich hinter dem Rechnungskauf verbirgt abgelehnt wurde.

Theoretisch kannst Du vieles über CSS lösen. Bei der Integration PayPal Checkout kommt seitens PayPal eine neue Form der Button/Icon Integration zum Einsatz.

Buttons und Icons werden über JavaScript eingeladen. Darauf greift das PayPal Checkout für OXID Module zurück. Die Dokumentation dafür findest Du unter https://developer.paypal.com/sdk/js/reference/

Selber habe ich es über das Child-Theme des Shops gelöst, damit die Logos der Zahlungsarten ins Gesamtbild des Shops passen.

@indianer3c: Zu Deinen Fragen und Wünschen:

1) Datensammeln bei Kreditkarte und Kauf auf Rechnung

Wenn Du Dir Kreditkarte genau anschaust, dann siehst Du das die Daten nicht in den Shop kommen, sondern das PP die Daten selbst per JS entgegen nimmt. Der Prozess erfährt dann nur, ob alles in Ordnung war. Das Entspricht den Anforderungen der europäischen Zahlungsdiensterichtlinie PSD2. Der Vorteil ist, Daten werden nicht im Shop gesammelt, obwohl es so wirkt, als ob man die Daten im Shop eingibt. Diese Art des Datensammelns werden/müssen bei allen Paymentern sukessive nachgezogen, die nicht auf die Technik setzen, während des Checkouts auf sichere Paymenter-Seiten zu springen, wie PayPal bei seinem eigenen Payment.

Bei Kauf auf Rechnung werden zwei Daten abgefragt (Telefon und Geburtsdatum) die OXID auch sammeln könnte, wenn sie als Pflichtfelder registriert sind. Diese Daten werden ggf. auch vorbelegt, wenn sie denn schon eingegeben wurden und werden auch in diesen Feldern gespeichert. Die sind sonzusagen “harmlos”.

2) Zusammenspiel mit Amazon

Das schaue ich mir an.

3) Anrede Pflichtfeld

Das schaue ich mir auch an. Zwei Gedanken: Anrede als Pflichtfeld könnte man aus Shopbetreibersicht überdenken. Es bringt für den Prozess kein Mehrwert. Das Päckchen kommt mit oder ohne Anrede an und Rechnungen lassen sich in der Ansprache auch sehr neutral formulieren. Dein Wunsch nach Divers lässt sich seid zwei Jahren sehr gut umsetzen. Es gibt einen block in der tpl/form/fieldset/salutation.tpl der sich sehr gut ergänzen lässt.

4) PayPal Express Gastbesteller erzeugen Fehler

Das hat einen anderen Grund (eine nicht angelegte Session). Das beheben wir bereits im nächsten Release.

5) Varianten und PP-Express-Button

Schaue ich mir an

6) onBoaring in Allgmeinen

Ja, Ja ich weiß :slight_smile:

7) enable-funding

Das ist richtig so. Hintergrund ist. PayPal will Kreditkarte über den Checkout laufen lassen. Was Du dort gesehen hast, ist der Fallback für den Fall, das Dir als Shopbetreiber Kreditkartenzahlung während des onBoardings nicht genehmigt wurde. Dann besteht immer noch die Option Kreditkartenzahlung über die PayPal-Buttons abzuwickeln.

1 Like

Moin @Mario_Lorenz danke Dir.

1) Datensammeln bei Kreditkarte und Kauf auf Rechnung

Ja, genau darauf bezieht es sich. Es wirkt so, dass es beim Shop gesammelt wird und dies könnte ggfs. den ein oder anderen Kunden davon abhalten dies zu nutzen bzw. den Kauf abzubrechen.

2) Zusammenspiel mit Amazon

Ja, danke Dir. Mir graut es bereis vor dem onBoarding Prozess :face_with_peeking_eye: Integration von neuen Amazon Pay Module auf Anfang August 2022 verschoben, weil ist mit PayPal Checkout zu viel.

3) Anrede Pflichtfeld

Zur Erklärung im konkreten Fall wird für die E-Mails die über ein Shop Modul versendet werden können sehr intensiv mit der Anrede für die E-Mails welche versendet werden gearbeitet. Deswegen wurde Anrede ein Pflichtfeld.

Danke für den Smarty Block Hinweis. Dort bin ich noch in Abstimmung wie dies gelöst. Meine Vorstellung dort, dass ich Deine Block Überladung nutze und ein Default Wert bestimme damit das Feld für den E-Mail Versand immer vorbelegt ist.

4) PayPal Express Gastbesteller erzeugen Fehler

Ja, also im Prinzip was ich versucht habe zu beschreiben mit fehlender Session durch fehlendes legen von Produkt in Warenkorb vorab.

Weil der Express Button auf Produktdetailseite hat zwei Aufgaben

a. Produkt in Warenkorb legen
b. PayPal Popup aufrufen

Wenn a. nicht erfolgt fehlt später bei Zurückleitung zum Shop die Session womit Gast-Besteller nicht angelegt werden kann.

Habe schon gesehen, dass Du dort wieder Sonderschichten schiebst und dran bist.

Im Prinzip muss es vorher funktioniert haben immer mit der Voraussetzung, dass addToBasket funktioniert hat um eine Session zu setzen über den Warenkorb. Wenn dies einen der 3 Fehlerfälle Out of Stock, Article Input oder No Article wirft, dann konnte der neue Gast-Benutzer über PayPal Checkout Modul wegen fehlender Session nicht angelegt werden.

5) Varianten und PP-Express-Button

Ergänzend im bisherigen Modul wird der Express Button disable markiert wenn noch kein kaufbares Produkt ausgewählt. Dies mit der neuen JavaScript Integration nicht mehr möglich von PayPal aus wie es scheint.

Mein Pull-Request beinhaltet die Lösung, dass der Express Button erst gerendert wird wenn ein kaufbares Produkt ausgewählt.

6) onBoaring in Allgmeinen

Man gewöhnt sich dran, aber für Kommunikation und Vertrauensverhältnis wird da vieles kaputt gemacht. Da vieles nicht nachvollziehbar und es wirkt so, als ob jemand sich unbefugt Zugriff zum PayPal Konto verschaffen möchte.

Was z.B. nicht verstanden wird, dass es anscheinend für jeden geschäftlichen PayPal Account automatisch ein Developer Account zu geben scheint. Die Überforderung, Skepsis und Angst ist dort riesig.

7) enable-funding

Guter und interessanter Hinweis. Dies heißt wenn beim Webhook das Häckchen für

  • CHECKOUT.PAYMENT-APPROVAL.REVERSED

nicht gesetzt, sollte alternativ neben PayPal Express Button und PayPal Pay Later Button noch ein Kreditkarten Button erscheinen?

Für die Code-Stelle wäre ein Kommentar wünschenswert, dass dort ein Fallback wenn neue Kreditkarten Zahlungsart inaktiv. Das heißt zum Verständnis der Kreditkarten Button ist der Standard von PayPal und die neue Zahlungsart Kreditkarte hat damit gar kein Logo über das SDK von PayPal.

Moin @bheyse

es fehlt in der Tat noch bei PayPal Definitions.

Aber es scheint zumindest in der Software Client Bibliothek die zusammen mit dem PayPal Checkout Module ausgeliefert integriert unter Sepa Debit.

Ggfs. kommt SEPA noch in Zukunft in neuerer Modulversion.

@bheyse & @indianer3c : SEPA kommt kurzfristig nicht als Checkout-Payment (ähnlich Kreditkarte und Rechnungskauf). Der dringende Wunsch danach ist PayPal aber bereits bekannt. Also abwarten.

1 Like

Wir haben gerade Version 2.1.3 bzw. 1.1.3 released.

  • Die Express-Buttons sind optimiert (Variantenhandling, Login als Gast, Express-Button im MiniBasket).
  • Für “Netto”-User gibt es mehr Stabilität durch Überbrückung der Mwst. Rundungsfehler

Alle anderen offenen Punkte in diesem Thread sind noch in Arbeit …

1 Like

Der Tag für 2.1.3 fehlt noch Tags · OXID-eSales/paypal-module · GitHub

Dank für die Info:-)

Eine Frage warum schreibt mir dann der PP Support folgendes?
So wie ich das verstehe ist es von PP bereits vordefiniert. Oder täusche ich mich?
….
Grundsätzlich ja! Ob OXID das jetzt auch implementiert hat, kann ich so natürlich schlecht sagen. Das müssten wir uns am lebenden Objekt anschauen. Die Doku von OXID hilft da jedenfalls nicht weiter.

Nach Update auf 1.1.3 geht bei mir Kreditkarte nicht mehr, alles andere läuft

Moinsen @bheyse und moinsen @kubber

dort hatte @Mario_Lorenz hier im Ticket bereits ausgeführt, dass es mittlerweile 3 Module für PayPal seitens OXID eSales gibt welche auf unterschiedliche Schnittstellen zurück greifen

  • PayPal Standard Modul = SOAP Schnittstelle
  • PayPal Plus Modul = API Schnittstelle Version 1 (welche anscheinend im September 2022 abgeschaltet werden soll)
  • PayPal Checkout Modul = API Schnittstelle Version 2

Daher wäre in der Kommunikation mit PayPal immer zu klären auf welche Schnittstelle sich die Aussagen beziehen.

@bheyse kannst Du dies bitte konkretisieren was dort Deine Annahme?

@kubber wie macht sich dies bemerkbar? Bist Du sicher, dass Du auch als Rechnungsanschrift nur Deutschland hast?

Weil Hintergrund ist, dass die neue Auswahl im Checkout Prozess sich nur auf Rechnungsanschrift in Deutschland zu beziehen scheint.

Deine beschriebene Weiterleitung auf Startseite lässt sich anscheinend nachstellen wenn Du als Rechnungsanschrift ein anderes Land als Deutschland, der neuen Zahlungsart Kreditkarte im Admin manuell von Dir weitere Länder zu geordnet hast und jemand aus dem Ausland versucht mit Kreditkarte zu bezahlen.

Daher meine Vermutung, dass dies kein Problem vom Update ist sondern schon von Anfang an so. Da Kreditkartenzahlung nur für Deutschland vorgesehen und nicht wie mit PayPal Plus noch weitere Länder ergänzt werden können.

Sie auch PayPal Checkout Modul Länder und Währungen im Blick haben!

Moin,

wir bekommen beim Modul 2.1.3 einen Fehler bei Giropay und Sofort, KRE funktioniert.
Woran kann das liegen?
OXID PE 6.4.1 / PHP 8.0.19

Hier die Meldung nah dem Absenden im 5. Schritt.

not set
OxidSolutionCatalysts\PayPal\Exception\Redirect Object
(
    [destination:OxidSolutionCatalysts\PayPal\Exception\Redirect:private] => https://sandbox.paypal.com/payment/giropay?token=92J39246TU5036637
    [type:protected] => oxException
    [_sFileName:protected] => /var/www/html/source/log/oxideshop.log
    [_blRenderer:protected] => 
    [_blNotCaught:protected] => 
    [message:protected] => not set
    [string:Exception:private] => 
    [code:protected] => 0
    [file:protected] => /var/www/html/vendor/oxid-solution-catalysts/paypal-module/src/Controller/OrderController.php
    [line:protected] => 262
    [trace:Exception:private] => Array
        (

Danke aber Einstellungen stimmten und vor Update auf 1.1.3 haben alle Zahlungsarten ink. Kreditkarte funtktioniert und es wurde sonst nichts verändert. Das “Fenster” mit den Kreditkartenangaben öffnet sich nicht mehr auf Übersichtsseite. Wenn die Seite lädt sieht man wie es sich ganz kurz öffnet und ann schließt…

Folgender Container klappt nicht auf

Es steht nur noch Titel der Zahlungsart = Kreditkarte.

Der Krediktkarten-Button auf der Produktseite unter “später bezahlen” erscheint auch nicht.

@kubber guter Hinweis, dies könnte in der Tat mit dem Modul-Update zu tun haben. Ggf. eine Version zurückspringen mit bitte zuerst in Testumgebung

composer require --no-update oxid-solution-catalysts/paypal-module:v1.1.2
composer update --no-dev

Die Info muss an @Mario_Lorenz um den Mario zu entlasten bei der Kommunikation einen Bug-Report unter Main - OXID eShop bugtrack einreichen mit genauer Fehlerbeschreibung.

@kubber & @bheyse eure Infos oder Fehlerbeschreibungen am Besten als Bug-Report anlegen damit dort ein bisschen Struktur rein kommt.

Wer technisch bewandert kann selbstständig Pull-Requests oder Issues unter GitHub einreichen unter GitHub - OXID-eSales/paypal-module

Danke für die Rückmeldung. Bin wieder auf 1.1.2 und es funktioniert wieder!

PS: Bin die ganze Zeit nur in Testumgebung (mit Live Daten) - um meine Paypal Konditionen für ein weiteres Jahr zu sichern muss ich die Umstellung aber bis zum 22.07.22 von Paypal Plus auf Checkout vollziehen. Das Problem haben wahrscheinlich noch mehr…hoffe das Modul läuft stabil bis dahin.

1 Like