Neu EPS / Sofort Zahlungen mit PayPal Checkout

[itratosTeam]

Hallo @all,

wir haben bei einem Kunden festgestellt das Bestellungen die aus AT mit EPS, oder Bestellungen aus DE die mit Sofort über den PayPal Checkout abgewickelt werden, nicht abgeschlossen werden

ACHTUNG: Die Zahlung erfolgte aber der Shopbetreiber kann sie nicht finden.

Wir erkundigen uns jetzt bei PP wohin die Zahlung ging.

 

[FPrüfer]

Wenn Bestellungen mit Third-Party-Payments bezahlt aber letztendlich nicht korrekt abgeschlossen werden, kann es passieren das das Geld beim Kunden abgebucht beim Händler aber nicht gutgeschrieben wird. Solche Transaktionen werden von PayPal automatisch refunded. Dieser Vorgang kann jedoch leider bis zu einigen Tagen dauern.

 

[itratosTeam]

Hallo FPrüfer,

es geht hier nicht nur um eine Zahlungsart es geht bereits um 2. EPS wurde von einer Kundin genutzt und Sofort testete der Shopbetreiber heute selbst - gleiche Ergebnis.

Die zusätzlichen Zahlungsarten, also auf alle Fälle die beiden gehen gar nicht bzw. buchen nur das Geld beim Kunden ab und der Shopbetreiber weiß gar nicht das es diesen Fehler gibt.

Diese Kundin sprach gleich von Betrugsversuch und das kann für den Shopbetreiber böse Folgen haben zumindest schlechte Kundenbewertungen.

Kleine Anregung, man sollte mal alle JTL Kunden mit PayPal Checkout informieren!

Ein kurzer Nachtrag zu dem Post.
Die Zahlung der Kundin aus AT, die via EPS zahlte, wurde zwischenzeitlich auf ihrem eigenen Konto wieder gutgeschrieben - es handelt sich somit nicht um Betrug.
Der Support von Paypal kann es sich nicht erklären, es wurde ein Ticket bei der Technik von Paypal geöffnet

 

[ChrisTS]

Betrifft ebenso giropay und iDEAL. Ich habe nun vorerst alle zusätzlich Zahlungsarten über PayPal aus. Die Kunden schließen nach eigenen Aussagen die Bestellung ab, der Warenkorb ist aber dennoch voll. Kein Fehler, keine Meldung aber auch keine AB und keine Bestellung im Shop 😔

Das PayPal Plugin sowie einige andere Zahlungsplugins sind bei JTL ja schon längst ein Problem und extremst umsatzschädlich. Ein Geheimnis ist das bei den SPs und jtl nicht, aber eine ordentliche Lösung gibt es noch immer nicht.

PayPal empfielt mir heute folgendes 🤔😂

Ich habe mir Ihr Anliegen angesehen und helfe Ihnen gerne weiter.

Wenn Sie einen Webshopanbieter nutzen, bitte ich Sie sich zunächst sich an Ihren Webshopanbieter zu wenden, damit die Integration überprüft werden kann. Sollte bei Ihrem Webshopanbieter alles vollständig integriert sein oder Sie sind Selbstintegrierer, können Sie über folgende Links alle Informationen zur korrekten Integration finden.

Giropay: https://developer.paypal.com/docs/checkout/apm/giropay/

Dort Punkt 5. Capture the transaction

SOFORT: https://developer.paypal.com/docs/checkout/apm/sofort/

Dort Punkt 5. Capture the transaction

P.s @css-umsetzung da geht es mehreren so

 

[itratosTeam]

Hallo Truckstyler,

ich hatte diesbezüglich auch mit JTL Kontakt und habe empfohlen alle Kunden zu informieren die einen jtl Shop nutzen und das Paypal Checkout Plugin.
Gerade jetzt wo viele einkaufen sollte man es verhindern das Bestellungen verloren gehen oder ein Shop schlechte Bewertungen bekommt - weil Kunden gleich Betrug vermuten.

Leider hielt man das Problem nicht für so kritischen, die Kunden die zahlten erhalten ja das Geld nach ein paar Tagen zurück - wurde mir geantwortet.

 

[ChrisTS]

Ja, du bist ja auch schon lang genug dabei. JTL meldet bekannte Fehler nie an alle Kunden. Und die Aussagen sind immer die gleichen.
Da kann ich über die Jahre einiges erzählen. Aber gehört so hier nicht her.

Wobei man bei den Umsatzverlusten so langsam doch mal über eine Schadensersatzklage nachdenken sollte.

Fakt ist, dass JTL noch immer kein funktionierendes PayPal Plugin hat. Aktuell viel schlimmer finde ich sogar noch, dass wenn die Server von PayPal hängen (zb Black Friday) das Ladesymbol im Bestellprozess dauerhaft dreht und der Kunde hier überhaupt nicht mehr bestellen kann. Also auch nicht mit einer anderen Zahlungsart.

 

[STH]

