unterschiedlicher request string von PayPal?

[Aretas]

Hallo allerseits,

mir ist aufgefallen, dass im Admin->Bestellung->Bearbeiten->Details (view=details) bei einigen Bestellungen Werte nicht ausgefuellt sind. Auf den ersten Blick sieht es so aus, dass email, status usw. des Kaeufers nur bei Expresscheckout (Warenkorb) ausgefuellt sind. Ueber den normalen Checkout sind diese Werte leer.
Da die Abfrage an den PayPalserver jeweils von der gleichen Funktion (GetTransactionDetails) ausgefuehrt wird, ist dies vielleicht ein Ansatz fuer den Support, den fehlenden Werten wie payer_email oder payer_status nachzugehen.

Apropo Support, wenigstens ein *wir arbeiten dran* sollte doch drin sein, aber absolute Funkstille bei den immensen Problemen, die das Modul macht?

Gruss Torsten

[xt:mzanier]

Da die Abfrage an den PayPalserver jeweils von der gleichen Funktion (GetTransactionDetails) ausgefuehrt wird, ist dies vielleicht ein Ansatz fuer den Support, den fehlenden Werten wie payer_email oder payer_status nachzugehen.

diese felder sind nicht bei allen transaktionen gesetzt, folglich kann man sie auch nicht über diese funktion holen....

Apropo Support, wenigstens ein *wir arbeiten dran* sollte doch drin sein, aber absolute Funkstille bei den immensen Problemen, die das Modul macht?

matthias postet hier täglich, das an dem modul gearbeitet wird sieht man ja schon alleine an dem changelog im download.

das einige probleme nicht von heute auf morgen zu beheben sind, sollte auch jedem klar sein, denn die tests auf der sandbox sind teilweise ein lotteriespiel.
Wir haben zwar eine direkte verbindung mit der Entwicklung bei PayPal, aber anhand der komplexität des Modules ist dies natürlich nicht so einfach.

[Aretas]

Zitat von mzanier

matthias postet hier täglich, das an dem modul gearbeitet wird sieht man ja schon alleine an dem changelog im download.

hmm, da sehe ich nur 12.10., noch dazu sind die 2 letzten release eingearbeitete bugfixe von mir.

Zitat von mzanier

Wir haben zwar eine direkte verbindung mit der Entwicklung bei PayPal, aber anhand der komplexität des Modules ist dies natürlich nicht so einfach.

genau deswegen draengele ich, ich brauch nicht bei PayPal anklopfen, ob wir mal Logs abgleichen koennen. Da kommt wahrschlich nicht mal ne Antwort.

Bleibt am Ende nur die Frage, wieso Tests und Entwicklerarbeit der Forumgemeinde ueberlassen wurde. Schon bei ersten Test haette auffallen muessen, dass das so nicht geht, z.B. das komplette Callback kaputt war (sql-error), die paypal_history_table leer waren usw..
Ich weiss, dass genau dieses Unmengen an Zeit und Resourcen kostet und man dann in Versuchung kommt, dass einzusparen. Man beachte aber, was xtc fuer einen internationalen Stellenwert hat - und dann sowas...

Gruss Torsten

[Aretas]

Zitat von mzanier

diese felder sind nicht bei allen transaktionen gesetzt, folglich kann man sie auch nicht über diese funktion holen....

Das ist so nicht richtig, das wuerde nur bei einem key wie *custom* zutreffen.

Bei payer_email bsplw. handelt es sich um die Kontomail des Kaeufers, die du ja gar nicht kennen kannst. Diese ist Bestandteil der Buyer Information, die Paypal normalerweise an das IPN zuruecksendet und die hier fehlt. Sollte so aussehen, zumindestens tun sie das bei meinen scripts:

payer_id => 'DTQMGCWEK7BHC',
residence_country => 'DE',
custom => 'newlicnc-119099734316515',
payment_gross => '',
txn_id => '40V435204G772791P',
last_name => 'V....',
receiver_id => '4GGSFL3FTMDT2',
receiver_email => 'music@...mail.com',
item_number => '1264',
payment_type => 'instant',
business => 'music@...mail.com',
payment_status => 'Completed',
shipping => '0.00',
payer_email => 'wemakeyouhappy@m....com',
cmd => '_notify-validate',
quantity => '1',
txn_type => 'web_accept',
tax => '0.00',
payment_fee => '',
charset => 'windows-1252',
item_name => 'Another Motive',
payment_date => '09:36:34 Sep 28, 2007 PDT',
mc_gross => '3.99',
notify_version => '2.4',
payer_status => 'verified',
mc_fee => '0.43',
mc_currency => 'EUR',
first_name => 'Thomas',

