Payment Module

ShopFusion unterstützt verschiedene Module von Zahlungsanbietern. Darüber hinaus gibt es aber noch Module von unterschiedlichen Herstellern, die nur in verschlüsselter Form erhältlich sind. Bei diesen Modulen sind wir auf die Mithilfe der Modulhersteller angewiesen, damit diese die Kompatibilität zu ShopFusion herstellen.

Trotzdem können Sie auch bisher nicht offiziell unterstützte Module einsetzen. Wie die Vorgehensweise dabei ist, wie Sie Ihren Fall testen können und wie Sie dabei mithelfen können, dass Ihr eingesetztes Modul zukünftig auch offiziell ShopFusion unterstützt, finden Sie im nachfolgenden Text beschrieben.

Offiziell unterstützte Payment Module

Magento
Standard PayPal Modul1)
Vorkasse
Kreditkarten Zahlung (Datenspeicherung)
Null-Zwischensumme Bezahlvorgang
Scheck / Zahlungsanweisung
Abruf aus Auftrag
Symmetrics Rechnung

OXID eShop
PayPal - 6vC-PayPal-Basic2)
Bankeinzug/Lastschrift
Kreditkarte
Nachname
Rechnung
Vorauskasse

Weitere Magento und OXID Module befinden sich im Test und werden sukzessiv hinzugefügt. Wenn Sie ein Modul vermissen, das Sie aber gern einsetzen möchten, dann sprechen Sie uns einfach an oder bestellen Sie unverbindlich eine kostenlose Testlizenz und probieren die Lösung aus.

Andere Module verwenden

Sollten Sie ein Modul einsetzen wollen, welches ShopFusion noch nicht unterstützt, dann stehen Ihre Chancen sehr gut, mit minimalem Aufwand, das Modul trotzdem erfolgreich einzusetzen.
Bevor Sie sich den alternativen Lösungsweg anschauen, bitten wir Sie jedoch, einmal bei dem Hersteller ihres Moduls nachzufragen, ob dieser bereits ShopFusion unterstützt oder ob er die Unterstützung von ShopFusion implementieren würde. Schicken Sie ihm am Besten auch einen Link, auf die notwendigen Modulanpassungen, um ShopFusion zu unterstützen. Diese Anpassungen zu implementieren, dauert für den Hersteller des Moduls nicht länger als 30 Minuten. Vielen Dank!

Wo kann es bei Payment und anderen Modulen haken?

ShopFusion verschmilzt zwei Systeme miteinander. Damit dies gelingt, übernimmt ShopFusion einige Verwaltungsaufgaben. Besondere Aufmerksamkeit liegt dabei auf den URLs, die jedes System generiert. Das TYPO3 generiert URLs, die auf das TYPO3 und der Shop generiert URLs, die auf den Shop verweisen. Bei der Verschmelzung, mit Hilfe von ShopFusion, verschwindet diese Trennung zwischen den beiden Systemen. ShopFusion kümmert sich darum, dass die URLs, die der Shop generiert, auf das TYPO3 verweisen.

Bei Payment Modulen ist jetzt idR. eine spezielle Situation gegeben. Diese Module kontaktieren normalerweise den Zahlungsanbieter direkt, bspw. PayPal. Bei dieser Kontaktaufnahme werden URLs übergeben, auf die der Webseitenbesucher gelangt, sobald er eine Zahlung abbricht3) oder abschließt4). Ggf. wird dem Zahlungsanbieter auch ein URL übermittelt, der aufgerufen werden soll, sobald zusätzliche Informationen zum Bezahlvorgang vorliegen5).

ShopFusion hat auf die Erzeugung dieser URLs keinen einfluß. Viel mehr müssen die Module / Klassen der Hersteller so erweitert / überladen werden, dass die Generierung der URLs korrigiert wird. Für die oben angeführten Module funktioniert dies bereits, weil diese entweder Open Source und damit frei anpassbar sind oder der Hersteller des verschlüsselten Moduls die erforderlichen Anpassungen bereits in sein Modul implementiert hat.

Wie kann ein nicht unterstütztes Modul trotzdem verwendet werden?

Mit dem Hintergrundwissen aus dem vorherigen Abschnitt, ist das Problem, welches diese Module hervorrufen können, klar. Nachdem der Webseitenbesucher den Bezahlvorgang beim Payment Anbieter abgeschlossen oder abgebrochen hat, wird er auf den Shop, statt auf das TYPO3 geleitet. Dieses Dilemma lässt sich aber auf einfache Weise, mit Hilfe enstprechender mod_rewrite Direktiven in einer .htaccess Datei, lösen. Immer wenn der Shop direkt aufgerufen wird, soll der Aufruf auf die TYPO3-Domain umgeleitet werden, es sei denn, es wird versucht auf den Admin-Bereich zuzugreifen.

