Erster kurzer Test, mehr folgt morgen: Während der Test durchgeführt wurde, waren auch keine PP-Bestellungen mit dem alten Modul im Liveshop bzw per Sandbox im Testshop möglich. Folgendes ist dabei im Testshop aufgefallen: - Kleinigkeit: Installation: inc/htmlspecialchars_wrapper.inc.php aus neu Verzeichnis bereits vorhanden und identisch zur vorhandenen Version - Die PP-Buttons auf den Artikelseiten und im WK waren schon aktiv, bevor paypalng installiert war - Fehler bei Klick auf Kaufen-Button auf checkout_confirm: got no token! - Fehler bei Klick auf einen der PP-Buttons (egal ob WK oder Artikelseite): paypal: error - Wie wird der PP Button auf der Artikelseite eingefügt? Bei mir kommt der 2-mal vor. Habe in der templates/EyeCandy/module/product_info/standard-USERMOD.html eine Anpassung drin, damit der Bewertungslink immer angezeigt wird. Folgender Code wurde dafür nach dem Merkzettel eingefügt: HTML: <div class="leaflet"> <a href="product_reviews_write.php?info=p{$PRODUCTS_ID}"> Produkt bewerten </a> </div> In der neuen Paypal-Konfiguration finde ich die beiden Buttons "hier abrufen" verwirrend, wenn man seine Daten eh schon kennt und nur hinterlegen will. Sind die beiden Status-Möglichkeiten "Bestellstatus abgewiesen" und "Bestellstatus in Bearbeitung" aus dem alten Modul nicht mehr vorgesehen?
Hm...grade noch was an der versuchten Testbestellung aufgefallen. Nachdem ich das geändert habe, ging zumindest das alte PP-Modul. Und zwar gibt es anscheinend einen Rundungsfehler, wenn man ot_payment verwendet. Konstellation wie folgt: Warenwert: 70,30€ 5% Rabatt, angezeigt: 3,52€ Versand: 13,50€ Summe, angezeigt: 80,29€ Wer das nachrechnet (70,3 - 3,52 + 13,5), kommt drauf dass die Summe eigentlich 80,28€ sein müsste. Der Unterschied kommt dadurch zustande, dass der Rabatt eigentlich 3,515€ ist und schon gerundet angezeigt wird. Es wird dann aber mit dem ungerundeten Wert weitergerechnet, was zu dem Ergebnis 80,285 führt, was dann gerundet wird. Mit der Konstellation bricht das alte Modul ab, nehm ich einen Artikel raus und falle damit unter die Rabattstufe geht das Modul durch. Das neue Modul bricht weiter ab. Die PP-Module wurden für den Test übrigens abwechselnd unter Zahlungsweisen komplett deinstalliert.
Das müsste man in der Installationsanleitung aufführen, danke für den Hinweis. Die Datei ist nur für ältere Shops notwendig, in denen sie fehlt. Das ist in der beiliegenden Version gefixt, die Buttons tauchen nur noch auf, wenn das Zahlungsmodul installiert und aktiv ist. Um beurteilen zu können, was da los ist, müsste ich einen Blick auf die Logfiles werfen. Sind denn die Zugangsdaten laut Anzeige auf der Konfigurationsseite OK? Per JavaScript vor div.leaflet. In der neuen Version jetzt nur noch vor dem ersten div.leaflet. Ist das wirklich so verwirrend? Eine abgewiesene Zahlung entspricht im Prinzip einer nicht durchgeführten Zahlung, die Bestellung bleibt dann im temporären Status („Bestellung im Zahlungsvorgang“), Zahlungen die nicht direkt bewilligt werden, bekommen den Status „in Schwebe“ („pending“). Geänderte Dateien in der beiliegenden Version: gm/classes/GMPayPal.php templates/EyeCandy/usermod/javascript/ProductInfo/PayPalButton.js
Mit Änderungen des Rechnungsbetrages durch Zusammenfassungsmodule gab es beim Standard-Checkout generell noch Probleme. In der beiliegenden Version ist dafür nun eine Korrektur enthalten, die aber noch nicht ausführlich getestet ist. Beim Checkout mit vorgezogenem PayPal-Login (von Artikeldetailseite oder Warenkorb aus) dürfte das Problem nicht auftreten. Geänderte Datei: gm/classes/GMPayPal.php
Da habe ich aber ein Thema angeregt. @ Marco Also ich finde schon das es Priorität haben sollte. Denn gerade wie Dennis schon mitteilte sind Leute schon durch den Button kostenpflichtig bestellen abgeschreckt. Dies kam bei mit am laufenden Band vor. Ich nutze tatsächlich Paypal Gold Modul und bin sehr zufrieden damit. Ich denke @Gambio, dass sich einige darüber freuen würden dies Standard mit drin sein haben und keiner muss sich mehr sorgen um ein Update machen. Solch ein Button Paypal Zahlungslink senden befindet sich bei mir bereits im Admin. Zusätzlich erhält er diesen Link auch in der Bestellbestätigung, falls er noch nicht gezahlt hat, kann er dies so vornehmen. Der Status wird zusätzlich auch auf "Zahlung eingegangen" gesetzt. Ich danke euch dennoch Ihr seid ja immer stets dabei.
Hallo Marco, die Weiterleitung zu Paypal, ob aus dem Warenkorb oder aus dem Produkt erfolgt im gleichem Fenster, währe es hier nicht besser, die Weiterleitung in einem neuem Fenster zu öffnen? Denn der Link bei Paypal zurück zum Shop ist doch sehr schwer zu sehen, und so haben die Kunden ganz schnell das Fenster geschlossen und sind weg.
Hallo Kai, nein, das ist schon so vorgesehen, dass das alles im selben Fenster abläuft. Und eigentlich erfolgt die Weiterleitung zurück in den Shop doch automatisch und unweigerlich, sobald man bei PayPal die Zahlung abgeschlossen hat …?! Ist das bei dir anders?
Bevor ich es vergesse: Eine Lösung zum Thema PayPal-Zahlungslink ist in Grundzügen fertig. Morgen mehr dazu.
Hallo Marco, so weit habe ich noch nicht getestet, da ich noch nicht dazu gekommen bin mir eine Sandbox Account anzulegen.
Neueste Version installiert, Artikelseite sieht jetzt gut aus. Kann auch einfach nur an mir liegen Hatte an der Stelle eher einen Button wie "Zugangsdaten prüfen" erwartet und musste mir den erstmal langsam anschauen und den Sinn davon verstehen. Wenn's entsprechend im Handbuch erwähnt wird kann ich mir aber schon vorstellen, dass es neuen Benutzern weiterhilft, durch die Buttons direkt auf die entsprechende Seite geleitet zu werden. Die Zugangsdaten für die Sandbox sind laut der Seite OK (auch extra mal was falsches eingegeben, da wird gleich gemeckert). Hier der Logeintrag aus payment-paypal-xxxx.log für einen Versuch über den normalen Checkout zu gehen: Code: [OrderTotal] => [ReturnURL] => http://url.de/checkout_process.php [CancelURL] => http://url.de/checkout_payment.php [TrackingImageURL] => [giropaySuccessURL] => [giropayCancelURL] => [BanktxnPendingURL] => [Token] => [MaxAmount] => [OrderDescription] => [Custom] => [InvoiceID] => [ReqConfirmShipping] => 0 [ReqBillingAddress] => [BillingAddress] => [NoShipping] => 1 [AddressOverride] => 1 [LocaleCode] => [PageStyle] => [cppheaderimage] => [cppheaderbordercolor] => 000000 [cppheaderbackcolor] => ffffff [cpppayflowcolor] => FF0000 [cppcartbordercolor] => 000000 [cpplogoimage] => [Address] => [PaymentAction] => Sale [SolutionType] => [LandingPage] => [BuyerEmail] => [ChannelType] => [BillingAgreementDetails] => [PromoCodes] => [PayPalCheckOutBtnType] => [ProductCategory] => [ShippingMethod] => [ProfileAddressChangeDate] => [AllowNote] => 0 [FundingSourceDetails] => [BrandName] => Shopname [CallbackURL] => [EnhancedCheckoutData] => [OtherPaymentMethods] => [BuyerDetails] => [PaymentDetails] => Array ( [0] => PaymentDetailsType Object ( [OrderTotal] => BasicAmountType Object ( [currencyID] => EUR [value] => 52.40 ) [ItemTotal] => BasicAmountType Object ( [currencyID] => EUR [value] => 43.40 ) [ShippingTotal] => BasicAmountType Object ( [currencyID] => EUR [value] => 9.00 ) [HandlingTotal] => [TaxTotal] => [OrderDescription] => [Custom] => [InvoiceID] => [ButtonSource] => [NotifyURL] => http://url.de/paypal_ipn.php [ShipToAddress] => AddressType Object ( [Name] => Shopname [Street1] => Daimlerstr. 2 [Street2] => [CityName] => Wernberg-Köblitz [StateOrProvince] => [Country] => DE [CountryName] => [Phone] => 01234/56789 [PostalCode] => 92533 [AddressID] => [AddressOwner] => [ExternalAddressID] => [InternationalName] => [InternationalStateAndCity] => [InternationalStreet] => [AddressStatus] => [AddressNormalizationStatus] => ) [FulfillmentReferenceNumber] => [FulfillmentAddress] => [PaymentCategoryType] => [ShippingMethod] => [ProfileAddressChangeDate] => [PaymentDetailsItem] => Array ( [0] => PaymentDetailsItemType Object ( [Name] => Versele-Laga Waldvögel Prestige 20 kg [Number] => [Quantity] => 1 [Tax] => [Amount] => BasicAmountType Object ( [currencyID] => EUR [value] => 26.90 ) [EbayItemPaymentDetailsItem] => [PromoCode] => [ProductCategory] => [Description] => [ItemWeight] => [ItemLength] => [ItemWidth] => [ItemHeight] => [ItemURL] => [EnhancedItemData] => [ItemCategory] => Physical ) [1] => PaymentDetailsItemType Object ( [Name] => Versele-Laga Türkentauben Prestige 20 kg [Number] => [Quantity] => 1 [Tax] => [Amount] => BasicAmountType Object ( [currencyID] => EUR [value] => 16.50 ) [EbayItemPaymentDetailsItem] => [PromoCode] => [ProductCategory] => [Description] => [ItemWeight] => [ItemLength] => [ItemWidth] => [ItemHeight] => [ItemURL] => [EnhancedItemData] => [ItemCategory] => Physical ) ) [InsuranceTotal] => [ShippingDiscount] => [InsuranceOptionOffered] => [AllowedPaymentMethod] => [EnhancedPaymentData] => [SellerDetails] => [NoteText] => [TransactionId] => [PaymentAction] => Sale [PaymentRequestID] => [OrderURL] => [SoftDescriptor] => [BranchLevel] => [OfferDetails] => [Recurring] => [PaymentReason] => ) ) [FlatRateShippingOptions] => [CallbackTimeout] => [CallbackVersion] => [CustomerServiceNumber] => [GiftMessageEnable] => [GiftReceiptEnable] => [GiftWrapEnable] => [GiftWrapName] => [GiftWrapAmount] => [BuyerEmailOptInEnable] => [SurveyEnable] => [SurveyQuestion] => [SurveyChoice] => [TotalType] => [NoteToBuyer] => [Incentives] => [ReqInstrumentDetails] => [ExternalRememberMeOptInDetails] => [FlowControlDetails] => [DisplayControlDetails] => [ExternalPartnerTrackingDetails] => [CoupledBuckets] => ) [DetailLevel] => [ErrorLanguage] => [Version] => ) ) 2013-11-05T09:16:50 01:00 | setECResponse: SetExpressCheckoutResponseType Object ( [Token] => [Timestamp] => 2013-11-05T08:16:50Z [Ack] => Failure [CorrelationID] => e2a18e692c2a8 [Errors] => Array ( [0] => ErrorType Object ( [ShortMessage] => Missing argument [LongMessage] => Item name, amount and quantity are required if item category is provided. [ErrorCode] => 10003 [SeverityCode] => Error [ErrorParameters] => ) ) [Version] => 98.0 [Build] => 8334781 ) Was mir daran auffällt: NoShipping steht auf 1, obwohl eigentlich 9€ Versandkosten anfallen. Das Versandmodul in dem Fall ist ein kopiertes und für eigene Zwecke angepasstes DPD Modul. Einstellungen unter Zusammenfassung -> ot_shipping stehen auf "Versandkostenfrei erlauben: false", allerdings ist ein Wert von 50€ bei "Versandkostenfrei für Bestellungen ab" hinterlegt. Bei Bedarf kann ich dir auch einen Zugang zum Testshop einrichten.
Hier kommt schon wieder eine neue Version. Die große Neuerung ist die Möglichkeit, bei jeder Bestellung (!) einen PayPal-Zahlungslink zu generieren und optional per E-Mail an den Kunden zu verschicken. Für die technisch Interessierten: Das läuft nicht über die weiter oben in diesem Thread schon einmal erwähnte BuyNow-Button-Schnittstelle von PayPal, weil diese offiziell die Übergabe von Parametern per GET nicht unterstützt und das Missbrauchsrisiko einfach zu hoch ist. Die versendeten Links haben stattdessen dieses Format: http://www.dein-shop.tld/paypal_payment.php?paycode=827ccb0eea8a706c4c34a16891f84e7b Der Code stellt die Verbindung zur Bestellung her, der Shop erzeugt dann eine relativ normale Weiterleitung zu PayPal über die auch im Checkout verwendete Schnittstelle. So kommt der Endkunde mit den Parametern für die Zahlung nicht in Berührung.
Bin leider noch nicht zum Testen gekommen, habe aber eine Frage dazu. wenn der Kunde bisher die Zahlung mit PP abgebrochen hat, wurde vom Shop keine Bestellbestätigung versendet, jedoch der Warenbestand reduziert. Wurde das geändert? Meiner Meinung nach sollte die Bestellbestätigung versendet werden, wenn der "Kaufen-Butten" geklickt wird, unabhängig davon ob die Zahlung abgeschlossen wird oder nicht.
Die Fehlermeldung scheint nicht zu dem Request zu passen, die monierten Felder sind ja ausgefüllt. Aber mit einem tiefen Blick in die Kristallkugel ahnt man, dass das Problem bei den Umlauten in den Artikelnamen liegt. In der beiliegenden Version ist das gefixt. Das hat nichts miteinander zu tun, der NoShipping-Parameter steuert, ob und wie PayPal die Erfassung einer Versandadresse ermöglicht.
Hm, komisch. War der einzige Logeintrag von heute. Glaskugel hat aber einwandfreie Dienste geleistet, jetzt funzt die Weiterleitung zu PP. Neue Beobachtungen: - Beim Klick auf den WK/Artikellink öffnet sich PP mit englischen Begriffen, über den Checkout deutsch (Falls das eine Rolle spielen kann: Mein Sandbox Account ist ein US-Account, weil DE damals nicht funktionierte) - Sehr gut: Wenn man über den WK/Artikellink zu PP kommt, wird ot_payment zwar nicht angezeigt, durch den weiteren Verlauf im Checkout dann aber doch berücksichtigt. - Die Umlaute werden auf der Bestellseite im Adminbereich (orders.php) noch nicht richtig dargestellt, sieht auch insgesamt noch bissl verwackelt aus: Fragen: - Beim Klick auf den Link im Artikel wird die Menge des Artikels um 1 erhöht und dann zu PP weitergeleitet; ich nehme an, das ist so gewollt? - Was wird durch die Einstellungen "Payflow Farbe" und "Seitenstil" in der Konfiguration geändert? Ich kann keine Veränderungen auf der PP-Seite feststellen. - Wird ot_payment dann generell so gehandhabt wie momentan im PP-Modul oder ist das nur ein temporärer Fix? Im Shop (und auf der Rechnung) wird ja noch so gerechnet wie weiter vorne im Thread beschrieben, PP weist aber momentan den Rabattbetrag anders aus. In der o.g. Konstellation von 5% Rabatt auf 70,30€ steht dann auf der Rechnung ein Rabatt von 3,52€, bei PP aber von 3,51€.
Momentan geben wir da absichtlich keine Sprache vor, in der Annahme, dass die PayPal-seitige Ermittlung der Benutzersprache (anhand von Browser, Benutzerdaten, IP-basierter Geolocation, …) relativ zielsicher funktioniert und flexibler ist. Da fehlt noch die Rückwandlung beim Encoding, ist notiert. Jein. Der PayPal-Button auf der Artikeldetailseite soll im wesentlichen so funktionieren, als würde man den In-den-Warenkorb-Button klicken und dann im Warenkorb den PayPal-Button anklicken. Da im Mengeneingabefeld i.d.R. eine 1 steht und der Klick auf den In-den-Warenkorb-Button dann eine Erhöhung der Artikelmenge im Warenkorb um 1 bewirkt, stimmt deine Beobachtung insofern. Es gibt bei PayPal ein paar Parameter zum Erscheinungsbild der Zahlungsseite, die bei der aktuell verwendeten Zahlungsseite nicht mehr zum Einsatz kommen. Die Payflow-Farbe gehört wohl dazu. Den Seitenstil kann man direkt bei PayPal konfigurieren, das ist da tief in den Einstellungen für Business-Accounts verborgen. Der dort konfigurierte Seitenstil hat dann einen Namen, den man in der Konfiguration im Shop eintragen kann. Das Thema Rundungsfehler im Zusammenhang mit den Zusammenfassungsmodulen ist leider ein ganz böser Zeitfresser. Ich werde mir das noch einmal genau ansehen, wenn ich die Gelegenheit habe. Aktuell ist es im PayPal-Modul einfach so geregelt, dass Abweichungen, die von Zusammenfassungsmodulen herrühren, gesammelt abgehandelt werden, damit PayPal in sich stimmige Daten erhält.
Hm, könnt ihr das bei euch denn nachvollziehen mit den unterschiedlichen Sprachen? Bei mir ist halt direkt die Einstiegsseite bei PP schon englisch. Wenn das anhand der Benutzersprache klappen würde, wäre natürlich super. Bei mir ist aber die eine Variante englisch (Button) und die andere (Checkout) deutsch. Oder kann jemand anders das bei sich nachvollziehen?
Hier kommt mal wieder ein Update mit ein paar Fixes für kleine Probleme, die inzwischen aufgetaucht sind. - Encoding der Daten bei der Bestellbearbeitung - Zahlungslink-Modul und PayPal-Bearbeitung störten sich so, dass bei der PayPal-Bearbeitung Operationen wie Rückzahlungen nicht funktionierten - Fehler bei vollständiger Rückzahlung - Weiterleitung bei der Verarbeitung von PayLinks funktionierte unter gewissen Umständen nicht - Zahlung über PayLink beachtete den eingegebenen Betrag nicht - zusätzliches Logging an einigen Stellen
Bei uns läuft das seit 1 Woche ca....aber eben doch nicht, es ist ein Graus!. Die letzten 3 PP-Bestellungen klappten alle nicht und wir mussten zu Kreuze kriechen. Schaden finanzieller Art und Vertrauensverlust immens. Und von G seit Tagen keinen Support erhalten. Sind sauer und das NEUE ist minestens so schlimm wie das alte - DAS ist keine Lösung - heute Abend mal nachhaken, was da noch möglich ist.
Das neue Modul ist zur Zeit im Betatest, und dieser Betatest soll eben gerade dazu dienen, Fehler zu finden. Wenn wir aber hier in diesem Thread keine Fehlerbeschreibungen bekommen, können wir die Fehler auch nicht bereinigen.
Tut mir leid das ich das sage, aber eine Betaversion in einen normalen Shop installieren, der läuft, finde ich schon etwas selten doof... Gerade vielleicht in einem Gewerbe wo die Preise hoch sind, ist es immer schwierig, sowas zu testen. Na ja, immerhin lernt man daraus. Ich entschuldige mich jetzt schon einmal für die Leute die das falsch in den Hals bekommen...