Gleiches Problem auch in unseren Shop (5.2.3) mit PayPal Checkout Plugin 1.3.0 und Zahlung per EPS. Der Bestellabschluss kommt nicht zustande, laut Kunde war er in einer Endlosschleife und der Betrag wurde nachweislich abgebucht von seinem Konto.
Laut Paypal-Support wird das Geld in solchen Fällen spätestens nach 5-7 Tagen zurückgebucht, der Kunde soll selbstständig keine Rückbuchung durch die Bank veranlassen.
Das Geld geht an eine deutsche IBAN in München (Banking Circle - German Branch). Hier verlieren Kunden das Vertrauen in uns, ohne, dass wir etwas verbessern könnten.

Das ist gerade im Weihnachtsgeschäft ein unhaltbarer Zustand - wann rechnet JTL hier mit einem Fix?
Imho trat der Fehler erst seit dem neuesten Pluginupdate auf.
@FPrüfer Bitte dringend ein Ticket dazu öffnen!

 

[ChrisTS]

Ja und das Beste ist, dass der Kunde nun PayPal noch hinterher laufen darf.
Habe daher alles zusätzlichen PP Zahlungsarten ausgemacht.
Ebenso hängt PayPal und die komplette Zahlungsseite im Shop an Tagen an denen die PayPal Server ausgelastet sind.

Hier noch die Antwort von PayPal in Bezug auf die Rückzahlung an den Kunden:

Ich bitte um Entschuldigung für diese Situation und weiß, wie ärgerlich dies ist, dennoch wird dies wie ein Zahlungsabbruch behandelt, da Sie als Händler den Betrag einziehen hätten müssen.

Zwecks der Rücküberweisung an den Kunden kann es mit unter zur Verzögerung kommen, da die Bank das Geld nicht zuordnen kann, hier kann Ihr Kunde nur Ruhe und Geduld bewahren.

 

[jherchen]

Dieses Problem tritt bei mir scheinbar in Verbindung mit Mollie und dort auch IDEAL auf.
Gibt es hier zwischenzeitlich irgendwo eine Rückmeldung?

 

[ChrisTS]

Dieses Problem tritt bei mir scheinbar in Verbindung mit Mollie und dort auch IDEAL auf.
Gibt es hier zwischenzeitlich irgendwo eine Rückmeldung?

Vielleicht ja doch ein Shopproblem, dass am Ende alle Zahlungsarten betrifft. Habe gerade auch eine Kundin mit Klarna PayNow über Mollie die bezahlt hat aber es keine Bestellung dazu gibt.
Probleme mit Kunden die nicht bestellen können über Mollie häufen sich seit Wochen.

@Jtl äußert sich hierzu in Bezug auf PayPal ja nicht wirklich und mit dem Support von @webstollen versuche ich auch schon seit Wochen klar zu machen, dass die vielen Fehler in den Logs nicht normal sind und Ihr Plugin ein Problem hat.
Scheinbar soll alles laufen und ich bin der Einzige der nicht klar kommt, obwohl der Fehler von Mollie auch schon erkannt wurde.

Zitat:
Derzeit ist uns kein Fehler im Plugin bekannt, es wird auch dieses Jahr kein Plugin Update mehr geben (Feature Freeze).

Ich bin mir nicht sicher, wie genau wir dir hier noch helfen können. Das Problem kann durchaus auch andere Ursachen haben. Unser Support beschränkt sich leider auf das Mollie Plugin und beinhaltet nicht die Prüfung des Großen und Ganzen (z.B. des JTL-Shops und dessen Plugins und Konfiguration)

@webstollen jetzt gibt es ja noch andere Kunden und Ihr könnt doch mal genauer schauen?

 

[itratosTeam]

Hallo Truckstyler,

da wir nicht nur Kunden von JTL haben kriegen wir hier etwas mehr mit, deshalb vermute ich das es ein generelles Problem bei den zusätzlichen Zahlungsarten ist.
Es betrifft also nicht nur den jtl Shop, dies kann ich ausschließen.

Bei den Kunden bzw. den Plugins wo es möglich ist, schauen wir uns gerade den Code bzw. die API an um mögliche Fehlerquellen zu finden.
Aber das Problem ist bei vielen das gleiche, der Kunde macht eine Bestellung wählt EPS, Sofort oder IDEAL, er zahlt, Geld wird abgebucht - aber ein Response kommt nicht beim Shop an.

Das Resultat = keine Bestellung im Shop / Wawi.

 

[ChrisTS]

Welche Shopsysteme betrifft es denn noch? Ist doch sehr unwahrscheinlich, dass alle Zahlungsanbieter ein Problem mit dem Response haben.
Zudem sollte JTLK das ja unbedingt abfangen so dass zumindest eine Bestellung im Shop landet oder der Kunde eine Meldung bekommt

 

[itratosTeam]

Hallo Truckstyler,

bisher sind es

Shopware 6.5 mit Paypal Checkout
OXID6 mit Mollie

wo wir auch ähnliches festgestellt haben

 

[R-W]

