MODUL: PayPal PLUS & PayPal Checkout Zahlungsmodule für modified eCommerce Shopsoftware

[GTB]

Korrekt, habe es geändert.

Gruss Gerhard

[noRiddle (revilonetz)]

Hatte noch einen Nachtrag: "Ach, und es kommt zweimal vor."
Ich gehe davon aus, daß es an beiden Stellen geändert werden muß.

Gruß,
noRiddle

[GTB]

Das 2te mal muss bleiben, denn da ist eine Bestellung bereits vorhanden und dann gibt es $order->delivery immer.

Gruss Gerhard

[noRiddle (revilonetz)]

Okay, dann sicherheitshalber:
Wir reden dann ausschließlich von dem Vorkommen in der Funktion patch_payment_paypalplus() ?

Gruß,
noRiddle

[GTB]

Habe die Anleitung in Antwort #1183 nochmals geändert. So ist es auch aktuell im SVN.

Gruss Gerhard

[Tomcraft]

Die Module in Beitrag 1 wurden erneut aktualisiert. Wer bereits eine ältere Version des Moduls installiert hatte, der lädt bitte einfach den Inhalt des Ordners "NEW_FILES" erneut in seinen Shop.

Zusätzlich sind seit der letzten Modulversion noch folgende Dateien aus dem Ordner "CHANGED_FILES" zu bearbeiten:

Für Shopversion 1.06 rev 4642 SP4, 2.0.0.0 rev 9678, 2.0.1.0 rev 10403, 2.0.2.0 rev 10591, 2.0.2.1 rev 10607, 2.0.2.2 rev 10690, 2.0.3.0 rev 10907, 2.0.4.0 rev 11204, 2.0.4.1 rev 11327 & 2.0.4.2 rev 11374

• /includes/external/paypal/classes/PayPalPayment.php
• /includes/external/paypal/classes/PayPalPaymentBase.php

Da hier davon ausgegangen wird, dass der Shopbetreiber an diesen Dateien keine Änderungen vorgenommen hat, können die Dateien aus dem Ordner "CHANGED_FILES" für die genannten Shopversionen einfach in den Shop kopiert werden.

Eingeflossen sind die Korrekturen aus r11536, r11537 & r11538, die das Problem bei abweichender Lieferadresse beheben.

Grüße

Torsten

[Timm]

Ich konnte nun in einem älteren Shop das Problem nachstellen.
[...]

Im Demoshop war es auch nachstellbar und bei uns Nutzern mit 2.0.4.2 auch.

Vielen Dank - funktioniert nun.

Nächstes mal wäre es nur schön, wenn man mehr auf uns eingeht. Werden sicher nicht umsonst mehrere den gleichen Fehler melden.

Gruß Timm

[WeXsler]

Danke an alle die daran mitgewirkt haben, dass das Modul weitergekommen ist!

Was mir noch fehlt ist der Firmenname in der Lieferanschrift. Der wird, zumindest im Plusmodul, noch nicht mit übergeben. Das scheint mir doch noch wichtig.

Eine vielleicht banale Frage noch zum Handling mit der Zahlungsauswahl im Plusmodul.

Im Text ist zu lesen "Bitte wählen Sie eine der unten aufgeführten Zahlarten durch Anklicken aus". Soweit so gut. PayPal-Standard ist da aber nun mit einem Häkchen schon immer vorausgewählt! Wenn ich diese PP-Zahlart möchte, muß ich es dann doch gar nicht mehr Anklicken. Klicke ich laut Hinweistext trotzdem darauf, verschwindet das Häkchen. Diese Zahlart wird aber trotzdem mit übergeben.

Also im Grunde funktioniert es, mich würde es aber als Kunde völlig verwirren. Wäre es nicht besser, dass die Vorauswahl nicht gemacht wird und der Kunde dann aktiv die Zahlart Anklicken muß und ihm der Erfolg des Klickens auch erst dann per erscheinendem Häkchen angezeigt wird?

[noRiddle (revilonetz)]

