Technischer Beitrag
Einstieg in die Payment-Gateway-Integration
Eine Zahlungs-App zum Laufen zu bringen bedeutet, mindestens zwei verschiedene Arten der Integration beherrschen zu müssen: Zunächst müssen Sie wissen, wie Sie die erforderliche Hardware integrieren (d. h. das Kartenlesegerät samt dem Gerät, an das es angeschlossen ist). Anschließend müssen Sie wissen, wie Sie die Integration mit einem Zahlungs-„Backend" vornehmen, beispielsweise einem Online-Zahlungsgateway – also der Instanz, die die Transaktion „genehmigt" und zur Abrechnung verarbeitet.
Im früheren Beiträgenhabe ich ausführlich über den Hardware-Integrationsteil dieses Puzzles gesprochen, der sich als gar nicht so schwierig erweist – denn bei ID TECH Kartenlesern können Sie unseren Universal SDK verwenden, um mit den Geräten aus einer High-Level-Sprachumgebung heraus zu kommunizieren. Alternativ können Sie auch eine reine JavaScript-Lösung umsetzen, sofern Sie bereit sind, Node JS in Ihre Architektur einzubinden. In jedem Fall ist die Kommunikation mit ID TECH Geräten kein besonders großes Thema.
Dennoch bleibt die Frage: Wie wandeln Sie die vom Kreditkartenleser ausgelesenen Chip- oder Magnetstreifendaten in eine genehmigte Transaktion um?
Vermutlich wissen Sie bereits, welcher Kreditkartenverarbeiter Ihre Anfragen übernehmen wird. Das eigentliche Problem besteht daher darin herauszufinden, welche Art von SDK-Unterstützung Ihr Verarbeiter oder Ihr Gateway für die Abwicklung von Online-Anfragen bietet.
Die meisten Gateways oder Verarbeiter verfügen über ein Entwicklerprogramm oder ein Online-Entwicklerportal, über das Sie SDKs für die Entwicklung von Zahlungs-Apps beziehen können. Mit diesen SDKs lassen sich in der Regel Frontend- und Backend-Komponenten kombinieren, um auf die Zahlungs-APIs des Verarbeiters zuzugreifen. Die Zahlungs-APIs unterstützen ihrerseits die Übertragung von MagStripe-Daten und/oder ICC-Daten (Chipkartendaten) über das Netzwerk an einen Backend-Verarbeiter, um eine Echtzeit-Autorisierung zu erhalten.
Die Zahlungsautorisierung ist jedoch nur eine von mehreren Online-Anfragetypen, die Sie voraussichtlich unterstützen müssen. Einige der weiteren Anfragetypen sind in der nachstehenden Tabelle aufgeführt.
Anfragetyp
Beschreibung
Auth
Zahlungsautorisierung anfordern
Conf
Eine vorherige Autorisierungsanforderung bestätigen
Offline
Eine Offline-EMV-Transaktion abrechnen
PreAuth
Kartendaten mit einem kleinen Transaktionsbetrag auf Gültigkeit prüfen
Refund
Eine bereits abgerechnete Transaktion erstatten
Test
Verbindung zum Zahlungsabwickler testen
VoiceReferralNotification
Den Prozessor über das Ergebnis einer telefonischen Autorisierungsanfrage informieren
Stornierung
Wird verwendet, um eine noch nicht abgerechnete Transaktion zu stornieren
Wenn Sie die SDK-Dokumentation Ihres Zahlungsabwicklers studieren, werden Sie feststellen, dass für jeden Transaktionstyp eine Vielzahl unterschiedlicher Ergebnis- und/oder Fehlercodes gilt. Wie testen Sie alle diese möglichen Fehlertypen? Die Antwort: Bei den meisten Prozessoren gibt es ein Schema, bei dem der Centbetrag einer Transaktion auf einen speziellen Wert gesetzt werden kann, um in einer Test-Sandbox-Umgebung einen bestimmten Fehler auszulösen. (Wenn beispielsweise der Fehlercode für „Betrag zu hoch" 1243 lautet, können Sie mit dem SDK diesen spezifischen Fehler auslösen, indem Sie eine Testtransaktion über 12,43 $ einreichen.) Details entnehmen Sie der SDK-Dokumentation Ihres Anbieters.
Viele Zahlungsabwickler bieten vorzertifizierte (halb-integrierte) „In-App"-Lösungen an, mit denen Sie verschlüsselte Kartendaten mehr oder weniger transparent direkt an das Backend weiterleiten können – und Ihre Zahlungs-App damit außerhalb des PCI-Geltungsbereichs halten. Andere hingegen setzen voraus, dass Sie die Fragen des Geltungsbereichs selbst übernehmen. In diesem Fall übertragen Sie verschlüsselte Kartendaten wahrscheinlich über das Netzwerk an Ihre eigene Server-Anwendung hinter einer Firewall, wo Sie die Kartendaten – mithilfe eines HSM – entschlüsseln, bevor Sie sie an einen Acquirer oder ein Gateway weiterleiten.
EIN BEISPIEL
Genug der abstrakten Übersicht. Lassen Sie uns darüber sprechen, was es in der Praxis bedeutet, eine Integration mit einem Zahlungs-Backend durchzuführen.
Dieses konkrete Beispiel gilt selbstverständlich nicht für alle Fälle – kein einzelnes Beispiel kann das –, es sollte Ihnen jedoch einen Eindruck davon vermitteln, was Sie bei der Integration mit einem Backend wahrscheinlich erwartet.
In diesem Fall bestand meine Aufgabe darin, eine Demo-App für ein „virtuelles Terminal" zu entwickeln, die Transaktionsdaten an den CreditCall Testserver sendet, um eine Echtzeitautorisierung für EMV-Transaktionen zu erhalten. CreditCall verfügt über ein Backend-Server-API, auf das per HTTPS über deren ChipDNA Direct API, gegen die wiederum mithilfe eines SDK in Java, C++, Perl oder anderen Sprachen entwickelt werden kann. Ich entschied mich für die Java-Version.
Auf der ChipDNA Direct -Website registrierte ich ein Entwicklerkonto und erhielt umgehend per E-Mail die Zugangsdaten für den CreditCall-Testserver. Außerdem lud ich das Java-SDK von CreditCall herunter und begann, mir den Beispielcode anzusehen. Mein Ziel war es insbesondere, zu verstehen, wie EMV-Transaktionen zur Autorisierung eingereicht werden. Glücklicherweise zeigte eine der Beispielcode-Dateien, ExampleAuthEMV.java, genau die Art von Code, die ich benötigte.
Ich machte mich daran, zwei Java-Klassen zu schreiben: eine Servlet-Klasse zur Verarbeitung von HTTP-Anfragen aus einem browserbasierten Frontend sowie eine „Worker"-Klasse, die die vom Servlet erfassten Browser-Daten an das CreditCall-Backend übermittelt. Erstere umfasste am Ende rund 250 Zeilen Java-Code, letztere 92 Zeilen.
Den Code für die Servlet-Klasse werde ich hier nicht zeigen, da es sich dabei weitgehend um Standard-Java-Servlet-Code handelt – mit dem Unterschied, dass er TLV-Werte (die per AJAX als Formularfeldwerte übermittelt werden) zur Laufzeit in ein java.util.Hashtable-Objekt einliest. Diese Hashtable wird anschließend an die statische Methode authorize() meiner Worker-Klasse übergeben. Die Worker-Klasse nutzt die SDK-Hilfsklassen (Bibliotheksklassen) von CreditCall ChipDNA Direct, um ein com.creditcall.Request-Objekt zu erstellen, das dann an ein Client-Objekt übergeben wird, welches seinerseits den CreditCall-Server aufruft. Hier ist der Code:
Dieser Code ist so knapp und selbsterklärend, dass er kaum weiterer Erläuterung bedarf. Das Praktische daran ist, dass die CreditCall-Klassen Request und Client die Erstellung der XML-Dokumente übernehmen, die letztlich an den CreditCall-Server gesendet werden. Als Entwickler müssen Sie sich zu keinem Zeitpunkt selbst mit rohem XML befassen, es parsen oder sich darum sorgen – ganz so, wie es sein sollte.
Beachten Sie, dass Sie in den Zeilen 18 und 19 Ihre Testkonto-Zugangsdaten angeben müssen. (Die oben gezeigten Zugangsdaten sind fiktiv. Verwenden Sie den Code bitte nicht unverändert!) In Zeile 69 legen Sie die URL des CreditCall-Endpunkts fest. Zeile 72 führt den eigentlichen ausgehenden HTTPS-Aufruf aus.
Der CreditCall-Server ist hinsichtlich der übermittelten TLV-Tags nicht besonders anspruchsvoll, solange die Tags mit den wesentlichen Kartendaten enthalten sind (beispielsweise die Tags 5A und 57 für kontaktbasiertes EMV, Tag 56 für kontaktlos sowie 9F26 und 9F27 mit den Kryptogramm-Informationen). Als Antwort auf Ihre EMV-Daten gibt der CreditCall-Server in der Regel TLVs für die Tags 8A, 89 und 91 zurück sowie optional 71 oder 72, falls Skripte an die Chipkarte übertragen werden müssen. Der gewünschte Autorisierungscode befindet sich in Tag 89.
Durch Ausprobieren habe ich festgestellt, dass die CreditCall-Server-App eine Transaktion nicht ohne Weiteres ablehnt, nur weil die Karte ein AAC-Kryptogramm liefert. (Den Kryptogrammtyp können Sie ermitteln, indem Sie die obersten Bits von Tag 9F27 prüfen. Nullen stehen für AAC bzw. Ablehnung.) Das ist jedoch nicht überraschend, denn die Empfehlung der Karte ist letztlich nur das: eine Empfehlung. Die endgültige Entscheidung über Genehmigung oder Ablehnung einer EMV-Transaktion liegt in der Regel beim Acquirer. Die Vorgabe der Karte kann übergangen werden – und wird es häufig auch.
Wie Sie sehen, lernt man beim Experimentieren mit diesen Themen viele interessante Details über EMV. Wenn es darum geht, den Code einer Zahlungsanwendung zu verifizieren, ist nichts vergleichbar mit einer Live-Autorisierung!
Suchen Sie weitere Informationen zu EMV-Transaktionen? Besuchen Sie unsere Development Home -Seite in der ID TECH Knowledge Base. Laden Sie unser EMV-Entwicklungs-Whitepaperherunter. Oder rufen Sie gebührenfrei einen unserer Experten an, um mit einem Eval-Kit zu starten: