Beteiligte Komponenten bei SET Transaktionen (Teil 2)

Beteiligte Komponenten bei SET Transaktionen (Teil 2)
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 umfasst:
The SET Standard Book 1 Business Description
The SET Standard Book 2 Programmer's Guide
The SET Standard Book 3 Formal Protocol Definitions
SET Glossary
External Interface Guide
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: http://www.setco.org/cgi- bin/vsm.cgi
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 POS
Basis 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-ShoppingSysteme 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-Schnittstelle
Die 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 SETProtokoll an die Schnittstelle zum Acquirer (Payment Gateway) sendet.
Administrationsschnittstelle
Die 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:
• Start, Stop, Wiederanlauf und Überwachung des Status des POS-Servers
• Überprüfung der zur Verfügung stehenden Zertifikate
• Konfiguration der Server-Logdateien, URL-Daten, Ports und Datenbanken
• Konfiguration und Überwachung der aktuellen Händler
• Manuelle Stapel- und Transaktionsverarbeitung zur Durchführung der
Zahlungsabwicklung
POS-Datenbank
Nach 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:
•
•
•
•
•
Transaction database
Authorization database
Batch database
Certificate database
Key database
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.
Datenbankstruktur
Die 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-Nachrichtenverlauf
Der 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.
1. Der Kunde füllt den Warenkorb.
2. Er bestätigt die Bestellinformationen und wählt eine Bezahlungsmethode
aus. Das Shopping-System erstellt eine Kickoff-Nachricht.
3. Das Shopping-System sendet die Kickoff-Nachricht an das POS.
4. Das POS erstellt eine Wakeup-Nachricht und sendet sie zurück
an das Shopping-System.
5. Die Wakeup-Nachricht gelangt über den Webserver zum
Browser.
6. Der Browser wurde dem SET-Standard gemäß so konfiguriert,
daß er beim Erhalt der Wakeup-Nachricht das Wallet aufruft.
7. Das Wallet nimmt mittels der URL der Wakeup-Nachricht
Kontakt zum POS auf.
8. Das POS antwortet auf die Anforderung der Kaufinitialisierung.
9. Das Wallet sendet eine Kaufanforderung an den Händler.
10. Das POS schickt eine Autorisierungsanforderung an das
Payment Gateway.
11. Das Gateway sendet eine Autorisierungsantwort zurück zum
POS.
12. Das POS sendet die Autorisierungsantwort an das Shopping-System.
13. Das POS sendet eine Erfolgs- oder Fehlermeldung an das
Wallet.
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:
SICHERHEITSMECHANIS
ALGORITHMUS
STANDARD
SCHLÜSSELLÄNGE
Signatur
Duale Signatur
RSA
RSA
1024 Bit
1024 Bit
Datenverschlüsselung
Hashing
Asymmetrische
Verschlüsselung
DES
SHA
RSA
PKCS 7
Neuentwicklung
für SET
PKCS 7
SHA-1
PKCS 1
Zertifikate
RSA
X.509 v 3
MUS
56 Bit
768
(Merchant)
und
1024
(Payment
Gateway)
1024
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:
• ASP-Adapter
• Intershop-Cartridge
• OpenShop-Cartridge
• C- oder Perl- API
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:
• Intershop-Cartridge
• OpenShop-Cartridge
• C- oder Perl- API
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.
Transaktionen
Eine Kreditkartentransaktion besteht immer aus 2 Schritten.
1. die reine Autorisierung
2. die nachfolgende Buchung, wobei der Buchungsbetrag vom
Autorisierungsbetrag abweichend sein kann.
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.: SoftwareDownload 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.
J
ede 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 BatchApplikation zur Verfügung zu stellen, die unabhängig von der POSAdministration 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-Service
Wenn 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
• Keine zusätzlichen monatlichen Providerkosten
• Keine eigene Domäne nötig
• Für jeden Shopbetreiber leistbar
• Keine Wartungskosten
• Geringere Aufwendung für Integration (tatsächlich liegt der
Integrationsaufwand für das Miet-POS händlerseitig im Stunden-Bereich.)
Von SET4U gibt es 3 Varianten des Payment-Services:
SET-light
Dieses 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
1.
2.
3.
4.
5.
6.
Shop --> Store Adapter (gemietet)
Store Adapter --> POS
POS --> Kreditkartenorganisation
Kreditkartenorganisation --> POS
POS --> Store Adapter
Store Adapter --> Shop
Der Kunde erhält dann eine Bezahlseite:
oder eine nach den Vorstellungen des Händlers zusammengestellte.
SET-complete
Dieses 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:
1. Shop (Store Adapter) --> POS
2. POS --> Kreditkartenorganisation
3. Kreditkartenorganisation --> POS
4. POS --> Store Adapter (Shop)
Weitere Informationen zu den hier vorgestellten 3 Services erhalten Sie bei:
SET4U Payment-Service
Schlußbemerkung
Unabhä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
http://goset.org
Links zu anderen Sites
•
•
•
•
•
•
•
http://set4u.at
http://goset.org
http://www.netlife.de
http://www.setco.org
http://www.ecin.de
http://www.visa.at
http://www.europay.at
Verwandte Artikel
•
•
SET allgemein
SET Teil 1