Wir haben auch katastrophale Probleme mit JTL SHOP und PAYPAL CHECKOUT PLUGIN JETZT,
und diese häufen sich immer mehr. Erst pro Monat 1 Bestellung die in JTL SHOP 5.2.3. mit JTL PLUGIN - PayPal Checkout hängen bleibt, am 6.12.2023 waren es Mittags 3 Bestellungen die nicht in die JTL WAWI übertragen werden.
WIR KOMMEN NICHT AN DIE BESTELLUNG RAN - ABER BLICK INS PAYPAL KONTO SAGT: BEZAHLT!
Maßnahme: 07.12.2023 Checkout auf neueste Version UPDATE heute. NIX. 3 Bestellungen stehen fest sind auch nicht als *offene Bestellung* im Plugin Paypal Checkout zu finden, also nichts zu manuellen freigeben. Super-Schrott sowas. (Sorry, aber genervt sein muss man).
- Merkwürdig ist: Wir erhalten Bestellungen vorher und nachher in die WAWI, auch mit allen möglichen Zahlarten, auch mit PP Checkout ...aber einige hängen, aber nur wenn Checkout genutzt wurde, und nun..?

 

[Enrico W.]

Wenn ich das richtig sehe, dann hast du vor 47 Minuten ein Ticket eröffnet? Das wurde vor 13 Minuten beantwortet. Demnach hat Paypal keine Zahlungsinformationen an den Shop gesendet, so dass die Bestellungen nicht freigegeben wurden.

 

[R-W]

DANKE! SUPPORT sendete jetzt ERSTE HILFE INFO. Finde es aber wichtig es hier zu schreiben, damit andere auch schnell an verlorene Bestellungen kommen:

KOPIE: JTL SUPPORT=
Das Problem hier ist das seitens Paypal keine Zahlungsinformationen an den Shop gesendet wurden, deshalb kann der Shop die Bestellung nicht freigeben und steht deshalb noch auf PENDING:

Hier müsste in der Shop Datenbank dann das P zu N geändert werden. Wenn die Zahlungen wirklich gutgeschrieben wurden.

 

[R-W]

Leider kann man also keinem WAWI Abgleich vom SHOP in die WAWI mehr trauen. Leider muss man also nun immer alle JTL WAWI Bestellungen noch mal mit allen SHOP Bestellungen im SHOP manuell und per Auge abgleichen und selbst suchen ob was fehlt... (Internet Zeitalter 2023) .... PayPal hurra - Bitte JTL macht da mal Druck ...

 

[FPrüfer]

In der aktuellen Version gibt es sehr wohl die Möglichkeit solche Bestellungen einzusehen. In den Einstellungen vom Plugin unter "offene Bestellungen" werden alle Bestellungen aufgelistet, die mit PayPal-Checkout bezahlt wurden und noch auf "Pending" stehen. Die Anzeige dort geschieht etwas zeitversetzt (3h), da in den meisten Fällen der korrekte Status von PayPal per Webhook übermittelt wird. Man kann dort auch jederzeit entscheiden die Bestellung in die Wawi zu übernehmen - auch wenn diese bei PayPal (noch) nicht bezahlt wurde.
@R-W Wenn bei dir keine Bestellungen gelistet wurden ist wahrscheinlich ein Abbruch oder Fehler bei der Bestellung / Zahlung schuld, so dass die Bestellung nicht automatisch einer Zahlung zugeordnet werden konnte oder es liegt daran, dass du erst gestern ein Plugin-Update auf die neueste Version gemacht hast...

 

[ChrisTS]

@FPrüfer das gehört nun aber nicht hier her. Viel wichtiger wäre, was nun aus dem eigentlichen Problem wird, welches euch ja offensichtlich längst bekannt ist 🤬

 

[R-W]

In der aktuellen Version gibt es sehr wohl die Möglichkeit solche Bestellungen einzusehen. In den Einstellungen vom Plugin unter "offene Bestellungen" werden alle Bestellungen aufgelistet, die mit PayPal-Checkout bezahlt wurden und noch auf "Pending" stehen. Die Anzeige dort geschieht etwas zeitversetzt (3h), da in den meisten Fällen der korrekte Status von PayPal per Webhook übermittelt wird. Man kann dort auch jederzeit entscheiden die Bestellung in die Wawi zu übernehmen - auch wenn diese bei PayPal (noch) nicht bezahlt wurde.
@R-W Wenn bei dir keine Bestellungen gelistet wurden ist wahrscheinlich ein Abbruch oder Fehler bei der Bestellung / Zahlung schuld, so dass die Bestellung nicht automatisch einer Zahlung zugeordnet werden konnte oder es liegt daran, dass du erst gestern ein Plugin-Update auf die neueste Version gemacht hast...

Naja. Die Zahlungen sind NICHT abgebrochen, das Geld ist definitiv im PayPal Konto ja angekommen. Wir haben den Reiter "offene Bestellungen" im Checkout PlugIn schon lange drin, und haben den auch schon angewendet, trotzdem war es so, das jetzt zwischen vielen Checkout Bestellungen nun 3 Stück Bestellungen gab, die im Checkout Plugin auch nach TAGEN nicht zu finden sind und somit nicht freizugeben waren. Einziger Weg war der korregierende Datenbankzugriff aktuell.