PayPal 6.0.3 - 6.0.7 - Diverse Fehler

Shopware 5 Plugins
1

Nachdem bei uns das neueste PayPal-Plugin v6.0.7 und auch die älteren Versionen bis v6.0.4 ausschließlich Fehlermeldungen bei allen Zahlungsarten brachte ist es uns gelungen mit dem älteren PayPal-Plugin v6.0.3 immerhin die Zahlungsarten „PayPal“, „PayPal, Später Bezahlen“ und „PayPal Lastschrift“ funktionsfähig zu machen. Die Zahlungsarten „Rechnungskauf“, „Giropay“, „Sofort“ und insbesondere für uns sehr wichtig „Kredit- oder Debitkarte“ funktionieren nach wie vor nicht. Es erfolgt die Fehlermeldung „Es ist ein unbekannter Fehler während des Bezahlvorganges aufgetreten.“.

Natürlich sind bei unseren PayPal-Einstellungen alle Zahlungsarten frei gegeben, aktiviert und ein Klick auf den blauen Button „Verfügbarkeitstest“ bringt immer die Meldung „Die Zahlungsmethode ist freigeschaltet“!

Habt ihr dieses oder ähnliche Probleme mit den neueren PayPal-Plugins?

2

Moin @ahdesign,

kannst du mal das Debug-Loggin für PayPal einschalten?

dazu einfach in der config.php folgenden Eintrag hinzufügen:

'logger' => [
    'level' => \Shopware\Components\Logger::DEBUG,
],

Danach Cache leeren und einmal einen Testkauf durchführen. Das log könntest du mir via PN zukommen lassen… Dann schau ich mal nach.

VG

Dennis Garding

3

Durch die Aktivierung des Buttons „Fehlermeldung ausgeben“ in den PayPal-Einstellungen wird jetzt folgender zusätzliche und etwas detailliertere Fehler ausgegeben:

Fehlermeldung: An error occurred: Required session parameter ‚token‘ (paypalOrderId) is missing [0]

4

Hallo Dennis, konntest du die Logfiles schon analysieren?

5

Mal noch ein ganz anderer Gedankengang, da dies nämlich auch bei der PayPal-Ratenzahlung in der Vergangenheit zu Missverständnissen geführt hat. Da war es nämlich so, dass in das damals neue PayPal-Plugin die PayPal-Ratenzahlung integriert wurde, viele Shops aber auch noch das zuvor eigenständige PayPal-Plugin „PayPal-Ratenzahlung“ parallel installiert hatten. Irgendwann wurde aber der Service für das ausgelaufene und veraltete eigenständige PayPal-Plugin „PayPal-Ratenzahlung“ deaktiviert und dieses Plugin hat dann nicht mehr funktioniert.

Jetzt zur eigentlichen Frage:
Gehört die Zahlungsart „Kredit- oder Debitkarte“ (Name: SwagPaymentPayPalUnifiedAdvancedCreditDebitCard) überhaupt noch parallel zur Zahlungsart „PayPal“ (Name: SwagPaymentPayPalUnified) bzw. zum neuen PayPal-Plugin oder sollte diese Zahlungsart deaktiviert werden, da man ja auch bei der Zahlungsart „PayPal“ auf dem erscheinenden PayPal-Popup-Display unten den Button „Mit Kredit- oder Debitkarte zahlen“ betätigen kann um eben auch noch an dieser Stelle ohne PayPal-Account bzw. PayPal-Login per „Kredit- oder Debitkarte zahlen“ zu bezahlen.

6

Also das Log gibt leider keine Informationen, an denen ich die Herkunft der Fehler bestimmen könnte.

SwagPaymentPayPalUnifiedAdvancedCreditDebitCard ist aktuell und sollte aktiv bleiben, wenn du diese Zahlungsart anbieten willst. Es wird lediglich „unbrandet“ angeboten.

7

