Diese Apps lassen sich sowohl Live als auch für die Sandbox löschen. Die ändern nichts an dem Konto selbst. Es geht also kein Geld verloren oder es ändert sich auch grundlegend nichts am Status des Kontos.
Beim onBoarden wird ja das Business-Konto auf Validität und Plausibilität geprüft. Diese Informationen speichert PayPal intern nicht in den Apps, sondern im Konto selbst (wo genau, ist nicht einsehbar). Darum wird man beim mehrmaligen durchlaufen des onBoardings in der Sandbox und im Live-System nicht mehr nach all den Daten gefragt.
Wichtig ist, falls man beim ersten Mal onBoarden im Live-System nicht die Freischaltung für Rechnungskauf und Kreditkarte erhält (Im Sandbox-System bekommt man die ja logischerweise immer), soll man nicht verzagen und den Prozess wiederholen. Denn beim onBoarden werden die hinterlegten Daten immer wieder neu bewertet. Angenommen der Liquditätsfluss hat sich verbessert oder ähnliche Aktionen, die PayPal zeigen, dass es sich um einen soliden Partner handelt, sorgen dafür, das eine Freischaltung auch später erfolgen kann.
Ja, zu dem Punkt komme ich noch hin. Da bin ich noch dran bezüglich Frontend Integration.
Generell sollte man sich glaube ich als Händler*in drauf einstellen, dass noch das ein oder andere Update des Moduls erfolgt. Gesehen es ist mittlerweile ein weiterer Bugfix in einer neuen Version 2.1.1 released wurden.
in Version 2.1.1 funktioniert das Modul nicht mehr in einen Shop im Nettomodus (CE 6.4.2, PHP 8).
Nach Absenden der Bestellung kommt man direkt wieder auf die Payment-Seite im Shop mit der Fehlermeldung “Autorisierung fehlgeschlagen”.
Im oxideshop.log steht:
OXID Logger.ERROR: Error on order create call. ["[object] (OxidSolutionCatalysts\\PayPalApi\\Exception\\ApiException(code: 422): POST https://api.paypal.com/v2/checkout/orders returned: 422 Unprocessable Entity\nReturned Message: The requested action could not be performed, semantically incorrect, or failed business validation.\nError Details: \n[{\"field\":\"\\/purchase_units\\/@reference_id=='OXID_REFERENCE'\\/amount\\/value\",\"value\":\"26.04\",\"issue\":\"AMOUNT_MISMATCH\",\"description\":\"Should equal item_total + tax_total + shipping + handling + insurance - shipping_discount - discount.\"}]\n\nResponse: \n{\"name\":\"UNPROCESSABLE_ENTITY\",\"debug_id\":\"532fd4c3d7c0c\",\"links\":[{\"href\":\"https:\\/\\/developer.paypal.com\\/docs\\/api\\/orders\\/v2\\/#error-AMOUNT_MISMATCH\",\"rel\":\"information_link\",\"method\":\"GET\"}]}\n\nThe following curl request could be used to simulate a similar request:\n \ncurl -v -X POST \"https://api.paypal.com/v2/checkout/orders\" -H \"User-Agent: GuzzleHttp/7\" -H \"Host: api.paypal.com\" -H \"Content-Type: application/json\" -H \"PayPal-Partner-Attribution-Id: Oxid_Cart_Payments\" -H \"PayPal-Client-Metadata-Id: \" -H \"Prefer: return=minimal\" -H \"Authorization: Bearer...
Ein weiteres Problem ist, dass die in der Tabelle oxorder__oxtransid gespeicherteTransaktions-ID nicht korrekt ist, bzw. nicht der PayPal-Transaktions-ID entspricht.
In dieser Tabelle sollte m.E. die Transaktions-ID gespeichjert werden, die auch im PayPalkonto und in den Emails zu sehen ist, damit man die Zahlungen abgleichen kann.
Aktuell wird anscheinend eine Order-ID dort gespeichert, die nach der Bestellung nirgends mehr auftaucht und daher nicht viel bringt.
@webchallenge ich bin jetzt einen Schritt weiter mit der Frontend Integration, welche sich sehr mühsam gestaltet wenn man ein individuelles Theme hat.
Frontend Integration PayPal Checkout Module
Für die Seitentypen Startseite, Suchergebnis, Kategorie, Produktdetailseite, Warenkorb, Versand & Zahlungsart kann man im Admin über die PayPal - Konfiguration - Banner Einstellungen festlegen ob das PayPal Banner angezeigt wird
Der PayPal Banner sieht bei mir wie folgt aus und wenn man drauf klickt öffnet sich Fenster wie folgt:
Für die Seitentypen Produktdetailseite und Warenkorb kann man den PayPal Express Button im Admin über die PayPal - Konfiguration - Einstellungen für die Buttonplatzierung konfiguieren mit dem Zusatz ob ein zweiter Button mit “Später Bezahlen”-Button anzeigen? angezeigt werden soll
Dies sieht dann bei mir wie folgt aus:
Was mir fehlt ist der PayPal Express Button für den Mini-Basket. Dies sieht das Modul zur Zeit anscheinend nicht vor.
Für den Seitentyp Versand & Zahlungsart werden ohne Konfigurationsanpassungen mir 7 Zahlarten angezeigt ohne Logos
PayPal
Kreditkarte
PayPal Express
GiroPay
PayPal - später bezahlen
Rechnungskauf
Sofort
Für den Seitentyp überprüfen & absenden stellen die Zahlungsarten Kreditkarte und Rechnungskauf eine Besonderheit dar, indem dort weitere Eingabefelder zur Eingabe/Kontrolle angezeigt werden.
a. Bei Kreditkarte werden Kartennummer, Ablaufdaum, CVV und Karteninhaber abgefragt
b. Bei Rechnungskauf wird Geburtsdatum und Telefonnummer abgefragt
Die nächsten Tage steht bei mir noch das funktionale Testen an und noch ggfs. Frontend Integration bisschen aufhübschen z.B. indem Bilder eingefügen und Fehlermeldung Handling und Co. verbessern
Für das PayPal-Modul gibt es eine separate Tabelle oscpaypal_order. In der Tabelle gibt es eine Spalte OXPAYPALORDERID. In dieser Spalte ist die zentrale ID der Order enthalten. Aus Kompatibilitätsgründen, wird diese ID ebenfalls in der OXTRANSID der oxorder abgelegt.
Eine PayPal-Order kann durch Prozesse wiederum mehrere Transaktionen enthalten (Teilstornos, Rückzahlungen etc.). Diese einzelnen Transaktionen haben wiederum eigene Transactions-IDs. Und hier entsteht das Mißverständnis: Da in 90% der Fälle eine PayPal-Order nur aus einer Transaktion besteht, könnte man meinen, das die Transaction-ID der Dreh- und Angelpunkt ist. Aus der Order-Sicht wie gesagt, nur eine untergeordnete Rolle. Man kommt aber aus einer PayPal-Order an die einzelnen Transaction-IDs ran. Sie werden u.a. in der Transaktions-Historie im Order-Backend gezeigt. Sie werden auch noch einmal eine Rolle für zukünftige Weiterentwicklungen haben (Pflicht-Übertragung der Tracking-IDs bei Kauf auf Rechnung und Kauf mit Kreditkarte). Im Moment passt aber alles so.
@nickname: Vielen Dank noch einmal für die Zusendung der ausführlichen Logs. Ich hoffe das die zurück geschickten Ansätze Dir bei Deiner “Netto”-Fehlersuche helfen werden. Für alle anderen Mitleser der Hinweis: In der Modulversion 1.1.1 u 2.1.1 gab es bewusst eine Fehlerbehebung für “Netto”-Shops, die wir auf Grund eines Community-Hinweises ergänzt haben.
@indianer3c: Es stimmt, in Deinem Fall (twig-theme) gibt es eine Menge zu tun. Im ersten Moment wirkt auch die Nutzung von Blocks in Kombination mit "include"ten Templates etwas übertrieben. Der große Vorteil ergibt sich jedoch, das Templates im Gegensatz zu Blocks noch einmal im eigenen Theme überschrieben werden können. D.h. wer mit Smarty-Themes arbeitet, kopiert betroffene Templates einfach aus dem Modul in sein Template und passt es da nach seinen Vorstellungen an.
Und ja, Du hast es richtig erkannt, es gibt im Mini-Basket keine Buttonlösung. Hintergrund ist, das sich neuerdings zwei integrierte Buttons gegenseitig beharken (Evtl. wird das auch wieder besser. PayPal kennt das Problem, kann aber nicht mal so schnell seine Technik ändern). Also wenn ich auf einer Detailseite mit Buttons oder im Warenkorb mit Buttons bin, ist bereits ein Button schon gesetzt. Da der Mini-Basket auf beiden Seiten Teil der komplett gerenderten Seite ist, kann ich den zweiten Button da nicht mehr platzieren.
Ja, dies stimmt teilweise. Neben Twig Theme kommt auch noch neuere Bootstrap Version zum Einsatz und das Theme ist sehr stark individualisiert.
Ah okay jetzt verstehe ich den Hintergedanken. So ähnlich löse ich es über mein Addon Modul auch, wo ich die Twig Templates rein lege um diese dort optimiert aufs shopspezifische Theme anzupassen für die Frontend Integration ins Design.
Dadurch das ich vor ca. 2 Jahren dieses Konzept für Amazon Pay, PayPal und PayPal Plus über Addon Module gelöst hatte besitze ich darin mittlerweile Erfahrung drin.
Das Vorgehen bringt auch Vorteile z.B. beschäftige ich mich dann intensiver mit dem Zahlungsarten Modul und seiner Arbeitsweise. Bleibt dann fürs spätere Debugging bei Problemen im Alltag keine Blackbox mehr.
Da wäre interessant wenn Ihr dort ein Sample Module für die Überladung der Templates aufsetzen könntet, dann könnte ich in ein Sample Modul meine Twig Parts noch mit einbringen. Im Kernmodul machen die Twig Anpassungen glaube ich noch keinen Sinn, weil zu stark individualisiert.
Gespannt bin ich dort auf die 7er Serie wie das mit den Blocks von Euch bei Twig gelöst wird.
Selber finde ich den Ansatz von Twig mittlerweile besser z.B. indem ich im Checkout Prozess die Templates
basket.html.twig
order.html.twig
payment.html.twig
um eine Mehrfachüberladung vorzunehmen mit extends
Finde dies auch leserlicher als die Verteilung für jede Block Überladung in eine extra Datei.
Wenn Smarty Template Engine rausfliegt solltet Ihr für ein neues Standard Theme da den strukturellen Aufbau der Theme Verzeichnisstruktur + Templates überdenken.
Ah okay, danke für Deine Ausführungen. Dies erklärt es.
Aus Händlersicht das schwer zu vermitteln, weil damit Umsatzverlust droht - da ein oder zwei Buttons weniger zum den potenziellen Kauf schnell abzuschließen.
Es fehlt auch noch der PayPal Express Button bei nicht eingeloggten Interessenten welche sich erst noch einloggen, als Gast oder Kunde registrieren müssen. Von der Benutzerfreundlichkeit um seine Bestellung schnell abzuschließen mit Adressdaten von PayPal bisschen ärgerlich an dieser Stelle.
Schön wäre noch eine offizielle Quelle wo man Icons/Bilder für die neuen Zahlungsarten für die Zahlungsarten Auswahl herbekommt. Die auswählbaren Zahlungsarten im Moment noch ein bisschen “Nackt” und unspektakulär.
Kleinigkeiten die mir noch aufgefallen sind und anscheinend auch auf Smarty Template Engine zutreffen sind
Moduleinstellungen Änderungen über Admin werden in 1.yaml Datei anstatt true/false mit 1/0 gespeichert. Aber auf die Funktionalität hat dies anscheinend keinen negativen Einfluss.
Bei allen neuen Zahlungsarten fehlt neben Icons/Bilder auch die Beschreibungstexte. Meine Annahme wäre dort, dass über die PayPalDefinitions Klasse die Beschreibungstexte eigentlich hinterlegt werden könnten oder?
'descriptions' => [
'de' => [
'desc' => 'PayPal - später bezahlen',
'longdesc' => '',
'longdesc_beta' => 'Kaufen Sie jetzt und bezahlen sie später mit PayPal.'
],
'en' => [
'desc' => 'PayPal- pay later',
'longdesc' => '',
'longdesc_beta' => 'Buy now and pay later with PayPal.'
]
],
Da scheint noch longdesc unbefüllt, aber longdesc_beta dafür befüllt.
@indianer3c: Wegen der Icons: PayPal macht da ja einen Spagat, indem es jetzt die neuen Zahlarten GiroPay, Sofort usw. anbietet. Es fällt PayPals Marketingabteilung etwas schwer Icons für andere Paymenter bereitzustellen. Du weißt, was ich meine Da man nicht für alle Payments Icons anbieten kann, hat man sich entschlossen, keine bereit zu stellen und es den Merchants zu überlassen. Du kannst Dich aber gern hier bedienen: PayPal Verified Logos, Icons, Images - PayPal Logo Center
Wegen der Texte: PayPals Marketingabteilung hat sich etwas schwer getan, aussagekräftige Marketingtexte für “End-Kunden” bereitzustellen. Es gibt Texte für Merchants (die werden aber nicht auf der Checkout-Seite angesprochen, sondern Kunden), allerdings auch nicht wieder für alle Payments . Auch hier dann die Entscheidung, lieber gar nichts als halbes oder falsches. Die ungenutzen “beta”-Texte im Modul sind also für den Moment vorgesehen, wenn da Vernunft und Ratio zu Entscheidungen führen …
Aber ganz wichtig folgender Punkt Deiner Frage: Die PayPal-Buttons gelten gerade für “nicht eingeloggte” Kunden (also für ALLE Kunden). Mit Hilfe der Buttons kann ein Kunde auch ohne Anmeldung im OXID-Shop einkaufen. Wenn die PayPal-E-Mail-Adresse sogar mit einem Kundenkonto des Shops übereinstimmt und im Backend der Haken gesetzt ist für “Login mit PayPal”, dann kann man sich sogar mit PayPal im Shop einloggen. Bitte prüfe das noch einmal in Deinem Theme. Die Bedingungen für die Anzeige des Buttons lauten: !$oDetailsProduct->isNotBuyable() - Artikel für Warenkorb erlaubt $config->isActive() - PayPal Config ist Ok !$oViewConf->isPayPalExpressSessionActive() - Es läuft nicht schon eine PayPalExpress-Session $config->showPayPalProductDetailsButton() - Button soll auf der Detailseite gezeigt werden
Schade mit den fehlenden Icons/Bilder und Beschreibungen.
Mit den Buttons ist mir schon klar, dass sich dies auf alle Kunden bezieht egal ob Gast, eingeloggt oder nicht-eingeloggt. Aber als nicht-eingeloggter Kunde stellt ein Button im Checkout wo er sich einloggen soll bzw. Gast oder Registrierung vornehmen soll ein Vorteil in der Benutzerfreundlichkeit dar. Da an dieser Stelle nachdem auf Produktdetailseite und Warenkorb noch nicht den Button genutzt hat dort nochmal die Chance bekommt einen Button zu nutzen um nicht alle Adressdaten von Hand eingeben zu müssen. Dieser Vorteil entfällt leider.
Beispiel alte Frontend Integration in Euren Demoshop
@Mario_Lorenz,
mir ist da auch noch etwas aufgefallen.
Bei mehreren Kunden gab es Bestellabbrüche von Paypal, hier ein Beispiel mit Kreditkarte. So ein ‘ERROR’ erschreckt die Kundschaft gewaltig! Ich habe mal in den Sprachdateien nachgeschaut, OSC_PAYPAL_STATUS_CREATED ist vorhanden.
Zu den Logos habe ich noch folgende Quellen entdeckt, wobei PayPal die Vorstellung hat dies über ein JavaScript SDK einzuladen… Aus Datenschutzgründen das suboptimal, weil für das externe SDK Skript und die Kommunikation nach Außen um das jeweilige Logo zu holen bräuchte man jedesmal die Einverständnis seitens DSGVO Gedanke. Die Links:
Ich habe die Modul Version 1.0 für 6.1 im Testsystem mit Livedaten per onBoarden installiert.
Im Backend wird angezeigt:
Freischaltung für besondere Zahlarten erfolgt:
Rechnungskauf: ja
Kreditkarte: ja
Während des onboarden bekomme ich Email von Paypal das “Antrag auf erweiterte Kredit- und Debitkartenzahlungen genehmigt wurden”. Rechnungskauf biete ich aktuell im Liveshop bereits an.
Im Frontend sieht es leider wiefolgt aus: Paypal funktioniert Kreditkarte leitet nur auf Homepage und leert Warenkorb Giropay leitet um auf Homepage und leert Warenkorb Später mit PayPal bezahlen funktioniert Rechnungskauf geht nicht und es kommt die Meldung “Die von Ihnen gewählte Versandart ist nicht mehr verfügbar. Bitte wählen Sie eine andere Versandart aus!” Sofort funktioniert
Hat das Modul schon jmd. bei Version 6.1 am laufen? Kann ich irgendwas prüfen wo der Fehler liegt?
ich hab da einmal eine Frage, ein Kunde möchte SEPA auch darüber laufen lassen.
Aus welchem Grund ist SEPA nicht integriert?
Laut PP Support wäre es freigeschaltet.
Danke für den Tipp, ich kann ja in der Testumgebung einfach auf Standardtheme zum Test umschalten aber das funktioniert weder bei Flow noch Wave, daran wird es eher nicht liegen.
… -