Legen Sie dazu in das oberste Verzeichnis Ihres Shops6) eine .htaccess Datei mit folgendem Inhalt oder falls bereits eine .htaccess Datei existiert, fügen Sie diese mod_rewrite regeln bitte am Anfang hinzu. Sollte bereits ein Abschnitt für mod_rewrite in Ihrer .htaccess Datei existieren, dann fügen Sie diese zusätzlichen Regeln bitte vor den bestehenden ein. Sollten Sie diese Regeln direkt in Ihre Vhost-Konfiguration einfügen, beachten Sie bitte, dass Sie ggf. Anpassungen vornehmen müssen.

Hinweis
Es kann u.U. notwendig sein, dass Sie die nachstehenden Beispiel um Ausnahmen ergänzen müssen. Es kommt vor, dass der Zahlungsanbieter auf das Magento zugreifen muss, um den Zahlungsvorgang abzuschließen. Diese Aufrufe des Zahlungsanbieters, dürfen nicht umgeleitet werden, weil den Umleitungen aus Sicherheitsgründen nicht gefolgt wird. In den folgenden Beispielen, finden Sie exemplarisch bereits einige auskommentierte Beispielzeilen.
Bitte berücksichtigen Sie auch, dass Sie ggf. weitere Ausnahmeregeln für andere Funktionen (JavaScript, API Zugriffe, etc.), hinzufügen müssen.

Beispiel für OXID eShop

.htaccess
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
 
# RewriteCond %{REMOTE_ADDR} !^123\.123\.123\.123
RewriteCond %{HTTP_COOKIE} !\bsfreq=1\b [NC]
### Heidelpay
# RewriteCond %{THE_REQUEST} !\bHeidelpay\b [NC]
RewriteRule ^$ http://meinecmsdomain.tld/shop-seite.html [R=307,L]
 
#RewriteCond %{REMOTE_ADDR} !^123\.123\.123\.123
RewriteCond %{HTTP_COOKIE} !\bsfreq=1\b [NC]
RewriteCond %{REQUEST_URI} !\badmin\b
### Heidelpay
# RewriteCond %{THE_REQUEST} !\bHeidelpay\b [NC]
RewriteCond %{REQUEST_FILENAME} !oxseo\.php
RewriteRule ^(.+)$ http://meinecmsdomain.tld/shop-seite/$1 [R=307,L]
# RewriteRule ^(.*)$ http://meinecmsdomain.tld/shop-seite/$1 [R=307,L]
</IfModule>

Beispiel für Magento

.htaccess
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
 
# RewriteCond %{REMOTE_ADDR} !^123\.123\.123\.123
RewriteCond %{HTTP_COOKIE} !\bsfreq=1\b [NC]
### Payone
# RewriteCond %{THE_REQUEST} !\bpayone\b [NC]
# RewriteCond %{THE_REQUEST} !\bpayone_core\b [NC]
RewriteRule ^$ https://meinecmsdomain.tld/shop-seite.html [R=307,L]
 
# RewriteCond %{REMOTE_ADDR} !^123\.123\.123\.123
RewriteCond %{HTTP_COOKIE} !\bsfreq=1\b [NC]
RewriteCond %{THE_REQUEST} !\badmin\b [NC]
### Payone
# RewriteCond %{THE_REQUEST} !\bpayone\b [NC]
# RewriteCond %{THE_REQUEST} !\bpayone_core\b [NC]
RewriteCond %{REQUEST_URI} !^/(media|skin|js)/
RewriteRule ^(.+)$ https://meinecmsdomain.tld/shop-seite/$1 [R=307,L]
# RewriteRule ^(.*)$ https://meinecmsdomain.tld/shop-seite/$1 [R=307,L]
</IfModule>

Erklärung
Im Wesentlichen ist die Magento- und die OXID-Version identisch. Nachfolgende finden Sie die Erklärung anhand des Magento Beispiels, für OXID funktioniert es aber analog.
Den ersten Block:

# RewriteCond %{REMOTE_ADDR} !^123\.123\.123\.123
RewriteCond %{HTTP_COOKIE} !\bsfreq=1\b [NC]
RewriteRule ^$ https://meinecmsdomain.tld/shop-seite.html [R=307,L]