Hallo Dennis,
ja das Ticket habe ich erstellt. Inzwischen hat sich etwas mehr Klarheit über den Fehler ergeben.
Wir nutzen aktuell das PayPal Plugin in der der v.6.0.3, da nach dem Update auf v.6.0.7 überhaupt nichts mher funktinierot hat.
mit v.6.0.3. können wir nach Auswahl der Zahloption PayPal, der Kunde wieder ordnungsgemäß zu PayPal weiter geleitet und kann sich dort anmelden.
Was allerdings nach wie vor nicht funktioniert ist die Zahloption PayPalAdvancedCreditDebitCard.
Wenn wir diese Zahlmöglichkeit in Shopware aktivieren und der Kunde beim Checkout diese auswählt und anschleißend auf „Zahlungspflichtig bestellen“ klickt . Erfolgt keine Weiterleitung und das Plugin liefert uns die Fehlermeldung: An error occurred: Required session parameter ‚token‘ (paypalOrderId) is missing [0].

Die Frage die wir uns stelle ist ob diese Zahlungsoption, seitens des Plugins überhaupt DIREKT - aufbar ist. Welche URL muss dabie angesprochen werden?

Den Hinweis „Die Zahlungsart AdvancedCreditDebitCard“ wird nur unbranded angeboten, verstehe ich nicht.

8

Also nicht nur Unbranded… Wenn die SmartPaymentButtons aktiv sind sollte man auch Branded mit Kreditkarte zahlen können. (PayPal Kreditkarten Button)

Unbranded meint, dass es zwar über PayPal läuft, aber nicht angezeigt wird, das PayPal dahinter steckt. Also ohne PopUp etc.

Aber immer noch. Auch bei der Version 6.0.3 sollte beim Auswählen der Zahlungsart PayPal im Check-out der PayPal Button erscheinen und nicht der Standard Button „Zahlungspflichtig Bestellen“ Wenn dem so ist, muss das Theme angepasst werden. In der Version 6.0.3 funktioniert es nur, weil vergessen wurde, Code zu löschen.

Ich denke bei der Zahlungsart AdvancedCreditDebitCard verhält es sich ähnlich. Entweder das Theme oder ein DrittPlugin wird da rein spielen, so dass ein Check-out nicht möglich ist.

9

Wir sind noch auf der 6.0.4 Version, updaten demnächst, allerdings sind uns vor zwei Tagen einige Lücken aufgefallen:

image
image775×252 56.4 KB

Am PayPal Konto ist Geld eingegangen, aber die Bestellungen fehlen uns einfach komplett? In der Datenbank gesucht, aber nicht ein Treffer mit dieser Bestellnummer. Auch im Mail-Log nichts zu finden. Wo sind diese Bestellungen hin?

10

Auch wenn Dir damit nicht geholfen ist: nach 15 Monaten Entwicklungszeit sind also die Paypal Plugins noch immer nicht zu 100% funktionsfähig.

11

Ganz vergessen im stinknormalen Systemlog (plugin_production.log) nachzusehen:

Meldung:

PayPal: (Webhook)Event: PAYMENT.CAPTURE.COMPLETED. Cannot find orderID by transactionID: XXXXXX

Context:

{
  "id": "XXXXXXXXXXXXX-XXXXXXXXXXXXX-XXXXXXXXXXXXX",
  "creationTime": "2023-06-11T12:53:09.707Z",
  "resourceType": "capture",
  "eventType": "PAYMENT.CAPTURE.COMPLETED",
  "summary": "Payment completed for EUR 75.0 EUR",
  "resource": {
    "id": "XXXXXXXXXXXXX",
    "amount": {
      "currency_code": "EUR",
      "value": "75.00"
    },
    "final_capture": true,
    "seller_protection": {
      "status": "NOT_ELIGIBLE"
    },
    "disbursement_mode": "INSTANT",
    "seller_receivable_breakdown": {
      "gross_amount": {
        "currency_code": "EUR",
        "value": "75.00"
      },
      "paypal_fee": {
        "currency_code": "EUR",
        "value": "2.22"
      },
      "net_amount": {
        "currency_code": "EUR",
        "value": "72.78"
      }
    },
    "invoice_id": "204993",
    "status": "COMPLETED",
    "processor_response": {
      "avs_code": "S",
      "cvv_code": "M",
      "response_code": "0000"
    },
    "supplementary_data": {
      "related_ids": {
        "order_id": "XXXXXXXXXXXXX"
      }
    },
    "create_time": "2023-06-11T12:53:05Z",
    "update_time": "2023-06-11T12:53:05Z",
    "links": [
      {
        "href": "https://api.paypal.com/v2/payments/captures/XXXXXXXXXXXXX",
        "rel": "self",
        "method": "GET"
      },
      {
        "href": "https://api.paypal.com/v2/payments/captures/XXXXXXXXXXXXX/refund",
        "rel": "refund",
        "method": "POST"
      },
      {
        "href": "https://api.paypal.com/v2/checkout/orders/XXXXXXXXXXXXX",
        "rel": "up",
        "method": "GET"
      }
    ]
  }
}

Gleichzeitig gibt es zwei weitere Logeinträge in Zusammenhang mit dieser Meldung:

Meldung

PayPal: (Webhhok) SwagPaymentPayPalUnified\WebhookHandlers\PaymentCaptureCompleted::invoke expect OrderAndPaymentStatusResult, got NULL

Context

{
  "type": "PAYMENT.CAPTURE.COMPLETED"
}

Beide Meldungen stehen zur exakt gleichen Zeit zwei Mal im Log drin. Es sind also 4 Einträge zu dieser verlorengegangen Bestellung zu finden.

Hier ist die Bestellung 204993 also geblieben. Wieso konnte die orderID also nicht gefunden werden? Die Zahlung ging durch, die Bestellung wurde anscheinend irgendwie nicht angelegt. Was eigenartig ist, dass entsprechende Einträge für die fehlenden Bestellungen 204990 und 204997 fehlen. Es ist nur der Eintrag für die 204993 vorhanden.

@d.garding irgendeine Idee?

@Steffffi habe schon oft deine Beiträge hier gelesen, wir haben auch lange gewartet mit dem Updaten, aber irgendwie haben beim alten Plugin dann bestimmte Sachen nicht mehr funktioniert, weswegen wir upgraden mussten :sweat_smile:

12

Nein, leider nicht.

Das einzige was ich anbieten kann ist das du das DebugLoggin aktivierst und du mir bei der nächsten nicht vorhandenen Bestellung das log über PM zukommen lässt. Dann kann ich mal reinschauen was passiert.

14

Auf 6.0.7 geupdated und das Debug Logging entsprechend aktiviert. Ich melde mich, falls es wieder passiert.

15

image

Wieder eine dicke Lücke gestern- natürlich kurz BEVOR ich den Debug Modus aktiviert habe. Bei einer Bestellung kam eine Zahlung mal an, mal nicht, mal gab es eine Bestellung, mal ein Abbruch, was für eine Sauerei. Ich weiß, dass SW6 schon raus ist und wir werden auch baldmöglichst migrieren- aber kümmern sich nur noch die unbezahlten Praktikanten und Azubis bei Shopware noch um SW5 oder wie läuft das bei euch? Selbst die SW6-Version gibt einem zu Denken, wenn man sich die Rezensionen ansieht:

Woran liegt’s? Ich verfolge schon seit einem Jahr das Debakel hier um das PayPal Plugin, SW5 oder 6 mal dahingestellt.

EDIT:

@d.garding
Alles klar, wir haben nun alle Möglichkeiten, die uns eingefallen sind, durchgetest und folgendes festgestellt:

Wenn jemand bspw. mit Giropay (nachdem die Zahlart ausgewählt und auf „Zahlungspflichtig bestellen“ geklickt wurde) zahlen möchte, und diesen Vorgang dann entweder durch Schließen des Browserfensters (egal, ob eingeloggt wurde im Bankkonto oder nicht) oder durch den „Zurück zum Händler“ Button abbricht, dann wird die nächste Bestellnummer verwendet. Wenn die Giropay-Bestellung also die 2007 gehabt HÄTTE, aber abgebrochen wurde, müsste die nächste Bestellung eigentlich die 2007 erhalten, erhält aber die 2008. Wird mehrfach abgebrochen, dann ist es dementsprechend bspw. die 2009 oder 2010.

Die Log-Datei habe ich. Wohin soll ich diese senden, damit dieser Fehler behoben werden kann? Dies muss übrigens auch bei Kreditkartenabbrüchen ähnlich sein, denn obwohl die Zahlung durchging (in obigen Beispielen wurde ja nicht gezahlt), wurde keine Order angelegt.

1 „Gefällt mir“
16

Moin, also das Log-File kannst du mir wie oben geschrieben via PM (Private Message) zukommen lassen. Dann kann ich da mal hineinschauen.

Ich kann dir aber gleich sagen, dass die Lücken in den Bestellnummern normal sind. Leider bekommen wir nicht immer mit wenn ein Kunde eine Bestellung abbricht. Somit wird die reservierte Bestellnummer übersprungen.

Normal ist es NICHT das es bei PayPal bezahlte Käufe gibt die nicht in Shopware als Bestellung landen. Das ist das eigentliche Problem, dem wir auf den Grund gehen müssen. Wenn deine Log-Datei einen solchen Fall enthält, wäre es sicher hilfreich. Ansonsten bedauerlicherweise nicht.

VG

Dennis Garding

17

Hi Dennis,

PM ist raus, schade, dass sich da allerdings nichts machen lässt. Wir müssen allerdings irgendwie mitbekommen, warum / wo diese Bestellnummern verbleiben. Wenn es nämlich an etwas anderem läge, könnten wir nicht schnell feststellen, ob es einfach nur eine übersprungene Bestellung wegen Zahlungsartabbruch war oder ob etwas (siehe Kreditkartenbeispiel) liegt.
Es gab eine Zeit lang die Lösung, dass für jeden Versuch in Shopware eine Bestellung angelegt wird- das wurde schön gelöst mittlerweile, aber wäre es vielleicht möglich, das als Option wieder zu implentieren? Unser Kunde hätte lieber eine lückenlose, fortlaufende Bestellliste in Shopware mit vielen Abbrüchen, als eine unvollständige Liste.

Sobald der Fall mit der verlorengegangenen, aber bezahlter Bestellung erneut auftritt, sende ich dir gerne wieder ein Log. Vielen Dank.

EDIT: Blöd gefragt: Das ging doch aber vorher oder irre ich mich? Es gab immer Abbrüche, die richtig erfasst wurden und es gab trotzdem keine Lücken. Oder kommt da erst durch die PayPal Checkout Geschichte durch die vielen, verschiedenen Zahlungsarten zustande?

18

Also früher hattet ihr die Auswahl, die Bestellnummer an PayPal zu übertragen, dabei konnten Lücken entstehen, oder eben nicht übertragen, dann wurde die Bestellnummer erst bei Erstellung der Shopware-Bestellung erstellt.

Um die Komplexität aus dem Plugin zu nehmen, aufgrund der ganzen Zahlungsarten haben wir uns dazu entschieden, dieses Feature auszubauen. D.h. die Bestellnummer wird nun immer übertragen.

19

Hallo @DenizGelion !

Wir geben uns alle Mühe, jeden Fehler, egal wo er gemeldet wird, anzugehen und auszumerzen. Vereinzelt kann es natürlich immer zu Problemen kommen, aber es gibt kein Software-Projekt, dass 100% reibungslos läuft.

Ich gehe davon aus Dir ist klar, dass hier nicht nur „unbezahlte Praktikanten und Azubis“ arbeiten. Mit solchen passiv-aggressiven Sätzen setzt Du uns Entwickler (und unsere Azubis) herunter.
Wenn man mal die Downloadzahlen und die Handvoll Leute, die sich hier beschweren gegenüberstellt, gibt es nur bei einem minimalem Prozentsatz von Shops Probleme, die zudem oft hausgemacht sind.

Daher würde ich dich gerne bitten, deinen Ton in Zukunft anzupassen und zu bedenken, dass auf beiden Seiten des Bildschirms Menschen sitzen.
Schreibe Deine Beiträge unter einer Annahme der guten Absicht und benutze das Forum nicht als Ort um „dich auszukotzen“.
Das hilft uns, Dir zu helfen.

Viele Grüße aus Schöppingen
Michael Telgmann

3 „Gefällt mir“
20

Hi Michael,

natürlich ist mir das klar, das war mehr sarkastisch, als ernst gemeint. Es ist auch sicher reizend für dich auf diese Kleinigkeit zu antworten, um auch deinen Frust mal loszuwerden (so eine Antwort habe ich bei anderen hier noch nicht gesehen, obwohl deren Ton deutlich „rauer“ war).

Wenn ich allerdings die Requests ansehe, die wir vor Urzeiten gemeldet haben, wovon keins bearbeitet wurde weil „nicht genügend allgemeines Interesse“ vorliegt bei Premium Plugins, die ihr weiterhin teuer verkauft, kannst du sicherlich auch unseren Unmut verstehen.
Die PayPal-Plugin Diskussion geht ja auch schon seit geraumer Zeit umher und wir haben aktiv Angst jedes mal upzudaten, dass da jedes Mal etwas schiefgeht. Das betrifft ja auch nicht nur einen Kunden, sondern alle.

Eine Firma möchte Geld verdienen, wer hätte es gedacht- ist auch verständlich und so soll es auch sein. Allerdings ist es auch offensichtlich, dass mehr Ressourcen in SW6 gesteckt werden, aber wenn 2/5 Sterne bei beiden eurer PayPal Plugins bei über 40 Bewertungen dabei sind und das Flaggschiff an Zahlungsschnittstelle in solch einer bedauernswerten Position feststeckt, weil (offensichtlich) nicht genügend Tests durchgeführt werden vor Release- was soll man dazu noch sagen? Ich schiebe es ja nicht auf den einzelnen Entwickler, diese können nie etwas dafür. Die Software wirkt durch solch eine Kleinigkeit direkt unprofessionell, wenn nicht einmal laufend Bestellnummern vergeben werden können, das kannst du sicherlich auch nachvollziehen?

Als Langzeitangesteller bei Shopware tut es sicherlich weh, solche Dinge lesen zu müssen und es ist sicherlich sowohl frustrierend, als auch ärgerlich, da verstehe ich auch, wenn so etwas persönlich genommen wird. Entschuldige daher die Wortwahl, es beruht schließlich alles auf Gegenseitigkeit.

1 „Gefällt mir“
21

Hallo Herr Telgmann!

Naja, die Paypal Misere geht jetzt schon seit 15 Monaten so, richtig?

Ich trau’ mich gar nicht mehr, irgend ein Update vorzunehmen, da dann wieder was anderes nicht mehr geht, daher ist auch Paypal Express aus. Also, ich denke, man kann den Frust schon ein wenig verstehen. Und das betrifft ja nicht nur Paypal, sondern auch zb. PHP und 5.7. Und kommt ein patch, geht etwas anderes nicht mehr. Und ich muss dazu sagen, dass meine Software Kenntnis soweit geht dass ich zumindest eine CSS Ableitung hinbekomme. Ich möchte aber gar nicht wissen wie viele Nutzer Probleme haben von denen sie gar nichts wissen.

Mir ist vollends bewusst dass Shopware 5 am Auslaufen ist, kein Thema, aber dass das Paypal Plugin nachwievor nicht läuft (verlässlich, ohne hacks und Abstriche) ist schwach.

1 „Gefällt mir“