Ich wuerde, wenn hier was fehlt, doch mal nachsehen, wieso es fehlt. Dass das Modul auch an anderen Stellen wegen fehlender Standardrueckgaben klappert, sollte eigentlich bei euch angekommen sein (z.B. Statuseintrag in callback).
Auch ein Tip: bei Antwort *FAILURE* koennte man nach einem kleinen timeout eine erneute Anfrage senden, um Netzprobleme auszuschliessen. Paypal ist ja bekannt fuer seine ueberaus rasanten Server.

Gruss Torsten

Gruss Torsten

[xt:mzanier]

Bleibt am Ende nur die Frage, wieso Tests und Entwicklerarbeit der Forumgemeinde ueberlassen wurde. Schon bei ersten Test haette auffallen muessen, dass das so nicht geht, z.B. das komplette Callback kaputt war (sql-error), die paypal_history_table leer waren usw..

das paypal modul wurde für 3.1 entwickelt und auch zusammen mit dem paypal team mehrere monate geteset und abgenommen.

möglich das bei der portierung auf 2.1 andere fehler auftreten, zudem es hier auch wenig bringen würde nochmals für 2.1 monate auf der sandbox und auf der beta sandbox die ganze abnahme nochmals zu machen.

Das ist so nicht richtig, das wuerde nur bei einem key wie *custom* zutreffen.

eben nicht, du kannst uns schon glauben das die coder durchaus wissen was von paypal wo zurück kommt, vorallem im neuen express und direct payment gibt es eben nicht alle variablen, das hat mit dem normalen IPN einer web accept zahlung nicht viel zu tun.

[Aretas]

Zitat von mzanier

das paypal modul wurde für 3.1 entwickelt und auch zusammen mit dem paypal team mehrere monate geteset und abgenommen.
möglich das bei der portierung auf 2.1 andere fehler auftreten, zudem es hier auch wenig bringen würde nochmals für 2.1 monate auf der sandbox und auf der beta sandbox die ganze abnahme nochmals zu machen.

Das hatte ich vermutet. Und nun? 2.1. ist der offizielle Shop im Moment, zig tausendfach im Einsatz. Vor 14 Tagen hat PayPal ein weltweites Mailing mit Empfehlung fuer XTC und PPE rausgeschickt, was du ja sicher weisst.
Ich betreue mehrere Shops (woher auch mein Engagement ruehrt, ich bekomm ja die Haue) und bei keinem laeuft das problemlos. Jetzt tasten wir uns alle hier muehsam an Fehler und Fehlerursachen heran, das kann nicht der Weisheit letzter Schluss sein...

Gruss Torsten

P.S. huestel, aber banale Dinge wie fehlende Transportkosten oder Statuseintrag sollten schon mittlerweile gefixed sein.

[Matthias]

Weil auch die Änderungen erstmal getestet werden müssen.
Update dafür gibts morgen oder übermorgen.

PS: Deine Änderung die du mir geschickt hast lief bei mir leider überhaupt nicht. Dann hab ich garkeine Versandkosten mehr ausgewählt / berechnet bekommen.

[Aretas]

Zitat von Matthias

Weil auch die Änderungen erstmal getestet werden müssen.
Update dafür gibts morgen oder übermorgen.

PS: Deine Änderung die du mir geschickt hast lief bei mir leider überhaupt nicht. Dann hab ich garkeine Versandkosten mehr ausgewählt / berechnet bekommen.

Dafuer tun sie es hier
Ansonsten: das Script selbst sollte in einem anderen Shop nicht laufen koennen, liegt an meinen weiteren Modifikationen (hatte ich aber dazu geschrieben). Mein Anliegen war eigentlich, dir nur den Bugfix zu uebermitteln (zeile 204).

Gruss Torsten

[Matthias]

Ja das iss klar das Deine Datei nicht 1zu1 läuft in nem normalen Shop mit den Änderungen die du dazusätzlich drin hast