Hallo miteinander, Ich habe folgendes Problem: Wenn ich PAYONE in den PlugIns lade, gibt es lediglich eine globale Einstellung zum aktivieren / deaktivieren. Unter Grundeinstellungen / Zahlarten gibt es keine weiteren Einstellungen. Unter Kunden / Zahlungen / PAYONE / Konfiguration kann ich die notwendigen Einstellungen vornehmen, allerdings nur global oder für einzelne Zahlarten, NICHT aber für die einzelnen Shops / Subshops. (Wir möchten domain.de in deutsch und domain.com als Subshop in englisch laufen lassen) Bei PAYONE gibt es aber pro Domain (jeweils für .de und .com) ein “Zahlungsportal”, mit jeweils eigenem KEY und PORTAL-ID. Ich müsste also, wenn ich es richtig sehe, für den Subhop mit eigener Domain, andere Angaben zu KEY und PORTAL-ID eingeben. Was jetzt? Wie richte ich das zweite PAYONE Zahlungsportal für meinen Subshop ein?? … der Support von Shopware kann nicht helfen, bzw. verweist an den Hersteller der Schnittstelle. Besten Dank für jeden Hinweis! Beste Grüße, Markus
Hallo, es ist bei fast allen Schnittstelle so, dass jeweils ein globales Projekt hinterlegt wird. Die Subshops greifen dann jeweils auf ein Projekt zu. (Das war z.B. auch bei Paypal bis zum letzten Update der Fall) Es gibt also vereinzelt Schnittstellen, die abweichende Einstellungen erlauben bzw. unterstützen. Soweit ich das jetzt sehen konnte, ist bei PAYONE eine globale Einstellung vorhanden. In dem Fall kann man dann keine abweichenden Projekte hinterlegen und Haupt- sowie Subshops greifen auf ein Projekt zu. Sebastian
… dann haben wir 500.- € für eine Subshop-Lizenz ausgegeben, die wir nicht benutzen können, weil die Schnittstelle zu PAYONE nicht Subshop - kompatibel ist. Mit PAYONE hatten wir bereits Verträge gemacht, wir hatten uns deswegen für diesen Dienstleister entschieden, weil die Schnittstelle in Shopware bereits zur Installation vorbereitet ist UND das Plug-In im Plugin-Manager als Shopware-eigenes Plug-In aufgeführt wird, und NICHT unter den Community Plug-Ins… Shopware sollte deutlich vor dieser Problematik warnen, und zwar vor dem Erwerb von Subshop-Lizenzen und vor der Verwendung des PAYONE Plug-Ins. Ich hoffe, das Problem bleibt anderen erspart! Gibt es technisch betrachtet die Möglichkeit, ein Plug-In zweimal zu installieren… und dann in diesem Fall PAYONE 1 für den Hauptshop und PAYONE 2 für den Subshop zu verwenden?? Das wäre ja eine Art Behelf… Bin für jede Idee dankbar!
Hallo, es sollte möglich sein, das Plugin so zu ändern, das es under einem veränderten Namen und abgewandelten Daten/Variablen/Funktionsnamen sich ein zweites mal installieren lässt. Diesen Plugin ist dann aber nicht mehr updatefähig, und alle Änderungen am Ur-Plugin müssten bei einem Update wieder manuell übernommen werden…
Wir möchten auch einen Subshop einrichten mit anderer europäischer Domain und Sprache. Zusätzlich wollten wir eigentlich in Kürze auch einen Vertrag bei payone unterschreiben. Sehe ich das richtig, dass man damit z.B. keine Möglichkeit hat, im Checkoutprozess die über payone angebotenen Zahlungsarten und andere Optionen für jeden Shop einzeln festzulegen bzw. auch unterschiedliche Sprachversionen anzuzeigen? Benötigt man 2 untersch. Zugänge bei payone für 2 Shopware-Shops (Hauptshop und ein lokalisierter Subshop)? Ich dachte, das funktioniert alles mit einem Plugin und einer Adminoberfläche bei payone? Was heißt „Haupt- sowie Subshops greifen auf ein Projekt zu“ konkret? Danke und viele Grüße Gabriel
Ich weiß nicht wie das Plugin für die Shopwareversion 4 aussieht. Für Version 3.5 mussten wir es seinerzeit hinsichtlich der Subshopunterstützung jedenfalls selbst erweitern. Das galt u.a. auch für Kleinigkeit wie die Übermittlung der richtigen Sprache und Erweiterung um entsprechende ISO-Codes für Bundesstaaten (USA, Kanada), Einschränkung der „Subpayments“ nach Ländern (die Maske gab’s schon, wurde nur nie frontendseitig berücksichtigt), etc. Für jeden echten Subshop (also Domain) benötigt man wohl ein eigenes Zahlungsportal. Das hängt wohl maßgeblich mit den Kreditkarteninstituten zusammen, wenn ich mich recht erinnere. Technisch gesehen funktionierte es allerdings auch über ein einzelnes Zahlungsportal reibungslos… wurde aber seitens PayOne bzw. der Kreditkarteninstitute (ich weiß es leider nicht mehr) nicht gerne gesehen, woraufhin wir es „bei Zeiten“ dann mal ändern sollten. Haben wir für die 3.5er Version gemacht. Wie es bei der 4er aussieht, wie gesagt, keine Ahnung.
[quote=„Sebastian Klöpper“]Hallo, es ist bei fast allen Schnittstelle so, dass jeweils ein globales Projekt hinterlegt wird. Die Subshops greifen dann jeweils auf ein Projekt zu. (Das war z.B. auch bei Paypal bis zum letzten Update der Fall) Es gibt also vereinzelt Schnittstellen, die abweichende Einstellungen erlauben bzw. unterstützen. Soweit ich das jetzt sehen konnte, ist bei PAYONE eine globale Einstellung vorhanden. In dem Fall kann man dann keine abweichenden Projekte hinterlegen und Haupt- sowie Subshops greifen auf ein Projekt zu. Sebastian[/quote] Fakt ist, dass payone derzeit für Shopware kein subshop-fähiges Plugin anbietet. Es steht auf der Agenda, aber ob und wann dies umgesetzt werden wird ist unbekannt. Die wichtige Frage lautet: Gibt es seitens Shopware überhaupt die Möglichkeit hinsichtlich der Plugin-Architektur, dass ein Payment-Provider ein subshop-fähiges Plugin anbieten kann? Und falls ja, welche Payment-Provider gibt es, die ein 100% subshop-fähiges Plugin anbieten? Die Schnittstelle von payone beispielsweise für Magento lässt sich laut technischem Support von payone für Subshops konfigurieren, d.h. jedem Subshop mit eigener URL kann die ID und Passwort etc. eines separaten Zahlungsportals zugeordnet werden. Ob dies nun an der Shopsoftware liegt oder am Plugin Entwickler weiß ich nicht - hier könnte aber Shopware Aufklärung anbieten. Laut meiner Information benötigt man zwingend für jede URL einen separaten Akzeptanzvertrag (dies ist wohl vom kreditkartenausgebenen Institut vorgeschrieben) und somit ein eigenes Zahlungsportal bei z.B. payone. Ein Subshop mit separater URL in Shopware macht also grundsätzlich nur Sinn, wenn es auch Plugins von Zahlungsprovidern dafür gibt - wenn diese Möglichkeit von vorneherein ausgeschlossen ist, macht ein Subshop doch gar keinen Sinn, oder liege ich falsch?
[quote]Ob dies nun an der Shopsoftware liegt oder am Plugin Entwickler weiß ich nicht[/quote] Es liegt am Pluginentwickler, bzw. vielleicht auch zum Teil an PayOne, die ihre Anforderungen dem Pluginentwickler gegenüber nicht deutlich genug gemacht haben und bei der Abnahme/QA wurde es dann auch “übersehen”. Wo jetzt wer was genau verbockt hat, keine Ahnung… spielt ja auch eigentlich keine Rolle. Wie ich vorher bereits schrieb, haben wir das für Version 3.5 seinerzeit erfolgreich nachgerüstet. Es ist also technisch grundsätzlich kein Problem.
Bei einer telefonischen Anfrage sagte mir ein Entwickler von Heidelpay, dass deren Lösung Subshop fähig sei – Ich habe das aber nicht ausprobiert. Meiner Meinung nach wäre es eine gute Idee, bei allen PlugIns grundsätzlich anzugeben, ob sie Subshop fähig sind. Das erspart möglicherweise so manchen Ärger. Gruß Markus
Hallo Zusammen, wir prüfen die Umsetzung dieses Features gerade mit unserer Agentur mediaopt. Gerne posten wir hier wann in etwa mit einer Fertigstellung zu rechnen ist. Bei weiteren Wünschen zu neuen Features schreibt doch bitte direkt eben an shopware@payone.de. Dann wird das gerne immer asap geprüft. Wir freuen uns immer sehr über solche Anregungen, weil diese dann aus der Praxis für die Praxis kommen :-)! Viele Grüße vom PAYONE - Team
Hallo liebe Community, die Funktionalität ist von uns bei unserer Agentur mediaopt beauftragt und wird voraussichtlich bis Ende November fertig sein. Bei Fragen stehen wir unter shopware@payone.de gerne zur Verfügung! Viele Grüße vom PAYONE-Team
Das hört sich gut an! Payone (mit Plugin 2.0.5) läuft mittlerweile übrigens bei uns auf einem Testsystem mit Shopware 4.1.2 einwandfrei. Bisher klare Empfehlung für das System , dass nicht zuletzt aufgrund guter Erreichbarkeit und unkomplizierte Unterstützung durch den Support, bessere Integration in den Warenkorbprozess, umfangreiche Plugin-Einstellungen und Log-Files / Auswertungen und vor allem zukünftige Skalierbarkeit unseren bisherigen Payment Provider Skrill ablösen wird.