Entwicklung von Zahlungs-Gateways #

Diese Seite ist für Entwickler, die einen Exponential-Shop an einen Zahlungsanbieter anbinden, für den es keine Erweiterung gibt. Das Repository liefert die Basisklassen und zwei vollständige Beispiele mit, ezpaypal (Weiterleitung) und ezauthorize (transparent). Diese Seite beschreibt, wie sie aufgebaut sind, damit Sie das nächste bauen können.

Inhalt #

1. Weiterleitung oder transparent
2. Die Dateien der Erweiterung
3. Die Gateway-Klasse
4. Der Callback
5. Einstellungen, die die Erweiterung ergänzt
6. Sicherheitsregeln
7. Testplan

Weiterleitung oder transparent #

Bevorzugen Sie eine Weiterleitung oder eine vom Anbieter gehostete Zahlungsseite, wenn der Anbieter eine anbietet.

Die Dateien der Erweiterung #

Nach dem Vorbild von extension/ezpaypal/:

extension/mypay/
  classes/mypaygateway.php        the gateway; loaded automatically for an active extension
  classes/mypaychecker.php        the callback checker (extends eZPaymentCallbackChecker)
  modules/mypay/module.php        a module with one view for the provider's callback
  modules/mypay/notify.php
  settings/module.ini.append      ModuleList[]=mypay, ExtensionRepositories[]=mypay
  settings/site.ini.append        AllowedRedirectHosts[], PolicyOmitList[]=mypay/notify
  settings/mypay.ini              provider settings without secrets

Der Dateiname des Gateways muss classes/<extension>gateway.php sein, damit es automatisch geladen wird (paymentgateways.ini durchgegangen).

Die Gateway-Klasse #

Für ein Gateway mit Weiterleitung erweitern Sie eZRedirectGateway (kernel/shop/classes/ezredirectgateway.php) und implementieren:

Den Rest erledigt die Basisklasse: Beim ersten Durchlauf speichert sie das Zahlungsobjekt und leitet weiter; beim zweiten akzeptiert sie, wenn das Zahlungsobjekt genehmigt ist, und lehnt sonst ab; cleanup() entfernt abgebrochene Zahlungsobjekte. Am Ende der Datei:

eZPaymentGatewayType::registerGateway( 'mypay', 'mypaygateway', 'My provider' );

Für ein transparentes Gateway erweitern Sie eZPaymentGateway und implementieren execute( $process, $event ), das eZWorkflowType::STATUS_ACCEPTED oder STATUS_REJECTED zurückgibt oder ein Template, um ein Formular anzuzeigen (STATUS_FETCH_TEMPLATE_REPEAT). createShortDescription( $order, $maxDescLen ) der Basisklasse liefert eine auf die Grenze des Anbieters gekürzte Bestellbeschreibung.

Der RAD-Handler-Assistent hat Rezepte für beide Arten und schreibt ein Gerüst mit Kommentaren zu jeder Methode (Pfad für Entwickler); vergleichen Sie seine Ausgabe mit den oben genannten Ladepfaden, bevor Sie sich darauf verlassen.

Der Callback #

Die Callback-View empfängt die Nachricht des Anbieters und sollte mit einem Prüfer, der eZPaymentCallbackChecker (kernel/shop/classes/ezpaymentcallbackchecker.php) erweitert:

1. Die Nachricht lesen (createDataFromPOST() oder createDataFromGET()).
2. Sie beim Anbieter validieren (requestValidation()) und, wo der Anbieter seine Adressen dokumentiert, checkServerIP().
3. Bestellung und Zahlungsobjekt laden (setupOrderAndPaymentObject()).
4. Betrag und Währung mit der Bestellung abgleichen (checkAmount(), checkCurrency()).
5. Genehmigen und den Workflow fortsetzen (approvePayment()), was den Rest der Kasse ausführt: Aktivierung und die Bestellmail.
6. Optional einen Bestellstatus setzen, wie es ezpaypal mit PaymentMadeOrderStatusID tut.

Antworten Sie dem Anbieter schnell; der Browser des Kunden wartet währenddessen auf shop/checkout, das bis zu 25 Sekunden lang abfragt (Die Kassenoperationen Schritt für Schritt).

Einstellungen, die die Erweiterung ergänzt #

Sicherheitsregeln #

• Vertrauen Sie nie der Rückkehr des Kunden auf Ihre Website als Zahlungsnachweis; nur der validierte Callback genehmigt.
• Prüfen Sie Betrag und Währung bei jedem Callback; lehnen Sie eine Abweichung ab.
• Schreiben Sie Kartennummern oder Sicherheitscodes nie in Logs, die Datenbank oder das Audit-Protokoll. Das Audit des Kernels erfasst Zahlungen ohne Kartendaten, und Ihr Code muss es ebenso halten.
• Behalten Sie den Schalter für den Testmodus und machen Sie in der Administration deutlich, welcher Modus aktiv ist.
• Siehe Sicherheit für Anwendungen und Formulare, CSRF und HTTP-Eingaben.

Testplan #

• To do: Das Gateway erscheint in der Liste des Ereignisses Zahlungs-Gateway.
• To do: Eine erfolgreiche Zahlung im Testmodus: Bestellung aufgegeben, Nummer vergeben, Mail versendet, Status gesetzt.
• To do: Eine abgebrochene Zahlung: keine aufgegebene Bestellung, Warenkorb intakt, der Kunde kann es erneut versuchen.
• To do: Ein Callback mit falschem Betrag: abgelehnt, ohne Kartendaten protokolliert.
• To do: Ein wiederholter Callback: keine zweite Aktivierung.
• To do: Ein später Callback (nach den 25 Sekunden): Die Bestellung wird trotzdem aktiviert, der Kunde findet sie in der Bestellliste.
• To do: Die Anleitung des Kernels in doc/eng-us/shop/examples/paypal/ mit Ihrem Code verglichen.

Verwandte Seiten #

• Den Shop erweitern
• Das Ereignis Zahlungs-Gateway
• Einen Workflow-Ereignistyp schreiben
• Freie Dokumentation: diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.