Zu "Bitte wählen Sie eine der unten aufgeführten Zahlarten durch Anklicken aus" und gleichzeitigem Vorausgewähltsein (gibt's das Wort ?) von PayPalPlus:
Volle Unterstützung. Das ist irreführend.

Gruß,
noRiddle

[MichaGE]

Ich habe das Problem mit PayPal Warenkorb und Zahlung abgebrochen immer noch. Vielleicht kann da jemand (kostenpflichtig) helfen?

[Timm]

Moin

Etwas wenig Infos. Welche Shopversion zb. Hast du "Warenkorb senden" auf nein? Liegt es an irgendwelchen Rabatten oder Guthaben bzw ist das immer so?

In der Fehlermeldung steht was von:

Code: PHP  [Auswählen]

purchase_units[0].amount

Hast du Verpackungseinheiten in Benutzung? Oder andere Dinge, die vom Standardshop abweichen wie Dezimalzahlen?

Wenn Programmierauftrag, dann ans Team, weil die einen möglichen Fehler dann auch in eine neue Modulversion einfließen lassen könnten.

Gruß Timm

[noRiddle (revilonetz)]

@MichaGE

• kannst du nicht davon ausgehen, daß wir deinen Post von zig Posts vorher noch kennen oder überhaupt kennen und du kannst hier niemanden zwingen alles durchzuschauen wo du evtl. was gepostet hast.
  Also: dich selbst zitieren oder auf den Post verlinken.
• ist das Problem ja im Log an dieser Stelle deutlich beschrieben:
  "Transaction amount details (subtotal, tax, shipping) must add up to specified amount total"
  Es stellt sich also die Frage wie das kommen kann.
  Evtl. ein nötiges ot-Modul nicht installiert ? (Backend => Module => Zusammenfassung)
  Evtl. eine Erweiterung die ein ot-Modul mit einschließt ?
  

Gruß,
noRiddle

[Timm]

2. ist das Problem ja im Log an dieser Stelle deutlich beschrieben:
"Transaction amount details (subtotal, tax, shipping) must add up to specified amount total"

Ganz so deutlich ist das glaube ich nicht. Seine Fehlermeldung

Code: XML  [Auswählen]

{"name":"VALIDATION_ERROR","details":[{"field":"purchase_units[0].amount","issue":"Transaction amount details (subtotal, tax, shipping) must add up to specified amount total"}],"message":"Invalid request

ist nämlich ähnlich wie meine

Code: XML  [Auswählen]

{"name":"VALIDATION_ERROR","details":[{"field":"transactions[0].amount","issue":"Transaction amount details (subtotal, tax, shipping) must add up to specified amount total"}],"message":"Invalid request

Bei mir musste ich vorläufige Versandkosten angeben, was aber weder aus der Fehlermeldung ersichtlich ist, noch macht es irgendeinen Sinn, warum bei mehr als 2 Artikeln mit ungerader zweiter Dezimalstelle der Fehler auftritt und bei nicht ungeraden Mengen (wie 1,40) der Fehler nicht auftritt, auch wenn keine vorläufigen Versandkosten angegeben sind.

Ich werde deshalb nachher mal die ot Module einzeln abschalten und gucken, ob das Auswirkung hat.

@MichaGE
Trag mal vorläufige Versandkosten ein und teste. Und antworte auf die anderen Fragen.

Gruß Timm

[AGI]

Guten Morgen,

Ich möchte kurz auf die Fehlermeldung eingehen, um die mögliche Ursache schneller zu finden:

Code: PHP  [Auswählen]

{"name":"VALIDATION_ERROR","details":[{"field":"purchase_units[0].amount","issue":"Transaction amount details (subtotal, tax, shipping) must add up to specified amount total"}],"message":"Invalid request

PayPal bekommt zu anlegen der Trasaktion die einzelnen Preise aus Positionen des Warenkorbs und einzelne Beträge aus den OT-Modulen (sofern man den detaillierten Warenkorb übergibt).
Und PayPal bekommt die Gesamtsumme der Bestellung/des Warenkorbs.
PayPal addiert nun die einzelnen Positionen und vergleicht die Summe mit der übermittelten Gesamtsumme. Wenn die Werte nicht übereinstimmen, gibt es die gezeigte Fehlermeldung.
Ein Unterschied von einem Cent reicht da schon aus.

Gründe für Differenzen können gibt es mehrere, Beispielsweise:
Rundungsfehler, auch durch die Berechnung der MwSt,
OT-Module, die zwar in der Gesamtsumme, nicht aber in den einzelnen Positionen berücksichtigt sind.

Durch das Abschalten der einzelnen OT-Module könnte der Fehler gefunden werden.

Sollte es sich nicht lösen lassen, hilft es, PayPal nicht mehr den kompletten Warenkorb zu übermitteln, sondern nur noch den Gesamtwert.

Offtopic:
Ich Frage mich tatsächlich immer, warum wir PayPal mit den einzelnen Positionen füttern. Es kann doch PayPal egal sein, was der Kunde kauft. Ich hatte Händler, deren Konten gesperrt wurden, da Sie Artikel verkauften, die wie Städte hießen. Und Städte kann man nicht verkaufen, also Betrug, also Kontosperrung.

Viele Grüße
Andreas

[Timm]

Danke @AGI der Tipp mit dem Rundungsfehler hat mich auf den tatsächlichen Fehler kommen lassen.

mein spezielles Problem:

Warenkorb wird übrigens nicht übermittelt, da bricht er mit und ohne vorläufige Versandkosten ab und paypalplus wird dann gar nicht mehr angezeigt

9,50€x1,15=10,925 woraus er 10,93 macht
13,50€x1,15=15,525 woraus er 15,53 macht
also 0,5 Cent aufgerundet macht bei 2 Artikeln 1Cent aufgerundet

dadurch stimmt subtotal (26,46€) nicht mit total (26,45€) überein, weil total mit den nicht gerundeten Werten arbeitet

[ Für Gäste sind keine Dateianhänge sichtbar ]

das führt zu dieser gekürzten Fehlermeldung

Code: XML  [Auswählen]

payment_error=paypalcart"},"transactions":[{"amount":{"total":"26.45","currency":"EUR","details":{"subtotal":"26.46"}},"item_list":{"items":[{"name":"Ihre Bestellung bei Stoffbiotop","currency":"EUR","quantity":1,"price":"26.46"}]}

nun das Ganze mit vorläufigen Versandkosten, wo es durchgeht:

Code: XML  [Auswählen]

"transactions":[{"amount":{"total":"31.35","currency":"EUR","details":{"subtotal":"31.35"}},"description":"Stoffbiotop","invoice_number":"5c6d20ef21a98","item_list":{"items":[{"name":"Ihre Bestellung bei Stoffbiotop","price":"26.45","currency":"EUR","quantity":1},{"name":"Vorläufige Versandkosten","price":"4.90","currency":"EUR","quantity":1}]},"related_resources":[]}]

Das könnte nun für alle interessant sein:
ohne vorläufige Versandkosten wird scheinbar die Zwischensumme 26,46€ als subtotal genommen und mit total 26,45€ verglichen, obwohl als Zwischensumme 26,45€ angegeben ist. Er berechnet subtotal also aus den addierten einzelnen Produktpreisen.

mit vorläufigen Versandkosten wird scheinbar die angezeigte Zwischensumme (26,45€) als subtotal genommen plus Versandkosten (4,90€) = 31,35€ und mit total (31,35€) verglichen. Er rechnet also nicht wie vorher die Produktpreise zusammen, sondern nimmt nur die angezeigte Zwischensumme.

Deshalb klappt es auch mit vorläufigen Versandkosten, weil er die Rundungsfehler nicht mit einbezieht.

Fragen:
1) Sollte er ohne vorläufige Versandkosten nicht auch die angezeigte Zwischensumme als Grundlage nehmen?
2) Warum wird das unterschiedlich gehandhabt?
3) Wie sollte ich verfahren? Preise mit mehr Nachkommazahlen anzeigen, oder die Zwischensumme um den Aufrundungsfehler erhöhen lassen, dass er also die dann angezeigten Artikelpreise zusammenrechnet auch wenn der Kunde dadurch am Ende die Rundungsdifferenz bezahlen muss?

Gruß Timm