Neuigkeiten
  • Die modified eCommerce Shopsoftware ist kostenlos, aber nicht umsonst.
    Spenden
  • Damit wir die modified eCommerce Shopsoftware auch zukünftig kostenlos anbieten können:
    Spenden
  • Thema: MODUL: PayPal PLUS & PayPal Checkout Zahlungsmodule für modified eCommerce Shopsoftware

    demoncleaner

    • Fördermitglied
    • Beiträge: 487
    Oh, ok. Danke karsta.
    Noch jemand eine Idee zu meinem Status-Problem? Ist das auch ein Bug? Oder wäre das im Sandbox-Modus normal, dass kein Capture kommt und in so fern auch der Status nicht umspringen kann?

    Gruß
    DC
    rechtstexte für onlineshop

    noRiddle (revilonetz)

    • Experte
    • Beiträge: 14.006
    • Geschlecht:
    Mir scheint, als hätte ich einen weiteren Bug entdeckt, den ich im Demoshop nachstellen konnte. Wenn ich im Demoshop z.B. paypal und paypalpui als nicht-erlaubte-Zahlungsweisen (für Admin) definiere, werden mir diese trotzdem im Checkout angezeigt.

    Diesen Bug für PayPal-Zahlungsarten gibt es seit man nicht-erlaubte-Zahlungsweisen eintragen kann.
    [...]

    Haben wir dazu bereits ein Ticket ?

    Weiß noch jemand noch etwas hierzu ?
    Ist es so, daß man bei PayPal-Zahlungen mit Rechnung und Kreditkarte keine Sendungsnummer aus dem Shop an PayPal senden kann ?
    Sieht auch so aus, als würde es zwar eine payment_id, nicht jedoch eine transaction_id geben in diesen Fällen.

    Wenn das sich so verhält, wer weiß warum, und behandelt Ihr das ?
    [...]

    Gruß,
    noRiddle

    Tomcraft

    • modified Team
    • Gravatar
    • Beiträge: 46.373
    • Geschlecht:
    [...]
    EDIT: Ich hab das mal im Demoshop versucht zu testen. Dabei fiel mir auf, dass wenn ich im Demoshop versuche einen anderen Status als Standardstatus zu definieren, erhalte ich eine weiße Seite. Ist das ein Bug oder Absicht? Jedenfalls hab ich dann mal einen neuen Status erzeugt den ich Erfolgreich genannt habe. Auch hier erhält die Bestellung nie den Status Erfolgreich, sondern immer nur den Standardstatus. Es kann natürlich sein, dass das in der Sandbox nicht anders geht. Das weiß ich nicht.

    Bitte teste das nochmal. Ich vermute, dass du genau um 06:00 Uhr getestet hattest, als die Datenbank zur vollen Stunde zurückgesetzt wurde.

    Mir scheint, als hätte ich einen weiteren Bug entdeckt, den ich im Demoshop nachstellen konnte. Wenn ich im Demoshop z.B. paypal und paypalpui als nicht-erlaubte-Zahlungsweisen (für Admin) definiere, werden mir diese trotzdem im Checkout angezeigt.

    Die Kundengruppe für Admins ist im Frontend "Neuer Kunde". Einzustellen unter "Konfiguration" -> "Mein Shop" -> "Kundenstatus(Kundengruppe) für Administratoren im Frontend".
    Und der Cache muss auch geleert werden, wenn man solche Änderungen vornimmt.

    Diesen Bug für PayPal-Zahlungsarten gibt es seit man nicht-erlaubte-Zahlungsweisen eintragen kann.
    [...]

    Das stimmt nicht, siehe oben. :whistle:

    Grüße

    Torsten

    demoncleaner

    • Fördermitglied
    • Beiträge: 487
    [...]
    Bitte teste das nochmal. Ich vermute, dass du genau um 06:00 Uhr getestet hattest, als die Datenbank zur vollen Stunde zurückgesetzt wurde.
    [...]

    Hallo Torsten, ich habe das nochmals getestet mit exakt dem selben Ergebnis.
    Hier mein Vorgehen:

    - ich gehe in Konfiguration > Bestellstatus und lege einen neuen Status an der heißt Erfolgreich
    - testweise versuche ich den mal als Standard zu definieren und erhalte eine weiße Seite - geht also nicht, aber egal an der Stelle
    - Ich gehe zur paypal Konfiguration und setze Status erfasst auf Erfolgreich
    - Ich gehe in die Webhooks und setze PAYMENT.CAPTURE.COMPLETED ebenfalls auf Erfolgreich und PAYMENT.CAPTURE.DENIED testweise mal auf Storniert
    - Die Bestellung bleibt auf Offen.
    - Ich gehe in die Bestellung und schaue mir das Dropdown bei Paypal Details an. Dort sehe ich ein Capture Completed

    [...]
    Die Kundengruppe für Admins ist im Frontend "Neuer Kunde". Einzustellen unter "Konfiguration" -> "Mein Shop" -> "Kundenstatus(Kundengruppe) für Administratoren im Frontend".
    Und der Cache muss auch geleert werden, wenn man solche Änderungen vornimmt.
    [...]

    Das wollte ich auch noch testen und ... [EDIT]

    Es lag am Cache.

    Tomcraft

    • modified Team
    • Gravatar
    • Beiträge: 46.373
    • Geschlecht:
    Ich habe den Fehler in Ticket #2497 festgehalten.

    Grüße

    Torsten

    Timm

    • Fördermitglied
    • Beiträge: 6.260
    @noRiddle

    Ich sehe bei einer Bestellung mit "paypalpui" im Backend beim Accordeon von PayPal zwei unterschiedliche IDs. Einmal links bei Zahlungsdetails und einmal rechts bei Transaktionen.

    Wenn ich dann auf "Sendungsnummer übertragen" klicke, wird diese Sendungsnummer auch in meiner PayPal App bei der Bestellung unter Versandinformationen eingetragen und im Shopbackend ist sie auch eingetragen und es erscheint neu dann der löschen Button.

    Gruß Timm

    demoncleaner

    • Fördermitglied
    • Beiträge: 487
    @Tomcraft
    Du hast jetzt das mit der weißen Seite bei Änderungsversuch des Standard-Status als Ticket angelegt. Das war zumindest bei mir jetzt aber nicht das Hauptproblem.

    Was ist denn mit dem Problem, dass der Status bei Bestellungen auf Rechnungen sich nicht ändert. Da hatte Timm zwar geschrieben, dass es bei ihm problemlos klappt, aber bei mir und im Demoshop anscheinend ja nicht. Ich vermute vielleicht ein Versions und/oder PHP-Problem?

    Also ich habe vs. 2.0.7.0 und PHP 8.0

    Tomcraft

    • modified Team
    • Gravatar
    • Beiträge: 46.373
    • Geschlecht:
    Das schauen wir uns noch an.

    Grüße

    Torsten

    noRiddle (revilonetz)

    • Experte
    • Beiträge: 14.006
    • Geschlecht:
    Ich habe den Fehler in Ticket #2497 festgehalten.
    [...]

    Ich habe im Ticket einen Fix gepostet (der wohl auch so kommen dürfte).

    Gruß,
    noRiddle

    Tomcraft

    • modified Team
    • Gravatar
    • Beiträge: 46.373
    • Geschlecht:
    Danke dir, schauen wir uns an. :thumbs:

    Grüße

    Torsten

    ChristianRothe

    • Mitglied
    • Beiträge: 187
    Ich habe ein Problem bei der Einbuchung von Bestellungen festgestellt, die mit PayPal bezahlt werden. Im Formular #checkout_confirmation werden Datenfeld beim Abschicken dieses Formulars nicht checkout_process übermittelt.

    Im Zahlungs-Modul /incudes/modules/payment/paypal.php lautet der Code für diesen Vorgang wie folgt:
    Code: PHP  [Auswählen]
    $paypalscript = '
          paypal.Buttons({
            fundingSource: paypal.FUNDING.PAYPAL,
            style: {
    ...
            },
            createOrder: function(data, actions) {
    ...
            },
            onApprove: function(data, actions) {
              $("#checkout_confirmation").submit();
              $("#checkout_confirmation").html("");
            },
            onError: function (err) {
     ...
            },
            onRender: function() {
    ....
            }
          }).render("#apms_button1");
        '
    ;

    Obiger Code-Schnipsel bedeutet: Das Formular #checkout_confirmation wird "onApprove" übermittelt ("$("#checkout_confirmation").submit.()") und dann sofort aus dem DOM-Tree entfernt ($("#checkout_confirmation").html()).

    Dies führt bei meinem Browser (Chrome in Version 111.0.5563.149) zu Timing-Problemen: Das Formular ist mit seinen Feldern schon weg, bevor der Submit-Vorgang alle Formularfelder für sein POST eingesammelt hat. Dann fehlen eben diese Formularfelder. Die darin enthaltenen Daten kommen also nicht in "checkout_process" an.

    Kann man problemlos beheben, in dem man das Entfernen des Formulars einfach etwas zeitverzögert durchführt. Ich habe mich für 200 Millisekunden Verzögerung entschieden. Et voilà: Alle Daten aus dem Formular checkout_confirmation kommen in checkout_process an.

    Deshalb möchte ich folgende kleine Ergänzung im Code vorschlagen: Der Timeout sorgt für die vorgeschlagene Verzögerung - und alle Timing-Probleme sind erfolgreich umschifft.

    Code: PHP  [Auswählen]
    $paypalscript = '
          paypal.Buttons({
            fundingSource: paypal.FUNDING.PAYPAL,
            style: {
    ...
            },
            createOrder: function(data, actions) {
    ...
            },
            onApprove: function(data, actions) {
              $("#checkout_confirmation").submit();
              setTimeout(function(){
                    $("#checkout_confirmation").html("");
              }, 200);
            },
            onError: function (err) {
     ...
            },
            onRender: function() {
    ....
            }
          }).render("#apms_button1");
        '
    ;

    noRiddle (revilonetz)

    • Experte
    • Beiträge: 14.006
    • Geschlecht:
    Ist das nicht zu heikel von einem willkürlichen Verzögerungszeitwert abzuhängen ?
    Warum nicht via Ajax und Callback, dann ist sicher, daß alle Daten übertragen wurden.

    Gruß,
    noRiddle

    ChristianRothe

    • Mitglied
    • Beiträge: 187
    Ein willkürlicher Verzögerungswert ist besser als null Verzögerung (wie es momentan implementiert ist). Es ist nämlich problematisch, ein Formular abschicken (submit) und dann genau dieses Formular sofort aus dem DOM-Tree quasi sofort zu entfernen. Aber genau so geht die Funktion in der aktuellen Implementierung vor. Mit Ajax und Callback ist hier bei "onApprove" nix zu erreichen. Denn das ist genau die Aktion, die ausgeführt wird, wenn der Käufer den Zahlungsablauf bei PayPal durchlaufen hat und sich das Bezahlfenster schließt.

    noRiddle (revilonetz)

    • Experte
    • Beiträge: 14.006
    • Geschlecht:
    Ich habe ja nicht gesagt, daß dein Vorschlag nicht besser ist als es bis jetzt ist.
    Ich habe mir auch die Implemantation nicht angeschaut und weiß nicht wohin was genau submited wird.
    Jedenfalls ist es keine sichere Methode mit einer Zeitverzögerung aber sicherlich besser als vorher.

    Gruß,
    noRiddle

    *NACHTRAG*
    Übrigens kommt der Code
    Code: Javascript  [Auswählen]
              $("#checkout_confirmation").submit();
              $("#checkout_confirmation").html("");

    in der paypal.php zweimal und in den weiteren Modulen paypalcard.php  und paypalcard.php  jeweils einmal vor.

    ChristianRothe

    • Mitglied
    • Beiträge: 187
    Bei dem Submit handelt es sich um den Submit, den man normalerweise mit dem Drücken des Knopfes "Kaufen" auslöst. Das PayPal-Javascript-Gedöns fängt diesen Klick quasi ab und leitet erst einmal den Zahlungsablauf ein. Ist dieser erfolgreich durchlaufen, dann passiert die "onApprove"-Aktion und das checkout_confirmation-Formular wird tatsächlich abgeschickt (und der checkout_process-Ablauf zum Einbuchen der Bestellung damit angestoßen. Da ist es einfach keine gute Idee, dass Formular quasi sofort nachfolgend zu löschen. Der Browser arbeitet den Submit und das Löschen nicht zwingend nacheinander ab. Die Verarbeitung des Formulars und dessen Löschung erfolgen eher als parallele Prozesse. Deshalb ist es eine bessere Praktik, das Löschen mit einer gewissen Zeitverzögerung auszuführen. 200 oder 300 Millisekunden Verzögerung sind völlig ausreichend.