Benötigen Sie nur dann, wenn Ihre sprechende URL Konfiguration im CMS Dateierweiterungen an die URLs anfügt. Enden Ihre CMS URLs auf „/“, können Sie diesen Block deaktivieren.

Den zweiten Block:

# RewriteCond %{REMOTE_ADDR} !^123\.123\.123\.123
RewriteCond %{HTTP_COOKIE} !\bsfreq=1\b [NC]
RewriteCond %{THE_REQUEST} !\badmin\b [NC]
RewriteCond %{REQUEST_URI} !^/(media|skin|js)/
RewriteRule ^(.+)$ https://meinecmsdomain.tld/shop-seite/$1 [R=307,L]
# RewriteRule ^(.*)$ https://meinecmsdomain.tld/shop-seite/$1 [R=307,L]

Benötigen Sie in jeden Fall. Sollten Sie den ersten Block deaktiviert haben, müssen Sie die letzte Zeile des zweiten Block aktivieren und die vorletzte deaktivieren. Das sähe dann also so aus:

# RewriteCond %{REMOTE_ADDR} !^123\.123\.123\.123
RewriteCond %{HTTP_COOKIE} !\bsfreq=1\b [NC]
RewriteCond %{THE_REQUEST} !\badmin\b [NC]
RewriteCond %{REQUEST_URI} !^/(media|skin|js)/
# RewriteRule ^(.+)$ https://meinecmsdomain.tld/shop-seite/$1 [R=307,L]
RewriteRule ^(.*)$ https://meinecmsdomain.tld/shop-seite/$1 [R=307,L]

Ersetzen Sie in allen Blöcken den Platzhalter meinecmsdomain.tld durch die Domains, auf der Ihr CMS läuft, shop-seite.html durch den pfad und der richtigen Dateierweiterung, zu einer TYPO3 Seite, auf die weitergeleitet werden soll, wenn die Startseite des Shops Aufgerufen wird und shop-seite7) durch den Pfad zu einer TYPO3 Shop-Seite.

Bedeutung der einzelen Zeilen

# RewriteCond %{REMOTE_ADDR} !^123\.123\.123\.123
RewriteCond %{HTTP_COOKIE} !\bsfreq=1\b [NC]

Diese Zeilen sind dafür verantwortlich, dass ShopFusion weiterhin auf den Shop per HTTP zugreifen kann. Sie können entweder die IP-Adresse des TYPO3s freischalten (1. Zeile) oder HTTP-Requests zulassen, die das Cookie sfreq=1 senden (2. Zeile). Nur eine der beiden Zeilen sollte aktiviert sein. Wenn Sie die erste Zeile aktivieren, ersetzen Sie bitte die IP-Adresse entsprechend.

RewriteRule ^$ https://meinecmsdomain.tld/shop-seite.html [R=307,L]

Beim Aufruf der Shop-Startseite, auf den angegebenen URL mit dem Redirect-Code 307 Umleiten.

RewriteCond %{THE_REQUEST} !\badmin\b [NC]
RewriteCond %{REQUEST_URI} !^/(media|skin|js)/

Zugriff auf den Shop-Admin-Bereich und die Verzeichnisse media, skin und js erlauben. Bei OXID wird der Inhalt von %{REQUEST_URI} statt %{THE_REQUEST} getestet, der Effekt ist der selbe.

RewriteRule ^(.+)$ https://meinecmsdomain.tld/shop-seite/$1 [R=307,L]
# RewriteRule ^(.*)$ https://meinecmsdomain.tld/shop-seite/$1 [R=307,L]

Wird eine Shopunterseite aufgerufen, auf den Angegebenen URL weiterleiten und die Unterseiten mit übergeben. Die auskommentierte Zeile erledigt das gleiche, mit dem Unterschied, dass sie auch dann greift, wenn die Startseite des Shops, also keine Unterseitem, aufgerufen wird.

RewriteCond %{REQUEST_FILENAME} !oxseo\.php

Diese Zeile bewirkt, dass im OXID Adminbereich, die Warnung verschwindet, dass der Shop sich ungewöhnlich verhalten würde.

1) Paypal Express Checkout, Website Payments Standard, Website Payments Pro
3) cancel_url
4) success_url
5) notify_url
6) document_root
7) im 2. Block ohne Dateierweiterung
Drucken/exportieren
QR-Code
QR-Code shopfusion:tipps_und_tricks:payment_module (erstellt für aktuelle Seite)