Zwei Geschäftskunden haben über PayPal Checkout jeweils mit der Zahlungsart Sofort bzw. EPS bestellt, aber im Shop sind diese mit Bestellnr. 0 nicht abgeschlossen, nicht bezahlt. Nach Rücksprache haben beide Kunden einen Kontoauszug gesendet auf dem der Empfänger der Händler ist aber IBAN und BIC sind gefaket.
Es wurde bei beiden Kunden auf dasselbe Fremdkonto IBAN DE68 2022 0800 0092 8250 36, BIC SXPYDEHHXXX abgebucht. Diese Bank war bis 2021 SAXO PAYMENTS Hamburg (bereits erloschen) und läuft jetzt 2022 unter BANKING CIRCLE S.A. München, eine Digitale Bank die es Betrügern leicht macht, mit gefälschten/gestohlenen Unterlagen Konton zu eröffnen.
Ich habe OXID, PayPal, Klarna und Banking Circle S.A. darüber informiert. Laut PayPal (Abt. Betrugsverdacht) geht das bei Kunden mit PayPal-Konto nicht so, sondern es könnte nur bei sog. Gästen ohne PayPal-Konto vorkommen. Die anderen Stellen haben noch keine Lösung bzw. nicht zurückgeantwortet.
Laut meiner Bank ist der Fall klar Betrug: Empfängername und IBAN passen nicht zusammen. Seit Prüfungspflicht der Banken erst ab 1000 Euro gilt, stehen die Türen für solche Betrugsmaschen offen.
Weiter Maßnahmen: Rückbuchungsversuch, Strafanzeige geg. Unbekannt und im Shop natürlich alle Zahlungsmethoden mit Lastschrift deaktiviert.
Über Google Suche mit “bankkonto DE68 2022 0800 0092 8250 36” gibt es noch etwas mehr Info dazu.
Wir haben das gleiche Problem. Es läuft über die Paypal-Schnittstelle und die Kunden zeigen diese gefakten Überweisungen vor. Wir hatten jedoch selbst einen Kunden mit iPhone, wo Malware ja sehr unwahrscheinlich ist. Auch wir konnten den genauen Ablauf noch nicht rekonstruieren.
Wir haben mal Klarna deaktiviert und schauen, was passiert.
Es ist natürlich schon oberpeinlich, dass sich diese Zahlungsdienstleister damit überhaupt nicht auseinander setzen und nicht reagieren. Das passt natürlich zu einem deutschen “IT-Unternehmen”
Ich habe nach einer von KLARNA unbeantworteten schriftlichen Meldung zu diesem Problem und mehreren Telefongesprächen mit den Klarna-Hotlines keine Unterstützung erhalten, sondern PayPal soll sich darum kümmern und umgekehrt dasselbe.
Letztendlich sollte und habe ich eine Email an [email protected] gesendet.
Bitte sendet auch eine Email an diese Adresse, damit es mehr Gewicht bekommt.
Insgesamt ließt sich das Thema wie eine Man-in-the-Middle-Attack, weil wenn man unter Wikipedia nachließt wie Sofort Überweisungen funktionieren, dann muss anscheinend der Kunde (Besteller) eine TAN eingeben um die Zahlung zu autorisieren.
Eine Idee wäre man müsste alle JavaScript Requests welche über PayPal Checkout ablaufen mitloggen um ein Muster zu erkennen, an welcher Stelle der API Version 2 manipuliert wird.
Zusätzlich könnte man unter Main - OXID eShop bugtrack noch ein Eintrag vornehmen, falls noch nicht geschehen.
I3C, mach doch bitte mal einen Live-Test mit z.B. 1 Euro und zeichne mit Screencam auf was da abläuft, wobei auch die URL-Veränderung erfasst wird. Nach der TAN-Eingabe und “Weiter” wird die Überweisung ausgelöst und genau dann passiert das Problem: Eine Nachricht wird angezeigt, die blitzschnell wieder verschwindet, sodaß man sie nicht lesen kann, dann rödelt eine Ladeanzeige auf weißem Hintergrund ein paar Sekunden, bricht ab und die Startseite des Shops wird angezeigt. Die Überweisung ist sofort vom Kundenkonto abgebucht, im Shop gibt es aber keine Bestellung, keine Zahlung.
Ich hoffe stark, dass die Zahlungsarten Sofort und EPS im LIVE Betrieb deaktiviert sind.
Und mit einen Original Konto dies zu testen ist Wahnsinn, dort muss man extra Konto eröffnen und was mit Rücksprache der jeweiligen Bank passieren sollte.
Da über eine TAN Eingabe nach PSD-2 Richtlinie im ungünstigsten Fall alle Kontobewegungen ausgelesen werden und dies dauerhaft.
Dort gibt es Unterscheidung nach einmalig zweckgebunden und einmal Pauschal für unbestimmte Zeit ohne neue Erlaubnis einzuholen.
Dort sitzt im ungünstigen Fall jemand welche sich zwischen Shop und Zahlungsdienst schaltet. Alle Eingaben vom Besteller mitgelesen werden und manipuliert werden.
Mich würde nicht wundern, wenn dort eine Smarty Version 2 Schwachstelle ausgenutzt wird oder ähnliches. Das neue PayPal Checkout Modul hat sich leider auch nicht so robust in der Zuverlässigkeit gezeigt.
Daher wäre dies die Aufgabe der Produktentwicklung ein Fall für @Mario_Lorenz oder den OXID Support zu prüfen ob ein Sicherheitsrisiko vom OXID Framework und/oder PayPal Checkout Modul ausgeht.
Drücke die Daumen, dass Deine E-Mail an [email protected] zu einer Lösung führt.
Mit meinem Kommentar wollte ich nur darauf hinweisen, wo man aus meiner Sicht ansetzen könnte.
Da die PayPal Checkout API 2.0 sehr JavaScript lastig ist bei der Kommunikation, wäre dies auf Modulebene die Stelle wo ich aus Entwicklersicht zuerst gucken würde. Wie genau der Ablauf der Requests ist weiß mit Sicherheit @Mario_Lorenz mit am Besten.
Nach meinem letzten Kontakt mit Sofort GmbH wurde das Problem verstanden, kurz erklärt wie der Workflow sein soll und das ernste Problem endlich an deren IT-Experten weitergeleitet.
“Sofort” und “EPS” werden als “Alternative payment methods” mit PayPal Checkout angeboten. Nach dem Klick auf “Jetzt kaufen” wird per PHP über die PayPal-API die Zahlung angestoßen. Dabei wird von der PayPal-API eine Redirect-URL zu “Sofort” bereitgestellt auf die OXID dann weiterleitet und von dort auch wieder zurück kommt.
Also an der Stelle spielt JS keine Rolle. Hilft das weiter? Ich denke auf einem komprimitierten Rechner ist alles möglich. Der Datenverkehr, der an Sofort.com gehen soll, muss ja nur irgendwie umgleitet werden. Da bin ich technisch dann aber raus …
Der Tech-Support von Sofort GmbH hat meine Testüberweisung (mit Screnshots
anhand der Überweisungs-ID, die unter dem Klarna-Logo im Überweisungsablauf auf deren Webseite steht), sofort am Bildschirm gefunden und sie ist mit grün (ok) weitergeitet worden und zwar an “PPRO Payment Services S.A.”.
ZITAT aus Sofort GmbH Email-Bestätigung an mich: Die von dir genannte IBAN gehört zu “PPRO Payment Services S.A.” Dies ist der Zahlungsdienstleister von PayPal Checkout. Diesbezüglich bitte sich mit denen in Verbindung zu setzen.
Seit 2.Sept.2022 kommt von PayPal keine Aktivität zur Lösung des Problems, sondern nur die interne Weiterleitung oder schreiben Sie an den Tech-Support oder alle anderen Möglichkeiten wie Z.B. den Verweis zu externen Stellen…
Das ist doch wirklich eine besch. Kunden- und Händler-Experience mit den neuen Paypal Checkout alternativen Zahlungsarten, bei denen das Geld verschwindet, das mit Echtzeitüberweisung auf das Händlerkonto beworben wird.
Mario,
meinen Live-Test hat die Sofort GmbH anhand der Logdaten ja mit ok an den PayPal-Partner PPRO Payment Services S.A. weitergeleitet und danach ist wohl was schief gelaufen - nächster Server kompromittiert? PayPal müßte das doch schon längst untersucht haben und will evtl. nach außen nicht kommunizieren, da grass formuliert der große Checkout-Wurf in ein Black Hole sein Image schädigt.
PS: Noch ein anderer Witz in Echtzeit: Gastkunden mit Kreditkartenzahlung ohne PayPal-Konto werden laut PP wegen zu hohem Risiko generell in Echtzeit abgelehnt.
Die verschwundenen Zahlungen der betroffenen Kunden sind stillschweigend auf deren Bankkonto (von dem sie überwiesen haben) zurückgebucht worden von: “PayPal Pte Ltd 5, Temasek Boulevard, 09-01 Suntec Singapore SH 038985” mit derselben IBAN DE68 2022 0800 0092 8250 36 und BIC SXPYDEHHXXX.
PayPal hat mir keine Lösung zum Problem gegeben aber gestern eine Email gesendet:
“Wie war PayPal? Kurze Fragen, 1–3 Minuten” - besser als “0” (Null) kann man dazu nicht geben.
Ich habe das gleiche Problem bereits vor einer Woche versucht an den Paypal Support zu melden.
Interessiert dort aber keinen und der englischsprachige Techniksupport kennt wohl nichtmal das eigene Produkt der Zahlung ohne Paypal Account und möchte die Kundendaten und Transaktionsdaten haben.
Den Sofortüberweisungs Dienst bzw. die Zahlungsmöglichkeit hatten wir letzte Woche dann bereits sofort deaktiviert.
Heute ist uns dann aufgefallen, dass auch Giropay betroffen ist.
Da geht die Zahlung an DE92202208000000019175
Hatte das auch bereits jemand? Wurde noch bei anderen Zahlungen zurückgebucht?
Danke
Guten Tag, folgende Info haben wir von PayPal erhalten:
Also, wir haben anchgeschaut und es handelt sich um ein legitimes Konto.
Arbeitshypothese ist, beim Checkout via APM ist was schiefgelaufen (zum Beispiel kein Capture durch den Händler)
Wenn so etwas passiert, erstatten wir das bereits aus dem Bankkonto des Kunden geflossene Geld. Es kann allerdings zwei Wochen dauern, bis das Geld beim Kunden wieder gutgeschrieben ist. Ärgerlich, aber passiert.
soweit ich den Prozessablauf recherchieren konnte, war der Zahlungsablauf bis Punkt 4 im Diagramm bei SOFORT noch ok (das hat mir SOFORT rückbestätigt). Das Problem liegt dann bei PPRO Payment Services S.A. wo die Überweisung eingeht aber nicht dem Händlerkonto zugewiesen wird. PayPal will oder kann den Fehler wohl nicht finden?
Hallo! Ich bin neu auf diesen Thread gestoßen. Ich habe das selbe Problem. Bei mir ist das wie folgt. Auf meinem Wordpress sitzt ein Formular von WPMUDEV (Forminator). Der Checkout funktioniert via PayPal Checkouts. Heute hatte ich meine ersten Bestellungen und einige Kunden erhielten keine Bestätigungs-Email. Das Geld vom Konto weg und auf das Konto mit der IBAN mit der 36 hinten. Keine Bestellung habe ich erhalten und Geld nicht im PayPal-Konto. Bisher konnte ich es nur bei Sofort feststellen, aber auch andere Zahlungsmethoden sind möglicherweise betroffen.
Wie schaffe ich es, dass diese Lücke behoben wird und, dass ich das Geld bekomme/der Kunde das Geld bekommt?
Moin handelt es sich beim Checkout um WooCommerce? Oder gibt es für WordPress separates Plugin was PayPal Checkout anbindet?
Naja, dies wird nur über PayPal Support laufen können, indem die Transaktions-ID denen nennst welche über Dich stattgefunden hat und Dich fragst warum Zahlung noch nicht bei Dir gelandet ist.
Manchmal kann es auch sein, dass die Zahlung nur vorgemerkt. Dies heißt der Besteller sieht, dass etwas vom Konto abgebucht wird demnächst. Die Zahlung aber dann noch nicht stattgefunden.
Merkwürdig an der ganzen Geschichte hier ist, dass das Geld anscheinend auf ein “offizielles” PayPal Konto nach Singapore überwiesen wird… Dies erinnert irgendwie an Wirecard, dass irgendwelche Luftbuchungen.
Wenn dies so häufig auftritt und systemübergreifend, dann wäre dies ein Fall für die Finanzaufsichtsbehörde BaFin bezüglich Thematik Geldwäsche.
Moin! Es handelt sich um keines von beiden. Das Plugin was ich benutze nutzt nur die Schnittstelle von PayPal checkout. Das Formular gibt den Wert der bezahlt werden soll an die Schnittstelle weiter und PayPal erledigt den Rest. Das komische ist, dass die Bestellung bei mir nicht angezeigt wurde. Die Bestellung ist also laut Formular noch nicht abgeschlossen. Fehlt das vielleicht an einer Stelle einfach die Verbindung, dass PayPal nicht weiß, dass die Zahlung abgeschlossen ist?
Ich habe leider in den API calls noch nicht geschaut, ob da nicht die Anfrage zu der Zeit war. Wo könnte ich eine Transaktionsid finden? In der Überweisung vom Kunden?
Kenne Deine Anleitung nicht welcher Du gefolgt bist.
Aber der “normale” Ablauf wäre wie im Schaubild dargestellt, dass bei der Kommunikation ab Schritt 6 von 7 PayPal wieder zurückmeldet z.B. “Zahlung erfolgreich”.
In diesem Request wird meist eine Transaktions-ID mitgegeben worüber sich eine Zahlung identifizieren lässt.
Ja, wahrscheinlich.
Um den Ablauf zu Testen gibt es extra den Sandbox Modus von PayPal. Das wäre das Mindeste was man vorher einmal durchspielen sollte bevor man einen eigenen Bezahlbutton verwendet.
Dies dürfte kompliziert werden, weil Deine JavaScript Integration den Wert wahrscheinlich schon entgehen genommen hat und weil es nicht verarbeitet wurde (Speicherung) ist Deine Transaktions-ID im Nirwana.
Dies wäre wahrscheinlich Deine einzige Chance, wenn Du selber die Transaktion nicht in Deinem PayPal Account siehst.
handelt es sich beim Checkout um WooCommerce? Oder gibt es für WordPress separates Plugin was PayPal Checkout anbindet?