|
|
|
|
|
Beteiligte Komponenten bei SET Transaktionen (Teil 2)
Geschrieben von: Christian Weissengruber Im letzten Artikel, Beteiligte Komponenten bei SET Transaktionen (Teil 1), haben wir das Gateway und das Wallet kennengelernt. Jetzt kommen wir zum "Zentrum" der gesamten SET-Trilogie, dem Point Of Sale, kurz POS genannt. Die Händlersoftware (Payware)Ich werde immer wieder gefragt ob es möglich sei, diesen Teil selber zu programmieren z.B. für eine Linux-Plattform oder sich so die Kosten für die Software zu ersparen. Natürlich ist nichts unmöglich. Nach Hinterlegung einer Anmeldegebühr von US$ 50.000,- steht es jedem frei, eine entsprechende Software zu entwickeln und deren Zertifizierung bei SETCO zu erreichen. Die notwendigen Spezifikationen gibt es bei: http://www.setco.org/download.html Der rein technische Teil umfaßt:
Aber auch wenn man die Software nicht selbst entwickeln will, ist die Lektüre der oben angeführten Dokumente für Integratoren von SET empfehlenswert. Auf jeden Fall benötigt der Händler eine Software: die sogenannte Payware oder POS (Point Of Sale)-Software. Die wichtigsten Lieferanten in Europa dafür sind: Globeset, Trintech, IBM. Eine Matrix über die jeweils angebotenen Produkte, auch anderer Hersteller gibt es ebenfalls bei SETCO. Zusätzlich zu der verwendeten Software benötigt der Händler auch ein Zertifikat des Acquirers. Dieses erhält er im Zusammenhang mit seinem Händlervertrag. Im Normalfall gibt es einen Zusatzvertrag zur Abwicklung von Mail/Telefon-Order und SET-Transaktionen (nur bei Verwendung von zertifizierter Software). POS-Systeme sind virtuelle Point-Of-Sale-Anwendungen, die das Händlersystem sowohl mit dem Kunden-Wallet (elektronische Brieftasche) als auch mit dem Zahlungssystem der Bank (Payment Gateway) verbinden. Sie arbeiten mit allen gängigen SET-konformen Applikationen anderer Hersteller sowie mit populären Shopsystemen zusammen, um die Autorisierung und den Zahlungsverkehr sicher abzuwickeln. Neben den neuen SET-Transaktionen (3KP), werden außerdem weitere Features, wie z.B. certless (certificate-less) und walletless angeboten, sodaß der Anwender kein Zertifikat und / oder Wallet besitzen muß. Die folgende Erklärung des POS-Systems basiert auf dem Netlife/Globeset POS 1.4, ist jedoch aufgrund der Spezifikationen von SETCO für alle anderen Systeme gleichwertig. Das Netlife/Globeset POS ist erhältlich für Windows NT und Sun/Solaris (Sparc). Die API's und Adapter gibt es für C (Windows-Dll's) und Perl-scripts. Als Datenbanken kommen zum Einsatz: MS-SQL, Oracle. Auch wenn MS-Access über ODBC angesprochen wird - MS-Access ist keine aktive Datenbank (da sie ohne die nötige Jet-Engine nicht funktioniert) und ist daher für das POS nicht verwendbar. MySql kann über eine ODBC-Schnittstelle verwendet werden, es gibt jedoch keinerlei offiziellen Support. Von der Verwendung anderer Datenbanksysteme wie Progress, Sybase oder Informix rate ich wegen des nicht vorhersehbaren Integrationsaufwandes ab. Bestandteile des POSBasis des Netlife POS ist die SET-Protokollkomponente. An diese gegliedert sind Netzwerkschnittstellen, Datenbanken und zusätzliche funktionale Komponenten. Die folgende Abbildung zeigt eine Übersicht der Interaktion dieser Bestandteile.
Shopping-Schnittstelle (POS Adapter)Die Shopping-Schnittstelle stellt einen Mechanismus für Online-Shopping- Systeme zur Einleitung von Kauftransaktionen bereit. Mittels dieser Schnittstelle sendet das Shopping-System Bestellinformationen an das POS, das anschließend das Wallet im Browser des Kunden startet. Netlife liefert ein POS API, das die Anbindung einer Online-Shopping-Anwendung an das Netlife POS ermöglicht. Es werden auch fertige Adapter für OpenShop und InterShop angeboten. SET-SchnittstelleDie SET-Schnittstelle ermöglicht einen Zugriff auf andere SET-konforme Applikationen. Sie besteht aus einem TCP/IP-Server-Port, der SET-Nachrichten vom Kreditkarteninhaber (Wallet) empfängt, Händlerinformationen hinzufügt und sämtliche Nachrichten über das SET-Protokoll an die Schnittstelle zum Acquirer (Payment Gateway) sendet. AdministrationsschnittstelleDie Administrationsschnittstelle ist eine Schnittstelle zum Netlife POS, auf die mit einem Standard-Browser zugegriffen werden kann. Diese Verbindung wird über eine SSL-Verschlüsselung geschützt. Folgende administrative Funktionen können durchgeführt werden:
POS-DatenbankNach der Installation auf der Web-Site des Händlers benutzt das POS dessen Datenbank-Server, um auf mehrere Datenbanken während des Normalbetriebs zugreifen zu können. Diese sind:
Diese Datenbanken werden bei der Installation erzeugt. Händler können sie mit den Tools Dritter abfragen, um zusätzliche Berichte zu jenen des POS zu generieren. Es macht beispielsweise durchaus Sinn für eine Übernahme in die Finanzbuchhaltung mittels SQL Buchungssätze aller tatsächlich durchgeführten Transaktionen der einzelnen Kreditkartenorganisationen zu erstellen, oder auch nur eine Liste zur Saldenabstimmung zu erzeugen. Auch eine Auswertung der Transaktionen abhängig von der eigenen Kunden-Datenbank kann für Fakturierung und Warenwirtschaft notwendig sein. DatenbankstrukturDie Schlüsseltabelle (Zertifikatsregistrierung) dient zum Speichern der privaten Schlüssel des Händlers und zur Information über die Zertifikatsregistrierung. Private Schlüssel sind durch ein vom Händler bestimmtes Paßwort geschützt. Zertifikatstabellen werden zum Speichern aller Zertifikate verwendet. Transaktionstabellen dienen zum Speichern des Transaktionsstatus und werden im Zusammenhang mit der Autorisierung sowie mit Stapeltabellen benutzt. Autorisierungstabellen verwendet man zum Speichern aller Informationen zur Zahlungsautorisierung und -erfassung. In Stapeltabellen werden Stapelinformationen gespeichert (Batches). POS-NachrichtenverlaufDer Ablauf der Zahlungsverarbeitung im SET-Protokoll beruht auf Nachrichtenpaaren zwischen sowohl dem Karteninhaber und dem Händler als auch dem Händler und dem Payment Gateway. Nachfolgend wird anhand eines Diagrammes der Nachrichtenverlauf erläutert.
Weil das Thema Sicherheit gerade bei Kreditkarten eine gewichtige Rolle spielt, hier noch ein paar Worte zur Verschlüsselung. Die SET Spezifikationen basieren auf folgenden Algorithmen und Mechanismen:
Soviel zum allgemeinen Teil. Wenn sich also ein Händler entschließt, seinen Kunden Kreditkartenzahlungen anzubieten, sollte er folgende Punkte beachten: (*) Der Betrieb eines POS ist mit einem gewissen finanziellen Mindestaufwand verbunden. Soferne der Shop bei einem ISP gehostet wird, sollte dieser die Installation von Fremdsoftware gestatten, die nötigen Datenbanksysteme unterstützen, Zugriff auf Log-Dateien gewähren, allenfalls Software-Updates ermöglichen. Dies ist natürlich mit laufenden Kosten verbunden (vor allem die Datenbanken). Bei Betrieb auf einem eigenen Server fallen diese Punkte weitgehend weg, es sollte natürlich ein Administrator mit dem POS-System vertraut sein. Auch wenn die angebotenen Adapter nur mehr "mit Parametern versorgt werden müssen", bzw. das API für Programmierer keine Hindernissse darstellt, darf man den Integrationsaufwand nicht vernachlässigen. (*) Hat man jetzt sein POS auf einem Rechner installiert, so ist es bis zum reibungslosen Funktionieren desselben nur mehr ein ganz kleines Stück Arbeit. Eine entsprechende Datenbank ist anzulegen, um die Tabellen kümmert sich dann das POS. (*) Eine ODBC-Schnittstelle (bei SQL) ist zu definieren oder ein Oracle Client ist einzurichten. (*) Das POS ist mit den Datenbankinformationen zu versorgen. (*) Der Händler mit seinen Basisdaten und den notwendigen Acquirer-Zertifikaten (von Visa und/oder Mastercard) ist anzulegen.
Nach Erhalt der Händler- und Acquirer-Zertifikate über das Gateway ist das POS betriebsbereit und mit Hilfe der zur Verfügung gestellten Demo-Applikation, der ASP-Demo, den Perl-Scripts oder dem C-Interface können SET oder 2KP Transaktionen durchgeführt werden. Jetzt folgt noch die Integration in die Shop-Umgebung des Händlers mit dem entsprechenden Adapter oder einem API und ein weiterer SET-Shop ist online. Bei Verwendung eines generischen Perl-Adapters ist es auch möglich Shops auf Linux-Servern mit SET-Funktionalität auszustatten. Adapter/API:Folgende Adapter gibt es für Windows NT:
Der Unterschied zwischen Adapter und Cartridge besteht darin, daß der Adapter universell einsetzbar ist und daher für jede Shoplösung unter ASP geeignet ist (z.B.: Site/Commerce-Server von Microsoft und eigene Lösungen), wogegen die Cartridge fix mit dem dazugehörigen Produkt verbunden ist und auch die Lizenzierung abhängig von den jeweiligen Produkten erfolgt. Folgende Adapter gibt es für Sun/Solaris:
Ein generischer Adapter besteht aus einem StoreFront-Adapter (SA) und einem POS-Adapter (PA), die auf verschiedenen Servern mit unterschiedlichen Plattformen laufen können. Das bedeutet, daß der SA in Perl unter Linux laufen kann, und mit einem PA auf WinNT kommuniziert. TransaktionenEine Kreditkartentransaktion besteht immer aus 2 Schritten.
Der klassische Fall für einen abweichenden Buchungsbetrag ist eine Hoteltransaktion: Der Kunde checkt im Hotel für 3 Nächte ein, es werden sofort 3.000,- autorisiert. Beim Auschecken nach 2 Nächten werden jedoch nur 2.000,- gebucht. Beim Auschecken nach 4 Nächten werden dann 4.000,- gebucht. Die Transaktion ist erst nach der erfolgten Buchung abgeschlossen, und der Händler erhält auch den tatsächlich gebuchten Betrag. Im POS erfolgt die Autorisierung immer Online (im Zuge der Einkaufstransaktion) Die Buchung (Capture) kann zu einem späteren Zeitpunkt (nach Warenversand) durchgeführt werden. Es besteht auch die Möglichkeit, Autorisierung und Buchung gleichzeitig durchzuführen. Dies ist zweckmäßig bei "virtuellen Waren" (z.B.: Software-Download oder Informationszugang) wo der Kunde seine Ware sofort erhält und auch keine Teillieferungen möglich sind. Abhängig von der Art der gebotenen Waren oder Dienstleistungen können 2 verschiedene Transaktionstypen verwendet werden. Aufgrund des Transaktionstyps wird im POS die Unterscheidung getroffen ob eine spätere Buchung möglich ist oder ob die Buchung (Capture) sofort durchgeführt wird. Für physikalischen Warenversand empfiehlt sich: Autorisierung durchführen und in einer späteren Transaktion (über Software oder POS-Administration) das dazugehörige Capture durchzuführen. Für virtuelle Waren oder Dienstleistungen (Download...) empfiehlt sich: Autorisierung und Capture in einer Transaktion durchzuführen. Capture: Erst durch das Capture wird aus einer Autorisierung eine tatsächliche Transaktion, die in einem "Batch" über das Gateway an das Kreditkarteninstitut gesandt wird. Batch: Zu einem definierten Zeitpunkt (oder manuell) sollte periodisch ein sogenannter Batch an die Acquirer gesandt werden. Dieser Batch entspricht im realen Leben dem Kassenabschluß am Terminal und bewirkt die Auszahlung (Verrechnung) der Zahlbeträge an den Händler durch das Kreditkarteninstitut.
Jede Transaktion ist im POS mit allen notwendigen (bzw. vom Shop zur Verfügung gestellten) Informationen abgespeichert.
Unabhängig von der TransaktionsID des Shops wird im POS eine Local ID Merchant of the transaction (LIDM genannt) gebildet. Diese LIDM begleitet die SET-Transaktion durch alle Instanzen, d.h. sie ist im Wallet (soferne verwendet) am Gateway und im Host des Kreditkarteninstitutes. Im Falle eines Einspruches oder Reklamation kann über diese LIDM die Transaktion rekonstruiert werden. Die LIDM kann neben der Shop Transaction ID natürlich auch als Referenz zu Händler-eigenen Kundendatenbanken herangezogen werden. Stornos (reversal) , Gutschriften (debit) oder Betragsänderungen (adjustment) bei Teillieferungen oder Überlieferungen sind über die POS-Administration möglich. Je nach Transaktions-Anfall bietet sich natürlich die Möglichkeit eine Batch-Applikation zur Verfügung zu stellen, die unabhängig von der POS- Administration deren Funktionalitäten zur Verfügung stellt. Der Händler erhält von den Kreditkarteninstituten verschiedene Händlernummern zugeteilt unter denen er seine Transaktionen mittels Batch einreicht. Er erhält je nach Vertrag und Periodizität der Batches entsprechend seine Kontoauszüge von den Kreditkarteninstituten. Diese verschiedenen Händlernummern erleichtern die Abstimmung von 2KP-, 3KP- Transaktionen und Transaktionen in verschiedenen Währungen mit dem jeweiligen Kontoauszug. Payment-ServiceWenn der Aufwand für eine eigene POS-Installation zu groß ist oder der ISP das nicht zulässt, gibt es auch noch die Möglichkeit der Miete eines POS-Services. Was ist das Payment-Service und was bringt mir dieses Service? Ganz einfach: der Händler möchte seinen Online-Kunden natürlich auch die sichere Zahlungsmöglichkeit SETTM (Secure Electronic Transaction) anbieten, findet aber, daß der Kauf einer eigenen Software (POS) zu aufwendig ist. Das Payment-Service ist funktional die gleiche Software wie das MerchantPOS, nur daß mehrere Shops ein und dasselbe Service nutzen (mieten) und trotzdem nicht auf die Daten des anderen Shopbetreibers zugreifen können. Jeder Shop hat einen eigenen Zugang zum POS, und da man sich das POS nun mit mehreren Shopbesitzern teilt bleiben die Kosten auch geringer. Vorteile
Von SET4U gibt es 3 Varianten des Payment-Services: SET-lightDieses Service beinhaltet die Miete des POS und des Store Front-Adapters, die "Bezahlseite" wird von SET4U über eine sichere Verbindung zur Verfügung gestellt. Auf der Bezahlseite wird ein Logo des Händlers eingebunden, die Bezahlseite läuft allerdings auf Servern von SET4U. SET-light+Dieses Service entspricht SET-light mit einigen "kosmetischen" Zusatzfeatures. Die "Bezahlseite" wird von SET4U nach Angaben des Händlers gestaltet oder wird vom Händler zur Verfügung gestellt. Die Seite liegt wie bei SET-light auf den Servern von SET4U. Grundsätzlich ist also mit SET-light+ eine Anpassung an die Corporate Identity (CI) möglich. Technische Voraussetzung für die Durchführung ist ein Link (SSL) von z.B. dem Button "Zur Kassa" auf die Bezahlseite. Um die Transaktionen durchzuführen benötigt die Bezahlsoftware (POS) einige Informationen wie den Betrag, Auftragsbeschreibung, Währung, die der Shop über eine sichere Verbindung an das POS übergibt. Der Ablauf einer Transaktion gestaltet sich wie folgt
Der Kunde erhält dann eine Bezahlseite:
oder eine nach den Vorstellungen des Händlers zusammengestellte. SET-completeDieses Service beinhaltet die Miete des POS, der Store Adapter wird vom Händler gekauft und kann daher im Shop des Händlers direkt eingebunden werden. Eine vollständige Anpassung an eine Corporate Identity ist dadurch möglich, allerdings läuft nun alles in der Web Site des Händlers. Sonst beinhaltet dieses Service die gleichen Optionen wie "SET-light". Technische Voraussetzungen: Es werden von der Bezahlseite des Händlers alle notwendigen Informationen über eine sichere Verbindung (SSL) an das POS übergeben. Der Ablauf einer Transaktion:
Weitere Informationen zu den hier vorgestellten 3 Services erhalten Sie bei: SET4U Payment-Service SchlußbemerkungUnabhängig von anderen Zahlungsweisen wie e-cash, cybercash, net900, und was immer die Zukunft bringen wird, ist die Zahlung mit Kreditkarten die einzig wirklich internationale Möglichkeit - und um allen Sicherheitsapekten gerecht zu werden, bietet der Einsatz von SET dem Händler derzeit den höchsten Standard. Auch wenn die Nutzung von Wallets zur Zeit nicht allzu hoch ist, ist alleine die Online-Autorisierung für den Händler von entscheidendem Vorteil gegenüber herkömmlichen MailOrder/TelefonOrder Transaktionen und die angekündigte Verwendbarkeit von MAESTRO-Karten im Rahmen von SET wird für den Händler auch ein Anreiz sein, diese Zahlungsmethode anzubieten. Shops aus aller Welt, die SET verwenden, finden sich auf goset.org Verwandte Artikel
Beteiligte Komponenten bei SET Transaktionen (Teil 1) Links zu anderen Sites
http://goset.org Wenn Sie jetzt Fragen haben...Wenn Sie Fragen rund um die in diesem Artikel vorgestellte Technologie haben, dann schauen Sie einfach bei uns in den Community Foren der deutschen .NET Community vorbei. Die Teilnehmer helfen Ihnen gerne, wenn Sie sich zur im Artikel vorgestellten Technologie weiterbilden möchten.
Haben Sie Fragen die sich direkt auf den Inhalt des Artikels beziehen, dann schreiben Sie dem Autor! Unsere Autoren freuen sich über Feedback zu ihren Artikeln. Ein einfacher Klick auf die Autor kontaktieren Schaltfläche (weiter unten) und schon haben Sie ein für diesen Artikel personalisiertes Anfrageformular.
Und zu guter Letzt möchten wir Sie bitten, den Artikel zu bewerten. Damit helfen Sie uns, die Qualität der Artikel zu verbessern - und anderen Lesern bei der Auswahl der Artikel, die sie lesen sollten.
©2000-2006 AspHeute.com |
