11.10.2013 Aufrufe

ZAHLUNGSSYSTEME im INTERNET - E-Commerce Group ...

ZAHLUNGSSYSTEME im INTERNET - E-Commerce Group ...

ZAHLUNGSSYSTEME im INTERNET - E-Commerce Group ...

MEHR ANZEIGEN
WENIGER ANZEIGEN

Erfolgreiche ePaper selbst erstellen

Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.

<strong>ZAHLUNGSSYSTEME</strong> <strong>im</strong> <strong>INTERNET</strong><br />

eingereicht von:<br />

Stefan Forsich<br />

DIPLOMARBEIT<br />

zur Erlangung des akademischen Grades<br />

Magistra rerum socialium oeconomicarumque<br />

Magistra der Sozial- und Wirtschaftswissenschaften<br />

(Mag. rer. soc. oec.)<br />

Fakultät für Wirtschaftswissenschaften und Informatik,<br />

Universität Wien<br />

Fakultät für Technische Naturwissenschaften und Informatik,<br />

Technische Universität Wien<br />

Studienrichtung: Wirtschaftsinformatik<br />

Begutachter:<br />

O.Univ.-Prof. Dr. Jürgen Dorn Wien, <strong>im</strong> April 2003


Danksagung<br />

Für die Fertigstellung dieser Arbeit gilt besonderer Dank meinem Betreuer ao. Univ. Prof.<br />

Dipl.-Inf. Dr. Ing. Jürgen Dorn, welcher mit seiner besonders sachkundigen Anleitung den<br />

Hauptteil der wissenschaftlichen Unterstützung leistete.<br />

Auch sei den Kontaktpersonen der Firmen Vodafone D2 GmbH, P.S.K. AG, VISA-Service<br />

Kreditkarten AG, Prozessdatentechnik und Systeme Gesellschaft für industrielle<br />

Datenverarbeitung GmbH, Bank Austria Creditanstalt AG, paysafecard.com Wertkarten<br />

Vertriebs GmbH und Europay Austria Zahlungsverkehrssysteme GmbH für deren<br />

bereitwillige Auskünfte über ihre Produkte noch einmal nachträglich gedankt.<br />

Ein ganz besonderer Dank gilt meinen Eltern, die mir das Studium ermöglicht und mich in<br />

jeder Hinsicht unterstützt haben.


Abstrakt<br />

Zahlungssysteme <strong>im</strong> Internet<br />

ABSTRAKT<br />

Um das weitläufige Themengebiet „Zahlungssysteme <strong>im</strong> Internet“ in einer übersichtlichen<br />

Systematik zu halten, wird die Arbeit in zwei großen Teilbereichen abgehandelt.<br />

Im ersten Teil wird versucht ein Klassifizierungsschema für Zahlungsverfahren zu entwerfen,<br />

nach dem die Zuordnung vorgenommen werden kann, um sich einen übersichtsmäßigen<br />

Überblick verschaffen zu können. Im weiteren Verlauf werden allgemeine Anforderungen<br />

und Kriterien herausgearbeitet, die für die praktische Realisierung eines Zahlungssystems<br />

substantiell sind. Anschließend erfolgt eine genaue Analyse der zum Zeitpunkt der Abfassung<br />

dieser Arbeit am österreichischen Markt bzw. deutschen Markt gängigsten Zahlungssysteme<br />

und eine Kritik darüber, inwieweit diese selektierten Kriterien in den Entwurf der jeweiligen<br />

Verfahren berücksichtigt wurden.<br />

Der die Arbeit abschließende Schwerpunkt liegt darin, die analysierten Zahlungssysteme als<br />

Workflowmodelle abzubilden. Die Intention ist dabei einen Überblick über die<br />

durchzuführenden Aktivitäten und Daten und somit über die dahinter stehenden<br />

Prozessabläufe zu erhalten, die zur Umsetzung eines Geschäftsmodells erforderlich sind. In<br />

weiterer Folge soll es möglich sein, diese Workflowmodelle nach dem Prinzip eines<br />

Baukastenmodells direkt in ein bestehendes Unternehmensmodell zu integrieren.<br />

Schlussendlich wird ein Profil erstellt, welches eine Art Regelwerk darstellt, nach dem eine<br />

Qualifikation der Zahlungsverfahren in ein Geschäftsmodell vorgenommen werden kann.<br />

Damit kann schon <strong>im</strong> Vorhinein die Möglichkeit ausgeschlossen werden, Zahlungsverfahren<br />

zu integrieren, die hierfür nicht geeignet sind.<br />

1


Inhaltsverzeichnis 2<br />

INHALTSVERZEICHNIS<br />

1 EINLEITUNG 5<br />

2 KRITERIEN VON <strong>ZAHLUNGSSYSTEME</strong>N 7<br />

2.1 Allgemeine Kriterien ......................................................................................................7<br />

2.1.1 Sicherheit...................................................................................................................7<br />

2.1.1.1 Verfügbarkeit......................................................................................................7<br />

2.1.1.2 Zuverlässigkeit....................................................................................................7<br />

2.1.1.3 Vertraulichkeit ....................................................................................................8<br />

2.1.1.4 Integrität..............................................................................................................8<br />

2.1.1.5 Authentifizierung ................................................................................................8<br />

2.1.2 Nichtabstreitbarkeit....................................................................................................9<br />

2.1.3 Kosten .......................................................................................................................9<br />

2.1.4 Rückverfolgbarkeit ..................................................................................................11<br />

2.1.4.1 Uneingeschränkte Rückverfolgbarkeit...............................................................11<br />

2.1.4.2 Eingeschränkte Rückverfolgbarkeit...................................................................12<br />

2.1.4.3 Nichtrückverfolgbare Zahlungen .......................................................................12<br />

2.1.4.4 Benutzergesteuerte Rückverfolgbarkeit .............................................................12<br />

2.1.5 Teilbarkeit ...............................................................................................................12<br />

2.1.6 Online Verifikation ..................................................................................................12<br />

2.1.7 Akzeptanzfähigkeit ..................................................................................................13<br />

2.2 Kundenseitige Kriterien ...............................................................................................13<br />

2.2.1 Übertragbarkeit........................................................................................................13<br />

2.2.2 Usability ..................................................................................................................13<br />

2.2.3 Registrierung ...........................................................................................................13<br />

2.2.4 Universalität ............................................................................................................14<br />

2.3 Händlerseitige Kriterien...............................................................................................14<br />

2.3.1 Implementierungseinfachheit ...................................................................................14<br />

2.3.2 Zahlungssicherheit ...................................................................................................14<br />

2.3.3 Transaktionsbearbeitung ..........................................................................................15<br />

3 BASISKONZEPTE VON <strong>ZAHLUNGSSYSTEME</strong>N IM <strong>INTERNET</strong> 16<br />

3.1 Unterscheidungskriterien von Zahlungssystemen.......................................................17<br />

3.1.1 Zahlungszeitpunkt....................................................................................................17<br />

3.1.2 Zahlungsvolumen.....................................................................................................19<br />

3.1.3 Zahlungskommunikation..........................................................................................22<br />

3.2 Einteilung der Internet Zahlungssysteme....................................................................23<br />

3.2.1 Offline-Zahlung .......................................................................................................23<br />

3.2.2 Bankeinzug..............................................................................................................24<br />

3.2.3 Kreditkartenbasierte Zahlungen................................................................................26<br />

3.2.4 Guthabenbasierte Zahlung........................................................................................27<br />

4 <strong>INTERNET</strong>-<strong>ZAHLUNGSSYSTEME</strong> 29<br />

4.1 Allgemeine Erläuterungen............................................................................................29<br />

4.2 Paybox...........................................................................................................................29<br />

4.2.1 Einsatzgebiet............................................................................................................29<br />

Zahlungssysteme <strong>im</strong> Internet


Inhaltsverzeichnis 3<br />

4.2.2 Voraussetzungen für Kunden ...................................................................................30<br />

4.2.3 Transaktionsablauf...................................................................................................30<br />

4.2.4 Kosten Kunde ..........................................................................................................31<br />

4.2.5 Kosten Händler ........................................................................................................32<br />

4.2.6 Voraussetzungen für Händler ...................................................................................32<br />

4.3 Paysafecard...................................................................................................................34<br />

4.3.1 Einsatzgebiet............................................................................................................34<br />

4.3.2 Voraussetzungen für Kunden ...................................................................................34<br />

4.3.3 Voraussetzungen für Händler ...................................................................................35<br />

4.3.4 Transaktionsablauf...................................................................................................35<br />

4.3.5 Kosten Händler ........................................................................................................36<br />

4.4 Quick.............................................................................................................................36<br />

4.4.1 Einsatzgebiet............................................................................................................37<br />

4.4.2 Voraussetzungen für Kunden ...................................................................................37<br />

4.4.3 Voraussetzungen für Händler ...................................................................................37<br />

4.4.4 Transaktionsablauf...................................................................................................38<br />

4.4.5 Kosten Händler ........................................................................................................39<br />

4.5 E-Einkauf......................................................................................................................39<br />

4.5.1 Einsatzgebiet............................................................................................................39<br />

4.5.2 Voraussetzungen für Kunden ...................................................................................40<br />

4.5.3 Voraussetzungen für Händler ...................................................................................40<br />

4.5.4 Kosten Händler ........................................................................................................40<br />

4.5.5 Transaktionsablauf...................................................................................................41<br />

4.6 Banking-Verfahren.......................................................................................................41<br />

4.6.1 Einsatzgebiet............................................................................................................42<br />

4.6.2 Voraussetzungen für Kunden ...................................................................................42<br />

4.6.3 Voraussetzungen für Händler ...................................................................................42<br />

4.6.4 Kosten Händler ........................................................................................................42<br />

4.6.5 Transaktionsablauf...................................................................................................43<br />

4.7 M-Pay............................................................................................................................44<br />

4.7.1 Einsatzgebiet............................................................................................................44<br />

4.7.2 Voraussetzungen für Kunden ...................................................................................44<br />

4.7.3 Voraussetzungen für Händler ...................................................................................44<br />

4.7.4 Transaktionsablauf...................................................................................................44<br />

4.7.5 Kosten Kunde ..........................................................................................................45<br />

4.7.6 Kosten Händler ........................................................................................................46<br />

4.8 Iclear .............................................................................................................................46<br />

4.8.1 Einsatzgebiet............................................................................................................46<br />

4.8.2 Voraussetzungen für Kunden ...................................................................................46<br />

4.8.3 Voraussetzungen für Händler ...................................................................................46<br />

4.8.4 Kosten Händler ........................................................................................................46<br />

4.8.5 Transaktionsablauf...................................................................................................47<br />

4.9 Kreditkarte SET ...........................................................................................................48<br />

4.9.1 Einsatzgebiet............................................................................................................48<br />

4.9.2 Voraussetzungen für Kunden ...................................................................................48<br />

4.9.3 Voraussetzungen für Händler ...................................................................................48<br />

4.9.4 Kosten Händler ........................................................................................................49<br />

4.9.5 Transaktionsablauf...................................................................................................49<br />

Zahlungssysteme <strong>im</strong> Internet


Inhaltsverzeichnis 4<br />

4.10 Verified by Visa ..........................................................................................................50<br />

4.10.1 Voraussetzungen für Kunden .................................................................................50<br />

4.10.2 Voraussetzungen für Händler .................................................................................51<br />

4.10.3 Transaktionsablauf.................................................................................................51<br />

5 ANALYSE UND KRITIK 52<br />

5.1 Paybox...........................................................................................................................53<br />

5.2 Paysafecard...................................................................................................................55<br />

5.3 Quick.............................................................................................................................56<br />

5.4 Kreditkarte SET ...........................................................................................................57<br />

5.5 Kreditkarte Verified by Visa........................................................................................59<br />

5.6 M-Pay............................................................................................................................60<br />

5.7 Banking-Verfahren.......................................................................................................61<br />

5.8 E-Einkauf......................................................................................................................63<br />

5.9 Iclear .............................................................................................................................63<br />

6 WORKFLOWMODELLE FÜR EPAYMENT VERFAHREN 65<br />

6.1 Allgemeine Erläuterungen............................................................................................65<br />

6.2 Hierarchisierung von ePayment Verfahren.................................................................68<br />

6.2.1 Paybox.....................................................................................................................73<br />

6.2.2 Paysafecard..............................................................................................................78<br />

6.2.3 Quick.......................................................................................................................83<br />

6.2.4 E-Einkauf.................................................................................................................86<br />

6.2.5 Banking-Verfahren ..................................................................................................90<br />

6.2.6 M-Pay......................................................................................................................94<br />

6.2.7 Iclear........................................................................................................................98<br />

6.2.8 Kreditkarte SET .....................................................................................................101<br />

6.2.9 Verified by Visa.....................................................................................................106<br />

6.3 Richtlinien für die Profilerstellung ............................................................................109<br />

6.3.1 Plattformunabhängigkeit ........................................................................................109<br />

6.3.2 Transaktionskosten ................................................................................................109<br />

6.3.3 Betragsl<strong>im</strong>it ...........................................................................................................110<br />

6.3.4 Backofficefähigkeit................................................................................................110<br />

6.3.5 Forderungsmanagement .........................................................................................110<br />

6.3.6 Zeitpunkt des Zahlungseingangs ............................................................................111<br />

6.3.7 Personalisierbarkeit................................................................................................111<br />

6.3.8 Warenart................................................................................................................111<br />

6.3.9 Stornierbarkeit .......................................................................................................112<br />

6.3.10 Variables Zahlungsziel.........................................................................................112<br />

7 REFERENZEN 114<br />

Zahlungssysteme <strong>im</strong> Internet


1 Einleitung 5<br />

1 Einleitung<br />

Kein anderes Medium wie moderne Computernetzwerke haben die über die Jahrtausende<br />

festgefahrenen Bahnen des herkömmlichen Zahlungsverkehrs auf Bargeldbasis verändert.<br />

Gewohnheiten die fast schon ein Bestandteil unseres alltäglichen Lebensablaufes waren,<br />

wurden fast über Nacht über den Haufen geworfen. Die Dinglichkeit des Bargeldverkehrs<br />

aber auch schon dessen Weiterentwicklung des Zahlscheins vermittelten uns ein Gefühl der<br />

Nähe und der persönlichen Verfügbarkeit über unser Geldvermögen. Der moderne<br />

Zahlungsverkehr hingegen erscheint uns <strong>im</strong>mer noch als etwas ominöses. Bisher hatte man<br />

persönlichen Kontakt zum Verkäufer, nun muss man blindes Vertrauen in den Verkäufer<br />

setzen. Kryptische Codes werden in ein fremdes Gerät eingegeben das wiederum mit anderen<br />

Geräten kommuniziert die außerhalb unserer Wahrnehmung stehen. Zugegeben es wird<br />

bequemer aber was garantiert, dass diese „eigenartige Apparatur“ auch das macht was wir<br />

wollen beziehungsweise auch nur Informationen dem zukommen lässt den wir mit diesen<br />

Transaktionen ansprechen wollen. Dieses Gefühl der Unsicherheit wird vermutlich nie<br />

gänzlich den Anwendern genommen werden können. Es liegt in der Psyche des Menschen.<br />

Obwohl die Technik der Zahlungsabwicklung durch umfangreiche Sicherheitstechnologien<br />

bereits hohe Sicherheit bietet, ist das individuelle Empfinden der Verbraucher emotional<br />

skeptisch gegenüber der Datenpreisgabe (Bankdaten, Personendaten, ...) <strong>im</strong> Internet. Laut<br />

Umfragen [IZV]besteht das größte Hemmnis be<strong>im</strong> Onlinekauf die kaufende Ware auch direkt<br />

„online“ zu bezahlen. Solange die Bezahlung über die bisher bekannten Wege wie<br />

Nachnahme oder Rechnung abgewickelt werden kann, bestehen „nur“ Ängste bezüglich der<br />

persönlichen Adressdaten. Sobald der Kunde aber diese Bezahlungsmöglichkeiten nicht mehr<br />

vorfindet und zum Beispiel per Bankeinzug oder Kreditkarte zahlen muss, n<strong>im</strong>mt die<br />

Hemmschwelle enorm zu. Der Käufer hat Angst seine persönlichen Daten wie Kreditnummer<br />

über das Internet zu übertragen. Man kann aber diese Skepsis abbauen helfen indem man<br />

best<strong>im</strong>mte Kriterien auf jedenfall in einem Zahlungssystem garantieren muss. Der weitere<br />

Verlauf der Arbeit dient der Vertiefung in die Problematik aber auch zur Lieferung von Ideen<br />

zu deren Lösung. Dies beinhaltet zum einen eine genaue Analyse der populärsten<br />

Zahlungssysteme und einer Kritik inwieweit diese selektierten Kriterien in den Entwurf der<br />

jeweiligen Verfahren berücksichtigt wurden.<br />

Nachdrücklich zu vermerken ist, dass dieses Analyseverfahren nicht auf quantitativen<br />

Methoden beruht sondern versucht empirische Erkenntnisse objektiv und begründbar<br />

darzustellen. Für eine exakte quantitative Analyse wäre ein wesentlich größerer Zeitrahmen<br />

vonnöten und deren Aussagekraft bliebe dennoch fragwürdig, da sich viele Verfahren in<br />

Entwicklung befinden und der Prozess der technologischen Verbesserung eine derartige<br />

Dynamik in den letzten Jahren erfahren hat, sodass es momentan sinnlos wäre einen<br />

Hardwarestandard für eine Messserie festzulegen.<br />

Die Grundidee des Analyseverfahrens besteht darin, die momentan aktuellen ePayment<br />

Verfahren standardisiert zu bewerten. Die Kriterien die Eingang in das Analyseverfahren<br />

fanden, wurden nach Gesichtspunkten getroffen, die sich schon bei vorhergehenden<br />

Forschungsarbeiten als charakteristisch für dieses Thema herauskristallisiert haben. Für deren<br />

Bewertung wird ein Benotungsschema verwendet, das aus 3 Noten gebildet wird. Als Vorbild<br />

dient die einfache Verkehrsampel. Note rot heißt dieses Kriterium ist in diesem Verfahren<br />

nicht erfüllt, gelb das Kriterium wird teilweise erfüllt und bei grün ist es vollständig erfüllt.<br />

Dem einfachen Verständnis halber werden die Kriterien in drei Gruppen geordnet:<br />

Zahlungssysteme <strong>im</strong> Internet


1 Einleitung 6<br />

1. allgemeine Kriterien<br />

2. kundenseitige Kriterien<br />

3. händlerseitige Kriterien<br />

Die in dieser Arbeit verwendete Gruppierung der Kriterien wurde derartig gewählt, dass<br />

spezifische Aussagen über die Bedürfnisse der Teilhaber an einen Bezahlungsprozess bewusst<br />

gemacht werden können. Ein Händler hat andere Interessen als der Kunde. Daher vertritt<br />

dieser eine andere Herangehensweise an das Problem. Dennoch muss das System<br />

Eigenschaften anbieten die mehr oder weniger für beide gleich verbindlich sind. Daher bleibt<br />

anzumerken, dass sich keine scharfe Trennung beider Sichtweisen durchziehen lässt. Einige<br />

Eigenschaften betreffen beide gleichsam, andere mehr die eine Sichtweise, wenige<br />

ausnahmslos nur diese. Eine Analyse und Einordnung der noch in Kapitel 4 vorzustellenden<br />

Internet-Zahlungssysteme in das Bewertungsprofil findet sich in Kapitel 5.<br />

Im Abschlusskapitel 6 dieser Arbeit werden Prozessabläufe der Zahlungsverfahren visuell<br />

abgebildet. Dies geschieht deswegen in einem separaten Teil, da der Versuch unternommen<br />

wird die aus dem vorhergegangen Kapitel gewonnenen Charakterisierungen der jeweiligen<br />

Verfahren in einen modellhaften Aufbau zu übernehmen. Es besteht die Idee diese Modelle in<br />

weiterführenden Arbeiten die sich mit dem Aufbau von Webshops beschäftigen zu<br />

integrieren. Es soll ermöglicht werden, dass mehrere Optionen der Zahlungsabwicklung<br />

exemplarisch innerhalb eines Gesamtmodells gegenübergestellt werden können.<br />

Zahlungssysteme <strong>im</strong> Internet


2 Kriterien von Zahlungssystemen 7<br />

2 Kriterien von Zahlungssystemen<br />

Erfolg und Brauchbarkeit vorgeschlagener oder bereits eingesetzter Zahlungssysteme hängen<br />

von vielen Faktoren ab. Folgende Kriterien aus den Sichtwinkeln des Händlers und des<br />

Kunden sowohl gegenseitig als auch für beide Seiten indifferent sind für die Beurteilung und<br />

Klassifizierung von Zahlungssystemen somit wesentlich.<br />

2.1 Allgemeine Kriterien<br />

2.1.1 Sicherheit<br />

Die Sicherheit ist eine wesentliche Eigenschaft für elektronische Zahlungssysteme <strong>im</strong><br />

Internet. Gerade bei Transaktionen, wo Geld über offene Netze den Besitzer wechselt und<br />

verbindliche Rechtsgeschäfte abgeschlossen werden, sind hohe Sicherheitsstandards<br />

unabdingbar. Aufgrund der offenen Architektur des Internet bestehen zahlreiche<br />

Manipulationsmöglichkeiten. Ein Nachrichtenpaket durchläuft vom Sender bis zum<br />

Empfänger des Pakets unzählige Internetknoten bevor es sein Ziel erreicht. Denkbar wäre,<br />

dass Kontonummern oder Rechnungssummen in einem elektronischen Dokument abgefangen<br />

werden und von nicht autorisierten Personen gelesen, verfälscht oder anderweitig verwendet<br />

werden. Teilnehmer könnten sich die Identität eines anderen Teilnehmers zulegen.<br />

Aus diesem Grund stellt die Sicherheit eine Hauptanforderung an Zahlungssysteme dar. Die<br />

konkreten Sicherheitsanforderungen an ein elektronisches Zahlungssystem variieren in<br />

Abhängigkeit von den Funktionen des Systems, sowie den jeweiligen Annahmen über das<br />

Vertrauen in ihre Sicherheit [ASO]. Generell müssen für ein Zahlungssystem ein oder<br />

mehrere der folgenden Sicherheitsanforderungen erfüllt sein.<br />

2.1.1.1 Verfügbarkeit<br />

Verfügbarkeit bedeutet, dass sämtliche teilnehmenden Parteien jederzeit die Möglichkeit<br />

haben, Zahlungen auszuführen und zu empfangen. Deshalb müssen der Zahlungsserver des<br />

Zahlungssystem-Anbieters, der Anbieter-/Electronic <strong>Commerce</strong>-Server, das Banken-<br />

Informationssystem ständig online sein und der Internet-Zugang für den Konsumenten <strong>im</strong>mer<br />

gewährleistet sein. [AHS]Online-Vandalen und Hacker versuchen, DoS-Angriffe (Denial of<br />

Service) durchzuführen, wobei Zahlungsdienste bevorzugte Ziele darstellen. [FUH] Eine<br />

Unterbrechung der Infrastruktur kann bei allen Beteiligten zu einem Verlust führen. Alle<br />

Beteiligten müssen in der Lage sein, ihren Teil der Finanztransaktion dann abzuwickeln,<br />

wenn dies gewünscht oder erforderlich ist. Um die Funktionsfähigkeit des Systems zu<br />

gewährleisten, sollte nach Möglichkeit ein verteiltes Systems verwendet werden, in dem sich<br />

Zahlungsserver an verschiedenen Standorten <strong>im</strong> Internet befinden, die eine rasche Rückkehr<br />

zum geordneten Betrieb wieder ermöglichen, falls eine der Verbindungen oder einer der<br />

Server ausfallen. [AMO]<br />

2.1.1.2 Zuverlässigkeit<br />

Zahlungstransaktionen müssen atomar (vollständig oder überhaupt nicht) ausgeführt werden.<br />

Transaktionen dürfen niemals unvollständig sein. Die Zahlung wird entweder akzeptiert oder<br />

verweigert. Ein dritter Zustand darf jedoch niemals auftreten. Um Atomarität zu<br />

gewährleisten, kann das Transaktionsmodell aus dem Datenbankbereich zu Hilfe genommen<br />

werden. Dieses beschreibt ein transaktional gesichertes Protokoll, das alle technischen<br />

Eigenschaften einer Transaktion – Atomarität, Konsistenz, Isolation, Dauerhaftigkeit (ACID –<br />

Zahlungssysteme <strong>im</strong> Internet


2 Kriterien von Zahlungssystemen 8<br />

Atomicity, Consistency, Isolation, Durability) – garantiert. [COU]. Kein Kunde und auch kein<br />

Unternehmen würde jemals Geldverlust durch einen Systemausfall akzeptieren. Die<br />

Anforderungen der Verfügbarkeit und Zuverlässigkeit setzen voraus, dass alle Software- und<br />

Hardwarekomponenten zuverlässig sind. [ASO97]<br />

2.1.1.3 Vertraulichkeit<br />

Vertraulichkeit <strong>im</strong> elektronischen Zahlungsverkehr soll Schutz vor unbefugter<br />

Kenntnisnahme von Informationen gewähren. [ENG]<br />

Best<strong>im</strong>mte Informationen über die Transaktion wie beispielsweise der Transaktionsinhalt<br />

(Preis, Produkte), Verkäufer- und Käuferidentität dürfen nur den beteiligten Parteien bekannt<br />

sein, für die sie best<strong>im</strong>mt sind. Diese Informationen bleiben gegenüber Unbeteiligten streng<br />

vertraulich und gehe<strong>im</strong>. Es darf keine unberechtigte Person die Möglichkeit erlangen den<br />

Datenstrom mitzuhören. [CHA] Vor allem Käufer fordern eine solche Vertraulichkeit, da sie<br />

durch die Internetkäufe nicht zum „gläsernen“ Menschen werden möchten. Maßnahmen zum<br />

Schutz der Vertraulichkeit und darauf aufbauend ein guter Ruf, was die Vertraulichkeit<br />

betrifft, sind daher essentiell für die Kundenakzeptanz eines Zahlungsverfahrens.<br />

Schutzmaßnahmen müssen aber auch getroffen werden, dass unbefugte Dritte nicht an<br />

archivierte Zahlungsinformationen gelangen können. [SHA] Zahlungsinformationen, die auf<br />

den Systemen der Parteien einer Transaktion gespeichert sind, müssen vor Angriffen von<br />

Außen geschützt sein. Vor allem die Datenbanksysteme des Händlers oder<br />

Zahlungsdienstleisters, wo meist wertvolle Kundenlisten mit dazugehörigen Profilen lagern,<br />

sind für Angreifer ein lohnendes Ziel.<br />

2.1.1.4 Integrität<br />

Unter Integrität versteht man, dass Nachrichteninhalte nicht verändert wurden, d. h. jede in<br />

einem Zahlungssystem gesendete Nachricht muss mit der empfangenen Nachricht identisch<br />

sein. Besonders in Hinblick auf Zahlungstransaktionen muss die Unversehrtheit der<br />

übertragenen Daten gewährleistet werden, um zu verhindern, dass Dritte Daten abändern,<br />

duplizieren, einfügen oder zerstören können. [RAE]<br />

Integrität speziell in Bezug auf Zahlungssysteme bedeutet aber auch, dass kein „Geld“ von<br />

einem Partner transferiert wird, solange die Zahlung nicht explizit von ihm autorisiert ist.<br />

Diese Art der Integrität wird durch Autorisierungsverfahren oder durch besondere Gestaltung<br />

der Zahlungsabläufe erreicht. [ASO]<br />

2.1.1.5 Authentifizierung<br />

Prinzipiell ist es <strong>im</strong> Internet ohne weiteres möglich eine beliebige Identität vorzutäuschen, da<br />

jeder in der Lage ist, sich eine falsche Identität zuzulegen, z. b. in Form von willkürlichen email-Adressen.<br />

Der zu vermeidende Angriffsfall ist also ein bösartiger Dritter, der eine<br />

Nachricht an einen Empfänger sendet und sich dabei als ein anderer als er selbst ausgibt. Bei<br />

Kauftransaktionen muss man jedoch darauf vertrauen können, dass am Ende der Leitung<br />

tatsächlich derjenige sitzt, der er zu sein behauptet. Ein noch so verlockendes Kaufangebot<br />

wird für den Verkäufer unerheblich sein, wenn er sich der Identität des Käufers nicht absolut<br />

sicher sein kann. Für den elektronischen Zahlungsverkehr ist es eine Voraussetzung, dass die<br />

Person, die vorgibt, Urheber einer Nachricht zu sein, diese auch wirklich ist.<br />

Der Vorgang der Verifikation der Teilnehmer-Identitäten wird als Authentifizierung<br />

bezeichnet. Damit wird sichergestellt, dass die an der Zahlungstransaktion beteiligten Partner<br />

Zahlungssysteme <strong>im</strong> Internet


2 Kriterien von Zahlungssystemen 9<br />

auch diejenigen sind, für die sie sich ausgeben. Diese Eigenschaft wird als Authentizität<br />

benannt.<br />

Die Authentizität eines Teilnehmers kann durch nachfolgende Merkmalsbereiche<br />

erfolgen[MER02]:<br />

• Durch Wissen, das nur die betreffende Person in Anspruch nehmen kann.<br />

(Nutzererkennung, PIN-Code, Passwort)<br />

• Durch den Besitz eines Gegenstandes, der die erforderliche Information enthält<br />

(Magnetstreifenkarte, Chipkarte, ...)<br />

• Durch biometrische Merkmale, die die Person besitzt. (Fingerabdruck, St<strong>im</strong>menfrequenz,<br />

Irisscan)<br />

• Durch eine Kombination dieser Merkmale (Smart Cards mit PIN-Nummer)<br />

Die ersten zwei Möglichkeiten haben aber den Nachteil, dass die zu identifizierende Person<br />

eine Sache stets bei sich tragen oder etwas merken muss. Man muss sich sehr viele<br />

Zugangscodes <strong>im</strong> Alltagsleben merken. Angefangen vom PIN der Bankomatkarte bis hin zu<br />

den verschiedensten Passwörtern für unterschiedliche Zugänge wie E-Mail Accounts,<br />

Firmennetzwerk etc. Um opt<strong>im</strong>ale Sicherheit zu gewährleisten, müssen diese Passwörter auch<br />

noch in regelmäßigen Intervallen geändert werden.<br />

Die Identifizierung durch biometrische Merkmale erspart der zu identifizierenden Person<br />

zwar das Mitführen von Karten oder Merken von Codes, doch die auszuführende Messung ist<br />

noch in den meisten Fällen technisch unzuverlässig und kostenintensiv. [MAN] Bei der<br />

Zuordnung einer Person zu den in einer Datenbank gespeicherten Merkmalen besteht <strong>im</strong>mer<br />

das Problem, dass aufgrund veränderter Bedingungen (zum Beispiel Lichtverhältnisse,<br />

M<strong>im</strong>ik, Kopfhaltung) das Probemuster niemals 100% mit dem Referenzmuster<br />

übereinst<strong>im</strong>mt. [RAE]<br />

2.1.2 Nichtabstreitbarkeit<br />

Die Nicht-Abstreitbarkeit von Transaktionen ist bei Zahlungstransaktionen von wesentlicher<br />

Bedeutung, damit keiner der Beteiligten <strong>im</strong> Nachhinein die Transaktion rückgängig machen<br />

oder abstreiten kann. Die von einer Person signierten Daten haben für diese verbindlichen<br />

Charakter. Man unterscheidet zwischen drei Arten der Nicht-Abstreitbarkeit [HIM]:<br />

• Non-Repudation of Origin: Der Empfänger wird geschützt, falls der Sender behauptet, die<br />

Nachricht nicht oder mit einem anderen Inhalt erhalten zu haben.<br />

• Non-Repudation of Delivery: Der Empfänger kann nicht leugnen dem Sender eine<br />

best<strong>im</strong>mte Nachricht geschickt zu haben.<br />

• Non-Repudation of Submission: Es wird verhindert, dass ein Message Transfer System<br />

gegenüber dem Sender leugnen kann, eine zur Versendung best<strong>im</strong>mte Nachricht an den<br />

Transaktionspartner erhalten zu haben.<br />

Durch die Einbeziehung eines für beide Partner vertrauenswürdigen, unparteiischen Dritten<br />

(trusted third party) in alle Transaktionen kann sichergestellt werden, dass alle drei Arten der<br />

Non-Repudation erreicht werden. Die trusted third party hat die Aufgabe durch<br />

Protokollierung und Zertifizierung von Dokumenten, eine Transaktion verlässlich<br />

nachvollziehbar zu machen, um <strong>im</strong> Streitfall eine Handlung bestätigen zu können. [MER96]<br />

2.1.3 Kosten<br />

Allgemeine Erläuterung<br />

Zahlungssysteme <strong>im</strong> Internet


2 Kriterien von Zahlungssystemen 10<br />

Da es kein Standardverfahren zur Kostenbest<strong>im</strong>mung eines Softwarepakets gibt, ist es auch<br />

hier schwierig eine qualifizierte Abwägung der ePayment-Systeme untereinander<br />

vorzunehmen. Manche Anbieter best<strong>im</strong>men den Wert ihrer Dienstleistung über Disagio<br />

andere wiederum verlangen pro Transaktion Gebühren. Die Entscheidung welches<br />

Zahlungssystem günstiger ist als das andere, kann somit von vielen Faktoren abhängen die ein<br />

Anwender nur anhand einer individuellen Analyse seines Geschäftsmodells treffen kann. Im<br />

Folgenden werden daher mögliche Kostensfaktoren nur zur Illustration angeführt.<br />

Gebühren für Sicherheitszertifikate: Die Durchführung einer gesicherten Zahlungstransaktion<br />

erfordert entsprechende Verschlüsselungstechniken, die auf Protokollen basieren (siehe SSL<br />

Kapitel 2). Bei der Verschlüsselung die zwischen Client und Server stattfindet muss sich der<br />

Server durch ein Zertifikat eindeutig identifizieren. Die Ausstellung eines Zertifikates muss<br />

bei so genannten Zertifizierungsstellen beantragt werden. Für deren Nutzung fallen jährliche<br />

Gebühren an. [RUB]<br />

Transaktionskosten<br />

Neben der Sicherheit stellen die Transaktionskosten ein weiteres wichtiges<br />

Bewertungsmerkmal für die Entscheidung über die Zweckmäßigkeit des Einsatzes eines<br />

ePayment-Systems dar. Transaktionskosten fallen für jede Transaktion an und können in der<br />

Höhe stark variieren. Sie best<strong>im</strong>men nicht nur den Min<strong>im</strong>albetrag, den ein Benutzer bei jeder<br />

Transaktion zweckmäßigerweise umzusetzen hat, sondern auch das Gebiet, für das die<br />

Zahlungssysteme anzuwenden sind.<br />

Die Transaktionskosten definieren sich hierbei zum einen als Zeit, die für eine Transaktion<br />

benötigt wird, zum anderen als die finanziellen Ausgaben, die mit der weiteren Verarbeitung,<br />

den Hardwarekosten und anderen Aufwendungen verbunden sind, speziell den Schäden, die<br />

durch Missbrauch in einem best<strong>im</strong>mten System entstehen. [FUR]<br />

Transaktionskosten entscheiden in welchem Rahmen die einzelnen Zahlungssysteme sinnvoll<br />

eingesetzt werden können. Systeme mit hohen Transaktionskosten bei geringen<br />

Zahlungsbeträgen wären nicht wirtschaftlich. [STO] Für einen Zahlungsbetrag von 100 Euro<br />

sind die Kosten für eine Kreditkartenzahlung in der Höhe von 1 – 2 Euro akzeptabel, für<br />

einen Zahlungsbetrag von 1 Euro sicher nicht. Die Transaktionskosten bei der Abwicklung<br />

des Zahlungsverkehrs müssen in Relation zum Warenwert gesehen werden. Ein<br />

elektronisches Zahlungssystem wird sich nur dann etablieren können, wenn die fixen<br />

Transaktionskosten gering sind. Bei steigendem Transaktionsvolumen sinkt dadurch der<br />

prozentuelle Kostenanteil. Beispielsweise wird man sich keine Pizza <strong>im</strong> Wert von 6 Euro<br />

kaufen, wenn die Transaktionskosten 3 Euro ausmachen. Damit die Kosten möglichst gering<br />

bleiben ist auf der Anbieterseite Effizienz gefragt, damit die Spesen möglichst gering gehalten<br />

werden können. Gleichzeitig dürfen Transaktionen nicht sehr lange dauern, weil dadurch<br />

längere Onlinezeiten notwendig sind, die die Transaktionskosten erhöhen. [HIM]<br />

Zahlungssysteme zeichnen sich durch nachstehende drei Kategorien aus[FUR]:<br />

• Hohe Transaktionskosten entstehen wenn irgendein ein Teil der Transaktion nicht<br />

automatisiert, sondern manuell ausgeführt wird. Dadurch fallen lange Abarbeitungszeiten<br />

an, die in manchen Bereichen lästig und unakzeptabel sind.<br />

• Mittlere Transaktionskosten stehen zumeist mit Systemen in Verbindung die zwar<br />

vollständig automatisiert ablaufen, aber auch eine prompte Bestätigung des vom Händler<br />

anzunehmenden Betrags benötigen. Die Online-Verifikation benötigt neben der Zeit auch<br />

Zahlungssysteme <strong>im</strong> Internet


2 Kriterien von Zahlungssystemen 11<br />

noch dafür abgestellte Kommunikationskanäle. Solche Systeme erweisen sich erst als<br />

sinnvoll, wenn viele Transaktionen ausgeführt werden.<br />

• Niedrige Transaktionskosten ergeben sich, wenn die Online-Verifikation entfällt und die<br />

Hardware- und Kommunikationsausgaben senkt, indem man öffentliche Netze nutzt und<br />

auf teure Hardware verzichtet. Bei Telefonkartensystemen entfällt die Online-<br />

Verrechnung, da Telefonkarten <strong>im</strong> Voraus bezahlt werden müssen. Selbst auf eine<br />

Zugangkontrolle wird verzichtet, da sich der Aufwand bei kleinen Geldbeträgen nicht<br />

lohnt.<br />

SunkCosts: Das sind diejenigen Kosten, die bzgl. ihrer Höhe und ihrem Grunde nach ex post<br />

nicht mehr beeinflussbar sind und daher keinen Einfluss auf eine aktuell zu treffende<br />

Entscheidung haben. Die mit einer Investition verbundenen Investitionskosten werden in<br />

diesem Zusammenhang als sunk costs verstanden. Investitionskosten beinhalten nicht nur die<br />

ursprünglichen Anschaffungs- bzw. Herstellungskosten, sondern sämtliche Kosten, die für<br />

aktuell zu treffende Entscheidungen irrelevant sind, beispielsweise Kosten für die Entsorgung<br />

von alter Hardware.<br />

2.1.4 Rückverfolgbarkeit<br />

Ein ganz entscheidender Punkt bei der Auswahl eines Zahlungssystems <strong>im</strong> Internet ist<br />

sicherlich die Frage, ob jemand sämtliche Transaktionen überwachen und nachvollziehen<br />

beziehungsweise zurückverfolgen kann, oder ob es möglich ist anonym zu bleiben. Eine<br />

Transaktion erfolgt anonym, wenn keiner der Kommunikationspartner Kenntnis der Identität<br />

des anderen erlangt. [Merz96] An einer Transaktion sind normalerweise drei Parteien (Käufer,<br />

Verkäufer und eine dritte Instanz) beteiligt. Aus Gründen des Datenschutzes soll ein<br />

elektronisches Zahlungssystem eine ebenso große Anonymität gewährleisten wie Bargeld, um<br />

das Bedürfnis des privaten Nutzers nach Schutz der Privatsphäre zu erfüllen, denn je mehr<br />

Informationen über eine Person verfügbar sind, desto leichter kann mittels Verknüpfung<br />

dieser Daten ein Persönlichkeitsprofil erstellt werden, das von den Kunden unerwünscht ist.<br />

Die Anonymität widerspricht aber zugleich dem Bestreben nach Schutz vor Missbrauch eines<br />

Zahlungssystems. Sie erleichtert es, Transaktionen zu verschleiern und nicht nachvollziehbar<br />

zu machen. Es sind aber auch Situationen denkbar, bei denen der Nachweis einer erfolgten<br />

Transaktion gewünscht ist um beispielsweise vor Gericht beweisen zu können, dass eine<br />

Zahlung erfolgt ist. In solchen Fällen muss es möglich sein, nachzuvollziehen, wer an wen<br />

welchen Betrag gezahlt hat. Dazu müssen Informationen über Betrag, Empfänger, Datum und<br />

Verwendungszweck gespeichert werden. [TEI] Der Grad der Rückverfolgbarkeit einer<br />

Transaktion ist klassifizierbar, indem die Sichtbarkeit der einzelnen Parteien, konkret des<br />

Käufers, des Verkäufers und der dritten Instanz (in der Regel die Bank), untereinander und<br />

das Ausmaß des Informationsaustausches während der Zahlungsabwicklung in Betracht<br />

gezogen werden. Man unterscheidet zwischen 4 Stufen der Rückverfolgbarkeit: [FUR]<br />

• Uneingeschränkte Rückverfolgbarkeit<br />

• Eingeschränkte Rückverfolgbarkeit<br />

• Nicht rückverfolgbare Zahlungen<br />

• Benutzergesteuerte Rückverfolgbarkeit<br />

2.1.4.1 Uneingeschränkte Rückverfolgbarkeit<br />

Zahlungssysteme sind uneingeschränkt zurückverfolgbar, wenn Verkäufer und Bank die<br />

Identität des Käufers kennen. Der Käufer identifiziert sich bei jeder Transaktion gegenüber<br />

Zahlungssysteme <strong>im</strong> Internet


2 Kriterien von Zahlungssystemen 12<br />

dem Verkäufer. Betrag, Datum, Uhrzeit, Käufer und Verkäufer werden protokolliert. Die<br />

Bank kann genau alle Käufe nachvollziehen. Alle elektronischen Kreditkartenzahlungen<br />

basieren auf dieser vollständigen Nachvollziehbarkeit von Transaktionen, und bieten somit<br />

keinen Schutz der Privatsphäre.<br />

2.1.4.2 Eingeschränkte Rückverfolgbarkeit<br />

Ein Zahlungssystem erlaubt die eingeschränkte Rückverfolgbarkeit, wenn Zahlungen anonym<br />

bleiben, aber zusätzlich die Übermittlung einer "Referenztransaktion" erfolgen kann. So<br />

können best<strong>im</strong>mte Informationen ausgetauscht werden. Es wird also kein Protokoll geführt,<br />

aber trotzdem ist es möglich den Benutzer zu identifizieren. Als Beispiel wären hier Systeme<br />

zu nennen, die eine Kennung für eine Quelle, wie z. b. eine Kartennummer, austauschen.<br />

Dadurch können Zahlungen mit einem Benutzer in Verbindung gebracht werden. Der<br />

Benutzer selber kann identifiziert werden, wenn er bei einer Transaktion seinen Namen<br />

angibt.<br />

2.1.4.3 Nichtrückverfolgbare Zahlungen<br />

Die Grundvoraussetzung, ein Zahlungssystem als nichtrückverfolgbar einzustufen, liegt<br />

einerseits darin, dass keine Verbindung zwischen zwei Zahlungen hergestellt werden kann,<br />

und andererseits, dass nur der Zahlungsleistende Zugriff auf die Transaktionsdetails hat.<br />

Weder Zahlungsempfänger noch Bank kennen die Identität des Zahlungsleistenden. Wie<br />

Bargeld wird das Zahlungsmittel von der Bank beglaubigt, aber es ist nicht nachvollziehbar<br />

welche elektronische Banknote von wem ausgegeben wurde. Dies wird durch das Konzept<br />

der blinden Signatur erreicht.<br />

2.1.4.4 Benutzergesteuerte Rückverfolgbarkeit<br />

Bei der benutzergesteuerten Rückverfolgbarkeit best<strong>im</strong>mt man den Grad der Anonymität<br />

selbst. Bei dieser Variante ist die Transaktion generell nicht rückverfolgbar. Jede Zahlung<br />

besitzt ihre eigene elektronische Quittung, die verschlüsselt mit den zugehörigen<br />

Zahlungsdaten abgespeichert wird. Nur der Käufer besitzt den Schlüssel, um verschlüsselte<br />

Zahlungsdaten zu dechiffrieren. Somit kann er in best<strong>im</strong>mten Situationen die Anonymität<br />

aufheben.<br />

2.1.5 Teilbarkeit<br />

Teilbarkeit ist eine Eigenschaft, die <strong>im</strong> Gegensatz zu traditionellen Bargeldsystemen in<br />

elektronischen Zahlungssystemen erreichbar ist. Beträge können beliebig in wesentliche<br />

kleinere Teile aufgeteilt werden, wobei die Summe der Beträge der einzelnen Teilergebnisse<br />

wieder den ursprünglichen Betrag ergibt. [SIE]<br />

2.1.6 Online Verifikation<br />

Die Online Verifikation, der sofortige Datenabgleich mit den bei einer Bank abgelegten<br />

kundenkontospezifischen Informationen, erfolgt aus zweierlei Gründen: entweder um<br />

abzuklären, ob der Zahlungsvorgang als Ganzes Gültigkeit hat, oder um festzustellen ob der<br />

Kontostand des potentiellen Käufers eine Geldüberweisung an den Händler <strong>im</strong> geplanten<br />

Ausmaß zulässt. Allerdings sind in der Regel elektronische Zahlungssysteme nicht gerade<br />

diejenigen, die geringe Transaktionskosten und schnelle Bearbeitungszeiten ihr eigen nennen<br />

können. Das Internet stellt für die Zahlungssysteme mit Clearing-Notwendigkeit sicherlich<br />

einen Vorteil dar, da es gleichzeitig die für die Kommunikation notwendige Infrastruktur<br />

Zahlungssysteme <strong>im</strong> Internet


2 Kriterien von Zahlungssystemen 13<br />

bereitstellt, sodass für die Online Verifikation keine zusätzlichen Kommunikationskanäle<br />

aufgebaut werden müssen. Durch den Einsatz von fälschungssicherer Hardware wäre es<br />

möglich auf die Online Prüfung zugunsten einer Offline Prüfung zu verzichten. [FUR]<br />

2.1.7 Akzeptanzfähigkeit<br />

Akzeptanzfähigkeit steht nicht für die Akzeptanz des elektronischen Zahlungssystems seitens<br />

der Benutzer. Sie beinhaltet, dass ein Zahlungssystem nicht nur auf eine Bank beschränkt ist,<br />

sondern dass auch elektronische Geldbeträge, die von einer Bank ausgegeben werden, auch<br />

von anderen Banken angenommen werden. Die meisten Systeme sind noch so beschaffen,<br />

dass sie von einer Bank beziehungsweise einem Clearingunternehmen unterstützt werden.<br />

Allerdings besteht insofern Akzeptanz, als dass andere Banken dann mit der jeweils nötigen<br />

Bank kommunizieren. [FUR]<br />

2.2 Kundenseitige Kriterien<br />

2.2.1 Übertragbarkeit<br />

Im realen Handel ist echtes Geld übertragbar, sodass mit anderen Worten die Möglichkeit<br />

gegeben ist, ohne Einschaltung eines Geldinstitutes den Geldbetrag zu transferieren. Die<br />

gleiche, nur schwer zu erfüllende Anforderung wird auch an elektronisches Geld<br />

beziehungsweise an die dahinter stehenden elektronischen Zahlungssysteme gestellt.<br />

Allerdings ist es zum jetzigen Zeitpunkt mit den zur Verfügung stehenden kryptographischen<br />

Methoden nicht machbar, ohne Verlust der Sicherheit uneingeschränkt übertragbare<br />

Geldbeträge über elektronische Zahlungssysteme weiterzuleiten. [FUR]<br />

2.2.2 Usability<br />

Damit ein Zahlungssystem von einer breiten Händlermasse eingesetzt und von vielen Käufern<br />

akzeptiert und verwendet wird, muss es benutzerfreundlich sein.[ABR] Die<br />

Benutzerfreundlichkeit ist ein äußerst wichtiges Kriterium für den potentiellen Benutzer bei<br />

der Wahl eines Zahlungsverfahrens. Zahlungssysteme werden nur auf breiter Basis<br />

angenommen werden, wenn sie ein hochwertiges Benutzererlebnis bieten, d. h. über eine<br />

einfache und bequeme Bedienbarkeit verfügen und die Bezahlung schnell vor sich geht.<br />

[SCH] u. [GOR] Die Menüführung sollte für den durchschnittlich versierten Benutzer leicht<br />

zu verstehen sein und sollte auf allen Plattformen und Endgeräten möglichst nach dem<br />

gleichem Schema aufgebaut sein. [HIM] Der Einstieg in die neue Technologie wird dadurch<br />

wesentlich erleichtert. Wenn die Bedienung des Zahlungssystems mit großer Anstrengung,<br />

Zeitaufwand, oder Trainingsaufwand verbunden ist, wird der Benutzer den Service<br />

höchstwahrscheinlich nicht mehr wiederverwenden. Für ein Zahlungssystem <strong>im</strong> Internet, bei<br />

dem hauptsächlich kleine Beträge bezahlt werden, sollte es möglich sein, best<strong>im</strong>mte<br />

Zahlungen so zu automatisieren, dass der Benutzer einer Bezahlung lediglich zust<strong>im</strong>men oder<br />

sie ablehnen muss, zum Beispiel durch Auswahl in einem Dialogfenster. Komplexe<br />

Registrierungsverfahren und aufwendige Installationen von Software werden den Kunden<br />

ebenfalls davon abhalten, dieses System zu benutzen.<br />

2.2.3 Registrierung<br />

Der Registrierungs- und Installationsvorgang müssen so strukturiert sein, dass der<br />

„Durchschnittsbenutzer“ die Prozedur ohne spezielle Kenntnisse in annehmbarer Zeit selbst<br />

durchführen kann. Ein weiterer wesentlicher Aspekt liegt der Freischaltung des Systems<br />

Zahlungssysteme <strong>im</strong> Internet


2 Kriterien von Zahlungssystemen 14<br />

zugrunde. Zugangsberechtigungen sollten, wenn möglich, online und sofort nach der<br />

Registrierung versendet werden. Käufe <strong>im</strong> Internet erfolgen häufig spontan. Der Benutzer<br />

sieht etwas und möchte es sofort an Ort und Stelle kaufen. Dabei n<strong>im</strong>mt der Benutzer den<br />

Installationsaufwand für ein Zahlungsverfahren eher auf sich, wenn er das System<br />

anschließend sofort anwenden kann und es ihm in einem konkreten Fall einen Mehrwert<br />

bringt. Kann er das System erst Tage nach der Installation beziehungsweise Registrierung<br />

anwenden, verzichtet er möglicherweise auf die Installation.<br />

2.2.4 Universalität<br />

Der Nutzen eines Bezahlungssytems hängt natürlich in sehr starkem Maße davon ab, wo man<br />

damit einkaufen kann. Wenn ein Bezahlungsverfahren nur für eine einzige best<strong>im</strong>mte<br />

Einkaufssituation die Bezahlung erlaubt, dann ist es unwahrscheinlich, dass es sich<br />

durchsetzen wird. Anzustreben ist daher ein Zahlungssystem, das sowohl <strong>im</strong> Internet als auch<br />

bei Einkäufen vor Ort eingesetzt werden kann.<br />

Ein Händler strebt stets danach seine Ware zu verkaufen und wenn die Anzahl derer, die ein<br />

System verwenden, zu gering ist, lohnt sich möglicherweise der Aufwand, ein<br />

Bezahlungssystem anzubieten, auch nicht. Daher ist für einen erfolgreichen Einsatz eines<br />

Zahlungssystems auch die Kundenbasis, das heißt die Anzahl derer, die davon Gebrauch<br />

machen können, von Bedeutung.<br />

2.3 Händlerseitige Kriterien<br />

2.3.1 Implementierungseinfachheit<br />

Für den Händler ist es von großer Bedeutung, dass sich das neue System unabhängig von<br />

eventuell bereits verwendeten Soft- und Hardwarekomponenten nahtlos in das bisherige<br />

Zahlungsgeschäft einfügt. Dies kann nur durch einen modularen Aufbau gewährleistet<br />

werden. Das heißt, die neue Komponente integriert sich über ihre Schnittstellen in eine Kette<br />

vorhandener Module. Dadurch fallen weitere Investitionskosten nicht ins Kalkül. Das<br />

bisherige System kann beibehalten werden und deren Funktionalität muss durch die<br />

Erweiterung nicht erneut entwickelt werden. Aber ebenso kann auf sukzessivem Weg der<br />

Umbau in eine effektivere Technologie gewährleistet werden. Die Gefahr, die eine radikale<br />

Systemveränderung mit sich bringt, wird verhindert. [KET]<br />

2.3.2 Zahlungssicherheit<br />

Eine entscheidende Rolle be<strong>im</strong> Einsatz von Internet-Zahlungssystemen kommt der<br />

Min<strong>im</strong>ierung von Zahlungsfällen für den Händler zu. Dabei können die Zahlungsausfälle auf<br />

zwei Ursachen zurückzuführen sein: Erstens kann der Kunde die Zahlung der bestellten Ware<br />

verweigern und zweitens führt auch ein Missbrauch von Abrechnungsdaten zum Verlust von<br />

Zahlungsforderungen. [KET]<br />

Der Grad der Abstreitbarkeit, die Authentifizierbarkeit und die Datensicherheit von<br />

Zahlungen die unter 1.2 schon erklärt wurden, gibt dem Händler die Sicherheit, dass eine <strong>im</strong><br />

Internet abgewickelte Zahlungstransaktion auch zur tatsächlichen Gutschrift auf seinem<br />

Konto führt. Programmiertechnisch müssen die Ansprüche der Zahlungssicherheit vor allem<br />

durch Plausibilitäts- und Bonitätskontrollen verwirklicht werden.<br />

Plausibilitätskontrollen beschäftigen sich mit Abweichungen des Zahlungsverkehrs von der<br />

Norm. Tritt zum Beispiel plötzlich eine übertrieben hohe Geldtransaktion auf so muss sie<br />

Zahlungssysteme <strong>im</strong> Internet


2 Kriterien von Zahlungssystemen 15<br />

nach Gründen hierfür suchen. Syntaktische Kontrollen wie zum Beispiel korrekte<br />

Adressangaben, Telefonnummern usw. fallen ebenfalls unter ihren Zuständigkeitsbereich.<br />

Bei Bonitätskontrollen, die Händler selber durchführen, besteht ein Lösungsansatz zur<br />

Reduzierung der Rückbuchungen darin, Kunden mit bekannt schlechter Zahlungsmoral auf<br />

Sperrlisten einzutragen. Diese können dann entweder überhaupt nicht mehr bestellen oder es<br />

stehen ihnen best<strong>im</strong>mte Zahlungsverfahren nicht mehr zur Verfügung. Alternativ können<br />

Bonitätsprüfungen auch automatisiert mit Hilfe von Wirtschaftsauskunfteien durchgeführt<br />

werden. In Österreich bietet der Kreditschutzverband 1870 solche Auskunftsdienste an.<br />

[ROB]<br />

2.3.3 Transaktionsbearbeitung<br />

Allen modernen Zahlungssystemen ist es eigen alle Transaktionen vollkommen automatisiert<br />

abwickeln zu können. Anhand einer getätigten Internet-Zahlung braucht sich der Händler<br />

nicht mehr um die korrekte Abwicklung seiner Gutschrift für sein Konto sowie der Kunde<br />

nicht mehr für die korrekte Abbuchung aus seinem Saldo zu sorgen. Es können aber auch<br />

Fälle eintreten, die den Händler zwingen eine einzelne nachverfolgbare Transaktion zu<br />

korrigieren. Es können zum Beispiel nachträglich Stornierungen von Bezahlungen,<br />

Verschiebungen von Auslieferterminen so einen Schritt erfordern. Das System muss also<br />

Schnittstellen bereitstellen können, die dem Händler diese Möglichkeiten eröffnen<br />

Transaktionen zu korrigieren. Je automatisierter die Transaktionsabwicklung eingesetzt<br />

werden kann, desto geringer sind die internen Verwaltungs- und Kommunikationskosten, die<br />

mit dem Einsatz des Zahlungssystems verbunden sind.<br />

Zahlungssysteme <strong>im</strong> Internet


3 Basiskonzepte von Zahlungssystemen <strong>im</strong> Internet 16<br />

3 Basiskonzepte von Zahlungssystemen <strong>im</strong> Internet<br />

Es gibt mehrere Kriterien e-payment Verfahren zu klassifizieren. Das Problem besteht darin,<br />

dass diese Kriterien zueinander nicht in eine obligatorisch hierarchische Beziehung zu bringen<br />

sind. Jedes Klassifizierungsschema steht für sich alleine. Daher besteht kein zwingender<br />

funktionaler Zusammenhang eines Basiskonzepts zu einem Klassifizierungsschema. Die<br />

einzelnen Charakteristika des Prozessablaufs eines e-payment Verfahrens können anhand<br />

dieser Kategorien frei best<strong>im</strong>mt werden. Die Klassifizierungskriterien welche schlussendlich<br />

die Merkmale eines Zahlungssystems ausmachen muss der Softwareentwickler anhand<br />

differierender Präferenzen <strong>im</strong> Entwurfsstadium festlegen. Differierende Präferenzen bedeutet,<br />

dass von verschiedenen Nutzern beziehungsweise bei verschiedenen Anwendungen<br />

verschiedene Ausprägungen des Merkmals vorgezogen werden. [TEI] Da sich der<br />

Beobachtungsgegenstand aufgrund der rasanten Entwicklung in diesem komplexen Bereich<br />

zusehends verändert, erhebt die folgende Aufstellung keinen Anspruch auf Vollständigkeit.<br />

Bevor ich auf die weiteren Klassifizierungsmerkmale und die Basiskonzepte eingehe, soll<br />

zuvor noch exemplarisch gezeigt werden, was ein Internet Zahlungssystem leisten muss und<br />

was hinter einer Handelstransaktion <strong>im</strong> Internet steckt.<br />

Abbildung 3-1 skizziert den prinzipiellen Ablauf eines Online Kaufes über das Internet.<br />

Abbildung 3-1: prinzipielle Bestandteile einer Handelstransaktion <strong>im</strong> Internet[STO]<br />

Der Kunde veranlasst einen Bestellvorgang über das Internet. Hierdurch werden zwei<br />

gegenläufige Prozesse gestartet:<br />

• Warenfluss<br />

• Finanzfluss<br />

Der Händler muss die Lieferung der bestellten Produkte an den Kunden auslösen und der<br />

Kunde muss <strong>im</strong> Gegenzug die Bezahlung des Händlers vornehmen. [STO] Dabei müssen die<br />

Zahlungssysteme den gleichen Zweck erfüllen wie das reale Geld, nämlich der<br />

Wertaufbewahrung dienen, einen Wertmaßstab setzten, eine Tauschfunktion beinhalten und<br />

eine Rechnungseinheit bilden. [PER]<br />

Ein Internet Zahlungssystem umfasst alle Systeme, in welchen der Transfer der<br />

elektronischen Daten über das Internet, ein öffentlich zugängliches Netzwerksystem, erfolgt.<br />

[AHU97]<br />

Zahlungssysteme <strong>im</strong> Internet


3 Basiskonzepte von Zahlungssystemen <strong>im</strong> Internet 17<br />

3.1 Unterscheidungskriterien von Zahlungssystemen<br />

Es werden folgende Unterscheidungskriterien erläutert:<br />

• Zahlungszeitpunkt: pre-paid(Vorausbelastung verlangt), post-paid(nachträgliche Zahlung)<br />

pay-now (sofortige Belastung)<br />

• Zahlungsvolumen: Micropayment (bis EUR 10,--) - Macropayment<br />

• Zahlungskommunikation: Online - Offline<br />

3.1.1 Zahlungszeitpunkt<br />

Eine erste Unterscheidung kann man bezüglich dem Zeitpunkt der Zahlung vornehmen. Die<br />

Zahlungsfinalität ist ein Ansatz zur Unterscheidung und Bewertung verschiedener Internet-<br />

Bezahlmodelle aus Kundensicht und geht der Frage nach, wann der Geldwert tatsächlich den<br />

Zahlungspflichtigen verlässt. Dabei kann man Prepaid-, Paynow- und Postpaid Systeme<br />

unterscheiden. [KÖH]<br />

In pre-paid Zahlungssystemen wird dem Kunden ein best<strong>im</strong>mter Geldbetrag abgezogen,<br />

bevor die Zahlung erfolgt. Üblicherweise wird dieser Betrag vom Bankkonto des Zahlenden<br />

abgehoben oder bar bezahlt. Die Verwahrung des Geldbetrages erfolgt auf einem Kartenchip<br />

oder einem virtuellem Konto. Dieser Betrag kann später für Zahlungen benutzt werden, die<br />

mit Hilfe einer Geldkarte (z.B. Telefonkarte) getätigt werden. Diese Idee eines prepaid-<br />

Zahlungsmittels ist nicht neu, sondern wird schon seit Jahren sehr erfolgreich <strong>im</strong><br />

Mobilfunkbereich eingesetzt. Hierbei wird ein Betrag auf die Geldkarte geladen, der dann in<br />

einzelnen Schritten verbraucht werden kann. Das heißt, es entsteht hier eine Zeitspanne<br />

zwischen dem Einzahlen des Geldes und der Ausgabe. Bekannt ist dies bereits in der realen<br />

Welt be<strong>im</strong> Bezahlen von Parkplatzgebühren oder Bustickets mit einer Geldkarte. (Meistens in<br />

Form eines Chips auf der EC-Karte) Geleistete Zahlungen in prepaid-Systemen können nicht<br />

mehr rückgängig gemacht werden. Damit entfällt die Notwendigkeit einer Zahlungsgarantie<br />

und auch die Erfordernis, dass der Zahlungsempfänger den Zahlungspflichtigen wegen<br />

eventuell notwendiger Maßnahmen zur Einbringung seiner Forderungen kennen muss. Bei<br />

prepaid-Verfahren kann also dieselbe Anonymität der Zahlung wie be<strong>im</strong> Bargeld hergestellt<br />

werden.[KET]<br />

pay-now meint, dass die Zahlung synchron erfolgen muss. Diese Transaktion führt sofort<br />

be<strong>im</strong> Auslösen der Zahlung zu einer Belastung auf dem Bankkonto des Kunden. Das heißt<br />

eine „Zwischenlagerung“ des Geldes ist nicht nötig. Ein Beispiel hierfür ist die Euroscheck-<br />

Karte. Als Nachteil erweist sich, dass die Bank in jede Transaktion eingebunden werden muss<br />

In post-paid Zahlungssystemen, wie z. b. Scheck- oder Kreditkartensystemen, wird dem<br />

Zahlungsempfänger der Betrag auf sein Konto gutgeschrieben, bevor das Konto des<br />

zahlenden belastet wird. Die Zahlung ist somit eher eine Zahlungsanweisung, da erst nach<br />

einem best<strong>im</strong>mten Zeitintervall die Abbuchung auf dem Bankkonto des Kunden erfolgt. Die<br />

Vorgehensweise dabei ist folgende: Der Kunde überträgt seine Kreditkartendaten wie Name,<br />

Kreditkartennummer und Ablaufdatum an den Anbieter des Produktes. Dieser rechnet den<br />

Betrag mit der Kreditkartengesellschaft ab und der Kunde erhält am Ende des Monats eine<br />

Rechnung/Abbuchung von der Kreditkartengesellschaft. [ILL]<br />

Die vorausbezahlten Zahlungssysteme sind dem bargeldähnlichen (cash-like) Modell,<br />

dargestellt in Abbildung 3-2, zugeordnet. Die sofort-bezahlten und später-bezahlten<br />

Zahlungssysteme <strong>im</strong> Internet


3 Basiskonzepte von Zahlungssystemen <strong>im</strong> Internet 18<br />

Zahlungssyteme gehören in Bezug auf das Zahlungsprotokoll dem scheckähnlichen (chequelike)<br />

bzw. kontenbasierten (account-based) Modell, dargestellt in Abbildung 3-3, an. Dieses<br />

Modell ist scheckähnlich, da <strong>im</strong>mer ein Zeichen (Notifikation), wie ein Scheck oder eine<br />

Kreditkarte, welches der Zahlende von seiner Bank (Issuer) erhält, vom Zahlenden zum<br />

Zahlungsempfänger übermittelt wird.<br />

Beide Modelle sind direkte Zahlungssysteme, d. h. eine Zahlung benötigt die Interaktion<br />

zwischen Zahlendem und Zahlungsempfänger. Bei indirekten Systemen wird die Zahlung<br />

vom Zahlenden bzw. Zahlungsempfänger initiiert, ohne den Zahlungsempfänger bzw.<br />

Zahlenden dabei online zu kontaktieren, wie beispielsweise eine Bezahlung mittels eines<br />

Überweisungsauftrags. [ASO97]<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Abbildung 3-2: Direktes bargeldähnliches Zahlungssystem [ASO97]<br />

Abbildung 3-3: Direktes scheckähnliches (kontenbasiertes) Zahlungssystem [ASO97]


3 Basiskonzepte von Zahlungssystemen <strong>im</strong> Internet 19<br />

3.1.2 Zahlungsvolumen<br />

Eine weitere Unterscheidung wird bezüglich der Zahlungshöhe vorgenommen. Hierfür kann<br />

man die Zahlungssysteme in Macropayment und Micropayment unterscheiden. Beide<br />

Bereiche stellen unterschiedlich Ansprüche an die Sicherheitsanforderungen der Verfahren<br />

und an die Höhe der Transaktionskosten pro Zahlung. [KON] Die Abwicklung von kleinen<br />

Beträgen <strong>im</strong> Internet spielt eine besondere Rolle, wenn Produkte zu kleinen Preisen und in<br />

großen Einzelstückzahlen online ausgeliefert werden. Es werden deutlich kleinere<br />

„Inhalteeinheiten“ als <strong>im</strong> physikalischen Vertrieb angeboten wie zum Beispiel Musikstücke<br />

statt der CD, einzelne Artikel statt des Fachbuches und Datenbankabfragen statt des 40bändigen<br />

Universallexikons. [KET]<br />

Micropayments<br />

Bei Micropayments handelt es sich um Zahlungssysteme, die für sehr kleine Beträge bis<br />

hinunter zu einzelnen Cent konzipiert sind. Die Hauptanforderungen von Micropayments<br />

liegen in der einfachen Bedienbarkeit durch den Benutzer und niedrige Transaktionskosten<br />

für den Anbieter. [KON] Um diese Anforderungen zu erfüllen, darf der gesamte<br />

Transaktionsablauf nicht zu zeitaufwendig, kostenintensiv und komplex sein. Dafür muss<br />

jedoch oft auf ausgeklügelte Sicherheitsmechanismen verzichtet werden.[ASO99] Aufgrund<br />

der Höhe der Beträge ist es durchaus vertretbar, nicht für jede Transaktion absolute Sicherheit<br />

zu garantieren. Für Benutzer kommt es wesentlich günstiger, eventuell 30 Cent für eine<br />

verlorene Transaktion doppelt zu bezahlen, als wenn die Verkäufer höhere<br />

Transaktionskosten in Rechnung stellen, um rentabel arbeiten zu können. Immer mehr<br />

Content-Anbieter <strong>im</strong> Internet merken, dass die „Alles-umsonst Strategie“, nur über Werbe-<br />

Banner Profit zu machen, nicht mehr aufgeht. Viele Angebote <strong>im</strong> Internet wie zum Beispiel<br />

individuelle Wirtschaftsinformationen, Börsenkurse in Echtzeit von Presse- und<br />

Bildagenturen, MP3-Songs oder Datenbankanfragen sind zu gut, um auf Dauer hergeschenkt<br />

zu werden. [AON]<br />

Eine Studie von Fittkau maas [ROB1] kommt zur Erkenntnis, dass sich in Zukunft kaum<br />

mehr ein Internetanbieter leisten kann, seine Services kostenfrei anzubieten. Dieser zwingt die<br />

Anbindung an ein Micropaymentverfahren. Die Nachrage nach solchen Systemen wird daher<br />

in Zukunft eher ansteigen. Trotz dieser für den Kunden unpopulären Eigenschaft scheint seine<br />

Zahlungsbereitschaft zuzunehmen, solange sich dieser Preisanstieg in moderaten Bahnen<br />

bewegt.<br />

Zahlungssysteme <strong>im</strong> Internet


3 Basiskonzepte von Zahlungssystemen <strong>im</strong> Internet 20<br />

Abbildung 3-4: Zahlungsbereitschaft für best<strong>im</strong>mte Online-Informationen (in %) [ROB1]<br />

Micropaymentsysteme funktionieren darin, dass nicht bei jedem Kauf eine echte<br />

Zahlungstransaktion stattfindet, sondern entweder die Kleinbeträge irgendwo aufsummiert<br />

werden, bevor die Zahlung erfolgt bzw. von vorausbezahlten Guthaben subtrahiert werden.<br />

[BÖH] Im Grundaufbau bestehen diese <strong>im</strong> Wesentlichen aus drei Parteien: der Kunde, der<br />

Händler, der Brokat. Kunde und Verkäufer agieren in der klassischen Rollenverteilung eines<br />

traditionellen Zahlungsverfahrens. Der Broker leitet den Zahlungsablauf dahingehend, dass er<br />

das Zahlungsverfahren zur Verfügung stellt und dafür sorgt, dass die Geldtransaktionen<br />

regulär ablaufen. (wie Überweisung, Bonitätskontrolle, Legalität) [LEE]<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Abbildung 3-5: Basisarchitektur Micropayment [LEE]<br />

Macropayments<br />

Unter Macropayments fallen alle Zahlungen die betragsmäßig oberhalb der Micropayments<br />

liegen. Hier stehen die Sicherheitsaspekte aller beteiligten Parteien <strong>im</strong> Vordergrund. Bei<br />

Zahlungen mit hohem Wert sind entsprechende Sicherheitsmaßnahmen enorm wichtig. Es<br />

kommen aufwendige Verschlüsselungs-, Authentifizierungs- und Validierungsverfahren zur<br />

Anwendung. Diese Verfahren verursachen hohe Eigenkosten, so dass sie sich auch nur bei<br />

Zahlungen mit hohen Beträgen lohnen. Diese Verfahren laufen prinzipiell nicht mehr über<br />

frei wählbare Kunden- Händlerbeziehungen sondern nur mehr über Kunden deren Bonität<br />

durch den Besitz einer Kreditkarte gewährleistet wird und durch Händler die einen<br />

Zahlungsablauf über diese Schiene zulassen. Dem Sicherheitsaspekt wird durch<br />

Gewährleistung moderner Protokolle (Set, SSL) genüge getan. [WEB]<br />

Sicherheitsprotokolle<br />

Für die verschiedenen Dienste und Aufgaben <strong>im</strong> Rahmen der Datenübertragung über das<br />

Internet stehen unterschiedliche Übertragungsprotokolle zur Verfügung, die eine sichere<br />

Kommunikation von Client-Server-Systemen erlauben und Zahlungstransaktionen,<br />

insbesondere Kreditkartenzahlungen, sicherer machen. Im Laufe der Entwicklungsgeschichte<br />

sicherheitsbasierter Transaktionen wurden viele Protokolle entwickelt. Sie bieten nicht nur die<br />

Möglichkeit, den Datenstrom zwischen Client und Server zu verschlüsseln, sondern dienen<br />

auch der Authentifizierung von Kommunikationspartnern <strong>im</strong> WWW. Besondere Wichtigkeit<br />

erlangt haben bis dato nur SSL und SET.<br />

SSL<br />

Das Secure Socket Layer (SSL) Protokoll wurde von der Netscape Communications<br />

Corporation <strong>im</strong> Jahre 1994 entwickelt und hat mittlerweile eine breite Akzeptanz gefunden,


3 Basiskonzepte von Zahlungssystemen <strong>im</strong> Internet 21<br />

weil es von allen wichtigen Webbrowsern sowie von anderen Software- und Hardware<br />

Protokollen unterstützt wird. SSL ist ein Sicherheitsprotokoll und dient der sicheren<br />

Kommunikation zwischen zwei Parteien. Auf der einen Seite steht der Client, der in der Lage<br />

ist, die Daten vor dem Versenden an einen Server zu verschlüsseln und auf der anderen Seite<br />

steht der Server, der <strong>im</strong>stande ist, die zuvor verschlüsselte Botschaft zu entschlüsseln und die<br />

ursprünglichen Daten zu lesen. [BUR] Im ISO/OSI Schichtenmodell ist SSL zwischen der<br />

Transportprotokollebene und der Anwendungsprotokollebene angesiedelt und erweitert das<br />

verwendete Transportprotokoll um einen gesicherten Übertragungskanal. Der<br />

Anwendungsprotokollebene ist das SSL Record Protocol unterlagert, das die vertrauliche<br />

Übertragung der Daten durchführt. Da SSL auf einer der Anwendungsschicht vorgelagerten<br />

Ebene arbeitet, können alle Anwendungsprotokolle wie etwa http, FTP, Telnet usw.<br />

transaprent oberhalb von SSL verwendet werden. Durch die Verwendung von TCP als<br />

Transportprotokoll kann eine garantierte Zustellung der Datenpakete sichergestellt werden.<br />

[COU] Der Einsatz von SSL wird durch einen eigenen URL-Identifier https:// sichtbar<br />

gemacht und läuft bei http-Übertragungen auf Port 443. Eine Kommunikationsverbindung,<br />

die durch SSL gesichert wird, beginnt <strong>im</strong>mer mit dem Abst<strong>im</strong>mungsprozess dem so<br />

genannten „Handshake“ zwischen Client und Server. Es dient zur Authentifizierung des<br />

Servers gegenüber dem Client und der Vereinbarung über Session Keys durch öffentliche<br />

Verschlüsselungsverfahren die für die sichere Datenübertragung verwendet werden. Bei SSL<br />

kommen zwei grundsätzlich unterschiedliche kryptografische Algorithmen zum Einsatz: Zum<br />

ersten das public-Key-Verfahren zur Authentifizierung der Kommunikationspartner sowie<br />

zum Austausch eines gehe<strong>im</strong>en Schlüssels für die symmetrische Verschlüsselung der<br />

Anwendungsdaten und zweitens ein symmetrisches Verfahren, das mit dem gehe<strong>im</strong>en<br />

Schlüssel die Daten auf der Ebene des SSL Record Protocols verschlüsselt. [LEP]<br />

SET<br />

SET steht für Secure Electronic Transaction und ist ein weltweiter, offener Sicherheitsstandard<br />

der ausschließlich für den Schutz von Finanztransaktionen in offenen Netzen wie<br />

dem Internet zum Einsatz kommt. Das SET-Protokoll wurde von den großen Kreditkartengesellschaften<br />

(VISA und MASTERCARD) in Zusammenarbeit mit namhaften IT-<br />

Unternehmen (GTE, IBM, Microsoft, Netscape, SAIC, Terisa,Verisign etc.) nach<br />

mehrjähriger Entwicklungsarbeit Anfang 1996 der Öffentlichkeit präsentiert. [AMO]<br />

Vermarktet wird SET ® von der durch MasterCard und Visa International am 19.12.1997<br />

gegründeten Firma SET Secure Electronic Transaction LLC (kurz: SETCo). SET ist für alle<br />

Zahlungssysteme die es verwenden wollen offen und verfügbar. Bedingt durch die<br />

Autorenschaft von MasterCard und Visa konzentriert sich SET jedoch auf Online-Einkäufe,<br />

die per Kreditkarte abgerechnet werden. Im Gegensatz zu SSL umfasst SET die sichere<br />

Abwicklung kompletter Kaufvorgänge – von der Bestellung und Zahlung bis hin zur digitalen<br />

Quittung und verwendet eine Hierarchie digitaler Zertifikate, um alle an einer SET-<br />

Transaktion beteiligten Parteien (Karteninhaber, Händler, Bank) auf sichere Art und Weise<br />

zu authentifizieren. Dadurch ist allen Transaktionsteilnehmern möglich, den jeweiligen<br />

Transaktionspartner auch über ein offenes und ungesichertes Medium wie das Internet sicher<br />

zu identifizieren.<br />

SET zielt darauf ab, alle Parteien, die in einen Zahlungsvorgang involviert sind, zu<br />

authentifizieren. Mit SET werden insgesamt 7 Ziele verfolgt die in der Business Spezifikation<br />

definiert sind. Darunter fallen unter anderem die Sicherung der Integrität aller übermittelter<br />

Daten durch digitale Signaturen oder die Wahrung der Vertraulichkeit der übermittelten<br />

Zahlungssysteme <strong>im</strong> Internet


3 Basiskonzepte von Zahlungssystemen <strong>im</strong> Internet 22<br />

Information durch Nachrichtenverschlüsselung und wie bereits erwähnt die Authentifizierung<br />

der Parteien durch Zertifikate. [VISA]<br />

In Abbildung 3-6 werden Zukunftsperspektiven sowohl der Micro- als auch der<br />

Macropayment Verfahren demonstriert. Es geht hervor, dass deren Marktsättigung noch lange<br />

nicht erreicht sein wird. Die Frage, ob sich noch weitere Verfahren als Standard etablieren<br />

werden, oder ob es weiterhin ein Kampf der Systeme geben wird, bleibt allerdings offen.<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Abbildung 3-6: Umsatzentwicklung Miro-/Macropayment [BEC]<br />

3.1.3 Zahlungskommunikation<br />

Ein weiteres wichtiges Klassifizierungsmerkmal wird nach dem Ort der Autorisierung<br />

vorgenommen. Man unterscheidet zwischen Online und Offline-Kommunikation. Im Online-<br />

Betrieb sind der Zahlende und der Zahlungsempfänger mit einem dritten Teilnehmer<br />

(üblicherweise dem Issuer oder Acquirer) online verbunden, während es <strong>im</strong> offline-Betrieb<br />

keine Notwendigkeit gibt neben Kunde und Händler noch eine dritte Instanz an der Zahlung<br />

online zu beteiligen. [ASO96] Online Systeme werden meist als sicherer betrachtet, da der<br />

dritte Teilnehmer sicherstellen kann, dass der Zahlende den Geldbetrag auch tatsächlich<br />

besitzt.[WEB] Bei den Offline-Bezahlsystemen kann eine solche Überprüfung nicht<br />

durchgeführt werden. Daten, die den Geldbetrag enthalten, müssen daher auf andere Weise<br />

vor Manipulation geschützt werden. In offline Systemen wird die Gefahr der<br />

Widerverwendbarkeit von virtuellem Geld durch den Einsatz von fälschungssicherer<br />

Hardware wie Smart Cards verhindert. [ASO96]


3 Basiskonzepte von Zahlungssystemen <strong>im</strong> Internet 23<br />

3.2 Einteilung der Internet Zahlungssysteme<br />

Um die Übersicht über die zahlreichen Verfahren zu gewährleisten, haltet sich die Arbeit<br />

systematisch an das in Abbildung 3-7 entworfene Schema.<br />

Offline-Zahlung<br />

Handygestützt Inkassosysteme<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Bankeinzug<br />

Einzugsermächtigung<br />

Internet-<br />

Zahlungssysteme<br />

Kreditkartenbasiert<br />

Smart Cards<br />

Abbildung 3-7: Basiskonzepte für Interneteinkauf [BEC]<br />

Guthabenbasiert<br />

elekronisches<br />

Geld<br />

3.2.1 Offline-Zahlung<br />

Der Gedanke moderne e-ayment Verfahren über traditionelle Verfahren abzuwickeln<br />

erscheint vordergründig als absurd. Dem ist aber nicht so, weil die Annehmlichkeiten<br />

moderner Intershoplösungen über Jahrhunderte eingefahrene Geschäftsprozesse bequemer<br />

machen. Die ursprüngliche Idee hinter jedem e-payment Verfahren eben dass sie traditionelle<br />

Verfahren ablösen sollten, wird sich nur langsam durchsetzen. Zu tief verwurzelt sind noch<br />

<strong>im</strong>mer Zahlungen mit Bargeld, per Rechnung, Lastschrift und Nachnahme. Daher werden die<br />

traditionellen Bezahlfunktionen, die <strong>im</strong> Versandhandel bereits seit Jahrzehnten erprobt und<br />

be<strong>im</strong> potentiellen Kunden bekannt sind, auch mit als erste Verfahren in Internet-Shops<br />

eingesetzt. So finden sich heute zahlreiche Anbieter, die eine Lieferung der <strong>im</strong> Internet<br />

bestellten Ware gegen Nachnahme, Rechnung oder Vorauskasse akzeptieren.<br />

Die Zahlung per Rechnung ist für den Konsumenten am bequemsten und sichersten, da er erst<br />

nach Zustellung und Prüfung der Ware bezahlen muss und den genauen Zeitpunkt zudem<br />

selbst best<strong>im</strong>men kann. Der Anbieter tritt dabei in Vorleistung. Er geht dabei das Risiko ein,<br />

dass sein Kunde trotz ordnungsgemäßer Lieferung nicht bezahlt. Umgekehrt ist die Situation,<br />

wenn Vorauskasse vereinbart wird: hier trägt der Kunde das Vorleistungsrisiko, weil nicht<br />

sicher ist, ob tatsächlich und vereinbarungsgemäß geliefert wird. In einem reinen e-payment<br />

Verfahren brauchen sowohl Kunde als auch Händler diese Szenarien nicht mehr ins Kalkül zu<br />

ziehen. Überdies hat sich die Warenpalette auch auf Güter ausgeweitet die nicht mehr in einer<br />

physischen sondern nur mehr in einer elektronischen Form existieren, die so genannten Soft<br />

Goods (Internetspiele, über Internet beziehbare Softwarepakete etc.) Diese <strong>im</strong>mer wichtiger<br />

werdende Marksparte ist für traditionelle Zahlungsverfahren nahezu ungeeignet (Anonymität,<br />

Vertraulichkeit, Verbindlichkeit). Sinnvoller ist der Einsatz von anderen Zahlungsschemata,<br />

die versuchen, den Bestell-, Liefer- und den Bezahlvorgang zeitlich und vom Ablauf her


3 Basiskonzepte von Zahlungssystemen <strong>im</strong> Internet 24<br />

miteinander zu verbinden und damit den zusätzlichen und zeitversetzten Aufwand der<br />

klassischen Bezahlvarianten zu vermeiden. [MER02]<br />

Abbildung 3-8: illustrativer Querschnitt der angebotenen Zahlungsformen <strong>im</strong> österreichischen<br />

Zahlungssysteme <strong>im</strong> Internet<br />

e-commerce Handel [WWW]<br />

3.2.2 Bankeinzug<br />

Der Bankeinzug mittels elektronischer Lastschrift ist neben den traditionellen Verfahren und<br />

der Kreditkarte zum einen ein häufiges und zum anderen ein einfaches e-Payment-Modell für<br />

den Einsatz <strong>im</strong> Internet. Die Anforderungen für die Ausführung einer Zahlungstransaktion<br />

sind denkbar gering: die beteiligten Parteien verfügen jeweils über ein Konto bei einer Bank<br />

beziehungsweise bei zwei Banken, die elektronisch miteinander in Verbindung stehen. Dabei<br />

erfolgt die Geldübertragung mittels Autorisierung der Zahlung durch den Zahlungspflichtigen<br />

und der nachfolgenden Belastung des einen Kontos (Kunde) bei gleichzeitiger Gutschrift auf<br />

das andere Konto (Händler).[CAM] (Die Zahlung selbst erfolgt, indem der Kunde seine Bank<br />

autorisiert, einen definierten Betrag von seinem Konto zugunsten des Kontos des Händlers<br />

abzubuchen, und indem die Bank die eigentliche Geldüberweisung vorn<strong>im</strong>mt. [FUR]) Damit<br />

ist der Bankeinzug dem Verfahren mit Kreditkarte vom Ablauf her sehr ähnlich, mit dem<br />

Unterschied, dass das Kundenkonto <strong>im</strong> Gegensatz zum Kreditkartenkonto unmittelbar belastet<br />

wird. Die grundlegende Problematik aller Einzugsverfahren besteht auch hier: Der<br />

Konsument kann <strong>im</strong> Internet nicht nachweisen, dass seine Kontoangaben korrekt sind und<br />

sein Konto gedeckt ist (und die Banken werden diesbezüglich nur bedingt auskunftsbereit<br />

sein). Er kann sich auch nicht durch manuelle Unterschrift mit der Abbuchung per Lastschrift<br />

von seinem Konto einverstanden erklären, was normalerweise von einer<br />

Einzugsermächtigung zur Abwicklung unter den Banken verlangt wird. Ferner sollten seine<br />

Kontodaten gegen mögliche missbräuchliche Abbuchungen geschützt werden.<br />

Ein Lösungsansatz wäre, Internet-Lastschriften mit dem SET-Protokoll eine Verschlüsselung<br />

der Daten zu ermöglichen, außerdem wird die Identität des Kunden durch sein Zertifikat<br />

nachgewiesen, eine Art digitaler Ersatz für seine persönliche Unterschrift. [IZV]


3 Basiskonzepte von Zahlungssystemen <strong>im</strong> Internet 25<br />

Inkassosysteme<br />

Bei diesem Ansatz werden Mittler zwischen Händler und Kunde eingesetzt. Der Kunde muss<br />

sich bei einem solchen Mittler unter Angabe von persönlichen Daten wie Name und Adresse<br />

registrieren. Nach erfolgreicher Registrierung bekommt er eine Kundennummer und ein<br />

Passwort oder eine spezielle Software. Bei einem Kauf wird der Mittler über den zu<br />

zahlenden Betrag informiert, der Konsument identifiziert sich dann gegenüber dem Mittler,<br />

der daraufhin eine Abbuchung vom Konto des Konsumenten veranlasst. Das Geld wird dann,<br />

nach Abzug einer Provision, an den Händler weitergeleitet. Alle Daten werden dabei über<br />

eine gesicherte Verbindung übertragen, die der Mittler bereitstellt. [IZV] Der Akt der<br />

Bezahlung und der tatsächlichen monetären Transaktion wird auf zwei Schritte aufgeteilt.<br />

Vorerst führt die Bezahlung einer Leistung nur zu einer Buchung auf der Betreiberseite. Die<br />

Konten der Teilnehmer werden dann in regelmäßigen Abständen ausgeglichen. Die<br />

Funktionsweise ist analog zu gewohnten Abrechnungssystemen <strong>im</strong><br />

Telekommunikationsbereich, wo Kosten für Telefonate auf einem Konto kumuliert werden<br />

und dann in best<strong>im</strong>mten zeitlichen Intervallen tatsächlich ausgeglichen werden. Der Vorteil<br />

dieser Methode ist, dass bei der Verbuchung der einzelnen Leistung nur sehr geringe Kosten<br />

anfallen. Damit ergibt sich eine besonders gute Eignung für Zahlungen <strong>im</strong><br />

Micropaymentbereich. Die Abrechnung erfolgt entweder über die Telefonrechnung oder<br />

mittels Bankeinzug. Dafür muss vom Kunden eine Einzugsermächtigung an den Betreiber des<br />

Inkassosystems erteilt werden. [MER02]<br />

Besonders <strong>im</strong> Bereich des Micropayment, wo die Rechnungsbeträge sehr klein sind, lohnt<br />

sich der Einsatz solcher Mittler. Der Konsument kann bei verschiedenen Händlern einkaufen,<br />

ohne dass er sich bei diesen mit seinen Kontodaten anmelden muss. Die Beträge werden alle<br />

zusammen in einer Sammelabbuchung vom Mittler eingezogen, oft nur einmal <strong>im</strong> Monat.<br />

Handygestützte Verfahren<br />

Der Grundgedanke hinter diesem Verfahren ist es, das Handy des Kunden in den<br />

Bezahlvorgang einzubinden. Der Kunde muss sich dazu bei einem Zahlungsdienstleister<br />

registrieren lassen und eine Einzugesermächtigung erteilen. Das Handygestützte Verfahren<br />

baut auf dem Prinzip auf, dass jedes Handy einer best<strong>im</strong>mten Person mit Kenntnis der Handy-<br />

PIN zugeordnet ist. Bei einer online-getätigten Zahlung wird das Sicherheits- und<br />

Authentifizierungsproblem durch eine Bestätigung auf dem Handy gelöst. Da bei diesem<br />

Verfahren zwei Kanäle – das Internet und das Handy – genutzt werden, wird es auch dualchannel<br />

genannt.[SIL] Dadurch wird die Sicherheit erhöht, denn durch den Medienwechsel<br />

nutzt das Abfangen oder Verfälschen der über das Internet übermittelten Zahlungsdaten<br />

nichts. Allerdings wird dieser Medienwechsel von vielen Menschen als störender<br />

Medienbruch empfunden. Es reicht nicht mehr nur der Computer aus, auch das Handy muss<br />

gleichzeitig griffbereit sein, um die Transaktion zu bestätigen. Für die handygestützten<br />

Verfahren spricht die große Anzahl von über 30 Millionen Mobilfunkkunden. Zusätzliche<br />

Software für den PC und langwierige Registrierungsprozesse erspart sich der Handybesitzer.<br />

[HEN01] Im Vergleich zu kreditkartenbasierten Verfahren finden handygestützte Verfahren<br />

eine höhere Akzeptanz in der Bevölkerung. In Deutschland ist das Verhältnis zwischen<br />

Handybesitzer und Kreditkartenbesitzer etwa 5:1. [MER02]<br />

Zahlungssysteme <strong>im</strong> Internet


3 Basiskonzepte von Zahlungssystemen <strong>im</strong> Internet 26<br />

3.2.3 Kreditkartenbasierte Zahlungen<br />

Prinzipiell gelten für eine Geschäftsabwicklung über Kreditkarte die gleichen Regeln wie für<br />

einen herkömmlichen Ablauf durch ein Kreditverfahren. Die Kreditkarte ist eigentlich nichts<br />

anderes als eine Garantie für die Kreditwürdigkeit eines Kunden. Sein Konto wird einmal<br />

monatlich mit den gesammelten Beträgen belastet, auf Wunsch kann er den zum<br />

Abrechnungstermin fälligen Gesamtbetrag anschließend in Raten abbezahlen, was dann der<br />

eigentlichen Kreditfunktion der Karte entspricht.<br />

Für Transaktionen <strong>im</strong> Internet-Zahlungsverkehr bilden heutzutage Verfahren auf Basis von<br />

Kreditkartenzahlungen sozusagen den Mainstream. Der Grund liegt darin, dass prinzipiell<br />

jeder, der über eine Kreditkarte und einen Internetanschluss verfügt, die einfachsten Varianten<br />

dieses Verfahrens ohne jeden weiteren Aufwand, wohl aber mit einem gewissen Risiko<br />

benutzen kann. Der Nutzer gibt dabei einfach seine Kreditkartennummer mit<br />

Gültigkeitsdatum in ein Formularfeld auf den Händlerseiten ein. Diese Kartendaten werden<br />

online an den Zahlungsempfänger übermittelt, der zeitgleich mit der Lieferung seine<br />

elektronische Rechnung bei der Kreditkartenorganisation zur Bezahlung einreicht. Im<br />

s<strong>im</strong>pelsten Fall findet die Übertragung der Kartendaten dabei ungesichert durch das offene<br />

Netz statt. Im nächsten Fall wird die Datenübertragung zum Händler verschlüsselt, damit<br />

niemand auf dem Übertragungsweg die Kartendaten abfangen und anschließend<br />

missbrauchen kann. Ferner gibt es Systeme, bei denen der Konsument seine Kreditkarten bei<br />

einem Anbieter von Online-Zahlungssystemen registrieren lässt, der dann <strong>im</strong> Bezahlvorgang<br />

eine Art Mittlerfunktion übern<strong>im</strong>mt. Die ausgeklügeltsten Kreditkartenverfahren (SET)<br />

sorgen außerdem dafür, dass Händler und Kunde über Zertifikate eindeutig und zweifelsfrei<br />

identifiziert werden können und der Kunde seinen Kaufwillen mit einer digitalen Signatur<br />

bestätigt. Dies gibt beiden Seiten die max<strong>im</strong>ale Sicherheit, ist aber technisch sehr aufwendig<br />

und teuer. [IZV]<br />

Da die Kreditkartengesellschaften online Zahlungen mittels Kreditkarte den so genannten<br />

MOTO-Transaktionen (Mail Order/Telefon Order-Verträge zwischen Händler und<br />

Kreditkartenorganisationen) gleichsetzt, weil kein unterschriebener Beleg vorliegt, ist der<br />

Händler stark benachteiligt. Wenn ein Kunde eine Bestellung per Kreditkarte abstreitet, weil<br />

er beispielsweise die Zahlung nicht selbst durchgeführt hat, ist der Händler in Beweisnot und<br />

hat auch die Kosten und Verluste der Rückbuchung zu tragen, durch die dem Händler<br />

abgesehen vom Umsatzausfall hohe Gebühren entstehen. Nur <strong>im</strong> Falle einer Zahlungsgarantie<br />

von Kreditkartenorganisationen muss der Händler keine Haftung übernehmen. [HEN01]<br />

Zusätzlich gelten die Best<strong>im</strong>mungen des Fernabsatzgesetzes, die ein generelles<br />

Rückgaberecht für Waren innerhalb von bis zu vier Monaten nach Bestelldatum vorsehen,<br />

wonach die Beweislast be<strong>im</strong> Einkauf mit Kreditkarte be<strong>im</strong> Händler liegt. [GOR]<br />

Bedingt durch die Umsatzbeteiligungen der Kreditkartenbanken und den hohen Fixkosten<br />

verursachen Kreditkarten relativ hohe Transaktionskosten, die weitgehend zu Lasten des<br />

Anbieters gehen. Für Micropayments sind Kreditkarten daher nicht geeignet. [SCH] Bei den<br />

kreditkartenbasierten Systemen wird grundsätzlich die Zahlung innerhalb eines offenen<br />

Systems versprochen, die eigentliche Zahlung wird jedoch in einem geschlossenen System<br />

geleistet.[PER] Bei jeder online durchgeführten Transaktion wird eine Verbindung zu einer<br />

Bank oder anderen Clearingstelle hergestellt, welche die jeweilige Transaktion autorisiert.<br />

Eine Anonymität für den Kunden ist damit nicht gewährleistet.<br />

Zahlungssysteme <strong>im</strong> Internet


3 Basiskonzepte von Zahlungssystemen <strong>im</strong> Internet 27<br />

3.2.4 Guthabenbasierte Zahlung<br />

Bei Guthabenbasierten Systemen muss der Kunde, noch bevor er irgendetwas <strong>im</strong> Internet<br />

erwerben und bezahlen kann, finanziell in Vorleistung treten. Er füllt zu diesem Zweck seine<br />

elektronische Geldbörse (egal ob diese auf seinem PC nur als Software vorhanden oder<br />

beispielsweise auf einer Chipkarte gespeichert ist) mit digitalem Guthaben auf, das er <strong>im</strong><br />

Tausch gegen Bargeld oder Girokontogeld erhält. Diese Verfahren wurden teilweise speziell<br />

für den Einsatz <strong>im</strong> Internet entwickelt, um möglichst einfache, rasche, kostengünstige bzw. in<br />

den Kaufvorgang "Zug-um-Zug" integrierbare Zahlungsmethoden zu schaffen, die auch für<br />

kleine Beträge einsetzbar sind. Teilweise entstanden vorausbezahlte Systeme auch als Ersatz<br />

für Bargeld zum Bezahlen kleinerer Beträge <strong>im</strong> täglichen Leben am Verkaufsort mit dem<br />

Ziel, Klein- und Wechselgeld be<strong>im</strong> Kauf von Fahrscheinen, Zeitschriften oder Brötchen<br />

überflüssig zu machen. Der Händler kann sich bei guthabenbasierten Systemen sehr sicher<br />

sein, dass er sein Geld erhält, da die herausgebende Bank eine Zahlungsgarantie für die<br />

eingenommenen Beträge in elektronischer Geldform abgibt. Bei manchen Systemvarianten<br />

kann der Käufer sogar anonym gegenüber der Bank und dem Händler bleiben. [IZV]<br />

Smart Cards<br />

Smart Cards sind elektronische Geldbörsen und bilden eine Form des anonymen Bezahlens.<br />

Die elektronische Geldbörse hat den gleichen Zweck wie die Geldbörse aus Leder mit dem<br />

Unterschied, dass in ihr keine Banknoten oder Münzen verwahrt werden, sondern<br />

elektronisches Geld. Verfügbare Geldbeträge werden auf den Smart Cards elektronisch<br />

gespeichert, d.h. Geld wird von einem Konto abgebucht und <strong>im</strong> Speicher der Karte abgelegt.<br />

Der Transfer erfolgt über eine Schnittstelle zu einem für die Zahlungsabwicklung<br />

konzipiertem Gerät (z.B. Bankomatkassen in einem Supermarkt). Der Austausch kann dabei<br />

direkt ohne Kontaktierung der Bank erfolgen. Der Betrag wird automatisch um den<br />

ausgegebenen Wert vermindert.<br />

Händlerseitig wird der überwiesene Geldbetrag wiederum via Schnittstelle auf eine Chipkarte<br />

übertragen. Eine solche Chipkarte ist eine besonders schwer manipulierbare Hardware. Der<br />

eingebaute Mikrochip enthält eine spezielle Verschlüsselungsfunktion, die bei der<br />

Transaktion die digitalen Signaturen erzeugt und Prüffunktionen wahrn<strong>im</strong>mt. Außerdem<br />

übern<strong>im</strong>mt er den Schutz der gespeicherten Daten vor Fälschung, Duplikation und anderen<br />

unbefugten Zugriffen. Deren Transaktionskosten sind wegen des Offline-Prozesses relativ<br />

gering, so dass sie sich für Kleinstbeträge eignen. [FUR]<br />

Die Smart Cards sollen den traditionellen Bargeldverkehr ersetzen. Deshalb ist man versucht<br />

sie beispielsweise be<strong>im</strong> Telefonieren, an Fahrkartenautomaten, in Supermärkten, bei jedem<br />

vorstellbaren Automaten, aber auch in offenen Netzwerken zur Anwendung zu bringen. Dazu<br />

werden intelligente Mikroprozessorkarten in vielen regionalen Projekten getestet<br />

(Bürgerkarte) oder sind bereits etablierte Anwendungen (Quick).<br />

Deren universelle Einsatzmöglichkeiten und der bereits bestehende große Erfahrungsschatz<br />

mit solchen Systemen tragen ein hohes Maß für deren Bevorzugung gegenüber anderen<br />

Verfahren bei. Wegen ihrer kommerziellen Verbreitung, der günstigen<br />

Abwicklungsmöglichkeiten aufgrund ihrer Offline-Fähigkeit und der hohen<br />

Sicherheitsaspekte bieten Smart Cards eine hervorragende Zahlungsmöglichkeit <strong>im</strong> Internet,<br />

besonders in Bezug auf Micropayments. [ILL]. Allerdings benötigt dieses System erstens eine<br />

Ladestation zum Aufladen der Smart Card und der Benutzer muss eine zusätzliche<br />

Hardwarekomponente (Kartenleser) besorgen, was mit Zusatzkosten verbunden ist und<br />

demnach fraglich, ob das nicht eine Hemmschwelle für den Benutzer darstellt.<br />

Zahlungssysteme <strong>im</strong> Internet


3 Basiskonzepte von Zahlungssystemen <strong>im</strong> Internet 28<br />

Elektronisches Geld<br />

Zum Zeitpunkt nur mehr vom historischen Interesse sind tokenbasierte Zahlungsverfahren<br />

wie das legendäre Ecash von DigiCash oder Cybercash. Die Grundidee dieses Verfahrens ist<br />

der Einsatz von Tokens als Geldersatz bei Zahlungsvorgängen. Token sind<br />

Informationspakete (Bit-Folgen) mit mehreren, best<strong>im</strong>mten Informationen enthaltenden<br />

Datenfeldern bestehend aus der Angabe des Tokenwertes die einen best<strong>im</strong>mten Geldwert<br />

repräsentieren. Eine zentrale Institution ist für die Ausgabe der Token verantwortlich. Bei<br />

dieser zentralen Institution wechselt man „echtes“ Geld in digitales Geld, das als Token auf<br />

Datenträgern wie zum Beispiel einer Festplatte gespeichert wird. Der Token kann über<br />

Datenleitungen übertragen werden und wie eine Banknote zur Zahlung verwendet werden.<br />

Daher wird auch von elektronischem Bargeld gesprochen. Der Mechanismus ist allerdings<br />

nicht in jeder Hinsicht mit Bargeld vergleichbar. Wird ein Einweg-Token ausgegeben so wird<br />

deren Seriennummer registriert und noch als geschäftgültig geführt. Nach einer<br />

Geschäftstätigkeit in der dieser Token als Zahlungsmittel Verwendung fand, verliert dieser<br />

seinen Wert. Der Empfänger des Geldes kann die Echtheit der Tokens nur durch die direkte<br />

Einschaltung einer dritten Instanz, der ausgebenden Bank, verifizieren. Dabei prüft die Bank<br />

die digitale Signatur der vorher von ihr ausgegebenen und als echt bestätigten Werteinheiten<br />

und ob die Münze bereits vorher ausgegeben wurde. Sind beide Überprüfungen erfolgreich,<br />

wird dem Einreicher signalisiert, dass das Geld echt ist, und die Transaktion ist<br />

abgeschlossen. [WEB1]<br />

Die Gründe für deren Scheitern trotzt massivsten Werbeaufwands mögen mannigfach sein.<br />

Entscheidend war allerdings die Unsicherheit über den momentanen Wertzustand des<br />

angeforderten Geldwertes. Es kann zum Beispiel sein, dass durch einen Netzwerkfehler<br />

angefordertes und bezahltes Cybergeld verloren geht beziehungsweise keine eindeutige<br />

Seriennummervergabe stattfindet. Der größte Vorteil wäre in deren absoluten Anonymität<br />

gelegen. Ebenso wäre die Ressourcenanforderung an den Bankserver relativ gering geblieben.<br />

[SCHI]<br />

Zahlungssysteme <strong>im</strong> Internet


4 Internet-Zahlungssysteme 29<br />

4 Internet-Zahlungssysteme<br />

4.1 Allgemeine Erläuterungen<br />

Es vergeht kaum ein Monat in dem nicht zumindest die Entwicklung eines neuen e-payment-<br />

Verfahrens in den Medien und Presse angekündigt wird. Es ist daher unmöglich alle<br />

Verfahren in dieser Arbeit zu behandeln. Wie das e-cash-Verfahren gezeigt hat, reichen weder<br />

ein großer Werbeaufwand noch ein „Kübel“ an Vorschusslorbeeren aus, um ein System am<br />

Markt zu etablieren. Daher werden hier nur diejenigen Systeme behandelt, die sich zumindest<br />

in Österreich eine feste Marktposition erkämpft haben.<br />

4.2 Paybox<br />

Paybox zählt zu den handygestützten Zahlungssystemen und ermöglicht eine schnelle und<br />

sichere Durchführung von Finanztransaktionen und Benutzer-Identifikation mit jedem beliebigen<br />

Mobiltelefon in jedem Mobilfunknetz. Anbieter dieses innovativen Zahlungssystems ist<br />

die paybox.net AG. Das paybox-System wurde <strong>im</strong> Mai 2000 zunächst in Deutschland eingeführt<br />

und ist inzwischen bereits in Österreich, Schweden, Spanien und Großbritannien <strong>im</strong> Einsatz.<br />

Seit dem 31. Jänner 2001 stehen paybox-Services dem österreichischen Markt zur Verfügung.<br />

Knapp 1 Jahr nach der Markteinführung nutzten <strong>im</strong> Mai 2001 bereits über 260.000<br />

Kunden und mehr als 5.000 Händler paybox. Zurzeit setzen bereits 750.000 Kunden paybox<br />

ein. Die Zahl der Unternehmen die paybox als Zahlungsmittel akzeptiert beläuft sich auf<br />

10.000, davon 1.300 alleine in Österreich. [AON1]<br />

4.2.1 Einsatzgebiet<br />

Das System der paybox.net AG ist eine bargeldlose Zahlungsmethode mit einer besonders<br />

breiten Anwendungsvielfalt und soll überall dort zum Einsatz kommen, wo Zahlungen geleistet<br />

werden müssen. Es gibt verschiedene Varianten der bargeldlosen Bezahlung mit paybox.<br />

Prinzipiell kann zwischen folgenden Möglichkeiten unterschieden werden [DIE]:<br />

• paybox2paybox, unabhängig von Ort und Zeit können zwischen zwei privaten Mobilfunkteilnehmern<br />

die bei paybox registriert sind gegenseitig Zahlungstransaktionen<br />

durchgeführt werden.<br />

• POS2paybox ermöglicht dem Konsumenten <strong>im</strong> Einzelhandel mit paybox zu zahlen. Für<br />

den Konsumenten bleibt der Zahlungsablauf stets gleich, lediglich die Einbindung in die<br />

Kassen- und Warenwirtschaftssysteme auf Seiten der Akzeptanzstellen kann variieren.<br />

Das Terminal be<strong>im</strong> Handel kann beispielsweise eine Scannerkasse sein, mit der die<br />

Handynummer des Kunden über einen Barcode-Leser eingelesen wird und anschließend<br />

an das payment weitergeleitet wird.<br />

• Mit Mobile2paybox können mobile Dienstleistungen wie zum Beispiel Pizzaservice oder<br />

Taxi mit dem Handy beglichen werden. Das Handy dient als Terminal, mit dem<br />

Zahlungen ausgelöst werden und man erspart sich zusätzliche Zusatzinvestitionen für<br />

Kartenlesegeräte.<br />

• Internet2paybox nutzt die Mobiltelefonnummer des Kunden um Zahlungen <strong>im</strong> Internet<br />

anzuweisen.<br />

Auf die letztgenannte Möglichkeit wird nachfolgend näher eingegangen.<br />

Zahlungssysteme <strong>im</strong> Internet


4 Internet-Zahlungssysteme 30<br />

4.2.2 Voraussetzungen für Kunden<br />

Damit der Kunde das paybox System nutzen kann, müssen folgende Voraussetzungen gegeben<br />

sein:<br />

• Mobiltelefon mit gültiger SIM-Karte<br />

Der Kunde muss ein Mobiltelefon mit gültiger Karte besitzen. Über die SIMCARD <strong>im</strong><br />

Handy wird der Kunde eindeutig identifiziert. An das Handy werden keine weiteren<br />

Bedingungen gebunden. Es ist gleichgültig ob es sich dabei um ein Wertkarten-Handy<br />

oder um ein Vertragshandy handelt. Ferner ist das Mobiltelefon an keinen Hersteller und<br />

kein best<strong>im</strong>mtes Mobilnetz geknüpft.<br />

• Vertrag mit paybox.net AG:<br />

Um das System nutzen zu können, muss der Kunde mit der paybox.net AG einen<br />

Endkunden-Vertrag abschließen, der die Volljährigkeit des Kunden voraussetzt. Neben<br />

der Angabe persönlicher Daten st<strong>im</strong>mt der Kunde <strong>im</strong> Vertrag einer Einzugsermächtigung<br />

für sein Girokonto für alle mit paybox getätigten Zahlungen und einer Bonitätsprüfung<br />

zu. Der Vertrag kann jederzeit ohne Einhaltung einer Frist gekündigt werden. Nach der<br />

Vertragsschließung erfolgt die Freischaltung und der Kunde erhält eine persönliche<br />

4stellige PIN auf sein Handy übermittelt, mit welcher er seine Zahlungen über das Handy<br />

bestätigt. Der Verfügungsrahmen wird von paybox.net festgelegt wobei die beruflichen<br />

Angaben des Kunden als Maßstab herangezogen werden. PayBox-Teilnehmer dürfen<br />

zwischen 300 und 1000 Euro täglich ausgeben. Je nach Bonität kann dieser Betrag auch<br />

erhöht werden. In Zukunft soll es für jeden Kontoinhaber die Möglichkeit geben auch<br />

ohne gesonderte Registrierung und Bonitätskontrolle Zahlungen per Handy<br />

durchzuführen.<br />

• Girokonto<br />

Damit der Kunde Bezahlungen über paybox durchführen kann, muss er Inhaber eines<br />

Girokontos einer in Österreich ansässigen Bank sein.<br />

4.2.3 Transaktionsablauf<br />

Der Zahlungsablauf von paybox läuft folgendermaßen ab:<br />

Zahlungssysteme <strong>im</strong> Internet


4 Internet-Zahlungssysteme 31<br />

1. Zahlungswunsch: Der Kunde wählt nach der Zusammenstellung des Warenkorbes als<br />

Zahlungsart „paybox“ aus. Daraufhin öffnet sich eine neue Internetseite, wo der<br />

Kunde seine Handynummer eingibt und die Zahlung per Mausklick bestätigt. Anschließend<br />

werden die Eingabedaten vom Kunden an den Händler weitergereicht. Die<br />

Übermittlung der Daten vom Kunden an den Händler erfolgt unverschlüsselt. Statt der<br />

Handynummer kann sich der Kunde bei paybox auch eine Alias-Nummer einrichten<br />

lassen, die eine nicht mit der Handynummer identische siebenstellige Nummer ist.<br />

2. Weiterleitung des Zahlungswunsches: Auf Händlerseite n<strong>im</strong>mt ein paybox Localhost<br />

Listener die Kundendaten entgegen und leitet die Zahlungsdaten und die Handynummer<br />

des Kunden sowie Daten seiner eigenen Kennung verschlüsselt über eine sichere<br />

SSL-Verbindung an das paybox Payment Gateway.<br />

3. Bestätigungsanfrage: Der paybox Server von paybox.net bearbeitet die Anfrage vom<br />

Händler, indem er die Kundendaten und die Händlerdaten einer Prüfung unterzieht.<br />

Nach erfolgreicher Prüfung wird der Kunde von paybox angerufen und um die Autorisierung<br />

der Zahlung durch seine persönliche paybox PIN gebeten, wobei die Kommunikation<br />

mit paybox durch einen Sprachcomputer realisiert wird, der den Namen des<br />

Händlers(Zahlungsempfänger) und den zu zahlenden Betrag mitteilt.<br />

4. Bestätigung durch die PIN: Durch die Eingabe der persönlichen paybox-PIN über<br />

die Tastatur des Mobiltelefons gibt der Kunde die Transaktion frei.<br />

5. Bestätigung an den Händler: Der Händler erhält von Paybox nach erfolgter<br />

Autorisierung durch den Kunden eine Bestätigung.<br />

6. Bestätigung an den Kunden: Die erfolgreiche Zahlungsautorisierung bestätigt die<br />

paybox.net AG direkt dem Kunden akustisch am Mobiltelefon durch eine SMS oder<br />

per e-mail. Auf der Internet-Seite des Händlers wird ebenfalls eine<br />

Bestätigungsmeldung angezeigt.<br />

7. Warenlieferung: Der Händler versendet die Waren an den Käufer.<br />

8. Abbuchung be<strong>im</strong> Kundenkonto: Sobald das vom Händler definierte Zahlungsziel<br />

erreicht ist, initiiert die paybox.net AG eine Lastschrift auf das Girokonto des Kunden.<br />

Der Händler kann also selbst best<strong>im</strong>men, wann der Kunde belastet werden soll. In der<br />

Regel orientiert sich diese Zeitspanne an der durchschnittlichen Lieferzeit<br />

9. Gutschrift auf das Händlerkonto: Der Rechnungsbetrag wird dem Händler unter<br />

Abzug eines Disagios auf sein Händlerkonto gutgeschrieben. Im zweiwöchentlichen<br />

Zyklus erhält der Händler eine Gutschrift für alle mit Paybox bezahlten Aufträge auf<br />

sein Girokonto überwiesen.<br />

4.2.4 Kosten Kunde<br />

Auf Kundenseite sind keine Investitionen in Hardware oder Software erforderlich. Sämtliche<br />

Einkäufe die von den Kunden über paybox initiiert werden sind kostenfrei. Für die Nutzung<br />

von paybox entstehen folgende Kosten für die Kunden, entnommen aus der Preistabelle der<br />

paybox.net AG:<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Jährliche Grundgebühr 15 Euro<br />

Änderung der Paybox-Nummer 15 Euro<br />

Tabelle 4-1: Nutzungskosten für Kunden


4 Internet-Zahlungssysteme 32<br />

Benutzt ein Kunde die paybox außerhalb seines Mobilfunknetzes und entstehen ihm durch<br />

einen Anruf der paybox Austria AG Roaming-Gebühren auf seiner Telefonrechnung, so muss<br />

der Kunde für diese Kosten aufkommen.<br />

4.2.5 Kosten Händler<br />

Für die Nutzung der Servicepakete muss der Händler mit paybox.net AG einen<br />

Softwarelizenzvertrag und einen Dienstleistungsvertrag abschließen. Die Kosten und die<br />

Laufzeiten für diese Verträge sind der Tabelle 4-2 zu entnehmen.<br />

Basic Service Standard Service Premium Service<br />

Softwarelizenzgebühr 500 500 2500<br />

Jahresgebühr 100 100 300<br />

Stornogebühr 0,25 0,25 0,25<br />

Gutschriftgebühr 3 3 3<br />

Disagio pro Transaktion 5 % 3,5 % 3 %<br />

Vertragslaufzeit 6 Monate 12 Monate 12 Monate<br />

Tabelle 4-2: Gebühren und Kostenstruktur der Servicepakete (Beträge in Euro)<br />

4.2.6 Voraussetzungen für Händler<br />

Paybox bietet für Händler drei unterschiedliche Service Pakete an zur Integration in einen<br />

Internet-Shop an, um deren wirtschaftlichen Bedürfnissen Rechnung zu tragen. Es gibt den<br />

Paybox BASIC Service, den Paybox STANDARD Service und den Paybox PREMIUM<br />

Service.<br />

• Der Basic Service ist für kleinere Händler mit einer überschaubaren Anzahl von Transaktionen<br />

geeignet und einfach in das bestehende Shopsystem zu integrieren, da der<br />

Service auf einer gehosteten Lösung basiert. Im Basic Service ist das Verfahren der<br />

„Online-Autorisierung mit manueller Freigabe“ integriert. Entscheidet sich der Kunde für<br />

das Zahlungssystem paybox wird er auf einen Server der paybox.net umgeleitet. Dort gibt<br />

der Kunde seine Handynummer ein und die Transaktion wird, wie <strong>im</strong> Zahlungsablauf<br />

bereits beschrieben, abgewickelt. Der Händler wird unabhängig von einzelnen<br />

Kundenzahlungen per SMS oder e-mail verständigt. Den Einzug des Zahlungsbetrages<br />

vom Girokonto des Kunden muss der Händler bei der paybox.net ausdrücklich anfordern.<br />

Der Basic Service bietet noch die Möglichkeit Teile von ausverkauften Bestellungen zu<br />

stornieren und Zahlungsziele zu verändern. [PAY1]<br />

• Der Standard Service bietet Unternehmen mit einem hohen Transaktionsvolumen eine<br />

sichere Lösung, die den shopbasierten Zahlungsprozess beschleunigt. Noch während der<br />

Transaktion wird die Zahlung nach erfolgreicher Online-Autorisierung des Kunden nach<br />

einem vom Händler vorgegebenen Zahlungsziel automatisch freigegeben (Verfahren der<br />

„Online-Autorisierung mit automatischer Freigabe“) Ein elektronischer<br />

Transaktionsbericht ermöglicht dem Händler einzelne Abrechnungen intern<br />

weiterzubearbeiten. Der Händler hat ferner Zugang zu einem Extranet mit manuellen<br />

Funktionen, die es ihm ermöglichen Stornierungen beziehungsweise Gutschriften von<br />

Zahlungen auszulösen. Bei der Installation der paybox-Software auf den Internet-Server<br />

vom Händler erfolgt die Anbindung an paybox durch mitgelieferte Skripte, die<br />

entsprechend der Systemumgebung des Händlers angepasst werden. [PAY2]<br />

• Der Premium Service ist die Ideallösung für große Unternehmen mit breiter<br />

Produktpalette, die eine Vielzahl von komplexen Transaktionen abwickeln. Der Service<br />

Zahlungssysteme <strong>im</strong> Internet


4 Internet-Zahlungssysteme 33<br />

ist vollständig in den Logistikprozess des Internethändlers integriert. Dies ermöglicht die<br />

zeitliche Abst<strong>im</strong>mung von Warenlieferung und Zahlungsfluss, die vor allem in<br />

unvorhersehbaren Einkaufssituationen unabdinglich ist. Durch die automatisierte<br />

Anbindung an die Logistik über XML- und Datei-Schnittstellen erfolgt <strong>im</strong> Backoffice-<br />

Bereich eine schnelle automatische Bearbeitung von alltäglichen Verwaltungsvorgängen<br />

wie etwa eine Stornierung von Reservierungen. [PAY3]<br />

In Tabelle 4-3 erfolgt eine Auflistung der einzelnen Lösungen, die paybox in seine jeweiligen<br />

Servicepakete integriert hat.<br />

Lösung Basic Service Standard Service Premium Service<br />

Online-Autorisierung<br />

manuelle Freigabe direkte Freigabe integrierte Freigabe<br />

Elektronische Abrechnung • •<br />

Händler Extranet • • •<br />

- Setzen/Verändern von Zahlungszielen • •<br />

- Transaktionsübersicht m. Suchfunktion • • •<br />

- Freigabe von Reservierungen u. Zahlungen • • •<br />

- Auslösen von Gutschriften • • •<br />

- Auslösen von Stornos • • •<br />

Automatische Backoffice Abwicklung •<br />

- Stornos von Reservierungen •<br />

- Belastungen von Reservierungen •<br />

- Gutschriften von Belastungen •<br />

- Stornos von Belastungen •<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Tabelle 4-3: Übersicht Leistungsmerkmale der Servicepakete<br />

Großes Gewicht legt paybox auf seine Modularität mittels Cartridges. Dies erleichtert<br />

Händlern die Integration ihrer individuell entwickelten Shop-Systemen in ein standardisiertes<br />

Zahlungsverfahren. Paybox bietet Schnittstellen die pr<strong>im</strong>är technologiebezogen (unter<br />

anderen Microsofts ASP, CGI/Perl oder JSP) und erst sekundär betriebssystemspezifisch sind,<br />

an.<br />

Nähere Angaben hierzu siehe Tabelle 4-4.<br />

Technologie Plattformen<br />

NT LINUX SUN Solaris Andere<br />

ASP • •<br />

PERL • • • •<br />

PHP • • • •<br />

JSP • • • •<br />

ColdFusion • • • •<br />

Tabelle 4-4: angebotene Technologien [PAY2]<br />

Paybox Cartridges<br />

Sollte es ein Händler dennoch vorziehen sich für ein kommerzielles Softwarepaket zu<br />

entscheiden braucht er ebenso wenig auf die Vorzüge von paybox zu verzichten. Viele „Plugand-Play-fertige“<br />

OnlineShop Anwendungen haben paybox als standardisiertes<br />

Zahlungsverfahren (Paybox-Module) integriert. So existieren schon cartridges für


4 Internet-Zahlungssysteme 34<br />

Broadvision, Intershop, Microsoft oder Internolix. Nähere Informationen sind der Tabelle 4-5<br />

zu entnehmen. Auch die Anbieter von Application Servern, darunter IBM (Websphere) und<br />

BEA(WebLogic), arbeiten an einer Integrationslösung. Die Unterstützung auf breiter Front<br />

durch die etablierten Software-Anbieter und die hohe Anzahl der schon nach kurzer Zeit<br />

eingegangenen Registrierungen von Benutzern des noch relativ jungen Zahlungsverfahrens<br />

lassen hoffen, dass paybox in Zukunft kein Schattendasein wie viele seiner Vorgänger führen<br />

wird. [RAE]<br />

Shop-Systeme Plattformen<br />

NT LINUX SUN Solaris Andere<br />

Broadvision •<br />

GS-Shopbuilder •<br />

IBM WebSphere • • •<br />

Internolix • •<br />

Intershop 4 • • • •<br />

Intershop Enfinity • •<br />

Intershop ePages • • •<br />

Microsoft Site Server •<br />

Shopfactory •<br />

Vignette • •<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Tabelle 4-5: Unterstützte Shop-Systeme für paybox-Module [PAY2]<br />

4.3 Paysafecard<br />

[PSC]<br />

Die paysafecard ist Europas erste Wertkarte (prepaid-Karte) zum Online-Shoppen. Am 13.<br />

November 2000 wurde die von einem jungen Unternehmen (paysafecard.com Wertkarten<br />

AG) zusammen mit IBM entwickelte paysafecard in den österreichischen Markt eingeführt.<br />

Im Mai 2001 erfolgte der Launch in Deutschland. Die paysafecard ist über ein breites<br />

Händlernetz erhältlich. So kann man die paysafecard zum Beispiel in allen BAWAG-Filialen,<br />

Postämtern, Tankstellen usw. erhältlich. Weitere Vertriebsstellen finden sich auf der<br />

Homepage von paysafecard.com, wo auch eine Suchfunktion zum Ermitteln von Händlern in<br />

einem best<strong>im</strong>mten Umkreis zur Verfügung steht. Es gibt keinerlei vertragliche Bindung,<br />

daher ist die paysafecard beliebig übertragbar.<br />

4.3.1 Einsatzgebiet<br />

Das wohl herausragernste Merkmal dieses Zahlungsmittels ist, dass sie auch noch eine<br />

zusätzliche Funktionalität anbietet, diejenige als Telefonwertkarte Verwendung zu finden.<br />

4.3.2 Voraussetzungen für Kunden<br />

• Kauf einer paysafecard: Die erfolgreiche Benutzung des Zahlungssystems paysafecard<br />

setzt für den Kunden den Erwerb einer paysafecard voraus. Die paysafecard ist bei über<br />

10.000 Vertriebspartner in zwei Varianten erhältlich: die classic paysafecard (blau) in den<br />

Nominalen zu EUR 25, 50 und 100 für Erwachsene und die


4 Internet-Zahlungssysteme 35<br />

paysafecard-Partnern Web-Einkäufe bis zum vorgegebenen Rahmen direkt online von<br />

jedem Web-Terminal aus zu bezahlen und dient außerdem zur Überprüfung von getätigten<br />

Umsätzen.<br />

4.3.3 Voraussetzungen für Händler<br />

• Vertrag mit paysafecard: Zur Implementierung der paysafecard benötigt der Händler<br />

keinerlei zusätzliche Hardware. Zahlungsmittelanbieter bekommen die benötigte<br />

paysafecard Applikation kostenlos zur Verfügung gestellt. Der Händler ist aber<br />

gezwungen eine auf Java basierende Merchant API in seinen Webshop zu integrieren.<br />

Diese läuft wiederum nur unter Bereitstellung eines Zertifikats und einer Merchant ID.<br />

• Zertifikat: Prinzipiell läuft der gesamte Datenverkehr über SSLv3 Protokollen zwischen<br />

Händler und paysafecard. Daher ist ein eigenes SSL-Modul durch den Händler zu<br />

installieren.<br />

4.3.4 Transaktionsablauf<br />

1. Kauf der paysafecard: Der Kunde ersteht bei einem Händler eine paysafecard seiner<br />

Wahl.<br />

2. Zahlungen des Händlers: Sämtliche Einnahmen für die paysafecard werden vom<br />

Händler abgeführt und auf so genannten „Nostro-Konten“ von den Bankpartnern der<br />

paysafecard verwaltet. Hierdurch garantiert paysafecard allen Web-Shop Partner, eine<br />

100% Zahlungsgarantie. Der Web-Shop Partner trägt somit kein Ausfallsrisiko.<br />

3. Kaufentscheidung: Der Kunde besucht den gewünschten Webshop mit integrierter<br />

paysafecard wo er ganz nach seinen Vorstellungen Produkte und Dienstleistungen<br />

auswählt. Schließlich klickt er be<strong>im</strong> Einkaufen den paysafecard-Button an.<br />

4. Autorisierungsanfrage: Der Webshop sendet ein Protokoll mit Merchant ID,<br />

Transaktionsnummer, Betrag, Währung an den paysafecard-Server.<br />

Zahlungssysteme <strong>im</strong> Internet


4 Internet-Zahlungssysteme 36<br />

5. Routing: Der paysafecard-Server n<strong>im</strong>mt eine Verbindung zum Käufer auf. Hierfür<br />

wird durch ein Redirect eine Session zwischen dem Kunden und dem paysafecard-<br />

Rechenzentrum geöffnet. Auf der paysafecard-Zahlungsseite bestätigt der Kunde<br />

durch die Eingabe seines freigerubbelten PIN-Codes und sein persönliches Passwort<br />

die Transaktion. Das Passwort kann vor dem ersten Gebrauch der Karte auf der<br />

Homepage von paysafecard eingerichtet werden und dient dem Missbrauch. Dadurch<br />

hat der Nutzer die Gewissheit, dass niemand ohne Kenntnis des Passworts mit der<br />

eigenen Karte einkaufen kann. Zur Ausgleichung von Restbeträgen und zur Zahlung<br />

höherer Beträge können bis zu zehn paysafecards pro Zahlungsvorgang benutzt<br />

werden. Nach erfolgreicher Validierung des Kartenwerts erhält der Kunde eine<br />

Nachricht, dass der gezahlte Betrag auf seiner paysafecard reserviert ist. Über diesen<br />

Betrag kann der Kunde nun nicht mehr verfügen. Gleichzeitig erhält der Webshop<br />

eine Meldung über eine erfolgreiche Zahlung. Die Verbindung zwischen Kunden und<br />

paysafecard wird getrennt und der Kunde befindet sich wieder auf der Website vom<br />

Webshop.<br />

6. Zahlung an den Webshop: Nach erfolgreicher Zahlung seitens des Kunden überweist<br />

der Bankpartner von paysafecard den Zahlungsbetrag nach Abzug des Disagios an den<br />

Webshopbetreiber.<br />

4.3.5 Kosten Händler<br />

In Tabelle 4-6 erfolgt die Auflistung der Kosten die bei der Integration von paysafecard in<br />

den Web-Shop durch den Händler zu tragen sind. Hierbei wird zwischen tangible, intagiblen<br />

Gütern und Micropayment unterschieden. Zu den tangiblen Gütern zählt man physische<br />

Güter, intagible Güter kennzeichnen Content-/Download-Produkte (digitale Inhalte) und<br />

Micropayment fassen alle digitalen Inhalte mit einem Transaktionsvolumen zwischen 0,01<br />

und 5 Euro zusammen.<br />

Tangibles Gut Intangibles Gut Micropayment<br />

Disagio pro Transaktion 5,50 % 12 % 35 %<br />

Vertragslaufzeit 1 Jahr 1 Jahr 1 Jahr<br />

4.4 Quick<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Tabelle 4-6: Kosten paysafecard – Händler<br />

Quick ist ein kleiner goldener wideraufladbarer Chip der von der Europay Austria<br />

Zahlungsverkehrssysteme GmbH, einer Tochtergesellschaft aller österreichischen<br />

Geldinstitute und der Austria Card GmbH, einer Tochtergesellschaft der österreichischen<br />

Nationalbank entwickelt wurde. Die Zahlungsabwicklung wird von Austrian Payment<br />

Systems Service GembH ebenfalls Tochter der österreichischen Geldinstitute abgewickelt.<br />

Alle Personen die <strong>im</strong> Besitz einer Karte mit integriertem Quick-Chip sind, können einfach<br />

bargeldlos an allen Kassen und Automaten die das Quick-Logo verwenden, einkaufen ohne<br />

nach Kleingeld suchen zu müssen. Derzeit befindet sich Quick auf über 6,2 Millionen Karten<br />

(Maestro-Karten, anonyme Quick-Wertkarten, Bankkundenkarte mit Chip) und kann mit<br />

max<strong>im</strong>al 400 Euro an 5.730 österreichischen Ladeterminals aufgeladen werden. Seit Mitte<br />

2002 spielt Bezahlen mit Quick auch <strong>im</strong> E-<strong>Commerce</strong> eine Rolle. Mit @Quick ist es möglich,


4 Internet-Zahlungssysteme 37<br />

Waren und Dienstleistungen, welche in Online-Shops angeboten werden, mittels Chipkarte<br />

online zu bezahlen. [PDT]<br />

4.4.1 Einsatzgebiet<br />

Die Quick-Karte, als elektronische Alternative für die Funktion des Bargeldes, insbesondere<br />

die Begleichung kleinerer Beträge, hat ein breites Anwendungsfeld. Beispielhaft ist in<br />

Österreich die Nutzung der Chipplattform für eine ganze Reihe von Anwendungen gelungen,<br />

die mit dem Zahlungsverkehr <strong>im</strong> Zusammenhang stehen. In mehreren größeren Unternehmen<br />

wurden Getränke- und Verpflegungsautomaten und Kantinen auf die bargeldlose Bezahlung<br />

mittels Quick umgestellt. Vielerorts ist es bereits möglich, in öffentlichen Verkehrsmitteln<br />

und an Parkscheinautomaten mit der elektronischen Geldbörse zu bezahlen. Anwendungen<br />

für @Quick finden sich nicht nur in Webshops, sondern auch <strong>im</strong> Bereich von<br />

Terminallösungen, wo es nun möglich ist, das Internet als Medium für Zahlungen und<br />

Einreichungen zu verwenden. Beispielsweise bieten einige Universitäten den Studenten<br />

bereits an, über @Quick an Internet Surfstationen den Studienbeitrag zu bezahlen.<br />

Damit hat sich die Chipkarte der österreichischen Banken als Basis für neuartige<br />

Anwendungen auch außerhalb des Zahlungsverkehrs etabliert, die zu einer hohen Akzeptanz<br />

bei Kunden und Handel geführt haben und für das Kreditgewerbe dadurch weitere Einnahmen<br />

bei gleichzeitigen Kostenreduktionen ermöglichen. [LUK]<br />

4.4.2 Voraussetzungen für Kunden<br />

Folgende Voraussetzungen sind für das Bezahlen <strong>im</strong> Internet erforderlich:<br />

• Geladene Quickkarte: Hervorstehendes Merkmal ist die geladene Chip-Karte. Diese ist<br />

für die Zahlungstätigkeit <strong>im</strong> Internet für den Kunden unerlässlich. Datenträgerfähige<br />

Chips sind schon seit geraumer Zeit fixer Bestandteil diverser Kartensysteme wie<br />

Bankomatkarte oder Euroscheckkarte. Das Aufladen der „kontogebundenen“ Karten ist<br />

derzeit auf EUR 400,-- begrenzt. Im Handel werden auch anonyme Quick-Wertkarten <strong>im</strong><br />

Wert von 7,30 Euro angeboten. Diese „kontoungebundenen“ Karten haben keinen Bezug<br />

zu einem Konto und machen daher anonyme Zahlungen möglich.<br />

• Kartenterminal: Für das Einlesen des Quick-Saldos muss aus Sicherheitsgründen ein von<br />

der Europay zugelassenes Lesegerät der Klasse 1 (ohne Display, ohne Tastatur) verwendet<br />

werden, um Zahlungen <strong>im</strong> Internet vorzunehmen. Das Aufladen des Quick-Chips erfolgt<br />

bei Bankomatkarten, die über eine Quick-Ladefunktion verfügen, über<br />

Geldausgabeautomaten. Die Besitzer einer anonymen Quick-Wertkarte können gegen<br />

Barzahlung, in einem österreichischen Kreditinstitut, das eine Ladestation bereithält,<br />

aufgeladen werden.<br />

• @Quick-Software: Ist ein sicheres Plug-In für den Internet-Browser, das zur Steuerung<br />

des Kartenterminals eingesetzt wird. Die Software, ein 500 KB großes File, kann sich der<br />

Kunde kostenlos bei PDTS runterladen und sofort installieren. Eine Verwaltungsfunktion<br />

bietet <strong>im</strong> Zusammenhang mit dem Lesegerät und dem Quick-Chip die Möglichkeit, die<br />

letzten 8 getätigten Transaktionen abzurufen.<br />

4.4.3 Voraussetzungen für Händler<br />

Durch @Quick ist es dem Händler möglich, dieses Service, ohne es selbst betreiben zu<br />

müssen, anzubieten. Sowohl Installation als auch technische Abwicklung werden in diesem<br />

Fall von PDTS durchgeführt. PDTS ist ein von der Europay Austria für die Akzeptanz von<br />

@Quick-Zahlungen lizenzierter Hosting-Anbieter <strong>im</strong> Sinne eines Application Service<br />

Provider und betreibt dafür eigens Server, auf welchen die Terminalkarten für die @Quick<br />

Zahlungssysteme <strong>im</strong> Internet


4 Internet-Zahlungssysteme 38<br />

Händler bereitstehen. Die Terminalkarte dient zur Speicherung von<br />

zahlungsabwicklungsrelevanten Umsatzdaten des Händlers. Auch die Einreichung der<br />

Umsätze und deren Kontrolle wird internetbasierend über dieses System ermöglicht. PDTS<br />

bietet verschiedene Möglichkeiten für den Händler zur Anbindung an das @Quick-<br />

Bezahlsystem an: @Quick-MiniPay und @Quick-StandardPay.<br />

Alternativ wird dem Händler auch die Option zugestanden, selber die Hostingverpflichtungen<br />

zu übernehmen. Der funktionale Ablauf bleibt davon unberührt.<br />

• Vertrag mit Europay: Der Händler schließt einen Vertrag über die Abwicklung von<br />

Zahlungen mit der Elektronischen Geldbörse <strong>im</strong> Internet (@Quick) mit Europay Austria<br />

betreffend einer Terminalkarte ab.<br />

• ASP-Vertrag mit PDTS: Bei diesem Vertrag wird die vom Händler gewünschte Option<br />

festgelegt. Der ASP ist daraufhin dem Händler verpflichtet die ausgehandelten Services<br />

zur Verfügung zu stellen.<br />

• CGI-Schnittstelle: Die Anbindung an den Payment Server von PDTS erfolgt durch eine<br />

CGI-Schnittstelle. Für diese Zwecke werden dem Händler zwei Scripts zur Verfügung<br />

gestellt, die einfach in seinen Web-Server zu integrieren sind. Mit dem ersten Script wird<br />

die Bezahlung eingeleitet. Dazu werden Händlernummer, Betrag, Währung und<br />

Warenbezeichnung übergeben. Das zweite Script kontrolliert das Ergebnis der Bezahlung<br />

und kommt vor der Freigabe der Ware zum Einsatz. Diese Scripts sind in den<br />

Programmiersprachen perl, PHP oder C <strong>im</strong> Quelltext verfügbar und können in einen Web-<br />

Server leicht eingebunden werden.<br />

PDTS bietet dem Händler die Möglichkeit über ein Internetportal jederzeit Einsicht in seine<br />

mit @Quick getätigten Umsätze und Transaktionen zu nehmen. Diese Daten werden in der<br />

Datenbank über einen Zeitraum von mindestens 3 Monaten gespeichert. PDTS ermöglicht<br />

das Herunterladen der Daten vom @Quick-Hosting-Server <strong>im</strong> CSV Format – einem Format<br />

das leicht von anderen Anwendungen wie MS Excel oder MS Access gelesen werden kann.<br />

Zu diesem Zweck erhält der Händler von PDTS eine eindeutige Händlernummer und ein<br />

Passwort. Unter Verwendung eines Internetbrowsers kann nach Authentifizierung durch<br />

Händlernummer und Passwort über eine SSL Verbindung auf die Daten zugegriffen werden.<br />

4.4.4 Transaktionsablauf<br />

Zahlungssysteme <strong>im</strong> Internet


4 Internet-Zahlungssysteme 39<br />

1. Zahlungswunsch: Nachdem der Kunde seinen Warenkorb zusammengestellt hat kann er<br />

per Klick das Quickpayment-Verfahren aktivieren.<br />

2. Zahlungsaufforderung: Das Plug-In wird gestartet und der Kunde führt die Quickkarte<br />

in sein Lesegerät ein. Gleichzeitig erfolgt ein gesicherter Verbindungsaufbau mit dem<br />

PDTS Hosting Server.<br />

3. Zahlungsbestätigung: In einem PopUp-Fenster werden die Zahlungsdaten und das auf<br />

der Quickkarte verfügbare Guthaben zur Kontrolle nochmals angezeigt. Durch Klick auf<br />

die OK-Tasten <strong>im</strong> PopUp-Fenster wird die Bezahlung durchgeführt und die<br />

Zahlungsdaten werden verschlüsselt an PDTS übertragen.<br />

4. Abbuchung des Zahlungsbetrages: Das Guthaben der Quickkarte wird um den<br />

Zahlungsbetrag reduziert und als Gutschrift für den Händler auf der Händlerterminalkarte<br />

um denselben Betrag erhöht.<br />

5. Abbuchungsbestätigung: Die erfolgreiche Bezahlung wird bestätigt und das Plug-In<br />

be<strong>im</strong> Kunden geschlossen.<br />

6. Abbuchung an Europay: PDTS leitet den auf der Händlerterminalkarte gespeicherten<br />

Betrag an Europay weiter.<br />

7. Gutschrift auf das Händlerkonto: Der Rechnungsbetrag wird dem Händler unter Abzug<br />

eines Disagios auf sein Kommerzkonto gutgeschrieben<br />

4.4.5 Kosten Händler<br />

Für die Integration von @Quick-MiniPay und @Quick-StandardPay werden von PDTS<br />

einmalig EUR 1.699,-- in Rechnung gestellt. Weitere laufende Kosten sind der Tabelle 4-7 zu<br />

entnehmen.<br />

Kosten / Jahr Transaktionen / Jahr Preis / Transaktionen darüber<br />

EUR 449,-- bis 2000 EUR 0,15<br />

EUR 579,-- bis 4000 EUR 0,15<br />

EUR 999,-- kein L<strong>im</strong>it EUR 0,15<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Tabelle 4-7: Kosten @Quick - Händler<br />

4.5 E-Einkauf<br />

[BEZ]<br />

Bezahlen.at ist eine elektronische Zahlungsplattform auf der Österreichs Unternehmen<br />

Rechnungen präsentieren, welche über das Clearinghaus der Postsparkasse <strong>im</strong> Wege des<br />

Internetbankverkehrs durchgeführt werden. Dabei fungiert die P.S.K als ein<br />

„Zwischenhändler“ zu allen anderen Banken und leitet freigegebene Rechnungen zum<br />

Fälligkeitstermin <strong>im</strong> Zwischenbankverkehr an die jeweilige Hausbank des Kunden weiter.<br />

Bezahlen.at-Kunden können daher bezahlen.at mit Ihrer bestehenden Kontoverbindung<br />

nutzen – unabhängig davon, bei welcher Bank das Konto geführt wird. Mit E-Einkauf bietet<br />

bezahlen.at ein neues Services an, dass Online-Shoppern die Möglichkeit eröffnet, diese<br />

Zahlungsvariante auszuwählen und damit den Einkauf <strong>im</strong> Internet sofort abzuschließen.<br />

4.5.1 Einsatzgebiet<br />

Für registriere Kunden bietet bezahlen.at <strong>im</strong> Rahmen eines 24-Stunden-Services eine Vielzahl<br />

von Funktionalitäten die eigene Rechnungen bequem und sicher von zuhause zu bezahlen.<br />

Egal ob es sich um Stromrechnungen, Telefongebühren oder Kanalgebühren handelt, alle<br />

Rechnungen von autorisierten Unternehmen werden für den Kunden gesammelt. Folgende


4 Internet-Zahlungssysteme 40<br />

Funktionen gelten generell für alle Rechnungen <strong>im</strong> Rahmen von bezahlen.at: Durch Aufruf<br />

der Einzelrechnung können sämtliche Detaildaten der Rechnung eingesehen werden. Eine<br />

Übersicht zeigt auch alle Rechnungen der Vergangenheit. Der Auftrag wird zum<br />

Zahlungstermin zur Buchung an die Bank des Kunden weitergeleitet. Auf dem Auszug des<br />

Kontos findet der Kunde die entsprechende Buchung. Er hat dann noch bis zu 42 Tage Zeit,<br />

Einspruch zu erheben, sollten sich in der Zwischenzeit Unklarheiten (zum Beispiel über den<br />

Leistungsumfang der bezahlten Rechnung) ergeben haben.<br />

4.5.2 Voraussetzungen für Kunden<br />

• Girokonto: Der Kunde muss ein eigenes Girokonto bei einer beliebigen inländischen<br />

Bank haben, der eine Einzugsermächtigung erteilt werden muss.<br />

• Vertrag: Zugang zu bezahlen.at erhalten Personen, die sich online bei bezahlen.at unter<br />

Eingabe von persönlichen Daten und gewählten Daten (Benutzername und Kennwort)<br />

identifizieren und das ausgedruckte Anmeldeformular mit ihrer eigenhändigen<br />

Unterschrift versehen gemeinsam mit der Kopie eines gültigen Ausweisdokumentes an<br />

bezahlen.at übermitteln. Nach erfolgreicher Prüfung der Identität des Kunden erfolgt die<br />

Freischaltung. Kunden, die als Kontoverbindung kein P.S.K. Konto haben und an E-<br />

Einkauf teilnehmen möchten, müssen sich in einer P.S.K.Servicestelle (P.S.K.<br />

Zweigstellen, Postämter) durch Vorlage eines gültigen Ausweisdokumentes legit<strong>im</strong>ieren.<br />

Im Zuge der Anmeldung zu E-Einkauf wird eine interne Bonitätsprüfung gemacht die<br />

ausschlaggebend für die Höhe des Einkaufsrahmens ist. Der einzelne Einkauf ist mit EUR<br />

800,-- beschränkt und insgesamt dürfen in einem Zeitraum von sechs Wochen, abhängig<br />

von der Bonität des Kunden max<strong>im</strong>al EUR 3.000,-- umgesetzt werden beziehungsweise<br />

EUR 1.500,-- von Kunden, die kein Konto bei der P.S.K. besitzen.<br />

4.5.3 Voraussetzungen für Händler<br />

• Verrechnungskonto: Voraussetzung für die Teilnahme des Online-Shop-Betreibers am<br />

E-Einkauf ist die Eröffnung eines bezahlen.at-Verrechnungskontos. Dazu füllt der<br />

OnlineShop-Betreiber ein Anmeldeformular online aus und gibt es am nächsten Postamt<br />

oder einer P.S.K.Zweigstelle ab. Die P.S.K. prüft die Daten und stellt dem<br />

Leistungserbringer kostenlos das Verrechnungskonto für bezahlen.at zur Verfügung, auf<br />

welches nur Umsätze aus dem Zahlungsverkehrsservice E-Einkauf gebucht werden<br />

können. Das auf diesem angehäufte Guthaben wird wöchentlich auf ein vom<br />

Leistungserbringer genanntes Konto abgeschöpft. Zur Absicherung dieser<br />

Rückbuchungen hat der Online-Shop-Betreiber auf dem für bezahlen.at einzurichtenden<br />

Verrechnungskonto einen Betrag von EUR 5.000,-- jederzeit zur Verfügung zu halten<br />

• Schnittstelle: Bezahlen.at gibt ein standardisiertes XML-Schema vor. Dies hat den<br />

Vorteil das der Händler, wenn er sich nicht für vorgefertigte Schnittstellensoftware<br />

entscheidet dennoch eine kompatible Applikation entwerfen kann.<br />

• Java virtual machine Version 1.2.1 oder höher: Der Localhost Listener basiert auf der<br />

Java Technologie. Damit kann er alle Vorteile, die eine Java Virtual Maschine bietet<br />

ausnützen sowie sich modular an andere moderne Java Webtechnologien anbinden.<br />

4.5.4 Kosten Händler<br />

Das Verrechnungskonto wird kostenlos seitens der P.S.K. zur Verfügung gestellt und bietet<br />

die ideale Basis für die explizite Verrechnung von bezahlen.at Gebarungen. Es entstehen<br />

keine laufenden Kontokosten, die Anbindung ist ebenso kostenfrei, wie der Software-<br />

Zahlungssysteme <strong>im</strong> Internet


4 Internet-Zahlungssysteme 41<br />

Download (Localhost Listener). Für jede vom Kunden getätigte Transaktion kommt ein<br />

Disagio in Höhe von 2,5% des jeweiligen Umsatzes zur Anlastung, wobei die P.S.K. die<br />

Garantie für den Ausfall übern<strong>im</strong>mt. Ohne Garantie beläuft sich das Disagio auf 1%.<br />

4.5.5 Transaktionsablauf<br />

1. Zahungswunsch: Nachdem der Kunde seinen Warenkorb zusammengestellt hat wählt er<br />

als Zahlungsoption bezahlen.at. Der Händler präsentiert online den Warenkorb (Shopping<br />

Cart) aufgrund einer Kundentransaktion und bietet die Zahlungsvariante bezahlen.at an.<br />

2. Zahlungsaufforderung: Der Retail-Kunde identifiziert sich mittels Benutzername und<br />

Kennwort; durch Klicken auf den bezahlen-Button wird der Prozeß angestoßen.<br />

3. Weiterleitung der Zahlungsdaten: Der Händler generiert die eigentliche bezahlen.at-<br />

Rechnung und überträgt diese Rechnung <strong>im</strong> XML-Format über eine verschlüsselten<br />

Kommunikationskanal zum Web-Server der P.S.K.<br />

4. Autorisierungsprüfung: Am bezahlen.at-Server wird geprüft, ob es sich um einen<br />

bezahlen.at-Teilnehmer handelt bzw. ob dieser für E-Einkauf freigeschaltet ist und dieser<br />

über die entsprechende Bonität zur Begleichung der Transaktion verfügt.<br />

5. Bestätigung: Nach der erfolgreicher Identifizierung des Kunden erfolgt eine positive<br />

Rückmeldung des Servers mittels XML-File (Statusmeldung) an den Online-Shop.<br />

6. Warenauslieferung: Der Online-Shop Betreiber hat aufgrund des positiven Transaktionsabschlusses<br />

die Möglichkeit, seine Waren sofort zu versenden.<br />

7. Belastung Kundenkonto: Am vom Händler definierten Fälligkeitstag werden die vom<br />

Kunden freigegebenen Rechnungen seitens der P.S.K. durchgeführt.<br />

8. Gutschrift Händlerkonto: Im Weg des Einzugsermächtigungsverfahrens werden die<br />

Rechnungen auf dem Bankkonto des Kunden, abzüglich eines Disagios zur Gutschrift<br />

gebracht.<br />

4.6 Banking-Verfahren<br />

Neben Telekommunikationsfirmen und sonstigen Softwarefirmen sprangen auch die großen<br />

österreichischen Geldinstitute auf den Zug der e-payment Verfahren auf. Aus Gründen des<br />

Prestiges und der Konkurrenz hat jedoch dabei jede Bank sein eigenes Verfahren entwickelt<br />

und bietet es für ihre jeweiligen Kunden an. Dabei scheint die Tatsache, dass alle diese von<br />

den Banken angebotenen Systeme funktional nahezu identisch ablaufen, wenig zu<br />

Zahlungssysteme <strong>im</strong> Internet


4 Internet-Zahlungssysteme 42<br />

interessieren. Das bedeutet aber, dass Händler für Kunden verschiedener Institute<br />

verschiedene Schnittstellen integrieren müssen und deren Protest kann nicht mehr auf lange<br />

Zeit überhört werden. Daher werden Versuche gestartet Banking Systeme zu vereinheitlichen.<br />

Wie dieses neue System aussehen wird, ist eine Frage für die nähere Zukunft. Derzeit kann<br />

man aber noch keine Prognosen stellen. In dieser Arbeit wird ein Banking Verfahren<br />

repräsentativ für alle dargestellt.<br />

4.6.1 Einsatzgebiet<br />

Netpay ist ein von der Erste Bank angebotenes Zahlungssystem das den Online-Shoppern <strong>im</strong><br />

Internet ermöglicht Zahlungsverpflichtungen aufgrund von online abgeschlossenen<br />

Geschäften auf unbürokratische und sichere Weise auch mittels online erteilten<br />

Zahlungsaufträgen zu erfüllen. Für die Bezahlung von Waren und Dienstleistungen <strong>im</strong><br />

Internet, bietet netpay die Möglichkeit, die Zahlung in Form eines Überweisungsauftrages<br />

direkt <strong>im</strong> Internet abzuwickeln. [NET]<br />

4.6.2 Voraussetzungen für Kunden<br />

• Girokonto: Für die Nutzung von netpay ist eine Kontoverbindung bei der Hausbank<br />

notwendig.<br />

• Vertrag: Um mit netpay zu bezahlen, ist für den Kunden keine separate Anmeldung oder<br />

Registrierung erforderlich. netpay basiert auf netbanking, deshalb sind alle netbanking-<br />

Kunden <strong>im</strong> Internet zahlungsbereit. Kunden die noch keine netbanking-Berechtigung<br />

haben, beantragen in einer der Geschäftsstellen die Freischaltung von netbanking oder<br />

drucken sich den Antrag gleich über das Internet aus und schicken ihn per Post an die<br />

Bank. Daraufhin wird der Kunde schriftlich über die Freischaltung verständigt und<br />

Verfügernummer mit Passwort zugestellt.<br />

• Javafähiger Browser: Der Browser des Kunden muss Java unterstützen, da die<br />

Autorisierungsanforderung in Form eines Java-Applets geladen wird.<br />

4.6.3 Voraussetzungen für Händler<br />

• Kommerzkonto: Für die Nutzung von netpay muss der Händler ein Firmenkonto bei der<br />

Erste Bank besitzen.<br />

• XML-Schnittstelle: Der Händler benötigt für die Anbindung seines Online-Shops eine<br />

spezielle Software, die von der Bank zur Verfügung gestellt wird.<br />

• Sicherheitszertifikat: Die Durchführung einer gesicherten Zahlungsabwicklung zwischen<br />

Online-Shop-Betreiber und dem Bankinstitut erfordert entsprechende<br />

Verschlüsselungstechniken. Am Server muss eine SSL-fähige Anwendung laufen und der<br />

Server benötigt ein Zertifikat einer weit verbreiteten und vertrauten CA<br />

4.6.4 Kosten Händler<br />

In Tabelle 4-8 sind die Anschaffungs- und Transaktionskosten angeführt die bei der Nutzung<br />

von Banking-Verfahren zu tragen sind.<br />

Einrichtungsgebühr am Bankrechner (einmalig) 150 Euro<br />

Transaktionsgebühr/Transaktion (mind. ! 9,45 pro Quartal) 0,14 Euro<br />

Umsatzprovision (mind. ! 15 pro Quartal) 1,9 %<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Tabelle 4-8: Kosten Banking - Händler


4 Internet-Zahlungssysteme 43<br />

4.6.5 Transaktionsablauf<br />

1. Zahlungswunsch: Entscheidet sich der Kunde be<strong>im</strong> Online-Shopping für eine Ware oder<br />

Dienstleistung, legt er diese in den Warenkorb und wählt über einen Button das netpay-<br />

Zahlungssystem<br />

2. Weiterleitung der Zahlungsdaten: Die Bezahldaten werden automatisch mittels XML-<br />

Stream an den netpay-Bankrechner geschickt. Die netpay-Anforderung des Händlers<br />

sowie die Authentifikation des Shop-Rechners werden am Bankrechner geprüft<br />

(Authentifikation Händler.) Im Anschluss daran retourniert der Bankrechner eine http-<br />

Adresse zu der der Kunde automatisch weitergeleitet wird, wo er sich wie bei netbanking<br />

mit seiner Verfügernummer einloggt.<br />

3. Kundenlegit<strong>im</strong>ierung: Der Kunde gelangt automatisch zur Einstiegsseite von netpay, wo<br />

er aufgefordert wird, sich durch Eingabe seiner Verfügernummer und Passworts zu<br />

identifizieren. Ein Java-Applet, das mit dem Aufruf der Einstiegsseite gestartet wird, führt<br />

mit Hilfe einer Hashfunktion die Verschlüsselung des Kundenpasswortes durch, das damit<br />

unleserlich erscheint. Durch einen Anmeldebutton bestätigt der Kunde die Weiterleitung<br />

der Eingabedaten an den Bankrechner.<br />

4. Autorisierungsprüfung: Die Identifikation des Kunden wird am Bankrechner geprüft<br />

5. Zahlungsfreigabe: Nach erfolgreicher Identifikation, werden dem Kunden nochmals die<br />

vom Rechner des Händlers aufgrund des Warenkorbs ermittelten Bezahldaten angezeigt.<br />

Der Kunde wählt nun das Konto aus von welchem die Buchung erfolgen soll. Daraufhin<br />

wird noch von der Bank überprüft, ob das Konto eine ausrechende Deckung für den<br />

gewünschten Zahlungsvorgang bietet. Durch die Eingabe der TAN erteilt der Kunde der<br />

Bank die Ermächtigung zum Einzug des Entgeltes für die Ware von dem von ihm<br />

angegebenen Konto und der Bankrechner führt die Überweisung durch.<br />

6. Zahlungsbestätigung: Nach Abwicklung der Transaktion erfolgt eine elektronische<br />

Zahlungsbestätigung an den Kunden und den Händler durch den Rechner des<br />

Geldinstitutes.<br />

7. Warenauslieferung: Der Händler liefert die Ware aus.<br />

Zahlungssysteme <strong>im</strong> Internet


4 Internet-Zahlungssysteme 44<br />

4.7 M-Pay<br />

[VOD]<br />

Der deutsche Mobilfunkbetreiber Vodafone D2 bietet seit September 2002 ein<br />

Abrechnungssystem für bargeldloses Bezahlen von Kleinbeträgen <strong>im</strong> Internet an. Alle<br />

Vodafone D2-Kunden können ohne weitere Anmeldung oder Registrierung diesen Dienst bei<br />

Vodafone-Partnern in Anspruch nehmen.<br />

4.7.1 Einsatzgebiet<br />

Je nach Nutzungsart, ob per Internet oder WAP, können digitale Inhalte bis zu einer<br />

Obergrenze von EUR 10,-- pro Transaktion verrechnet werden. Als typische Beispiele für<br />

Leistungen, die per Vodafone m-pay bezahlt werden können, zählen Finanz- und<br />

Börseninformationen, Download von Software oder Dokumenten, aber auch mobile Inhalte<br />

wie Bildschirmschoner, Spiele oder Klingeltöne. Darüber hinaus ist m-pay auch für die<br />

Abrechnung von Recherchen in Datenbanken und Online-Archiven prädestiniert.<br />

4.7.2 Voraussetzungen für Kunden<br />

• Vertrag mit Vodafone D2: Kunden, die das Zahlungssystem m-pay nutzen wollen,<br />

müssen einen bestehenden Mobilfunk-Vertrag bei Vodafone haben.<br />

• Mobiltelefon mit gültiger SIM-Karte<br />

Der Kunde muss ein Mobiltelefon mit gültiger Vodafone D2-Karte besitzen. Über die<br />

SIMCARD <strong>im</strong> Handy wird der Kunde eindeutig identifiziert. An das Handy werden keine<br />

weiteren Bedingungen gebunden. Es ist gleichgültig ob es sich dabei um ein Wertkarten-<br />

Handy oder um ein Vertragshandy handelt. Bei Vertragshandys erfolgt die Abbuchung<br />

automatisch per Mobiltelefonrechnung von Vodafone.<br />

4.7.3 Voraussetzungen für Händler<br />

• Vertrag mit Vodafone D2: Der Händler muss einen Händler-Vertrag mit Vodafone D2<br />

abschließen und ein Girokonto bekannt geben.<br />

Die Anbindung an Vodafone m-pay erfolgt für Händler ohne zusätzliche Hardware- oder<br />

Softwareanschaffung. Der Händler benötigt nur ein s<strong>im</strong>ples standardisiertes Interface über<br />

http und die Integration von Vodafone m-pay kann in allen Shopsysteme zum Einsatz<br />

gebracht werden.<br />

4.7.4 Transaktionsablauf<br />

Zahlungssysteme <strong>im</strong> Internet


4 Internet-Zahlungssysteme 45<br />

1. Zahlungswunsch: Nachdem der Bestellablauf durch einen modernen e-commerce-Shop<br />

via virtuellen Einkaufswagen durchgeführt wurde, kann durch einfachen Klick auf den mpay-Button<br />

der Zahlungsablauf in Gang gesetzt werden.<br />

2. Weiterleitung des Zahlungswunsches: Mit Hilfe der Vodafone-Telefonnummer, die<br />

selbstverständlich ein eindeutiger Identifikationsausweis für den Kunden ist, wird die<br />

Rechtmäßigkeit des Bestellablaufs bestätigt. Die Kundendaten und die Händlerdaten<br />

werden vom Händler an den m-pay-Payment Server weitergeleitet.<br />

3. Bestätigungsanfrage: Das System bestätigt den Kunden nach erfolgreicher Verifikation<br />

der Kunden- und Händlerdaten durch die Übermittlung eines temporären PIN, welcher per<br />

SMS an den Kunden übermittelt wird, den erfolgreichen Abschluss des Bestellvorgangs.<br />

4. Bestätigung durch SMS: Zwecks Bestätigung der Autorisierung muss der Kunde diesen<br />

temporären PIN-Code in einem Popup-Fenster eingeben und bestätigt damit die<br />

Korrektheit der Zahlungsaufforderung sowie sein Einverständnis, dass der Händler das<br />

Bankkonto bzw. CallYa-Konto über den offenen Zahlungsbetrag belasten darf. Es kann ja<br />

sein, dass der Kunde sich nicht mehr in Besitz des Handys befindet oder jemand<br />

willkürlich eine Handynummer eingegeben hat.<br />

5. Bestätigung an den Händler: Durch die Autorisierung von Vodafone kann nun der<br />

Bestellablauf durch Ausliefern der Ware an den Kunden vollzogen werden, indem der<br />

Händler ein so genanntes Capture Token von m-pay bekommt. Der Forderungsbetrag wird<br />

zunächst von Vodafone für den Händler „reserviert“ ein Banktransfer findet noch nicht<br />

statt. Der Händler kann jetzt über diesen Betrag in einem definierten Zeitraum verfügen<br />

und zu einem späteren Zeitpunkt die Buchung einleiten. Diese Art der Transaktion ist<br />

insbesondere bei langen Laufzeiten einer Bestellung sinnvoll. Der Kunde wird dadurch<br />

zeitnah zur Auslieferung der Ware belastet.<br />

6. Bestätigung an Kunden: Durch eine weitere SMS an den Kunden wird die erfolgreiche<br />

Zahlungsautorisierung bestätigt und der Händler verschickt den Content an den Kunden.<br />

7. Capture Request: Durch den abschließenden Capture Request sendet der Händler ein<br />

Bestätigungstoken an Vodafone, dass die Auslieferung in die Wege geleitet wurde.<br />

8. Abbuchung vom Kundenkonto: Im Entwurf ist vorgesehen, dass die finanziellen<br />

Transaktionen (Bankabbuchungen) von Vodafone geregelt werden. Der Betrag wird per<br />

Vodafone-Rechnung eingezogen oder vom CallYa-Konto (Wertkarte) abgebucht. Bei<br />

Wertkartentelefonen werden die Beträge in „Echtzeit“ abgebucht, somit hat der Kunde<br />

auch <strong>im</strong>mer eine Kostenkontrolle. Bei den „Post-paid“-Kunden steht der Betrag dann<br />

hinterher auf der monatlichen Mobiltelefonrechnung.<br />

9. Gutschrift auf Händlerkonto: Unter Abzug eines vertraglich festgehaltenen Disagios<br />

werden die Umsätze gesammelt und in regelmäßigen Abständen erhält der Händler seinen<br />

Forderungsbetrag gutgeschrieben.<br />

4.7.5 Kosten Kunde<br />

Für den Kunden entstehen bei der Nutzung des Handy-Zahlungsmittels Vodafone m-pay<br />

keinerlei zusätzliche Gebühren. Er zahlt lediglich für die kostenpflichtigen Angebote, die er<br />

be<strong>im</strong> Händler in Anspruch n<strong>im</strong>mt, sowie je nach seiner Nutzung des stationären oder<br />

mobilen Internets für den Zugang bzw. die Verbindungspreise seines Providers. Die Übersicht<br />

seiner Ausgaben erhält der Kunde ebenfalls kostenfrei auf seiner Mobilfunkrechnung.<br />

Zahlungssysteme <strong>im</strong> Internet


4 Internet-Zahlungssysteme 46<br />

4.7.6 Kosten Händler<br />

Für Händler entstehen keinerlei Anschlussgebühren, Lizenzkosten oder Jahresgebühren. Für<br />

die Inanspruchnahme der Leistungen aus Vodafone m-pay ist eine umsatzabhängige<br />

Vergütung zu entrichten, die sich mindestens auf EUR 500,-- pro Monat beläuft, darüber<br />

hinaus wird eine umsatzabhängige Vergütung von Vodafone vom Forderungsbetrag<br />

verrechnet.<br />

4.8 Iclear<br />

[ICL]<br />

Die EuroCoin iclear GmbH eine Tochterfirma der EuroCoin AG, dem weltweit größten<br />

Münzhersteller, ist Anbieter der Dienstleistung iclear, ein weiteres Zahlungssystem, das es<br />

ermöglicht, <strong>im</strong> Internet per Rechnung zu bezahlen. IClear fungiert als Clearing-Haus<br />

zwischen Lieferanten (Online-Shop) und Kunden. Anstelle eines direkten Geschäfts zwischen<br />

Händler und Kunde kommen zwei zustande, nämlich zwischen Händler und iclear einerseits<br />

und iclear und dem Kunden andererseits. Dabei erfasst iclear alle Rechnungen der Lieferanten<br />

für Lieferungen an den jeweiligen Kunden zentral in einer Datenbank.<br />

4.8.1 Einsatzgebiet<br />

Iclear ermöglicht den Kauf von physischen Waren aber auch von virtuellen Produkten, deren<br />

Existenz nur in elektronischer Form vorliegt.<br />

4.8.2 Voraussetzungen für Kunden<br />

• Vertrag mit iclear: Die Registrierung bei iclear erfolgt über ein Online-Formular.<br />

Optional kann sich der Kunde den Vertrag ausdrucken und nach Unterzeichnung an iclear<br />

zurückschicken. Per e-mail wird der Benutzername und Passwort übermittelt. Gleichzeitig<br />

wird ein Verfügungsrahmen von EUR 100,-- eingerichtet, der den Kunden gestattet<br />

Online-Käufe bis zu dieser Obergrenze zu tätigen. Von Einkauf zu Einkauf wird dieser<br />

Rahmen von iclear stufenweise erhöht.<br />

• Girokonto: Der Kunde benötigt ein Girokonto bei einem Kreditinstitut.<br />

4.8.3 Voraussetzungen für Händler<br />

• Vertrag mit iclear: Der Händler hat die Möglichkeit einen Vertag für physische Güter und<br />

für elektronische Güter abzuschließen. Die jeweils vertraglich geforderten Daten schickt<br />

der Händler per Post oder Fax an iclear. Nach erfolgreicher Freischaltung erhält der<br />

Händler eine Merchant-ID und eine Bestellseite, die er in ein bestehendes Shopsystem<br />

einbinden muss. Da das Zahlungsverfahren iclear in vielen Shop-Systemen (z.B. GS Shop<br />

Builder Pro 2.0) bereits integriert ist, erfolgt eine rasche und einfache Anbindung ohne<br />

zusätzliche Hardware- oder Softwareinvestitionen.<br />

4.8.4 Kosten Händler<br />

Der Händler zahlt für die Zahlungsabwicklung durch EuroCoin iclear und die Organisation<br />

des Zahlungsverkehrs sowie die Absicherung eines Forderungsausfalles gegenüber dem<br />

Kunden nachfolgende Leistungsentgelte (Tabelle 4-9):<br />

Lizenzgebühr EUR 116,--<br />

Transaktionskosten 3,9 % v. Umsatz<br />

Transaktionsbearbeitung/Sammelrechnung EUR 1,--<br />

Zahlungssysteme <strong>im</strong> Internet


4 Internet-Zahlungssysteme 47<br />

4.8.5 Transaktionsablauf<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Tabelle 4-9: Kosten iclear - Händler<br />

1. Zahlungswunsch: Nachdem der Kunde den Warenkorb gefüllt und überprüft hat, wählt er<br />

die Zahlung Rechnungskauf über iclear aus. Die lästige Eingabe von Liefer und<br />

Rechnungsadresse entfällt, da diese Daten bei der Registrierung von iclear erfasst werden<br />

und von iclear an den Shop übertragen werden.<br />

2. Zahlungsaufforderung: Die bestellte Ware sowie der Preis werden per Java-Script<br />

direktübernommen und durch einen Redirect gelangt der Kunde ins System von iclear, wo<br />

der Kunde seine Benutzerdaten eingeben muss.<br />

3. Authentifizierung: Durch Eingabe von Benutzername und Passwort erfolgt die<br />

Identifizierung des Kunden.<br />

4. Autorisierungsprüfung: Iclear überprüft Benutzerdaten und den aktuellen<br />

Verfügungsrahmen. Nach erfolgreicher Autorisierung bekommt der Kunde seine<br />

Bestellung nochmals angezeigt.<br />

5. Zahlungsfreigabe: Der Kunde kontrolliert nochmals seine Bestellung und gibt diese<br />

durch einen einfachen Mausklick frei.<br />

6. Zahlungsbestätigung: Iclear generiert eine automatische Bestätigungsmail an den<br />

Kunden und leitet parallel die Lieferadresse des Kunden an den Händler weiter.<br />

7. Warenauslieferung: Der Händler schickt die Ware an den Kunden.<br />

8. Rechnungsstellung: Nach Warenauslieferung übermittelt der Händler die Rechnung an<br />

Iclear.<br />

9. Belastung Kundenkonto: Der Rechnungsbetrag wird 14 Tage nach Rechnungsdatum von<br />

EuroCoin iclear <strong>im</strong> Lastschriftverfahren eingezogen.<br />

10. Gutschrift auf Händlerkonto: Nach erfolgter Belastung des Kundenkontos wird der<br />

Zahlungsbetrag vermindert um die Leistungsentgelte von iclear auf das Kommerzkonto<br />

des Händlers eingezahlt.


4 Internet-Zahlungssysteme 48<br />

4.9 Kreditkarte SET<br />

SET ist ein Protokoll für eine sichere Kreditkartenzahlung über unsichere Netzwerke und<br />

umfasst die sichere Abwicklung von kompletten Geschäftsvorgängen. Ein Benutzer kann ein<br />

Produkt, eine Dienstleistung oder Information mit Kreditkarte bezahlen, ohne dabei seinem<br />

Geschäftspartner seine Kreditkartennummer <strong>im</strong> Klartext nennen zu müssen. Ebenso werden<br />

Anmeldeprozeduren für das Ausstellen von Zertifikaten sowie die Struktur von<br />

Zertifizierungsstellen festgelegt. SET ist kein benutzbares Zahlungssystem, sondern ein<br />

Richtlinie, nach dessen Protokoll Übertragungssysteme verfahren sollen.<br />

4.9.1 Einsatzgebiet<br />

Die Kreditkarte hat sich als universelles Zahlungsmittel etabliert. Und dies nicht nur <strong>im</strong><br />

Bereich des epayment bzw. <strong>im</strong> Bereich des Handels mit digitalen Gütern. Sie ist auch für den<br />

traditionellen Zahlungsverkehr ein nicht mehr wegzudenkender Bestandteil geworden.<br />

4.9.2 Voraussetzungen für Kunden<br />

• Kreditkarte: Der Kunde muss <strong>im</strong> Besitz einer Kreditkarte sein, die er bei seiner<br />

Hausbank beantragen kann.<br />

• Zertifikat: Für die Kreditkarte beantragt der Kunde ein so genanntes SET-Zertifikat. Die<br />

Bank bestätigt, dass der Kunde der rechtmäßige Kartenbesitzer ist und sendet ihm einen<br />

Brief mit Passwort und Anleitung, wie er das Zertifikat aus dem Internet installieren muss.<br />

Das Passwort dient zur Legit<strong>im</strong>ation be<strong>im</strong> Download des Zertifikates.<br />

• Wallet: Der Kunde benötigt für die Teilnahme am SET-Zahlungsprotkoll eine<br />

entsprechende SET-fähige Software (SET-Wallet), die die notwendige Funktionalität zur<br />

Zahlungsabwicklung zur Verfügung stellt. [RAE] Dieses Wallet steht dem Kunden zum<br />

kostenlosen Download <strong>im</strong> Internet zur Verfügung und muss von der SETCo zertifiziert<br />

sein. Eine Liste zertifizierter SETCo SET-Wallets ist <strong>im</strong> Internet auf der Homepage von<br />

SETCo[SET] abrufbar.<br />

4.9.3 Voraussetzungen für Händler<br />

• Händler-Vertrag: Der Händler benötigt einen Kreditkartenakzeptanzvertrag mit einer<br />

Kreditkartengesellschaft, um Kreditkartenzahlungen <strong>im</strong> Internet akzeptieren zu können.<br />

Daraufhin erhält er eine Vertrags-Unternehmensnummer vom abrechnenden Institut. Über<br />

diese Nummer werden die Transaktionen des Händlers direkt dem zuständigen<br />

Abrechnungsinstitut zugeordnet.<br />

• Zertifikat: Von der Kreditkartengesellschaft erhält der Händler nach Abschluss des<br />

Händler-Vertrages ein digitales Zertifikat, das ihn für die Abwicklung elektronischer<br />

SET-Transaktionen autorisiert.<br />

• SET-Software: Für SET-Transaktionen muss der Händler eine SET-Software auf seinem<br />

Server installieren, welche Transaktionen vom Kunden entgegenn<strong>im</strong>mt und an das SET-<br />

Gateway weiterleit.<br />

Zahlungssysteme <strong>im</strong> Internet


4 Internet-Zahlungssysteme 49<br />

4.9.4 Kosten Händler<br />

Die Kosten für die Software liegen zwischen 2000 – 3000 Euro. Eine Liste der am Markt<br />

verfügbaren Software findet man unter www.setco.com. Für jede einzelne Transaktion<br />

werden weitere 2,8 % vom Transaktionsvolumen veranschlagt.<br />

4.9.5 Transaktionsablauf<br />

Eine Transaktion mit SET geht wie folgt vonstatten [MER02, SCH]:<br />

1. Zahlungswunsch/Initiierungsantrag: Während des Verkaufsdialoges wählt der Käufer<br />

auf den Angebotsseiten des Händlers die gewünschten Waren oder Dienstleistungen aus<br />

und sendet einen Initiierungsantrag welcher unter anderem den Kartentyp (welche<br />

Kreditkarten-gesellschaft), die zur Zahlung benutzt werden soll, beinhaltet.<br />

2. Initiierungsantwort: Der Händler antwortet auf diesen Initiierungsantrag durch die<br />

Übermittlung einer „Wake-Up“-Information zum Browser des Karteninhabers. Dieser<br />

Wake-Up Nachricht werden noch das Zertifikat vom Händler und Payment Gateway<br />

beigefügt.<br />

3. Zahlungsanweisung/Auftragsanweisung: Zum Bezahlen der ausgewählten Ware öffnet<br />

sich automatisch das SET-Wallet welches auf dem lokalen PC installiert ist und der<br />

Käufer muss das Wallet mit seinem Benutzernamen und einem Passwort freigeben. Wie<br />

be<strong>im</strong> Zahlen an der Kasse, wo der Kunde seine Geldbörse hervorholt, wählt er eine der <strong>im</strong><br />

Wallet verfügbaren Kreditkarten aus, es wird ihm <strong>im</strong> SET-Wallet die Rechnung nochmals<br />

angezeigt und er bestätigt die Zahlung. Daraufhin überprüft das Wallet die Zertifikate des<br />

Händlers und des SET-Payment-Gateways. Dies gibt dem Käufer die Gewissheit, dass es<br />

sich um offizielle Vertragspartner handelt. Anschließend generiert die Software des<br />

Karteninhabers anhand der ausgewählten Waren und/oder Dienstleistungen die<br />

Bestelldaten für den Händler und die Zahlungsinstruktionen für das Gateway. Beide<br />

Nachrichten werden mit einer dualen Signatur verbunden. Die Zahlungsinstruktionen (mit<br />

Kreditkarteninformationen des Karteninhabers) werden mit dem öffentlichen<br />

Nachrichtenschlüssel des Zahlungs-Gateway verschlüsselt. Der Karteninhaber sendet nun<br />

Zahlungssysteme <strong>im</strong> Internet


4 Internet-Zahlungssysteme 50<br />

die Bestelldaten, die duale Signatur, die Zahlungsinstruktionen und sein Zertifikat<br />

verschlüsselt an den Händler.<br />

4. Zahlungsanweisung/Rechnungsbetrag: Der Händler prüft als erstes das Zertifikat des<br />

Kunden, um sicherzugehen, dass er die Daten vom echten Karteninhaber erhalten hat und<br />

danach erstellt die Händler-Software eine Autorisierungsanfrage an das SET-Payment-<br />

Gateway mit folgendem Inhalt: a. Die Meldung des Käufers mit dessen Zertifikat. b. Eine<br />

Meldung des Händlers, welche dieselben Informationen (Prüfsumme, Währung, Betrag)<br />

aus der Sicht des Händlers enthält. Diese Meldung hat der Händler mit seinem privaten<br />

SET-Schlüssel unterschrieben, verschlüsselt und mit seinem Zertifikat ergänzt.<br />

5. Autorisierungsanfrage: Das SET-Payment-Gateway prüft die Unterschrift des<br />

Karteninhabers, die Unterschrift des Händlers sowie Übereinst<strong>im</strong>mung von Rechnungs-<br />

Prüfsumme, Währung und Betrag aus den beiden Meldungen. Sofern diese Prüfungen<br />

erfolgreich sind, ist sowohl die Echtheit von Karteninhaber und Händler als auch die<br />

Übereinst<strong>im</strong>mung der Kaufabsichten von Käufer und Händler erwiesen. Das SET-<br />

Payment-Gateway leitet nun die Währung, den Betrag und die Kartennummer an den<br />

Autorisierungshost.<br />

6. Autorisierungsbestätigung: Der Autorisierungshost der Kreditkartenorganisation prüft,<br />

ob ein gültiger Vertrag mit dem Händler vorliegt, die Karte des Kunden nicht gesperrt ist<br />

und das L<strong>im</strong>it der Karte nicht überschritten ist. Das Ergebnis der Autorisierung wird<br />

wieder an das SET-Payment-Gateway zurück gesandt.<br />

7. Weiterleitung der Autorisierungsbestätigung: Das SET-Gateway informiert seinerseits<br />

den Händler-Server.<br />

8. Bestätigung: Wenn der Kauf vom SET-Payment-Gateway freigegeben wurde, wird die<br />

erfolgreiche Abwicklung des Kaufes dem Käufer bestätigt. Andernfalls wird der<br />

Karteninhaber über den Grund der Ablehnung informiert.<br />

9. Warenlieferung: Nach Abschluss der Autorisierung erfolgt außerhalb von SET die<br />

Auslieferung der bestellten Waren oder Dienstleistungen durch den Händler.<br />

10. Gutschrift: Die Kreditkartengesellschaft überweist den Zahlungsbetrag abzüglich des<br />

Disagios auf das Girokonto des Händlers.<br />

11. Belastung: Das Girokonto des Käufers wird mit dem offenen Forderungsbetrag durch die<br />

Kreditkartengesellschaft belastet.<br />

4.10 Verified by Visa<br />

Seit 2000 entwickelt Visa ein neues Internet-Bezahlverfahren welches vor allem die<br />

bestehenden Schwachstellen von SET beheben soll. Die Einführung von Verified by Visa in<br />

Östereich ist für Mitte 2003 projektiert aus diesem Grund können auch nachfolgend keine<br />

relevanten Aussagen über die Kostenbelastung des Händlers gemacht werden.<br />

4.10.1 Voraussetzungen für Kunden<br />

• Kreditkarte: Der Kunde muss <strong>im</strong> Besitz einer Kreditkarte sein die er bei seiner Hausbank<br />

beantragt.<br />

• Registrierung: Bevor ein erster Einkauf mit Verified by Visa getätigt werden kann, muss<br />

sich der Kartenbesitzer mit seiner zuständigen Bank online in Verbindung setzen und ein<br />

Online-Formular für die Registrierung ausfüllen. Erfasst werden Name, Kartennummer,<br />

Ablaufdatum der Karte, CSV2 und ein vom Kunden selbstgewähltes Passwort.<br />

Zahlungssysteme <strong>im</strong> Internet


4 Internet-Zahlungssysteme 51<br />

4.10.2 Voraussetzungen für Händler<br />

• Händler-Vertrag: Der Händler benötigt einen Kreditkartenakzeptanzvertrag mit einer<br />

Kreditkartengesellschaft, um Kreditkartenzahlungen <strong>im</strong> Internet akzeptieren zu können.<br />

Daraufhin erhält er eine Vertrags-Unternehmensnummer vom abrechnenden Institut. Über<br />

diese Nummer werden die Transaktionen des Händlers direkt dem zuständigen<br />

Abrechnungsinstitut zugeordnet.<br />

• Merchant-Plug-IN: Eine Software, die dem Händler von Visa kostenlos zur Verfügung<br />

gestellt wird.<br />

4.10.3 Transaktionsablauf<br />

1. Zahlungswunsch: Nachdem der Kunde seinen Warenkorb zusammengestellt hat, wählt er<br />

als Zahlungsoption „Verified by Visa“.<br />

2. Zahlungsaufforderung: Das Formular für die Eingabe der Kreditkartennumer wird<br />

angezeigt. Der Kunde gibt seine Kreditkartennummer ein.<br />

3. Online-Verifikation: Der Händler fragt bei einem speziellen Directory Server an, ob die<br />

vom Kunden verwendete Kartennummer bereits für „Verified by Visa“ freigeschaltet<br />

wurde. Dieser hierfür installierte Directory Server prüft, ob die kartenausgebende Bank<br />

an Verified by Visa teiln<strong>im</strong>mt und reicht die Anfrage an einen sogenannten Issuer Access<br />

Control Server weiter. Der Issuer Access Control Server überprüft, ob die betroffene<br />

Karte für Verified by Visa schon freigeschaltet wurde und reicht bei positivem Ergebnis<br />

seine URL an den Directory Server zurück, der seinerseits diese URL an den Händler<br />

weiterreicht.<br />

4. Redirect: Der Händler führt den Kunden über einen Redirect zu genau der URL des<br />

Issuer Access Control Servers.<br />

5. Freigabe der Transaktion: In einem Browser-Fenster, welches direkt von der Bank<br />

angezeigt wird, authentisiert sich der Kunde durch ein Passwort und autorisierst zugleich<br />

die Transaktion.<br />

6. Authentisierungsbestätigung: Nachdem der Kunde durch Eingabe seines Passwortes die<br />

Transaktion freigegeben hat, wird dem Händler eine Authentisierungsbestätigung<br />

übermittelt. Somit kann die Transaktion starten.<br />

Zahlungssysteme <strong>im</strong> Internet


4 Internet-Zahlungssysteme 52<br />

7. Autorisierungsanfrage: Das Merchant Plug-IN stellt eine Autorisierungsanfrage an das<br />

Payment Gateway.<br />

8. Autorisierungsbestätigung: Der Autorisierungshost der Kreditkartenorganisation prüft,<br />

ob ein gültiger Vertrag mit dem Händler vorliegt, die Karte des Kunden nicht gesperrt ist<br />

und das L<strong>im</strong>it der Karte nicht überschritten ist. Das Ergebnis der Autorisierung über das<br />

Payment-Gateway an den Händler übermittelt.<br />

9. Zahlungsbestätigung: Wenn der Kauf vom SET-Payment-Gateway freigegeben wurde,<br />

wird die erfolgreiche Abwicklung des Kaufes dem Käufer bestätigt. Andernfalls wird der<br />

Karteninhaber über den Grund der Ablehnung informiert. [VISA1]<br />

5 Analyse und Kritik<br />

Das Analyseverfahren beruht nicht auf quantitativen Methoden sondern versucht empirische<br />

Erkenntnisse objektiv und begründbar darzustellen. Für eine exakte quantitative Analyse wäre<br />

ein wesentlich größerer Zeitrahmen vonnöten und deren Aussagekraft bliebe dennoch<br />

fragwürdig, da sich viele Verfahren in Entwicklung befinden und der Prozess der<br />

technologischen Verbesserung eine derartige Dynamik in den letzten Jahren erfahren hat,<br />

sodass es momentan sinnlos wäre einen Hardwarestandard für eine Messserie festzulegen. Da<br />

die jeweiligen Anforderungen an Internet-Zahlungssysteme zudem noch sehr stark von der<br />

Einsatzsituation abhängen, kann die ausgearbeitete Tabelle nur als erste, grobe Orientierung<br />

dienen, der eine detaillierte, auf den konkreten Fall bezogene Analyse folgen muss.<br />

Sicherheit<br />

- Vertraulichkeit<br />

- Zuverlässigkeit<br />

- Integrität<br />

- Verfügbarkeit<br />

- Nichtabstreitbarkeit<br />

- Authentifizierung<br />

Rückverfolgbarkeit<br />

Teilbarkeit<br />

Online-Verifikation<br />

Akzeptanzfähigkeit<br />

Registrierung<br />

Usability<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Paybox<br />

paysafecard<br />

Kreditkarte<br />

(VbV)<br />

Kreditkarte<br />

(SET)<br />

Quick<br />

m-pay<br />

e-einkauf<br />

iclear<br />

netpay


5 Analyse und Kritik 53<br />

Universalität<br />

Transaktionsbearbeitung<br />

Zahlungssicherheit<br />

Implementierung<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Tabelle 5-1: Bewertungstabelle der Zahlungssysteme<br />

5.1 Paybox<br />

Vertraulichkeit: Der Anteil sensibler Daten die über das Internet transferiert werden müssen<br />

ist sehr gering. Durch die Notwendigkeit einer Kombination aus Besitz und Wissen ist das<br />

Verfahren gegenüber anderen Lösungen deutlich sicherer. [RAE] Das Unternehmen hat eine<br />

Reihe von strategischen Kooperationen mit namhaften Partnern geschlossen, die eine sichere<br />

Infrastruktur garantieren. Dazu zählen unter anderem Lufhansa Systems (Rechenzentrum,<br />

Datensicherheit), Compaq und HP. Die Paybox-Datenbanken werden auf dem<br />

Hochsicherheitsgelände von Lufhansa Systems gehosted und sind durch mehrschichtige<br />

Firewalls geschützt. [DIE]<br />

Zuverlässigkeit: Schon alleine durch die Grundanforderung jedes modernen<br />

Datenbanksystems, die ACID-Eigenschaften als unabdingbares Fundament festschreiben,<br />

wäre dieser Punkt bestens erfüllt.<br />

Integrität: Der Prozess läuft prinzipiell nie ohne eine SSL-geschützte Verbindung ab. SSL<br />

<strong>im</strong>pliziert durch seine Definition beste Datenintegrität.<br />

Verfügbarkeit: Aufgrund von technischen Einschränkungen kann es passieren, dass dieses<br />

Verfahren regional nicht zur Verfügung steht. In Zeiten der Spitzenauslastung kann es<br />

vorkommen, dass dieses Verfahren gar nicht oder nur verzögert verwendbar ist.<br />

Nichtabstreitbarkeit: Der hohe Grad an Autorisierung von Kundenseite identifiziert diesen<br />

mit einem sehr hohen Sicherheitsgrad, der nur sehr schwer abzustreiten ist. Auch wenn der<br />

Kunde anderen Personen Zugang zu seinem Mobiltelefon gewährt hat, bliebe seine<br />

Verpflichtung dem Händler gegenüber bestehen, da er seine Sorgfaltspflicht verletzt hätte.<br />

[PAY]<br />

Authentifizierung: Zur Autorisierung einer Zahlung muss ein Kunde drei Voraussetzungen<br />

erfüllen: Er muss <strong>im</strong> Besitz der SIM-Karte sein, unter deren Nummer die Paybox eingerichtet<br />

wurde, muss dieses Mobiltelefon mit der Handy-PIN aktivieren können und schließlich seine<br />

Paybox-PIN kennen. Zum Missbrauch einer Kunden-Paybox müsste ein Unberechtigter diese<br />

drei Informationen besitzen. Die Wahrscheinlichkeit von so genannten „Funbestellungen“ ist<br />

somit sehr gering, da nur der Kunde die Autorisierungs-PIN kennt und so eindeutig<br />

identifiziert werden kann. Der PIN ist eine 4-stellige Zahl und jede einzelne Transaktion muss<br />

mit diesem PIN bestätigt werden. Die Paybox wird automatisch nach der dritten<br />

Falscheingabe der PIN gesperrt und kann nur mit einer persönlichen Sicherheitsfrage wieder<br />

aktiviert werden.<br />

Rückverfolgbarkeit: Das Verfahren bietet eine teilweise Anonymität. Die Bankverbindung<br />

kennt nur Paybox, sie ist für den Händler verborgen. Paybox wiederum erfährt nicht, wofür<br />

das Geld ausgegeben wird. Wer dem Händler seine Mobiltelefonnummer nicht mitteilen<br />

möchte, kann von paybox eine Alias-Nummer erhalten.


5 Analyse und Kritik 54<br />

Teilbarkeit: Die transferierten Geldbeträge müssen nicht durch die reelen gedeckt sein, da<br />

jeder Geldbetrag unabhängig ob es banknotenmäßig eine Entsprechung gibt, von einem Konto<br />

abgebucht und einem anderen Konto gutgeschrieben werden. Im Bargeldzahlungsverkehr<br />

entsteht durch die Rückgabe von Wechselgeld ein zusätzlicher Mehraufwand, weil man<br />

einerseits stets eine best<strong>im</strong>mte Menge von Wechselgeld benötigt und andererseits das Risiko,<br />

dass dieses in falscher Höhe ausbezahlt wird.<br />

Online-Verifikation: Die Bonität wird bei erstmaliger Registrierung des Kunden durch<br />

Angabe seiner Bankverbindung und Einkommens überprüft. Während der Transaktion erfolgt<br />

keine Prüfung.<br />

Akzeptanzfähigkeit: Die Hauptlast des Zahlungsverkehrs läuft <strong>im</strong> herkömmlichen<br />

Internetbankverkehr ab und wird von allen angeschlossenen Banken unterstützt.<br />

Usability: Da der Kunde aufgrund des Telefonierens und sonstiger Funktionen mit dem<br />

Umgang des Mobiltelefons vertraut ist, gibt es in Bezug auf Überschaubarkeit der<br />

Funktionalität und leichte Bedienung keinerlei Probleme.<br />

Universalität: Das paybox lässt sich leicht in die alltägliche Gebrauchwelt integrieren, weil<br />

vor allem durch die Verwendung von Mobiltelefonen als Kommunikationsmedium ein hoher<br />

Grad an Ortsungebundenheit gegeben ist. Für den Nutzer ergibt sich somit die Möglichkeit,<br />

das Medium überall mit sich zu führen und dort in Echtzeit Informationen anzufordern oder<br />

Transaktionen durchzuführen. Einschränkend ist aber darauf hinzuweisen, dass hierbei eine<br />

vollständige Gebietsabdeckung und fehlerfreier Empfang durch den Mobilfunkbetreiber<br />

unterstellt ist. Hierdurch hat er die Chance, spontane Ideen und Bedürfnissen augenblicklich<br />

zu realisieren. Bei Kaufentscheidungen können so besonders gute Angebote sofort<br />

angenommen werden, ohne die günstige Gelegenheit zu verpassen. Es besteht auch bereits die<br />

Möglichkeit für die Benutzung von Spielautomaten per paybox zu bezahlen. [ZDN] Weitere<br />

Zahlungsmöglichkeiten mit paybox wurden bereits <strong>im</strong> Kapitel 4.2.5. angeführt.<br />

Transaktionsbearbeitung: Alle 3 Servicepakete von paybox inkludieren die Möglichkeit<br />

vom herkömmlichen Geschäftsprozess abweichende Handlungen wie zum Beispiel<br />

Stornierungen oder Zahlungszieländerungen händlerseitig autonom über ein Extranet<br />

durchzuführen.<br />

Zahlungssicherheit: Wegen der strengen Bonitätskontrolle kann der paybox-Betreiber dem<br />

Händler eine hohe Zahlungssicherheitsgarantie zubilligen. Eine explizite Zahlungsgarantie<br />

wird von paybox aber nicht garantiert. Bei Missbrauch können relativ hohe<br />

Rückbuchungsgebühren (siehe Kap. 4.2.5) entstehen, die zu Lasten des Händlers gehen.<br />

Implementierung: Softwaremodule, die von paybox für besondere Anwendungslösungen,<br />

wie zum Beispiel Anbindungen an Logistik-, Zahlungs- und Warenwirtschaftssysteme<br />

entwickelt wurden, erfordern vom Händler ein gewisses technisches Know-How. Obwohl die<br />

Integration be<strong>im</strong> Händler durch ein zusätzlich Service „I-Box“ Unterstützung findet, dauert<br />

der gesamte Installationsvorgang für eigenentwickelte Shop-Lösungen 1-2 Tage. Für<br />

Standard-Shopsysteme existieren Payment-Cartridges (siehe Kapitel 4.2.6.) deren Integration<br />

nur einen geringen Zeitaufwand in Anspruch n<strong>im</strong>mt.<br />

Registrierung: Um als Paybox-Kunde angenommen zu werden ist eine umfangreiche<br />

Anmeldung mit Bekanntgabe sensibler Daten wie zum Beispiel Einkommensverhältnisse<br />

vonnöten. Ebenso ist die Anschaffung eines Kommunikationsmediums obligatorisch.<br />

Registrierung und Freischaltung sind online möglich, und es können sofort Zahlungen bis zu<br />

einem L<strong>im</strong>it von 25 Euro getätigt werden. Erst wenn der Kunde die Bestätigungsunterlagen<br />

von paybox per Post erhalten hat und unterschrieben zurückschickt, ist das Zahlungsverfahren<br />

uneingeschränkt nutzbar.<br />

Zahlungssysteme <strong>im</strong> Internet


5 Analyse und Kritik 55<br />

5.2 Paysafecard<br />

Vertraulichkeit: Die Vertraulichkeit von Informationen ist gewährleistet, da mit der Karte<br />

keine Informationen über den Nutzer der Karte übertragen werden. Der Benutzer muss<br />

keinerlei persönliche Daten preisgeben, Angaben zu Bankverbindungen oder<br />

Kreditkartennummern werden nicht mehr benötigt. Sowohl der PIN-Code und das Passwort,<br />

als auch persönliche Informationen des Kunden werden dem Händler niemals ersichtlich,<br />

sondern werden nur vom paysafecard-Server, der über eine verschlüsselte Verbindung läuft,<br />

überprüft und bestätigt, wie auch der Einkauf.<br />

Zuverlässigkeit: Dieser Punkt ist <strong>im</strong> Sinne der Anforderungen eines modernen Shopsystems.<br />

Integrität: Der Prozess läuft prinzipiell nie ohne eine SSL-geschützte Verbindung ab. SSL<br />

<strong>im</strong>pliziert durch seine Definition beste Datenintegrität.<br />

Verfügbarkeit: Da dieses Verfahren nicht der Datenübermittlung unter zu Hilfenahme<br />

atmosphärischer Medien bedarf, bestehen hierfür keine Einschränkungen.<br />

Nichtabstreitbarkeit: Da als Grundvoraussetzung zur Gewährleistung der<br />

Nichtabstreitbarkeit die Rückverfolgbarkeit gehört und diese in diesem Verfahren nur bedingt<br />

ermöglicht wird, erübrigt sich für diese Eigenschaft jede weitere Diskussion.<br />

Authentifizierung: Aufgrund der Konzeption von paysafecard erfolgt die Authentifizierung<br />

und folglich die Autorisierung der Transaktion durch Eingabe einer 16stelligen Nummer.<br />

Optional eröffnet paysafecard dem Kunden die Möglichkeit durch ein selbstgewähltes<br />

Passwort die Transaktion in Kombination mit dem 16stelligen Code freizugeben. Somit ist<br />

gewährleistet, das Dritte eine verlorene oder gestohlene Karte nicht verwenden können. Der<br />

Bezahlvorgang dieses Systems erfolgt, wie be<strong>im</strong> Bezahlen mit Bargeld anonym.<br />

Rückverfolgbarkeit: Da der Endkunde weder Name, Bankverbindungen noch Unterschrift<br />

angeben muss, ist eine Rückverfolgung von Transaktionen nicht möglich. Der Händler kann<br />

nicht in Erfahrung bringen, wer bei ihm seine Produkte eingekauft beziehungsweise seine<br />

Dienstleistungen in Anspruch genommen hat, und der Kunde bleibt auch nach<br />

abgeschlossener Transaktion anonym.<br />

Teilbarkeit: Die transferierten Geldbeträge müssen nicht durch die reelen gedeckt sein, da<br />

jeder Geldbetrag unabhängig ob es banknotenmäßig eine Entsprechung gibt, von einem Konto<br />

abgebucht und einem anderen Konto gutgeschrieben werden.<br />

Online-Verifikation: Eine Online-Prüfung entfällt hier, da der Wert der karte schon <strong>im</strong><br />

vorhinein bezahlt worden ist.<br />

Akzeptanzfähigkeit: Die Hauptlast des Zahlungsverkehrs läuft <strong>im</strong> herkömmlichen<br />

Internetbankverkehr ab und wird von allen angeschlossenen Banken unterstützt.<br />

Usability: Eine große Stärke von paysafecard liegt in der Überschaubarkeit der Funktionalität<br />

und leichter Bedienung. Man braucht nur einen 16stelligen Code auf der Rückseite der Karte<br />

freirubbeln und diesen be<strong>im</strong> Bezahlen <strong>im</strong> Online-Shop angeben. Das Verfahren erfordert<br />

außer der physischen Beschaffung der Paysafecard keinerlei Registrierungs- oder<br />

Installationsaufwand. Zur Benutzung der paysafecard sind weder Softwareinstallationen noch<br />

zusätzliche Hardware erforderlich. Somit stellt paysafecard ein besonders einfaches<br />

Zahlungsmittel fürs Shoppen <strong>im</strong> Internet dar, das zudem geeignet ist für all jene, die, wie z.B.<br />

Jugendliche, keine Kreditkarte besitzen oder davor zurückscheuen, ihre Kreditkarte <strong>im</strong> Web<br />

einzusetzen.<br />

Universalität: Das Potenzial des Konzepts der paysafecard ist mit schlichtem Web-Payment<br />

nicht erschöpft, denn auf Basis des numerischen Schlüssels lassen sich auch andere Dienste<br />

Zahlungssysteme <strong>im</strong> Internet


5 Analyse und Kritik 56<br />

außerhalb der Online-Welt bezahlen, wo sie schon als Prepaid-Telefonwertkarte eingesetzt<br />

wird. [PSC]<br />

Zahlungssicherheit: Als Prepaid-Karte bringt die paysafecard eine Zahlungsgarantie mit<br />

sich, da der Kartengegenwert vorausbezahlt werden muss und auf einem „Nostro-Konto“ der<br />

Bankpartner bereit steht. Weil das Geld nur noch verteilt werden muss, bedarf es auch nicht<br />

mehr dem Hinterherlaufen ausstehender Beträge. Als zusätzliche Sicherheit verwaltet<br />

paysafecard eine Datenbank, in der Informationen über die <strong>im</strong> Umlauf befindlichen<br />

Kartennummern gespeichert sind. Mit Hilfe dieser Datenbank lässt sich leicht feststellen, ob<br />

eine Karte noch für den Zahlungsverkehr zugelassen ist.<br />

Transaktionsbearbeitung: Der Händler hat die Möglichkeit über ein Internetportal jederzeit<br />

Einsicht in seine Zahlungstransaktionen und durchgeführten Buchungen zu nehmen. Darüber<br />

hinaus ermöglicht paysafecard das Korrigieren von Zahlungszielen bei Lieferverzögerungen.<br />

Umsatzdaten erhält der Händler als Textdatei <strong>im</strong> CSV-Format.<br />

Implementierung: Paysafecard bietet dem Händler verschiedene Implementationsarten an,<br />

die in Java oder Perl realisiert werden können. Die Software ist leicht zu installieren, für praktisch<br />

jedes Betriebssystem verfügbar und benötigt keinerlei besondere Anpassung.<br />

Registrierung: Der Aufwand für den Kunden beschränkt sich lediglich auf den Kauf einer<br />

paysafecard. Zusätzliche Registrierungs- oder Anmeldeprozeduren entfallen.<br />

5.3 Quick<br />

Vertraulichkeit: Das Quick-System ist vertraulich, da keine sensiblen Daten über das<br />

Internet übertragen werden. Aus diesem Grund kann auch seitens des Händlers auf<br />

aufwendige Verschlüsselungsmechanismen verzichtet werden. Überdies verfügt die als<br />

elektronische Geldbörse zu gebrauchende Karte über einen Prozessor, der die<br />

Zugangsberechtigung kontrolliert und sich auch um das Auf- und Abbuchen der Geldbeträge<br />

kümmert. Die Hardware auf der Chipkarte ist sozusagen die vertrauenswürdige Hardware des<br />

Herausgebers der Geldbörse. Der Prozessor der Chipkarte übern<strong>im</strong>mt sämtliche<br />

Identifizierungs- und Verschlüsselungsaufgaben.<br />

Zuverlässigkeit: Dieser Punkt ist <strong>im</strong> Sinne der Anforderungen eines modernen Shopsystems.<br />

Integrität: Der Prozess läuft prinzipiell nie ohne eine SSL-geschützte Verbindung ab. SSL<br />

<strong>im</strong>pliziert durch seine Definition beste Datenintegrität.<br />

Verfügbarkeit: Da dieses Verfahren nicht der Datenübermittlung unter zu Hilfenahme<br />

atmosphärischer Medien bedarf, bestehen hierfür keine Einschränkungen.<br />

Nichtabstreitbarkeit: Da als Grundvoraussetzung zur Gewährleistung der<br />

Nichtabstreitbarkeit die Rückverfolgbarkeit gehört und diese in diesem Verfahren nur bedingt<br />

ermöglicht wird, erübrigt sich für diese Eigenschaft jede weitere Diskussion<br />

Authentifizierung: Die Authentifizierung des Kunden gegenüber dem Zahlungsdienstleister<br />

erfolgt durch die Chipkarte über ein Challenge-Response Verfahren. Darunter versteht man<br />

ein asymmetrisches Verschlüsselungsverfahren wobei der Chip auf einer Plastikkarte<br />

angebracht ist.<br />

Rückverfolgbarkeit: Bei diesem Zahlungsverfahren bleibt der Kunde anonym, somit hat der<br />

Händler keine Möglichkeit sich ein Kundenprofil anzulegen. Den Beweis einer erfolgten<br />

Zahlung und damit die Beziehung zwischen Name und Kartennummer kann nur durch eine<br />

Reidentifikation einer Transaktion durch die ausgebende Bank erfolgen. Bei der Verwendung<br />

von White Cards können keine personenbezogenen Transaktionsdaten rückverfolgt werden.<br />

Zahlungssysteme <strong>im</strong> Internet


5 Analyse und Kritik 57<br />

Teilbarkeit: Die transferierten Geldbeträge müssen nicht durch die reelen gedeckt sein, da<br />

jeder Geldbetrag unabhängig ob es banknotenmäßig eine Entsprechung gibt, von einem Konto<br />

abgebucht und einem anderen Konto gutgeschrieben werden.<br />

Online-Verifikation: Eine Online-Prüfung entfällt hier, da die Daten auf einer Händlerkarte<br />

bei PDTS zur weiteren Verarbeitung gespeichert und zum Inkasso an Europay weitergeleitet<br />

werden. Die Gültigkeit der Karte und des L<strong>im</strong>its wird <strong>im</strong> Chip der Karte geprüft.<br />

Akzeptanzfähigkeit: Die Hauptlast des Zahlungsverkehrs läuft <strong>im</strong> herkömmlichen<br />

Internetbankverkehr ab und wird von allen angeschlossenen Banken unterstützt.<br />

Usability: Die Bedienung von Quick ist sehr einfach. Bei Zahlungen <strong>im</strong> Internet braucht der<br />

Kunde nur seine Karte in das Kartenlesegerät einzuschieben und kann ohne Eingabe von<br />

Logindaten Transaktionen durchführen. Anhand eines Dialogfensters, das automatisch<br />

erscheint, wenn der Kunde zu einer Zahlung aufgefordert wird, werden nochmals alle<br />

Auftragsdaten angezeigt und per Mausklick hat er die Möglichkeit die Zahlung abzulehnen<br />

oder zu akzeptieren.<br />

Universalität: Die Quickkarte verfügt durch ihren goldfarbenen Chip über ein breites<br />

Einsatzspektrum. Nutzt der Kunde den auf dem Chip gespeicherten Betrag nicht vollständig<br />

für Einkäufe <strong>im</strong> Internet, so kann er den Restbetrag in der „realen“ Welt ausgeben und so die<br />

geladene Summe verwenden. Die Anwendungsfelder reichen von Zahlungsfunktionen<br />

(elektronische Geldbörse) über Identifikationsfunktionen (Ausweis, Zugangsberechtigung)<br />

hin zu Datenbankfunktionen (Patientendaten, Kundenkarte). Zusatzanwendungen des<br />

Dienstleistungsgewerbes (Tourismus, Gaststätten), aber auch des Einzelhandels, machen die<br />

Karte für Besitzer und Betreiber attraktiv. Die White Card [MER02] bietet sich hier besonders<br />

an, weil sie auch als Familienkarte genutzt werden kann (problemlos ausleihbar, weil sie<br />

anonym ist und kein Zugang zum Konto hergestellt werden kann). Zu erwarten ist deshalb,<br />

dass die White Card für den täglichen Gebrauch bei Kleinbeträgen wegen der Hauptvorteile<br />

wie geringes Risiko, geringe Kosten, Bequemlichkeit und Anonymität insbesondere <strong>im</strong><br />

Automatenmarkt und <strong>im</strong> regionalen Leistungsverbund eine gute Marktchance besitzt.<br />

Transaktionsbearbeitung: Der Händler hat die Möglichkeit über ein Internetportal jederzeit<br />

Einsicht in seine getätigten Umsätze und Transaktionen zu nehmen. Darüber hinaus<br />

ermöglicht PDTS das Herunterladen der Daten <strong>im</strong> CSV Format<br />

Zahlungssicherheit: Durch den prepaid-Charakter des Verfahrens kann dem Händler eine<br />

Zahlungsgarantie gegeben werden, da der Kunde ja schon bezahlt hat. Der Händler kann sich<br />

bei Quick sicher sein, dass er sein Geld bekommt, da Europay eine Zahlungsgarantie für die<br />

aufgebuchten Geldbeträge übern<strong>im</strong>mt.<br />

Implementierung: Die Anbindung des Online Shops an PDTS erfolgt über CGI-Programme,<br />

die auf einem C und Perl verfügbaren API aufbauen. So kann es jederzeit den individuellen<br />

Bedürfnissen des Händlers angepasst werden. Für die Implementierung von Skripten die<br />

PDTS zur Verfügung stellt ist ein hierfür notwendiger Interpreter unabdingbar. Diese sind als<br />

Freeware beziehbar und können rasch eingebunden werden.<br />

Registrierung: Das Verfahren erfordert außer der physischen Beschaffung der Quickkarte<br />

keinerlei Registrierungsaufwand.<br />

5.4 Kreditkarte SET<br />

Vertraulichkeit: Wenn der Kunde die Bestellung beendet hat, gelangt er auf eine<br />

„Bezahlseite“, wo die Zahlungsdetails abgefragt werden und deren Übertragung zwischen<br />

dem Browser des Kunden und dem Web-Server des Händlers mittels des<br />

Sicherheitsprotokolls SSL abgesichert ist. Die Vertraulichkeit der persönlichen Daten des<br />

Zahlungssysteme <strong>im</strong> Internet


5 Analyse und Kritik 58<br />

Benutzers des Wallets wird mit kryptographischen Mitteln (Verschlüsselung nach dem DES-<br />

Verfahren) gesichert. Erst der Zugang zur Wallet-Anwendung und die Kenntnis des<br />

Passwortes erlauben den Zugriff auf die Zahlungsmittel und die Transaktionsdaten des<br />

Wallets. Bei Verwendung der entsprechend hohen Verschlüsselungslänge ist sichergestellt,<br />

dass das Abhören der eingegebenen Zahlungsdaten auf diesem Kommunikationsweg nur<br />

äußerst schwierig oder überhaupt nicht möglich ist. [SCH]<br />

Zuverlässigkeit: Dieser Punkt ist <strong>im</strong> Sinne der Anforderungen eines modernen Shopsystems.<br />

Integrität: Durch Verwendung von digitalen Signaturen wird gewährleistet, dass die<br />

Zahlungstransaktion vor Manipulation und vor Umleitung der Transaktionsdaten geschützt<br />

wird.<br />

Verfügbarkeit: Da dieses Verfahren nicht der Datenübermittlung unter zu Hilfenahme<br />

atmosphärischer Medien bedarf, bestehen hierfür keine Einschränkungen.<br />

Nichtabstreitbarkeit: Im Gegensatz zu anderen ungesicherten Kreditkartenzahlungen <strong>im</strong><br />

Internet, ermöglicht die Authentifizierungsfunktion von SET, die Identität eines<br />

Karteninhabers zweifelsfrei festzustellen. Ein Kunde kann somit eine von ihm mittels SET<br />

getätigte Kreditkartentransaktion nicht abstreiten.<br />

Authentifizierung: Der Kunde wird über ein Zertifikat eindeutig und zweifelsfrei identifiziert<br />

und bestätigt seinen Kaufwillen durch eine digitale Signatur.<br />

Rückverfolgbarkeit: Der hohe Grad der Authentifizierung, bei der alle beteiligten Parteien<br />

durch eine Überprüfung der Zertifikate eindeutig identifiziert werden, hinterlässt für jede<br />

Transaktion nachhaltige Spuren. Dadurch ist eine Rückverfolgbarkeit stets möglich.<br />

Teilbarkeit: Die transferierten Geldbeträge müssen nicht durch die reelen gedeckt sein, da<br />

jeder Geldbetrag unabhängig ob es banknotenmäßig eine Entsprechung gibt, von einem Konto<br />

abgebucht und einem anderen Konto gutgeschrieben werden.<br />

Online-Verifikation: Eine Online-Verifizierung der Kartendaten und der Kontodeckung wird<br />

während der Transaktion durch das Payment Gateway eingeholt.<br />

Akzeptanzfähigkeit: Die Hauptlast des Zahlungsverkehrs läuft <strong>im</strong> herkömmlichen<br />

Internetbankverkehr ab und wird von allen angeschlossenen Banken unterstützt.<br />

Usability: Für den Kunden ist der Einstieg in das Verfahren mit einem erheblichen Aufwand<br />

verbunden. Er muss erst die Software aus dem Internet runterladen und installieren. Der<br />

Erwerb von einem Zertifikat erfordert zusätzlichen Zeitaufwand der vom Kunden abverlangt<br />

wird. Zudem ist der Kunde an den PC gebunden, auf dem das Wallet installiert ist, welches<br />

die Kreditkartendaten und das Zertifikat abspeichert. Dies kann zwar durch<br />

Mehrfachinstallation und Beförderung der Zertifikate mittels Diskette von einem Rechner<br />

zum nächsten umgangen werden, ist aber mühsam und zeitintensiv.<br />

Universalität: Kreditkarten sind heute ein durchaus gängiges Zahlungsmittel und in vielen<br />

Portemonnaies anzutreffen. Sie ist gleichermaßen <strong>im</strong> realen wie <strong>im</strong> elektronischen<br />

Zahlungsverkehr einsetzbar und durch die große Verbreitung erklären sich <strong>im</strong>mer mehr<br />

Händler bereit Akzeptanzverträge mit allen großen Kreditgesellschaften abzuschließen.<br />

Weltweit gibt es mittlerweile 15 Millionen Akzeptanzstellen für die Visa Card und sogar 17<br />

Millionen für die Mastercard. Hat man für seine Kreditkarte eine PIN kann man zusätzlich an<br />

zahlreichen Geldautomaten rund um den Globus Bargeld beziehen.<br />

Transaktionsbearbeitung: Eine Überprüfung der eingereichten Einzelbeträge ist nicht<br />

möglich. Der Händler muss die autorisierten Beträge selber protokollieren.<br />

Zahlungssicherheit: Da die Zahlungsabwicklung von einem kreditinstitutsnahen<br />

sogenannten Payment Gateway verantwortet wird, das bei jeder Zahlung prüft, ob die<br />

Zahlungssysteme <strong>im</strong> Internet


5 Analyse und Kritik 59<br />

Kreditkarte gestohlen wurde, beziehungsweise ob der angeforderte Kreditrahmen noch<br />

ausreicht, wird dem Händler der Forderungsbetrag zugesichert.<br />

Implementierung: Der Installationsaufwand stellt an den Händler eine enorme<br />

Herausforderung, da er über eine e-<strong>Commerce</strong> Software verfügen muss, die mit SET<br />

kompatibel ist. Hierzu muss noch eine Sicherheitsinfrastruktur installiert und laufend gewartet<br />

werden.<br />

Registrierung: Bevor ein Kunde am Kreditkarten-System per Internet aktiv teilnehmen kann,<br />

muss er sich bei der Bank, von welcher er die Wallet-Software bezogen hat, registrieren<br />

lassen. Bei diesem Vorgang prüft die Bank die Legit<strong>im</strong>ation des Kunden. Dazu muss der<br />

Kunde den Personalausweis und einen geeigneten Kontonachweis vorlegen.<br />

5.5 Kreditkarte Verified by Visa<br />

Vertraulichkeit: Da der Händler die Kreditkartennummer des Karteninhabers erfährt, besteht<br />

die Gefahr eines Kartenmissbrauchs durch unseriöse Händler, wodurch die Vertraulichkeit<br />

der Daten nicht mehr hinreichend geschützt wäre. Die serverseitige Verarbeitung der Daten<br />

hängt von den Datenschutzmaßnahmen des Händlers ab. Sobald die Übertragung der Daten<br />

erfolgt ist, muss sichergestellt werden, dass diese weiterhin vor unbefugter Einsichtnahme<br />

oder Verwendung geschützt werden. Vor allem für kleinere Online-Händler stellt dies einen<br />

beträchtlichen Aufwand dar, weil eigene Sicherheitskonzepte benötigt werden.<br />

Zuverlässigkeit: Dieser Punkt ist <strong>im</strong> Sinne der Anforderungen eines modernen Shopsystems.<br />

Integrität: Der Prozess läuft prinzipiell nie ohne eine SSL-geschützte Verbindung ab. SSL<br />

<strong>im</strong>pliziert durch seine Definition beste Datenintegrität.<br />

Verfügbarkeit: Da dieses Verfahren nicht der Datenübermittlung unter zu Hilfenahme<br />

atmosphärischer Medien bedarf, bestehen hierfür keine Einschränkungen.<br />

Nichtabstreitbarkeit: Durch die Eingabe eines Passwortes während des<br />

Authentifizierungsprozesses, identifiziert sich der Kunde eindeutig als legit<strong>im</strong>ierter Benutzer<br />

der Kreditkarte und kann folglich eine Transaktion nicht abstreiten.<br />

Authentifizierung: Die Authentifizierung des Kunden ist durch eine Kreditkartennummer in<br />

Kombination mit einem Passwort gegeben. Die Ausgabe der Kreditkartennummer erfolgt<br />

ausschließlich nach persönlicher Identifizierung durch die Hausbank.<br />

Rückverfolgbarkeit: Bei diesem Bezahlsystem bleibt der Kunde nicht anonym. Durch den<br />

hohen Grad der Authentifizierung kann festgestellt werden, welche Person zu welchem<br />

Zeitpunkt welches Produkt gekauft hat.<br />

Teilbarkeit: Die transferierten Geldbeträge müssen nicht durch die reelen gedeckt sein, da<br />

jeder Geldbetrag unabhängig ob es banknotenmäßig eine Entsprechung gibt, von einem Konto<br />

abgebucht und einem anderen Konto gutgeschrieben werden.<br />

Online-Verifikation: Eine Online-Verifizierung der Kartendaten und der Kontodeckung wird<br />

während der Transaktion durch das Payment Gateway vorgenommen.<br />

Akzeptanzfähigkeit: Die Hauptlast des Zahlungsverkehrs läuft <strong>im</strong> herkömmlichen<br />

Internetbankverkehr ab und wird von allen angeschlossenen Banken unterstützt.<br />

Usability: Die Vorteile für den Kunden liegen auf der Hand. Er muss keine spezielle SET-<br />

Software installieren, kann ohne ein Zertifikat bezahlen und sich dennoch sicher sein, dass<br />

seine Kreditkarten- und Bestellungsdaten nicht in die falschen Hände geraten. Mit dieser<br />

neuen Technologie ist der Karteninhaber nicht mehr an einen Rechner gebunden. Die<br />

Kreditkarte kann so auch für den Online-Einkauf in Internet-Cafes, an Universitäten oder vom<br />

Arbeitsplatz aus genutzt werden.<br />

Zahlungssysteme <strong>im</strong> Internet


5 Analyse und Kritik 60<br />

Universalität: Kreditkarten sind heute ein durchaus gängiges Zahlungsmittel und in vielen<br />

Portemonnaies anzutreffen. Sie ist gleichermaßen <strong>im</strong> realen wie <strong>im</strong> elektronischen<br />

Zahlungsverkehr einsetzbar und durch die große Verbreitung erklären sich <strong>im</strong>mer mehr<br />

Händler bereit Akzeptanzverträge mit allen großen Kreditgesellschaften abzuschließen.<br />

Weltweit gibt es mittlerweile 15 Millionen Akzeptanzstellen für die Visa Card und sogar 17<br />

Millionen für die Mastercard. Hat man für seine Kreditkarte eine PIN kann man zusätzlich an<br />

zahlreichen Geldautomaten rund um den Globus Bargeld beziehen.<br />

Transaktionsbearbeitung: Eine Überprüfung der eingereichten Einzelbeträge ist nicht<br />

möglich. Der Händler muss die autorisierten Beträge selber protokollieren.<br />

Zahlungssicherheit: Das Verified by Visa System beziehungsweise die Kunden Bank<br />

überprüft online die Identität und Berechtigung des Karteninhabers. Dadurch verliert die Bank<br />

„Chargebackrechte“ bei Betrugsfällen und sichert den Händler nachhaltig vor<br />

Forderungsausfällen ab. [ECI1]<br />

Implementierung: Für die Nutzung von Verified by Visa ist lediglich ein Merchant Plug-In<br />

erforderlich, dass ohne fundiertes technisches Know-How in kurzer Zeit <strong>im</strong>plementiert<br />

werden kann. Eine Adaption vom Back-Office-Bereich sowie der Checkout-Site muss vom<br />

Händler auch nicht vorgenommen werden.<br />

Registrierung: Die erforderliche Anmeldung für Verfied by Visa erfordert vom Kunden<br />

lediglich die Bekanntgabe von Kreditkartennummer, Ablaufdatum und ein selbstgewähltes<br />

Passwort über eine WWW-Schnittstelle. Der gesamte Vorgang dauert nur wenige Minuten<br />

und die Freischaltung erfolgt gleich an die Übermittlung der Anmeldedaten.<br />

5.6 M-Pay<br />

Vertraulichkeit: Während der Transaktion werden alle Daten SSL-verschlüsselt übertragen.<br />

M-Pay unterhält überdies eine Kooperation mit einer Reihe von strategischen Unternehmen,<br />

die eine sichere Infrastruktur bereitstellen.<br />

Zuverlässigkeit: Dieser Punkt ist <strong>im</strong> Sinne der Anforderungen eines modernen Shopsystems.<br />

Integrität: Der Prozess läuft prinzipiell nie ohne eine SSL-geschützte Verbindung ab. SSL<br />

<strong>im</strong>pliziert durch seine Definition beste Datenintegrität.<br />

Verfügbarkeit: Aufgrund von technischen Möglichkeiten kann es passieren, dass dieses<br />

Verfahren regional nicht zur Verfügung steht. In Zeiten der Spitzenauslastung kann es<br />

vorkommen, dass dieses Verfahren gar nicht oder nur verzögert verwendbar ist.<br />

Nichtabstreitbarkeit: Da der Kunde mit dem SMS-Code die Transaktion freigibt, kann er<br />

später die Zahlung nicht mehr abstreiten.<br />

Authentifizierung: Hierfür offeriert das Verfahren zwei Optionen: Bei einem<br />

Wertkartentelefon verfügt ein Kunde über ein Konto als Mobiltelefonnutzer, dessen SIM-<br />

Code be<strong>im</strong> Mobilfunkbetreiber nur anonym registriert ist. Es kann folglich keine<br />

Verbindung zum Kunden als physische Person hergestellt werden. Besitzt der Kunde ein<br />

Konto bei Vodafone, so ist er über seinen SIM-Code und Mobiltelefonnummer als physische<br />

Person identifizierbar.<br />

Rückverfolgbarkeit: Der hohe Grad an Authentifizierung ermöglicht das vollständige<br />

Protokollieren aller Transaktionen in deren chronologischer Anordnung.<br />

Teilbarkeit: Die transferierten Geldbeträge müssen nicht durch die reelen gedeckt sein, da<br />

jeder Geldbetrag unabhängig ob es banknotenmäßig eine Entsprechung gibt, von einem Konto<br />

abgebucht und einem anderen Konto gutgeschrieben werden.<br />

Online-Verifikation: Eine Online-Prüfung findet während des Ablaufs eine Transaktion<br />

nicht statt.<br />

Zahlungssysteme <strong>im</strong> Internet


5 Analyse und Kritik 61<br />

Akzeptanzfähigkeit: Die Hauptlast des Zahlungsverkehrs läuft <strong>im</strong> herkömmlichen<br />

Internetbankverkehr ab und wird heutzutage von allen namhaften Bankinstituten unterstützt.<br />

Usability: Da der Kunde aufgrund des Telefonierens und sonstiger Funktionen mit dem<br />

Umgang des Mobiltelefons vertraut ist, gibt es in Bezug auf Überschaubarkeit der<br />

Funktionalität und leichte Bedienung keinerlei Probleme.<br />

Universalität: Durch die Verwendung des Mobiltelefons als Zahlungsmittel verfügt der<br />

Kunde über eine bequeme Zahlungsmöglichkeit mit der man unabhängig vom Aufenthaltsort<br />

- vorausgesetzt man befindet sich <strong>im</strong> Empfangsbereich des Mobilfunkdienstleisters – rund um<br />

die Uhr über das sichere GSM-Mobilfunknetz zahlen kann. Weiters hat der Kunde die<br />

Möglichkeit seine monatlichen Transaktionen übersichtlich, ohne Extrakosten <strong>im</strong> Web zu<br />

überprüfen.<br />

Transaktionsbearbeitung: Die Leistungen von Vodafone m-pay sind auf die Inkasso-<br />

Funktionalität beschränkt. Der Händler hat somit <strong>im</strong> Vergleich zum<br />

„Konkurrenzbezahlverfahren“ paybox keine Möglichkeit Zahlungsziele zu korrigieren oder<br />

Stornierungen vorzunehmen. Lediglich die Kontrolle von Zahlungen über das Händlerportal<br />

kann durchgeführt werden.<br />

Zahlungssicherheit: Vodafone übern<strong>im</strong>mt für den Händler das Forderungsausfallrisiko für<br />

die vom Kunden zu leistenden Zahlungen und bietet somit einen gesicherten Umsatz.<br />

Implementierung: Für Händler sollten sich bei der Integration dieses Bezahlsystems<br />

keinerlei Schwierigkeiten ergeben, da es keine zusätzliche Hardware oder Software erfordert.<br />

Der Händler benötigt nur ein s<strong>im</strong>ples standardisiertes Interface über http und die Integration<br />

von Vodafone m-pay kann in allen Shopsysteme zum Einsatz gebracht werden.<br />

Registrierung: Für die Freischaltung beziehungsweise Nutzung von m-pay erspart sich der<br />

Kunde eine langwierige Registrierungsprozedur, denn wenn er mit Vodafone einen gültigen<br />

Handyvertrag bereits unterzeichnet hat, ist er von Vodafone automatisch für das<br />

Zahlungsverfahren freigeschaltet.<br />

5.7 Banking-Verfahren<br />

Vertraulichkeit: Die Sicherheit, die mit diesem Banking-System erreicht werden kann, ist<br />

weitgehend von der Effektivität der für die Autorisierung eingesetzten Mechanismen zur<br />

Zugriffskontrolle und zur Identifikation und von der Zuverlässigkeit der Geldüberweisung<br />

abhängig. In diesem Sinne kann ein hohes Maß an Sicherheit durch eine Kombination fälschungssicherer<br />

Autorisierungsmethoden und verlässlicher Übertragungsabläufe erreicht werden.<br />

Hierfür ist das System durch eine Kombination von Verfügernummer und Passwort<br />

gesichert. Überweisungen sind darüber hinaus jeweils einzeln gegen Replay-Attacken durch<br />

Einweg-Passwörter in der Form von Transaktionsnummern (TAN) abgesichert, die aus einer<br />

vorgegebenen Liste von Zufallszahlen entnommen werden müssen. Selbst be<strong>im</strong> Abhören der<br />

Datenübertragung ist ein Hacker damit nicht in der Lage, eigene Transaktionen<br />

durchzuführen, da er weitere gültige TANs benötigen würde. Zudem wird der Zugang zum<br />

System bei dre<strong>im</strong>aliger Falscheingabe des Passworts dauerhaft gesperrt.<br />

Zuverlässigkeit: Dieser Punkt ist <strong>im</strong> Sinne der Anforderungen eines modernen Shopsystems.<br />

Integrität: Der Prozess läuft prinzipiell nie ohne eine SSL-geschützte Verbindung ab. SSL<br />

<strong>im</strong>pliziert durch seine Definition beste Datenintegrität.<br />

Verfügbarkeit: Da dieses Verfahren nicht der Datenübermittlung unter zu Hilfenahme<br />

atmosphärischer Medien bedarf, bestehen hierfür keine Einschränkungen.<br />

Zahlungssysteme <strong>im</strong> Internet


5 Analyse und Kritik 62<br />

Nichtabstreitbarkeit: Der hohe Grad an Autorisierung von Kundenseite identifiziert diesen<br />

mit einem sehr hohen Sicherheitsgrad, der nur sehr schwer abzustreiten ist. Überdies können<br />

Transaktionen nur in Einvernehmen von Kunden und Händler rückgängig gemacht werden.<br />

Authentifizierung: Bei diesem Verfahren wird direkt am Bankserver überprüft, ob der<br />

angegebene Absender der Transaktion auch der tatsächliche Absender ist. Hierzu erfolgt die<br />

Anmeldung am Bankserver über eine Verfügernummer und Passwort, die in Verbindung mit<br />

der Eingabe einer einmalig zu verwendenden persönlichen Transaktionsnummer kombiniert<br />

wird.<br />

Rückverfolgbarkeit: Das Zahlungsverfahren erfüllt einen hohen Grad an<br />

Rückverfolgbarkeit. Die Anonymität findet in diesem Modell keinen entsprechenden Schutz,<br />

zumal die Bank über alle Details eines jeden Zahlungsvorgangs informiert ist: über den<br />

Empfänger, den Sender, den Betrag und auch über das Datum der Transaktion. Mit anderen<br />

Worten hat die Umsetzung dieses Zahlungsverfahrens die Möglichkeit zur bedingungslosen<br />

Zurückverfolgung aller Transaktionen und die Notwendigkeit zur sofortigen Online-<br />

Verifikation zur Folge.<br />

Teilbarkeit: Der Vorteil des Zahlungssystems ist eindeutig die Teilbarkeit, da jeder<br />

Geldbetrag unabhängig ob es banknotenmäßig eine Entsprechung gibt, von einem Konto<br />

abgebucht und einem anderen Konto gutgeschrieben werden<br />

Online-Verifikation: Während des Transaktionsprozesses erfolgt direkt am Bankrechner eine<br />

Online-Prüfung des Kundenkontos.<br />

Akzeptanzfähigkeit: Die Hauptlast des Zahlungsverkehrs läuft <strong>im</strong> herkömmlichen<br />

Internetbankverkehr ab und wird heutzutage von allen namhaften Bankinstituten unterstützt.<br />

Usability: Im Unterschied zu vielen anderen Zahlungsverfahren erfordert die Nutzung von<br />

netpay keine gesonderte Anmeldung oder Registrierung seitens des Benutzers, wenn bereits<br />

ein Netbankingzugang besteht. Zum einen erfolgt die Identifikation des Benutzers gegenüber<br />

dem Bank-Server wie <strong>im</strong> E-Banking mit Verfügernummer und Passwort, zum anderen bleibt<br />

die Menüführung des System identisch zum E-Banking, was dem Gewohnheitsverhalten der<br />

Benutzer an einem Bildschirm sehr zuträglich ist. Die gewohnten Banktransaktionen können<br />

direkt aus dem Online-Shop getätigt werden, und das mit denselben Autorisierungscodes<br />

(Verfügernummer, Passwort, TAN), die der Benutzer bereits von seiner Bank bekommen hat.<br />

Universalität: Das Banking Verfahren benützt die angebotene Funktionalität des Internets<br />

und ermöglicht dem Kunden unter anderem seine Bankgeschäfte online abzuwickeln.<br />

Daneben ist auch ein Zugang in die reale Geldwelt mittels Bankomatkarte möglich.<br />

Transaktionsbearbeitung: Dem Händler wird eine Schnittstelle zur Verfügung gestellt über<br />

die er die Transaktionsdaten in das Buchhaltungssystem übernehmen kann. Nachträgliche<br />

Stornierung von Transaktionen aufgrund von Lieferengpässen können nicht vorgenommen<br />

werden.<br />

Zahlungssicherheit: Der Händler bekommt eine Zahlungsgarantie durch die Bank, da eine<br />

autorisierte Transaktion nicht einseitig widerrufen werden kann.<br />

Implementierung: Dieses Zahlungssystems lässt sich durch eine einfache Softwarelösung in<br />

das bestehende Shopsystem integrieren. Durch die Anbindung über eine XML-Schnittstelle<br />

können ohne großen Aufwand jederzeit neue technische Entwicklungen eingebracht werden.<br />

Registrierung: Eine Anmeldung für bereits bestehende Online-Banking-Kunden ist nicht<br />

notwendig.<br />

Zahlungssysteme <strong>im</strong> Internet


5 Analyse und Kritik 63<br />

5.8 E-Einkauf<br />

Vertraulichkeit: Die Software auf dem Server des Internethändlers und die Software des<br />

bezahlen.at Servers kommunizieren über eine gesicherte SSL-Verbindung auf Basis einer<br />

128-bit Verschlüsselung um die vertraulichen Informationen über Benutzername, Passwort<br />

und Bestellung zu schützen.<br />

Zuverlässigkeit: Dieser Punkt ist <strong>im</strong> Sinne der Anforderungen eines modernen Shopsystems.<br />

Integrität: Der Prozess läuft prinzipiell nie ohne eine SSL-geschützte Verbindung ab. SSL<br />

<strong>im</strong>pliziert durch seine Definition beste Datenintegrität.<br />

Verfügbarkeit: Da dieses Verfahren nicht der Datenübermittlung unter zu Hilfenahme<br />

atmosphärischer Medien bedarf, bestehen hierfür keine Einschränkungen.<br />

Nichtabstreitbarkeit: Der relativ hohe Grad an Authentifizierung und die Möglichkeit der<br />

Rückverfolgung jeder einzelnen Transaktion <strong>im</strong>plizieren ebenso einen hohen Grad an<br />

Nichtabstreitbarkeit.<br />

Authentifizierung: Die Authentifizierung des Kunden geschieht durch die Eingabe von<br />

Benutzername und Passwort.<br />

Rückverfolgbarkeit: Der Zahlungspflichtige bleibt vor der beteiligten Bank nicht anonym,<br />

da diese wissen muss, von welchem Konto wie viel abgebucht wird.<br />

Teilbarkeit: Der Vorteil des Zahlungssystems ist eindeutig die Teilbarkeit, da jeder<br />

Geldbetrag unabhängig ob es banknotenmäßig eine Entsprechung gibt, von einem Konto<br />

abgebucht und einem anderen Konto gutgeschrieben werden.<br />

Online-Verifikation: Eine Online-Verifikation findet noch während der Transaktion statt.<br />

Akzeptanzfähigkeit: Die Hauptlast des Zahlungsverkehrs läuft <strong>im</strong> herkömmlichen<br />

Internetbankverkehr ab und wird heutzutage von allen namhaften Bankinstituten unterstützt.<br />

Usability: Die P.S.K. stellt den Systemteilnehmern unter einer einheitlichen<br />

Benutzeroberfläche, die an die Rechnungsplattform bezahlen.at angelehnt ist, eine Lösung zur<br />

Verfügung mit der eine Zahlungstransaktion schnell durch wenige Benutzeraktionen<br />

vorgenommen werden kann.<br />

Universalität: E-Einkauf bietet nicht nur die Möglichkeit <strong>im</strong> Internet Zahlungstransfers<br />

abzuwickeln. Registrierte Kunden können mittels Bankomakarte auch in der realen Geldwelt<br />

Zahlungen tätigen.<br />

Transaktionsbearbeitung: Alle erfolgreich durchgeführten Transaktionen können über ein<br />

Webportal jederzeit überprüft und zusätzlich als CSV-Datei abgespeichert werden. Eine<br />

Stornierung beziehungsweise Änderung von Zahlungszielen ist nicht möglich.<br />

Zahlungssicherheit: Die P.S.K. übern<strong>im</strong>mt für den Händler die Zahlungsgarantie und bietet<br />

somit die Möglichkeit das Ausfallrisiko zu min<strong>im</strong>ieren.<br />

Implementierung: Die tatkräftige Unterstützung durch den E-Einkauf-Support sowie eine<br />

umfassende Dokumentation der Schnittstelle ermöglichen auch Händlern die nicht soviel<br />

Know-How <strong>im</strong> Technikbereich mitbringen, eine rasche Anbindung. Die Anschaffung<br />

zusätzlicher Hardware entfällt.<br />

Registrierung: Um E-Einkauf verwenden zu können, muss man sich über ein WWW-<br />

Formular anmelden. Sofern man kein P.S.K.-Konto hat, ist zudem noch eine persönliche<br />

Identifikation in einer Filiale notwendig die schließlich zur Freischaltung von E-einkauf führt.<br />

5.9 Iclear<br />

Vertraulichkeit: Alle persönlichen Daten die über das offene Internet geschickt werden<br />

müssen, werden via SSL-Protokoll gesichert.<br />

Zuverlässigkeit: Dieser Punkt ist <strong>im</strong> Sinne der Anforderungen eines modernen Shopsystems.<br />

Zahlungssysteme <strong>im</strong> Internet


5 Analyse und Kritik 64<br />

Integrität: Der Prozess läuft prinzipiell nie ohne eine SSL-geschützte Verbindung ab. SSL<br />

<strong>im</strong>pliziert durch seine Definition beste Datenintegrität.<br />

Verfügbarkeit: Da dieses Verfahren nicht der Datenübermittlung unter zu Hilfenahme<br />

atmosphärischer Medien bedarf, bestehen hierfür keine Einschränkungen.<br />

Nichtabstreitbarkeit: Durch den hohen Grad der Authentifizierung der durch die persönliche<br />

Identifikation mittels Lichtbildausweis bei der Registrierung und die Aufzeichnung jeder<br />

einzelnen Transaktion durch iclear, kann keine Transaktion abgestritten werden.<br />

Authentifizierung: Über eine SSL-Verbindung meldet sich der Zahlungspflichtige wie auf<br />

einem Multi-User-Rechner durch einen Login/Passwort-Dialog be<strong>im</strong> Server von iclear an.<br />

Rückverfolgbarkeit: Durch den hohen Grad an Authentifizierung ist iclear über alle Details<br />

eines Zahlungsvorgangs informiert und kann somit alle Transaktionen nachvollziehen.<br />

Teilbarkeit: Jeder Geldbetrag unabhängig ob es banknotenmäßig eine Entsprechung gibt,<br />

kann von einem Konto abgebucht und einem anderen Konto gutgeschrieben werden.<br />

Online-Verifikation: Eine Online-Verifikation wird nicht durchgeführt.<br />

Akzeptanzfähigkeit: Die Hauptlast des Zahlungsverkehrs läuft <strong>im</strong> herkömmlichen<br />

Internetbankverkehr ab und wird heutzutage von allen namhaften Bankinstituten unterstützt.<br />

Usability: Die Bedienung von iclear ist sehr einfach. Bei Zahlungen <strong>im</strong> Internet braucht der<br />

Kunde nur seine Benutzerkennung einzugeben. Dabei benutzt der Kunde den üblichen<br />

Internet-Browser.<br />

Universalität: Iclear ist ein rein an das Internet gebundenes Verfahren und findet daher nur<br />

für Online-Shopping Verwendung.<br />

Transaktionsbearbeitung: Über ein Internetportal bekommt der Händler zwar eine<br />

Übersicht aller Buchungen die auf seinem I<strong>Commerce</strong>-Konto durchgeführt wurden, aber eine<br />

vollautomatische Abwicklung des gesamten Zahlungsprozesses ist nicht gegeben, da jede<br />

autorisierte Transaktion seitens des Händlers manuell freigegeben werden muss.<br />

Zahlungssicherheit: Iclear steht für die Bezahlung aller Forderungen durch den<br />

Zahlungsempfänger ein und bietet diesem somit einen gesicherten<br />

Implementierung: Einstweilen gehört iclear in vielen am Markt erhältlichen Shopsystemen<br />

zum Standard Repertoire und die Anbindung stellt für den Händler einen einfachen Vorgang<br />

dar, weil kein spezielles Know-How vonnöten ist. Der Implementierungsaufwand besteht<br />

lediglich darin, ein von iclear zur Verfügung gestelltes Skript in das eigene Shopsystem zu<br />

integrieren und den eigenen Bedürfnissen anzupassen.<br />

Registrierung: Erste Voraussetzung für die Nutzung ist, dass man über ein Benutzerkonto bei<br />

iclear verfügt. Um das Konto einzurichten, genügt es ein Online-Formular auszufüllen. Die<br />

notwendige Zugangsberechtigung in Form von (Benutzername und Passwort) werden per email<br />

übermittelt. Um die Identität des Kunden zu überprüfen, muss dieser einen<br />

Lichtbildausweis an iclear schicken.<br />

Zahlungssysteme <strong>im</strong> Internet


6 Workflowmodelle für ePayment Verfahren 65<br />

6 Workflowmodelle für ePayment Verfahren<br />

In den bisherigen Kapiteln wurde die Betrachtung der ePayment Verfahren rein auf verbale<br />

Analyse beschränkt. Das Ziel dieser Arbeit sollte in einem Versuch liegen, die aus der<br />

verbalen Betrachtung gewonnenen Erkenntnisse in reale Sachbezogenheiten zu<br />

transformieren. Damit ist gemeint, grafische Diagramme zu entwickeln, welche in einem<br />

Baukasten für Workflowmodelle integriert werden sollen. Dieser Baukasten kann zur<br />

Entwicklung kompletter Geschäftsmodelle Verwendung finden.<br />

Zur Beurteilung der Verwendbarkeit eines ePayment Verfahrens muss zusätzlich ein Profil<br />

erstellt werden. Dies ist dafür notwendig um die Qualifikation des ePayment Verfahrens das<br />

das Modell repräsentiert, vornehmen zu können. Es soll von vornherein die Möglichkeit<br />

ausgeschlossen werden, in einem Geschäftsdiagramm ein Zahlungsmodell zu integrieren, das<br />

sich hierfür überhaupt nicht eignet. Deswegen muss jedes Modell wiederum separat einem<br />

Bewertungsschlüssel unterzogen werden, das zur Erstellung eines Profils gedacht ist. Die<br />

konturierenden Kriterien werden <strong>im</strong> Kapitel 6.2. behandelt.<br />

6.1 Allgemeine Erläuterungen<br />

Die Erstellung der Workflowdiagramme erfolgt nach folgendem Schema:<br />

1. Vollständige Prozesskette<br />

2. Transaktionsdatenerfassungsprozess<br />

3. Autorisierungsprozess<br />

4. Abbuchungsprozess<br />

Vollständige Prozesskette:<br />

Dieses Diagramm beschreibt möglichst den gesamten Prozessablauf auf der höchsten<br />

Abstraktionsebene. Dieser Teil kann den Ankerpunkt zur Integration in ein Geschäftsmodell<br />

bieten.<br />

Transaktionsdatenerfassungsprozess:<br />

Jedes Zahlungsverfahren benötigt für seine Arbeit eine Menge von genuinen Daten. Daher ist<br />

ein spezielles Diagramm zur Beschreibung notwendig. Es werden die Daten des<br />

Zahlungspflichtigen, der den Auftrag erteilt hat, und die Daten des Artikels, den der<br />

Zahlungspflichtige angefragt hat, sowie die Daten des Zahlungsempfängers für den<br />

nachfolgenden Autorisierungsprozess ermittelt.<br />

Autorisierungsprozess:<br />

Autorisierungsprozesse werden je nach Zahlungsverfahren unterschiedlich vorgenommen.<br />

Dies bedeutet, dass in einem ersten Schritt lediglich eine Autorisierung und Vorreservierung<br />

des Zahlungsbetrages durchgeführt wird. Dabei wird eine Verbindung zwischen dem<br />

Zahlungsempfänger und Zahlungsdienstleister aufgebaut und überprüft, ob der<br />

Zahlungspflichtige über den entsprechenden Betrag verfügt oder zum Beispiel die Kreditkarte<br />

gültig und gedeckt ist und die Kreditkartengesellschaften die Transaktion akzeptieren wird.<br />

Der Zahlungsempfänger kann somit über diesen Geldbetrag in einem definierten Zeitraum<br />

Zahlungssysteme <strong>im</strong> Internet


6 Workflowmodelle für ePayment Verfahren 66<br />

verfügen. Erst zu einem späteren Zeitpunkt, üblicherweise bei Versand der Ware erfolgt der<br />

eigentliche Buchungsvorgang, sprich die finale Belastung des Zahlungspflichtigen.<br />

Abbuchungsprozess:<br />

Die Zahlungsverfahren verwenden teilweise unterschiedliche Lösungen für den zum<br />

Geschäftsabschluss notwendigen Abbuchungsprozess am Kundenkonto und einige bieten<br />

zusätzliche Optionen an, wie zum Beispiel das Korrigieren eines vorgegebenen<br />

Zahlungszieles bei verzögerter Lieferung. Diese Aspekte werden in diesem „Prozess“<br />

berücksichtigt. Dabei ist festzuhalten, dass nur für Verfahren die eine „Reservierung des<br />

Zahlungsbetrages“ vornehmen der Entwurf eines solchen Diagramms sinnvoll ist. Für<br />

einfache Verfahren die diesen Prozess in einer singulären Aktivität abwickeln, ist der<br />

Abbuchungsablauf aus dem Autorisierungsprozessdiagramm ersichtlich und muss nicht<br />

gesondert behandelt werden.<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Abbildung 6-1: Legende verwendeter Symbole<br />

Anwendungssoftware: Dieses Symbol steht für eine den Prozess unterstützende Applikation<br />

Konkretere Aussagen über Funktionsweise und Art des Aufbaus können anhand der<br />

mannigfaltigen Möglichkeiten wie solch eine Anwendung konstruiert sein kann, nicht<br />

gemacht werden.<br />

Umfelddaten: Es gibt Sequenzen <strong>im</strong> Geschäftsprozess die für die Durchführung einer<br />

Aktivität gewisse Daten als Input benötigen.<br />

Informationsfluss: Zeigt die Richtung des Informationsweges an.<br />

Kontrollfluss: Verbindet zwei oder mehrere Aktivitäten zu einer chronologischen<br />

Reihenfolge.<br />

Nachricht: Die in eine Aktivität eingehenden bzw. daraus generierten Parameter bilden zu<br />

einander eine höhere Ordnung. Diese werden durch das Symbol Nachricht visualisiert.<br />

Rolle: Eine Rolle ist eine abstrakte Beschreibung einer Person, nämlich jemand, der die<br />

Berechtigung hat, diese Aktivität durchzuführen. Diese wird mit dem Begriff der "Rolle"<br />

beschrieben.<br />

Prozess: Zusammengehörende Aktivitäten können zueinander einen funktionalen<br />

Zusammenhang besitzen. Dieser wird unter diesem Symbol bezeichnet.<br />

Aktivität: Eine Aktivität beschreibt einen durchgeführten Bearbeitungsschritt eines<br />

Prozesses. Sie ist die kleinste Verfeinerungsstufe eines Bearbeitungsschrittes - ein einzelner<br />

atomarer Arbeitsschritt.


6 Workflowmodelle für ePayment Verfahren 67<br />

XOR: Steht für zwei sich an einem Prozessschritt folgenden aber sich gegenseitig<br />

ausschließenden Aktivitäten.<br />

Leistung: Ergebnis das ein Prozess liefert.<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Abbildung 6-2: Nachrichtenfluss – allgemein<br />

Die Abbildung zeigt die am Geschäftsprozess beteiligten Rollen und verdeutlicht die<br />

Informationsflüsse bei der Abwicklung einer Zahlungstransaktion. Der Informationsfluss<br />

zwischen den einzelnen beteiligten Akteuren ist durch die punktierten Linien gekennzeichnet.<br />

Die darauf folgende, tatsächliche Übertragung des Geldes findet <strong>im</strong>mer elektronisch über die<br />

Netzwerke der Banken und deren Verrechnungssysteme statt.<br />

Dieses Diagramm beschreibt das Grundszenario der interaktiven Kommunikation der<br />

Rollenträger, wie es für die meisten Zahlungsverfahren gültig ist.<br />

Zahlungspflichtiger: Der Zahlungspflichtige löst die Zahlung aus, die zu seinen Lasten geht.<br />

In einer e-commerce Transaktion ist der Zahlungspflichtige üblicherweise der Kunde, der<br />

Waren <strong>im</strong> weiten Sinn kauft. Dies betrifft sowohl physikalische Güter, digitale Güter als auch<br />

Dienstleistungen wie zum Beispiel Literaturrecherchen.<br />

Zahlungsempfänger: Der Zahlungsempfänger ist der Begünstigte einer Zahlung, der Waren<br />

oder Dienstleistungen gegen Entgelt anbietet. Im e-<strong>Commerce</strong> ist <strong>im</strong> Allgemeinen der<br />

Händler der Zahlungsempfänger.<br />

Banken: Bei elektronischen Zahlungsverfahren sind meist die Hausbanken des<br />

Zahlungspflichtigen und des Zahlungsempfängers beteiligt. Diese regeln den Fluss des echten<br />

Geldes – die tatsächliche Wertübertragung – zwischen den Kunden- und Händlerkonten. Die<br />

Händler Bank empfängt die Zahlung von der Kunden Bank und schreibt den Betrag dem<br />

Zahlungsempfänger gut.<br />

Zahlungsdienstleister: Der Zahlungsdienstleister ist eine Drittpartei und bietet als<br />

Schnittstelle zwischen Kunde, Händler und den Banken verschiedene Zahlungsmethoden an.


6 Workflowmodelle für ePayment Verfahren 68<br />

6.2 Hierarchisierung von ePayment Verfahren<br />

Dem ersten Eindruck folgend erscheint es dem Betrachter unmöglich anhand der<br />

mannigfaltigen auf dem Markt präsenten Zahlungsverfahren eine systematische Ordnung<br />

feststellen zu können. Jedes Verfahren scheint für sich selber ohne Beeinflussung durch die<br />

anderen Systeme entwickelt worden zu sein. Wie kann man trotzdem eine hierarchische<br />

Ordnung einführen? Hierfür gäbe es eine Vielzahl von Ansatzmöglichkeiten. Das<br />

Betrachtungsfeld für payment Verfahren würde Kriterien für eine stufenweise Klassifizierung<br />

zu genüge anbieten. Nachfolgend wird der Versuch unternommen eine Hierarchisierung von<br />

Bezahlungsprozessen vorzunehmen, indem ein 3stufiges Modell entworfen wird, das es<br />

erlauben soll eine systematische Zuordnung aller hier erwähnten Verfahren vorzunehmen.<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Abbildung 6-3: dreistufiges Hierarchisierungsmodell<br />

Grundmodell<br />

Auf der untersten Architekturebene wird ein Geschäftsprozess von einem sehr hohen<br />

Abstraktionsniveau aus betrachtet. Bedingt durch die unterschiedliche Struktur der einzelnen<br />

Verfahren gibt es unterschiedliche Vorgehensweisen bei der Abwicklung einer Transaktion,<br />

die zwar letztendlich zum gleichen Ziel führt, <strong>im</strong> Detail aber zum Teil andere fachliche<br />

Begriffe erfordert. So ist es notwendig die wesentlichen „Bestandteile“ (Aktivitäten und<br />

Daten) auf einer abstrakten Ebene zu definieren, um die Grundlage für ein gemeinsames<br />

Modell zu bilden und aufzuzeigen was alle Verfahren unbedingt beinhalten müssen um<br />

marktfähig zu sein. Zur Realisierung einer Geschäftstransaktion wurde das in Abbildung 6-4<br />

dargestellte Modell entwickelt.<br />

Erweitertes Grundmodell<br />

In der mittleren Differenzierungsebene wird vor allem der unterschiedliche Grad der<br />

Kundeninteraktion augenfällig. Während Verfahren mit einem hohen Grad an<br />

Kundeninteraktion keine weiteren Aktivitäten zur Kundenauthentifizierung benötigen,<br />

erfordern andere Verfahren denen es an derartig ausgeklügelten Mechanismen mangelt einen<br />

arbeitsintensiveren Identifikationsprozess, der mittels Redirect realisiert werden muss. Dieser<br />

durch Einbezug dieses Kriteriums entstandenen Zweiteilung wird <strong>im</strong> Modellentwurf<br />

(Abbildung 6-5 und 6-6) Rechnung getragen.


6 Workflowmodelle für ePayment Verfahren 69<br />

Detailmodell<br />

Jedes Zahlungsverfahren wird <strong>im</strong> Detail nach dem <strong>im</strong> Kapitel 6.1. festgelegten Schema<br />

modelliert.<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Abbildung 6-4: Grundmodell – allgemeiner Transaktionsablauf<br />

Grundmodell – allgemeiner Transaktionsablauf<br />

Im Transaktionsdatenerfassungsprozess (Bestelldaten u. Akteursdaten übernehmen) werden<br />

Bestelldaten mit Akteursdaten zusammengeführt. Aus welcher Konsistenz diese Akteursdaten<br />

bestehen, ob nur Händlerdaten oder Händler- und Kundendaten in einem Verbund sind für<br />

dieses hohe Abstraktionsniveau noch nicht von Belang. Ein virtueller Warenkorb fungiert<br />

dabei als Datenbehälter für die relevanten Bestelldaten. Die Transaktionsdaten beschreiben<br />

somit eine Art „Datenverbund“, der sich aus den Bestell-, und Akteursdaten zusammensetzt<br />

und dem Zahlungsdienstleister zur Verifikation vorgelegt werden muss. Die Akteursdaten<br />

tragen zur Identifikation jener Akteure bei zwischen denen die Markttransaktion


6 Workflowmodelle für ePayment Verfahren 70<br />

abgeschlossen wird. Der dem Datenerfassungsprozess folgende Autorisierungsprozess<br />

(Aggregierte Daten übertragen) ist für den Verbindungsaufbau zwischen Zahlungsempfänger<br />

und Zahlungsdienstleister verantwortlich. Die zentrale Komponente in diesem Prozess bildet<br />

ein vom jeweiligen Zahlungsdienstleister zur Verfügung gestellte Payment Schnittstelle.<br />

Diese bekommt die aggregierten Transaktionsdaten durch das Shopsystem geliefert und muss<br />

diese dann an den Server be<strong>im</strong> Zahlungsdienstleister übertragen. Kann die<br />

Zahlungstransaktion be<strong>im</strong> Zahlungsdienstleister fehlerfrei abgearbeitet werden, erhält der<br />

Zahlungsempfänger als Leistung eine positive Transaktionsbestätigung (Zahlungszusage) und<br />

die Transaktion kann als abgeschlossen betrachtet werden. Wird die Zahlungstransaktion<br />

nicht erfolgreich durchlaufen, erhält der Zahlungsempfänger eine negative<br />

Transaktionsbestätigung (Zahlungszusage) und die Zahlungstransaktion wird zurückgesetzt.<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Abbildung 6-5: erweitertes Grundmodell ohne Kundeninteraktion


6 Workflowmodelle für ePayment Verfahren 71<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Abbildung 6-6: erweitertes Grundmodell mit Kundeninteraktion


6 Workflowmodelle für ePayment Verfahren 72<br />

Erweitertes Grundmodell – keine Kundeninteraktion<br />

Dadurch, dass sich der Kunde <strong>im</strong> wesentlichen dem Händlersystem gegenüber nicht<br />

identifizieren muss, wird die Zahlungsaufforderung durch Weiterleitung an den<br />

Zahlungsdienstleister des Kunden durchgeführt. Das Händlersystem teilt dem Kunden mittels<br />

Zusendung einer Redirect-URL die Aufforderung zum Geschäftsabschluss mit. Besitzt der<br />

Kunde keine zulässige Geschäftsfähigkeit, vielleicht dadurch, dass er sich dem<br />

Zahlungsdienstleister gegenüber nicht identifizieren kann, kommt es <strong>im</strong> Geschäftsprozess zu<br />

keinem positiven Abschluss.<br />

Erweitertes Grundmodell – mit Kundeninteraktion<br />

Verfahren mit dieser Eigenschaft verlangen zur Fortführung des Prozessablaufs weitere<br />

Identifikations- beziehungsweise Kundendaten. Der Kunde muss aufgefordert werden dem<br />

Händler zusätzliche Daten mitzuteilen, wie zum Beispiel eine Mobiltelefonnummer oder<br />

Kreditkartennummer, da ansonsten der Ablauf nicht ordnungsgemäß erledigt werden kann.<br />

Das der Kunde hierbei noch separat über den Zahlungsverlauf informiert werden muss ist<br />

unabdingbar.<br />

Nachfolgend erfolgt in Tabelle 6-1 die Einordnung der Zahlungssysteme in das erweiterte<br />

Grundmodell.<br />

mit Kundeninteraktion ohne Kundeninteraktion<br />

• Paybox<br />

• Mpay<br />

• Kreditkarte SET<br />

• Verified by Visa<br />

• E-Einkauf<br />

Zahlungssysteme <strong>im</strong> Internet<br />

• Paysafecard<br />

• Banking<br />

• @Quick<br />

• Iclear<br />

Tabelle 6-1: Einordnung nach Kundeninteraktion


6 Workflowmodelle für ePayment Verfahren 73<br />

6.2.1 Paybox<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Abbildung 6-7: Prozesskette – Paybox<br />

Prozesskette<br />

Der Prozess startet mit der Ermittlung der relevanten Transaktionsdaten durch Interaktion mit<br />

dem Zahlungsempfänger und Zahlungspflichtigen. Kann das Ergebnis dieses Schrittes als<br />

positiv qualifiziert werden, können die Transaktionsdaten an den Autorisierungsprozess<br />

weitergereicht werden. Sind die Daten korrekt erfolgt postwendend die Belastung des Kunden<br />

durch den Zahlungsempfänger. Unabhängig vom Ergebnis des Autorisierungsprozesses setzt<br />

der Zahlungsempfänger den Zahlungspflichtigen über den Ausgang der Transaktion in<br />

Kenntnis.


6 Workflowmodelle für ePayment Verfahren 74<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Abbildung 6-8: Transaktionsdatenerfassungsprozess – Paybox


6 Workflowmodelle für ePayment Verfahren 75<br />

Transaktionsdatenerfassungsprozess<br />

Am Anfang der Transaktionsdatenerfassung steht die Prüfung des Kundenprofils. Dazu<br />

verwaltet die Benutzerverwaltung die aktuellen BenutzerIDs von den angemeldeten<br />

Benutzern und ordnet über diese ID dem jeweiligen Benutzer seine gespeicherten<br />

Kundendaten zu. Ist dieses unvollständig, werden die fehlenden Daten (Mobiltelefonnummer<br />

oder optional Alias Nummer) vom Zahlungsempfänger angefordert. Als unvollständig kann<br />

die Angabe einer falschen oder abgelaufenen BenutzerID gelten. Der Standardfall dürfte<br />

allerdings das Fehlen einer Mobiltelefonnummer sein. Wird dies nämlich be<strong>im</strong> Einlesen der<br />

Kundendaten festgestellt, obwohl der Kunde registriert ist, muss die Mobiltelefonnummer<br />

mittels Html-Formular abgefragt werden. Ist die erneute Prüfung erfolgreich werden die<br />

Kundendaten aktualisiert.<br />

Für Neukunden ist die Kundenprofiluntersuchung vorerst irrelevant, obwohl deren Ergebnis<br />

nur negativ sein kann, weil das System dies als Aufforderung zur Neuaufnahme in den<br />

Kundenstamm auffasst. Der Zahlungspflichtige erfährt seine Einstufung als Neukunde und<br />

fehlende Daten (Benutzername, PWD, Mobiltelefonnummer bzw. Alias Nummer) werden<br />

über ein Html-Formular eingefordert. Sind obligatorische Daten (Mobiltelefonnummer bzw.<br />

Alias Nummer) nach wie vor fehlerhaft, so fordert das Shopsystem so lange eine<br />

Wiederholung des Eingabevorganges an, bis ein zulässiger Datensatz vorliegt.<br />

Für einen schon registrierten Kunden, ein so genannter Stammkunde, braucht das Profil nach<br />

erfolgter korrekter Identifikation (BenutzerID) nur mehr über die Benutzerverwaltung<br />

aktiviert werden. Dennoch werden auch für Stammkunden ständige Prüfungen auf<br />

Vollständigkeit unternommen. Dies ist notwendig um die Daten auf den aktuellen Stand zu<br />

halten. Der „Datenbehälter“ für die Transaktion besteht aus einer Verbindung der<br />

Mobiltelefonnummer, der vom Shopsystem freigegebenen Händlerdaten und den Bestelldaten<br />

aus dem Warenkorb. Diese werden zeitgleich zur Autorisierung einer Transaktion verwendet.<br />

Autorisierungsprozess<br />

Der Teilprozess Autorisierungsanfrage wird durch den Händler initiiert. Im Falle eines<br />

Online-Shops muss dazu ein Local Host Listener <strong>im</strong> lokalen Netz des Händlers installiert<br />

sein, der Anfragen vom Online-Shop entgegenn<strong>im</strong>mt und diese durch eine verschlüsselte<br />

Verbindung über das Internet an ein zentrales paybox-System weiterleitet, das dann die<br />

weitere Steuerung des Autorisierungsprozesses mit dem Endkunden übern<strong>im</strong>mt. Hierzu wird<br />

der Händler durch die übersendete HändlerID eindeutig authentifiziert. Daraufhin erfolgt von<br />

paybox ein Anruf be<strong>im</strong> Kunden (Mobiltelefonnummer), der durch erneute Nennung der<br />

Kaufsumme und dem Namen des Händlers über eine Automatenst<strong>im</strong>me die Transaktion<br />

durch Eingabe seiner paybox-PIN und einer anschließend erfolgreichen Prüfung der vom<br />

Kunden eingegebenen PIN zu einer Zahlungsautorisierung (Leistung: Autorisierungsergebnis)<br />

an den Händler führt, die der Local Host Listener entgegenn<strong>im</strong>mt. Fällt das<br />

Autorisierungsergebnis positiv aus, wird auch eine Reservierungsbestätigung generiert. Die<br />

Reservierungsbestätigung beinhaltet eine von paybox erzeugte TransaktionsID, die von<br />

paybox für die finale Belastung des Kundenkontos verlangt wird. Die Bearbeitung und<br />

Übersendung der Reservierungsbestätigung geschieht <strong>im</strong> Prozess Kundenkonto belasten.<br />

Zahlungssysteme <strong>im</strong> Internet


6 Workflowmodelle für ePayment Verfahren 76<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Abbildung 6-9: Autorisierungsprozess – Paybox<br />

Abbuchungsprozess<br />

Der Prozess startet mit einer Überprüfung des Zahlungsziels, das aufgrund von variierenden<br />

Lieferzeiten geändert werden kann. Ist der Vergleich des Lieferdatums eines Produktes<br />

ermittelt und mit dem vorgeschriebenen Zahlungsziel des Kunden nicht vereinbar<br />

(Zahlungsziel prüfen: Lieferdatum ist jünger als Zahlungsziel) erfolgt eine manuelle<br />

Korrektur des Zahlungsziels über das von paybox betreute Extranet.<br />

Um Zugang zum Extranet zu erhalten, authentifiziert sich der Zahlungsempfänger durch<br />

Eingabe seiner HändlerID. Daraufhin wird dieser von paybox auf seinem Mobiltelefon<br />

angerufen und aufgefordert, sich mit seiner PIN eindeutig zu identifizieren. Nun kann der<br />

Zahlungsempfänger <strong>im</strong> Extranet sein neues Zahlungsziel definieren. Nach erfolgreicher<br />

Korrektur wird das geänderte Zahlungsziel aktualisiert und mit Hilfe einer TransaktionsID<br />

erfolgt eine Bestätigungsmeldung. Wenn keine Anpassung des Zahlungsziels vonnöten ist,<br />

generiert das Shopsystem die Bestätigungsmeldung an paybox.


6 Workflowmodelle für ePayment Verfahren 77<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Abbildung 6-10: Abbuchungsprozess – Paybox<br />

Nachrichtenfluss<br />

Nachdem sich der Kunde durch seine Mobiltelefonnummer identifiziert hat und dem Händler<br />

die Bestelldaten bekannt gegeben hat, erteilt dieser dem paybox Server den Auftrag das<br />

Geschäft abzuwickeln. Nach Autorisierungsbetätigung mit erneuter Rückbestätigung seitens<br />

des Händlers gibt dieser der Bank des Kunden eine Abbuchungsverfügung. Der weitere<br />

Verlauf der Abbuchung und Umbuchung entspricht einer herkömmlichen Banktransaktion.


6 Workflowmodelle für ePayment Verfahren 78<br />

6.2.2 Paysafecard<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Abbildung 6-11: Nachrichtenfluss – Paybox<br />

Abbildung 6-12: Prozesskette – Paysafecard


6 Workflowmodelle für ePayment Verfahren 79<br />

Prozesskette<br />

Der Prozess startet mit der Ermittlung der relevanten Transaktionsdaten durch Interaktion mit<br />

dem Zahlungsempfängers und Zahlungspflichtigen. Kann das Ergebnis dieses Schrittes als<br />

positiv qualifiziert werden, können die Transaktionsdaten an den Autorisierungsprozess<br />

weitergereicht werden. Sind die Daten korrekt erfolgt postwendend die Belastung des<br />

Zahlungspflichtigen durch den Zahlungsempfänger.<br />

Transaktionsdatenerfassungsprozess<br />

Am Anfang des Transaktionsprozesses werden alle für das Clearing wichtigen Bestelldaten<br />

aus dem Warenkorb entnommen die mit dem vom Shopsystem freigegebenen Händlerdaten<br />

eine Leistung in Form einer Informationsbereitstellung repräsentieren. Die Bestelldaten<br />

beinhalten den Wert der vom Kunden bestellten Waren (Betrag) und die Währung in welcher<br />

der Web-Shop mit paysafecard fakturiert. Die Händlerdaten umfassen eine eindeutige, 10stellige,<br />

seitens paysafecard vergebene Nummer für den Zahlungsempfänger (MerchantID),<br />

eine URL zu der paysafecard den Zahlungspflichtigen nach erfolgreicher (OKURL)<br />

beziehungsweise nicht erfolgreicher (NOKURL) Zahlung weiterleitet und den Parameter<br />

businesstype der für physische Waren mit den Wert „tangible“ und für digitale Waren mit den<br />

Wert „intangible“ initialisiert werden muss. Zu den Transaktionsdaten zählt neben den<br />

Bestell- und Händlerdaten eine so genannte „Merchant Transaction ID“ (MTID). Diese MTID<br />

muss vom Shopsystem erstellt werden und dient der eindeutigen Identifizierung aller noch<br />

nachfolgend notwendigen Transaktionsschritte.<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Abbildung 6-13: Transaktionsdatenerfassungsprozess – Paysafecard


6 Workflowmodelle für ePayment Verfahren 80<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Abbildung 6-14: Autorisierungsprozess – Paysafecard<br />

Autorisierungsprozess<br />

Allen Anfragen an den paysafecard-Server resultieren in http-Requests, die mittels des<br />

SSLv3-Protokolls verschlüsselt werden. Auf diese Weise autorisieren sich beide<br />

Transaktionspartner gegenseitig beieinander. Mit der Aktivität „Disposition generieren“<br />

beginnt der Zahlungsvorgang, indem ein Funktionsaufruf an paysafecard geschickt wird, der<br />

am Server eine Disposition anlegt. Unmittelbar danach muss der Zahlungsempfänger den<br />

Kunden auf die paysafecard Zahlungsseite weiterleiten. Bei diesem Redirect müssen die<br />

Redirectdaten als Parameter mitgegeben werden. Der Zahlungspflichtige ist nach dem


6 Workflowmodelle für ePayment Verfahren 81<br />

Redirect direkt mit dem paysafecard Server verbunden und kann eine oder mehrere Karten zu<br />

der erzeugten Disposition zuordnen, wobei eine Vormerkung für den Betrag auf diesen<br />

Karten angelegt wird. Damit hat der Kunde seine Bezahlung beendet und wird auf die OK-<br />

URL oder die NOK-URL weitergeleitet. Der Ablauf <strong>im</strong> Onlineshop kann nun fortfahren.<br />

Durch die Aktivität „Disposition abfragen“ kann der Zahlungsempfänger jederzeit den<br />

gegenwärtigen Zustand einer Zahlungstransaktion abfragen. Als Parameter müssen die<br />

Merchant ID und die Merchant Transaction ID übergeben werden. Der paysafecard Server<br />

antwortet mit einer Statusmeldung, d. h. ob die Zahlung fertig zum Abbuchen ist. Folgende<br />

Parameter werden dabei übermittelt: Währung, reservierter Geldbetrag (Betrag), errorcode: 0<br />

gibt an dass die Disposition erfolgreich angelegt wurde; 1 bzw. 2 signalisieren ein logisches<br />

bzw. technischen Problem; state – liefert den Status einer Disposition und kann folgende<br />

mögliche Zustände annehmen: C - Disposition ist erfolgreich erstellt, aber es wurden noch<br />

keine Karten zugeordnet; X – Disposition ist entweder vom Zahlungspflichtigen abgebrochen<br />

oder zu wenig Guthaben; D – Der Zahlungspflichtige hat seine Kartennummer eingegeben<br />

und die Zahlung ist erfolgt. Eine Abbuchung ist nur bei einem state=D möglich.<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Abbildung 6-15: Abbuchungsprozess – Paysafecard


6 Workflowmodelle für ePayment Verfahren 82<br />

Abbuchungsprozess<br />

Mit „Disposition bestätigen“ wird die Verbuchung des zuvor <strong>im</strong> Autorisierungsprozess<br />

reservierten Betrages angestoßen und die Abbuchung des reservierten Guthabens von den<br />

einer Disposition zugeordneten paysafecard-Wertkarten in die Wege geleitet. Wird das<br />

closeflag auf 1 gesetzt ist die Disposition geschlossen und keine weiteren Abbuchungen sind<br />

mehr möglich. Wenn eine Ware oder Dienstleistung nicht sofort beziehungsweise in<br />

Teillieferungen geliefert werden kann (Lieferdatum jünger als Zahlungsziel), besteht die<br />

Möglichkeit den ursprünglich reservierten Geldbetrag in einen Teilbetrag und den noch<br />

ausstehenden Restbetrag nach der letzten Teillieferung abzubuchen. Die notwendigen<br />

Eingabeparameter sind die MID, MTID, der reduzierte Geldbetrag und die Währung.<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Abbildung 6-16: Nachrichtenfluss – Paysafecard<br />

Nachrichtenfluss<br />

Der Zahlungspflichtige teilt dem Händler den Kaufwunsch durch die Bestelldaten mit.<br />

Daraufhin benachrichtigt dieser den Zahlungsdienstleister und leitet den Zahlungspflichtigen<br />

an sich über einen PIN auszuweisen. Geschieht dies wird dessen Konto belastet und dem<br />

Zahlungsempfänger gutgeschrieben.


6 Workflowmodelle für ePayment Verfahren 83<br />

6.2.3 Quick<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Abbildung 6-17: Prozesskette - @Quick<br />

Prozesskette<br />

Der Prozess startet mit der Ermittlung der relevanten Transaktionsdaten die lediglich aus dem<br />

virtuellen Warenkorb und „nur“ aus den den Händler identifizierenden Daten bestehen. Zu<br />

bemerken ist, dass dieser Prozess vollständig ohne Einbezug des Kunden durchgeführt wird.<br />

Diese bilden nun die Inputdaten für den Autorisierungsprozess. Das Ergebnis des<br />

Autorisierungsprozesses liefert die Leistung in Form einer Zahlungsbestätigung, ob die<br />

Transaktion erfolgreich beziehungsweise nicht erfolgreich verlaufen ist.<br />

Transaktionsdatenerfassungsprozess<br />

Am Anfang des Transaktionsprozesses werden alle für das Clearing wichtigen Bestelldaten –<br />

Gesamtsumme der bestellten Ware (Bezahlbetrag), Währung in der die Bezahlung<br />

durchgeführt wird und Beschreibung des Einkaufs - aus dem Warenkorb entnommen die mit<br />

dem vom Shopsystem freigegebenen Händlerdaten eine Leistung in Form einer<br />

Informationsbereitstellung repräsentieren. Die Händlerdaten beinhalten eine merchantID,<br />

eine Nummer des Zahlungsempfängers die von PDTS vergeben wird. Mit dieser Kennung<br />

wird der Bezahlvorgang dem Händler zugeordnet. Zu den Transaktionsdaten zählt neben den<br />

Bestell- und Händlerdaten eine so genannte „Customer ID“. Über diese Kennung kann eine<br />

Bezahlung einem best<strong>im</strong>mten Zahlungspflichtigen zugeordnet werden. Es handelt sich dabei<br />

um einen alphanumerischen String der vom Shop frei vergeben wird. Zuletzt wird noch mit<br />

Hilfe eines merchantKey (von PDTS vergeben) ein Hashwert über die aggregierten<br />

Transaktionsdaten erzeugt.


6 Workflowmodelle für ePayment Verfahren 84<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Abbildung 6-18: Transaktionsdatenerfassungsprozess - @Quick<br />

Autorisierungsprozess<br />

Am Beginn des Autorisierungsprozesses wird das Integrationsskript vom Shopsystem mit den<br />

zur Bezahlung und zur Identifikation am Paymentserver notwendigen Parametern<br />

(Transaktionsdaten) aufgerufen. Sind diese Daten syntaktisch und semantisch in Ordnung<br />

initiiert dieses mittels eines PlugIns auf Kundenseite ein Bezahlfenster. In diesem Fenster<br />

wird die Transaktion mit dem PDTS Hostingserver und dem Zahlungspflichtigen über ein<br />

„Quick Zahlungsprotokoll“ abgewickelt. Der Zahlungspflichtige kann die Richtigkeit der<br />

Bestellung nochmals nachprüfen und die Transaktion freigeben. Nach dem Ende eines<br />

Bezahlvorganges beziehungsweise einer Bezahlungsüberprüfung wird das Ergebnis als<br />

Parameter (result) an den Zahlungsempfänger übergeben. Anhand der Auswertung der<br />

Ergebnisparameter durch das Integrationsskript kann <strong>im</strong> Shop der Erfolg oder Misserfolg<br />

eines Bezahlvorgangs festgestellt und <strong>im</strong> Shop verbucht werden. Wurde der Vorgang<br />

erfolgreich durchgeführt ist der Wert von result 0, andernfalls größer als 0.


6 Workflowmodelle für ePayment Verfahren 85<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Abbildung 6-19: Autorisierungsprozess - @Quick<br />

Nachrichtenfluss<br />

Der Ablauf des Bezahlens beginnt mit der Bestätigung des Zahlungsbetrags durch den<br />

Karteninhaber und dem Einführen der Karte in das Kartenlesegerät. Dieses übermittelt die<br />

Daten der Quick-Börse und den Betrag an die be<strong>im</strong> PDTS eingebaute Händlerkarte, welche<br />

die Daten auf Echtheit prüft. Die Chipkarte reduziert den Saldo um den Betrag, signiert die<br />

Transaktionsdaten und sendet diese über den Kartenleser an die Händlerkarte. Die<br />

Händlerkarte schreibt den Betrag dem betreffenden Poolkonto gut und signiert und speichert<br />

die Transaktionsdaten zur späteren Verrechnung. Die auf der Händlerkarte gespeicherten<br />

Summen der Bezahltransaktion werden regelmäßig bei der Zentrale eingereicht.


6 Workflowmodelle für ePayment Verfahren 86<br />

6.2.4 E-Einkauf<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Abbildung 6-20: Nachrichtenfluss - @Quick<br />

Abbildung 6-21: Nachrichtenfluss – E-Einkauf<br />

Nachrichtenfluss<br />

Der Zahlungspflichtige gibt seine Bestellung über den WWW-Server des<br />

Zahlungsempfängers und übermittelt seine Login-Daten. Der Zahlungsempfänger leitet diese<br />

Login-Daten zur Prüfung an den Server des Zahlungsdienstleisters weiter zusammen mit den


6 Workflowmodelle für ePayment Verfahren 87<br />

anderen Informationen wie die Kennung des Zahlungsempfängers. Nach erfolgter<br />

Verifikation wird der Zahlungsempfänger informiert. Dieser wiederum schickt dem<br />

Zahlungspflichtigen eine Benachrichtigung und das Clearing wird über das geschützte<br />

Banknetz abgewickelt<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Abbildung 6-22: Prozesskette – E-Einkauf<br />

Prozesskette<br />

Der Prozess startet mit der Ermittlung der relevanten Transaktionsdaten durch Interaktion mit<br />

dem Zahlungsempfängers und Zahlungspflichtigen. Kann das Ergebnis dieses Schrittes als<br />

positiv qualifiziert werden können die Transaktionsdaten an den Autorisierungsprozess<br />

weitergereicht werden. Der Zahlungsempfänger wird durch eine Statusmeldung vom Ausgang<br />

des Autorisierungsprozesses informiert. Abschließend bekommt der Zahlungspflichtige die<br />

Bestätigung des Auftrags in seinem Internet-Browser angezeigt.<br />

Transaktionsdatenerfassungsprozess


6 Workflowmodelle für ePayment Verfahren 88<br />

Sind die Login-Daten via Eingabemaske bekannt gegeben wird aus dem Warenkorb ein<br />

Bestellformular erzeugt. Login-Daten und Bestelldaten bilden in der weiteren Folge unter zu<br />

Hilfenahme des Local Host Listeners <strong>im</strong> Autorisierungsprozess eine <strong>im</strong> XML-Format<br />

abgefasste Dateneinheit. Die Bestelldaten umfassen den Wert der vom Kunden bestellten<br />

Waren (Betrag), die Währung in welcher der Web-Shop mit der P.S.K. fakturiert und eine<br />

Kurzbeschreibung der Bestellartikel. Die Firmenbezeichnung (FA-Name) sowie die<br />

Kontonummer (KTO.NR.) dienen der eindeutigen Identifizierung gegenüber dem<br />

Zahlungsempfänger und müssen diesem bei der erstmaligen Registrierung mitgeteilt werden.<br />

Zu den Transaktionsdaten zählt neben den Bestell- und Händlerdaten eine so genannte<br />

DokumentID. Diese DokumentID muss vom Shopsystem erstellt werden und dient der<br />

eindeutigen Identifizierung aller noch nachfolgend notwendigen Transaktionsschritte.<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Abbildung 6-23: Transaktionsdatenerfassungsprozess – E-Einkauf<br />

Autorisierungsprozess<br />

Dieser Vorgang läuft vollständig händlerseitig ab. Besteht ein Online-Shop muss dazu ein<br />

Local Host Listener <strong>im</strong> lokalen Netz des Händlers installiert sein, der Anfragen vom Online-


6 Workflowmodelle für ePayment Verfahren 89<br />

Shop entgegenn<strong>im</strong>mt und diese durch eine verschlüsselte Verbindung über das Internet an<br />

bezahlen.at weiterleitet. Hierzu wird der Händler durch die übersendete HändlerID eindeutig<br />

authentifiziert. Daraufhin erfolgt von bezahlen.at eine Prüfung auf ausreichende<br />

Kontodeckung des Zahlungspflichtigen sowie die Verifikation des freigegebenen<br />

Datenbestandes. Das Autorisierungsergebnis wird in Form einer Statusmeldung übermittelt.<br />

Status=OK signalisiert eine positive Prüfung. Im Fehlerfall (Status=NOK) ist die Ursache<br />

zusätzlich durch ein code-Attribut genauer spezifiziert.<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Abbildung 6-24: Autorisierungsprozess – E-Einkauf


6 Workflowmodelle für ePayment Verfahren 90<br />

6.2.5 Banking-Verfahren<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Abbildung 6-25: Nachrichtenfluss – Banking<br />

Nachrichtenfluss<br />

Der Zahlungspflichtige hat seinen Einkauf getätigt und wird vom Zahlungsempfänger auf die<br />

URL vom Bankserver weitergeleitet, wo er nach einem Login die Transaktion durch die<br />

Eingabe einer TAN nochmals bestätigt. Der Zahlungsdienstleister prüft während des<br />

Zahlungsvorgangs die Authentizität und Kontodeckung des Zahlungspflichtigen und setzt<br />

diesen und den Zahlungsempfänger über die erfolgte Autorisierung in Kenntnis.


6 Workflowmodelle für ePayment Verfahren 91<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Abbildung 6-26: Prozesskette – Banking<br />

Prozesskette<br />

Der Prozess startet mit der Ermittlung der relevanten Transaktionsdaten die lediglich aus dem<br />

virtuellen Warenkorb und „nur“ aus den den Händler identifizierenden Daten bestehen. Zu<br />

bemerken ist, dass dieser Prozess vollständig ohne Einbezug des Kunden durchgeführt wird.<br />

Diese bilden nun die Inputdaten für den Autorisierungsprozess. Das Ergebnis des<br />

Autorisierungsprozesses liefert die Leistung in Form einer Zahlungsbestätigung, ob die<br />

Transaktion erfolgreich beziehungsweise nicht erfolgreich verlaufen ist.<br />

Abbildung 6-27: Transaktionsdatenerfassungsprozess – Banking<br />

Transaktionsdatenerfassungsprozess<br />

Am Anfang des Transaktionsprozesses werden alle für das Clearing wichtigen Bestelldaten<br />

aus dem Warenkorb entnommen die mit dem vom Shopsystem freigegebenen Händlerdaten<br />

eine Leistung in Form einer Informationsbereitstellung für den nachfolgenden<br />

Autorisierungsprozess repräsentieren. Die HändlerID und das Passwort zur HändlerID werden<br />

vom Zahlungsdienstleister vergeben und dienen zur Identifikation. Folgende Parameter<br />

müssen vom Zahlungsempfänger initialisiert werden: homepageurl – wenn die Überweisung<br />

nicht erfolgreich durchgeführt wird, erhält der Kunde einen Redirect auf diese URL;<br />

transactionurl – jene URL die dem Zahlungspflichtigen angezeigt wird, wenn die Transaktion<br />

erfolgreich ist; confirmationurl – Adresse an welche die Zahlungsbestätigung gesendet wird.


6 Workflowmodelle für ePayment Verfahren 92<br />

Zahlungssysteme <strong>im</strong> Internet


6 Workflowmodelle für ePayment Verfahren 93<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Abbildung 6-28: Autorisierungsprozess – Banking


6 Workflowmodelle für ePayment Verfahren 94<br />

Autorisierungsprozess<br />

Der Bankrechner erwartet sich vom Händler einen XML Strom mit welchem die eigentliche<br />

Session beginnt. Als Antwort auf den XML Strom sendet der Bankrechner eine Nachricht mit<br />

einer Session ID. Nach Erhalt dieser Nachricht sendet der Händler einen http redirect an den<br />

Browser des Kunden, wobei <strong>im</strong> Ziel URL die Session ID übermittelt wird. Dieser Ziel URL<br />

zeigt zur Bankapplikation Startseite für den Käufer. Der Käufer identifiziert sich am Bank-<br />

Server mit dem von der jeweiligen Bank vorgesehenen Mechanismen. Nach dem Login am<br />

Bank-Server kann der Zahlungspflichtige sein Auftraggeberkonto auswählen und bekommt<br />

den Rechnungsbetrag zur Unterschrift mit einer TAN vorgelegt. Nach der TAN Eingabe<br />

überprüft der Bankrechner ob die Verbindung zum Webshop noch aktiv ist.<br />

Dazu wird ein XML Strom an den Händler gesendet. Die Bankapplikation erwartet sich, dass<br />

die gleiche Nachricht wieder zurückgesendet wird, andernfalls wird angenommen, dass dieser<br />

nicht mehr erreichbar ist und die Überweisung wird nicht durchgeführt. Nach positivem<br />

Vitality Check des Händlers wird die Überweisung durchgeführt und anschließend erhält der<br />

Händler eine Zahlungsbestätigung. Bei einem erfolgreichen Zahlungsvorgang weist das<br />

Attribut „Status“ den Wert „ok“, andernfalls „nok“.<br />

6.2.6 M-Pay<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Abbildung 6-29: Nachrichtenfluss – M-pay<br />

Nachrichtenfluss<br />

Der Kunde teilt dem Händler seine Mobiltelefonnummer mit. Dieser initiiert daraufhin den<br />

Bezahlvorgang und übermittelt Transaktionsdaten und Mobilnummer an den<br />

Zahlungsdienstleister. Durch Eingabe eines per SMS zugesendeten Codes über die Website<br />

des Zahlungsempfängers veranlasst der Zahlungsdienstleister die Abbuchung auf dem<br />

Kundenkonto und die Gutschrift des Betrages auf dem Händlerkonto.


6 Workflowmodelle für ePayment Verfahren 95<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Abbildung 6-30: Prozesskette – M-pay<br />

Prozesskette<br />

Der Prozess startet mit der Ermittlung der relevanten Transaktionsdaten durch Interaktion mit<br />

dem Zahlungsempfängers und Zahlungspflichtigen. Kann das Ergebnis dieses Schrittes als<br />

positiv qualifiziert werden, können die Transaktionsdaten an den Autorisierungsprozess<br />

weitergereicht werden. Unabhängig vom Ergebnis des Autorisierungsprozesses muss der<br />

Zalungspflichtige auf elektronischem Weg benachrichtigt werden.<br />

Transaktionsdatenerfassungsprozess<br />

Mit Prüfung des Kundenprofils wird der Prozess in seine Startphase geleitet. Dazu muss eine<br />

von der Benutzerverwaltung freigegebene BenutzerID publik gemacht werden, um ein<br />

tatsächlich auf die physische Person des Kunden referenzierendes Profil aufzubauen. Ist<br />

dieses unvollständig, müssen fehlenden Daten (Mobiltelefonnummer) vom<br />

Zahlungsempfänger angefordert werden. Als unvollständig kann die Angabe einer falschen<br />

oder abgelaufenen BenutzerID gelten. Als schwerwiegenderer Mangel wird allerdings das<br />

Fehlen einer Mobiltelefonnummer gewertet. Wird dies nämlich be<strong>im</strong> Einlesen der<br />

Kundendaten festgestellt, obwohl der Kunde registriert ist, muss die Mobiltelefonnummer<br />

abgefragt werden. Ist die erneute Prüfung erfolgreich werden die Kundendaten aktualisiert.<br />

Für Neukunden ist die Kundenprofiluntersuchung fürs erste irrelevant, obwohl das Ergebnis<br />

des Profilaufbaues nur negativ bewertet werden kann, weil das System dies als Aufforderung<br />

zur Neuaufnahme in den Kundenstamm auffasst. Der Zahlungspflichtige erfährt seine<br />

Einstufung als Neukunde und fehlende Daten (Benutzername, PWD, Mobiltelefonnummer)<br />

werden über Eingabe mittels eines Html-Formulars eingefordert. Für einen schon registrierten<br />

Kunden, ein sogenannter Stammkunde, braucht das Profil nach erfolgter korrekter<br />

Identifikation nur mehr über die Benutzerverwaltung aktiviert werden. Der „Datenbehälter“<br />

für die Transaktion besteht aus einer Verbindung der Mobiltelefonnummer, der vom<br />

Shopsystem freigegebenen Händlerdaten und den Bestelldaten aus dem Warenkorb.


6 Workflowmodelle für ePayment Verfahren 96<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Abbildung 6-31: Transaktionsdatenerfassungsprozess – M-pay


6 Workflowmodelle für ePayment Verfahren 97<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Abbildung 6-32: Autorisierungsprozess – M-pay<br />

Autorisierungsprozess<br />

Der Prozess startet mit der Übergabe der Transaktionsdaten an die m-pay-Schnittstelle, die<br />

eine Nachricht an den Zahlungsdienstleister schickt um den Zahlungspflichtigen aufzufordern<br />

einen best<strong>im</strong>mten Betrag zu reservieren.<br />

Der Zahlungspflichtige erhält vom Zahlungsdienstleister eine SMS, in der ein Bezahlcode<br />

genannt wird (nur einmal gültig) und in der der Betrag wiederholt wird. Gleichzeitig bereitet<br />

das Shopsystem eine Bildschirmmaske auf, wo der Bezahlcode einzutragen ist. Nun muss der<br />

Zahlungspflichtige auf die von m-pay erhaltene Aufforderung zur Zahlungsreservierung<br />

reagieren. Dazu gibt er den Bezahlcode ein, der anschließend an den Zahlungsdienstleister<br />

übermittelt wird. Der Zahlungsempfänger wird benachrichtigt, dass die Zahlung reserviert


6 Workflowmodelle für ePayment Verfahren 98<br />

wurde. Die erhaltene Autorisierungsantwort muss daraufhin bestätigt werden, um die<br />

Transaktion abzuschließen.<br />

6.2.7 Iclear<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Abbildung 6-33: Prozesskette – iclear<br />

Prozesskette<br />

Der Prozess startet mit der Ermittlung der relevanten Transaktionsdaten die lediglich aus dem<br />

virtuellen Warenkorb und „nur“ aus den den Händler identifizierenden Daten bestehen. Diese<br />

fließen als Inputdaten in den Autorisierungsprozess ein. Wurde die Autorisierung positiv<br />

abgewickelt, erfolgt postwendend die Belastung des Kundenkontos und die Auslieferung der<br />

Waren an die bekannt gegebene Lieferadresse. Eine negative Autorisierung führt zum<br />

Abbruch der Transaktion.<br />

Transaktionsdatenerfassungsprozess<br />

Am Anfang des Transaktionsprozesses werden alle für das Clearing relevanten Bestelldaten<br />

aus dem Warenkorb entnommen und nachfolgend mit den vom Shopsystem freigegebenen<br />

Händlerdaten ergänzt. HändlerID und das Passwort werden vom Zahlungsdienstleister<br />

vergeben und dienen zur Identifikation. ConfirmUrl ist vom Zahlungsempfänger zu belegen<br />

und steht für jene Adresse, an welche die Zahlungsbestätigung und die Lieferadresse (vom<br />

Zahlungspflichtigen) gesendet werden.


6 Workflowmodelle für ePayment Verfahren 99<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Abbildung 6-34: Transaktionsdatenerfassungsprozess – iclear<br />

Abbildung 6-35: Autorisierungsprozess – iclear


6 Workflowmodelle für ePayment Verfahren 100<br />

Autorisierungsprozess<br />

Der Autorisierungsprozess wird durch die Übernahme der Transaktionsdaten vom<br />

Shopsystem an die iclear-Schnittstelle angestoßen. Neben der Weiterleitung der<br />

Transaktionsdaten an iclear erfolgt parallel ein Redirect des Zahlungspflichtigen zur<br />

Bezahlseite von iclear. Der Zahlungspflichtige muss sich mit seinem Benutzernamen und<br />

Passwort anmelden. Hat der Server das Paar bestätigt, kann der Zahlungspflichtige mit Hilfe<br />

einer WWW-gestützten Schnittstelle alle bestellten Waren online ansehen und die Zahlung<br />

bestätigen. Damit erhält der Zahlungsempfänger die seitens von iclear registrierte<br />

Lieferadresse des Zahlungspflichtigen und das Resultat dieser Prüfung, die eine ReferenzID<br />

(dient zur eindeutigen Kennung des Bezahlvorgangs) beinhaltet.<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Abbildung 6-36: Abbuchungsprozess – iclear<br />

Abbuchungsprozess<br />

Der Zahlungsempfänger ist verpflichtet iclear mittels einer Rechnung ausgestellt auf<br />

EuroCoin iclear den Auftrag zur Abbuchung vorzulegen. Die Weiterleitung erfolgt auf<br />

elektronischem Weg (e-mail) oder per FAX. Parallel zur Weiterleitung der Rechnung muss<br />

jede autorisierte Transaktion über ein so genanntes i<strong>Commerce</strong>-Konto manuell freigegeben


6 Workflowmodelle für ePayment Verfahren 101<br />

werden, damit der Zahlungsempfänger den Forderungsbetrag auf seinem Konto<br />

gutgeschrieben bekommt.<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Abbildung 6-37: Nachrichtenfluss – iclear<br />

Nachrichtenfluss<br />

Bei einer Kaufabsicht teilt der Zahlungspflichtige dem Zahlungsempfänger seine Bestelldaten<br />

mit und gelangt über einen Redirect in das System von iclear wo er Benutzername und<br />

Passwort eingeben muss und daraufhin eine Rückmeldung zum Status der Zahlung erhält. An<br />

den Zahlungsempfänger wird neben der Autorisierungsbestätigung die Lieferadresse des<br />

Kunden geschickt worauf die Erstellung einer Rechnung an den Zahlungsdienstleister die<br />

Abwicklung der Zahlung in die Wege leitet.<br />

6.2.8 Kreditkarte SET<br />

Abbildung 6-38: Nachrichtenfluss – Kreditkarte SET


6 Workflowmodelle für ePayment Verfahren 102<br />

Nachrichtenfluss<br />

Wenn der Zahlungspflichtige eine Bezahlung veranlasst, wird die Zahlungsinformation und<br />

Bestellinformation verschlüsselt an den Zahlungsempfänger gesendet und von diesem<br />

unterschrieben an den Zahlungsdienstleister weitergeleitet. Dort erfolgt die Entschlüsselung<br />

sowie die Verifikation der Unterschrift und der Transaktionsdaten. Im positiven Fall<br />

veranlasst der Zahlungsdienstleister nach Erhalt der Zahlungsantwort den Zahlungsverkehr.<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Abbildung 6-39: Prozesskette – Kreditkarte SET<br />

Prozesskette<br />

Der Prozess startet mit der Ermittlung der relevanten Transaktionsdaten durch Interaktion mit<br />

dem Zahlungsempfängers und Zahlungspflichtigen. Kann das Ergebnis dieses Schrittes als<br />

positiv qualifiziert werden, können die Transaktionsdaten an den Autorisierungsprozess<br />

weitergereicht werden. Bei positiver Rückmeldung erfolgt die Belastung des Kundenkontos


6 Workflowmodelle für ePayment Verfahren 103<br />

und unabhängig vom Ergebnis der Autorisierung benachrichtigt der Zahlungsempfänger den<br />

Zahlungspflichtigen über seinen Auftragsstatus.<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Abbildung 6-40: Transaktionsdatenerfassungsprozess – Kreditkarte SET


6 Workflowmodelle für ePayment Verfahren 104<br />

Transaktionsdatenerfassungsprozess<br />

Der Zahlungsempfänger erhält vom Zahlungspflichtigen einen Initiierungsantrag, welcher den<br />

Kartentyp enthält der zur Zahlung benutzt werden soll. Daraufhin weist sich der<br />

Zahlungsempfänger gegenüber dem Zahlungspflichtigen mit seinem digitalen Zertifikat aus<br />

und verbindet die Initiierungsantwort mit einem eindeutigen Transaktionsidentifikator<br />

(TransID) der in weiterer Folge Bestandteil der Bestell- und Zahlungsdaten ist und zur<br />

Verknüpfung dieser dient. Anschließend übermittelt die Software vom Zahlungspflichtigen<br />

die aus der Sicht des Kunden für die Autorisierung relevanten SET-Daten, wobei die<br />

Bestelldaten vom Zahlungsempfänger nochmals verifiziert werden. Nun stellt der<br />

Zahlungsempfänger alle Transaktionsdaten zusammen, die unter anderem den Bestell-<br />

Hashwert der Bestelldaten beinhalten. Anhand dessen kann die Übereinst<strong>im</strong>mung zwischen<br />

den Händler-Bestelldaten und Käufer-Bestelldaten geprüft werden, um sicherzustellen, dass<br />

der Zahlungspflichtige für genau diese Bestellung die Zahlungsdaten zur Verfügung gestellt<br />

hat. Über die VU-Nummer werden die Transaktionen des Händlers direkt dem zuständigen<br />

Abrechnungsinstitut zugeordnet.<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Abbildung 6-41: Autorisierungsprozess – Kreditkarte SET<br />

Autorisierungsprozess<br />

Die ermittelten Transaktionsdaten aus dem Transaktionsdatenerfassungsprozess setzt der<br />

Merchant-Server über eine SSLv3-Verbindung an das Payment-Gateway ab, das alle<br />

notwendigen Überprüfungen vorn<strong>im</strong>mt, die dem Zahlungsempfänger die Kreditwürdigkeit<br />

des Zahlungspflichtigen zusichern und die Berechtigung einräumen, das Kundenkonto mit der


6 Workflowmodelle für ePayment Verfahren 105<br />

autorisierten Summe zu belasten. Ist die Prüfung positiv sendet das Payment Gateway die<br />

Antwort zusammen mit einem „Capture Token“ (Auftragsstatus) der als Referenz auf die<br />

autorisierte Transaktion dient an den Zahlungsempfänger. Der Merchant Server entschlüsselt<br />

diese Daten und speichert das Token ab, das zur späteren Abrechnung mit dem<br />

Zahlungsdienstleister benötigt wird. Der Zahlungsauftragscode ist bei der Freigabe der<br />

Transaktion (Abbuchungsprozess) anzugeben und hat keine weitere Bedeutung.<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Abbildung 6-42: Abbuchungsprozess – Kreditkarte SET


6 Workflowmodelle für ePayment Verfahren 106<br />

Abbuchungsprozess<br />

In diesem Prozess sendet der Zahlungsempfänger das erhaltene Token mit dem zu zahlenden<br />

Betrag und einem Transaction Identifier sowie einem Zahlungsauftragscode in der<br />

Zahlungsanforderungsnachricht an den Zahlungsdienstleister und gibt damit die Transaktion<br />

frei. Wenn der Zahlungsempfänger bemerkt, dass er einen Teil der Ware nicht liefern kann<br />

(Lieferdatum jünger als Abbuchungsdatum), hat er die Möglichkeit einen bereits autorisierten<br />

Betrag nach unten zu korrigieren. Die nachfolgende Zahlungsanforderung an den<br />

Zahlungsdienstleister bezieht sich mittels des enthaltenen Auftragsstatus auf die<br />

vorangegangene Autorisierungsantwort <strong>im</strong> Prozess „Autorisierung v. Kunden“ und dient zum<br />

tatsächlichen Durchführen der Transaktion <strong>im</strong> Clearingnetzwerk der Banken. Abschließend<br />

schickt der Zahlungsdienstleister eine Nachricht über den Zahlungsvollzug.<br />

6.2.9 Verified by Visa<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Abbildung 6-43: Nachrichtenfluss – KK Verified by Visa<br />

Nachrichtenfluss<br />

Der Zahlungspflichtige st<strong>im</strong>mt den Kaufskonditionen zu indem er die Kreditkartennummer<br />

dem Zahlungsempfänger mitteilt. Daraufhin initiiert der Zahlungsempfänger die Überprüfung<br />

der Kreditkartennummer durch den Zahlungsdienstleister und erhält eine URL auf die der<br />

Zahlungspflichtige weitergeleitet wird. Diesem wird ein Passworteingabebildschirm angezeigt<br />

wo er sich durch ein personalisiertes Passwort ausweist. Bei erfolgreicher Authentizität des<br />

Karteninhabers wird der Zahlungsempfänger in Kenntnis gesetzt und leitet daraufhin die<br />

erhaltene Authentifizierungsantwort zur finalen Zahlungsautorisierung an den


6 Workflowmodelle für ePayment Verfahren 107<br />

Zahlungsdienstleister weiter, der die Belastung der Kreditkarte über das geschützte<br />

Bankennetz durchführt.<br />

Abbildung 6-44: Transaktionsdatenerfassungsprozess – Kreditkarte Verified by Visa<br />

Zahlungssysteme <strong>im</strong> Internet


6 Workflowmodelle für ePayment Verfahren 108<br />

Zahlungssysteme <strong>im</strong> Internet<br />

Abbildung 6-45: Authentifizierungsprozess – Kreditkarte Verified by Visa<br />

Transaktionsdatenerfassungsprozess<br />

Am Anfang der Transaktionsdatenerfassung steht die Prüfung des Kundenprofils. Dazu<br />

verwaltet die Benutzerverwaltung die aktuellen BenutzerIDs von den angemeldeten<br />

Benutzern und ordnet über diese ID dem jeweiligen Benutzer seine gespeicherten<br />

Kundendaten zu. Ist dieses unvollständig, werden die fehlenden Daten (Kreditkartennummer<br />

und Karteninhaberadresse) vom Zahlungsempfänger angefordert. Als unvollständig kann die<br />

Angabe einer falschen oder abgelaufenen BenutzerID gelten. Der Standardfall dürfte<br />

allerdings das Fehlen einer Kreditkartennummer sein. Wird dies be<strong>im</strong> Überprüfen der<br />

Kundendaten festgestellt (Aktivität: Daten auf Vollständigkeit prüfen), obwohl der Kunde<br />

registriert ist, muss die Kreditkartennummer mittels Html-Formular abgefragt werden. Ist die<br />

erneute Prüfung erfolgreich werden die Kundendaten aktualisiert. Für Neukunden ist die<br />

Kundenprofiluntersuchung vorerst irrelevant, obwohl dessen Ergebnis nur negativ sein kann,<br />

weil das System dies als Aufforderung zur Neuaufnahme in den Kundenstamm auffasst. Der<br />

Zahlungspflichtige erfährt seine Einstufung als Neukunde und fehlende Daten<br />

(Benutzername, PWD, Kreditkartennummer und Karteninhaberadresse) werden über Eingabe<br />

mittels eines Html-Formulars abgefragt. Eine Aktualisierung der Kundendaten schließt die


6 Workflowmodelle für ePayment Verfahren 109<br />

Erfassung des Neukunden ab. Für einen schon registrierten Kunden, ein sogenannter<br />

Stammkunde, braucht das Profil nach erfolgter korrekter Identifikation nur mehr über die<br />

Benutzerverwaltung aktiviert werden. Im letzten Schritt des Prozesses erfolgt die Aggregation<br />

aller für die Autorisierung einer Kreditkartenzahlung benötigten Daten. Dazu zählen die<br />

ermittelten Kundendaten (Kreditkartennummer, Kreditinhaberadresse), die vom Shopsystem<br />

freigegebenen Händlerdaten, eine Authentisierungsbestätigung sowie alle relevanten<br />

Bestelldaten, die aus dem Warenkorb entnommen werden.<br />

Authentifizierungsprozess<br />

Die Kreditkartennummer wird direkt an den Visa Directory Server weitergeleitet der<br />

seinerseits den „Issuer Control Server“ der Kundenbank kontaktiert, um die Teilnahme an<br />

Verified by Visa zu bestätigen. Die entsprechende Rückmeldung an den Zahlungsempfänger<br />

enthält unter anderem eine URL vom „Issuer Control Server“ an die der Zahlungspflichtige<br />

nun per Redirect geführt wird. Parallel zum Browser-Redirect sendet der Zahlungsempfänger<br />

eine Authentisierungsanforderung, die eine OK-URL beinhaltet auf die der<br />

Zahlungspflichtige nach erfolgter Authentisierung zurückgeführt wird. Nachdem sich der<br />

Zahlungspflichtige durch ein Passwort authentisiert hat, erzeugt der „Issuer Control Server“<br />

(Kunden Bank) eine digital signierte Authentisierungsbestätigung für den<br />

Zahlungsempfänger.<br />

Hinweis: Der Autorisierungs- und Abbuchungsprozess laufen ident zu KK SET ab.<br />

6.3 Richtlinien für die Profilerstellung<br />

Wird ein Geschäftsmodell entworfen, so ist man permanent mit der Frage konfrontiert,<br />

welches Payment-Verfahren am besten den Anforderungen genügt. Jedes Verfahren ist<br />

gekennzeichnet durch eine Reihe von Eigenschaften. Diese müssen durch Abfrage eines<br />

Kriterienkataloges best<strong>im</strong>mt werden. Der abschließende Teil widmet sich daher zum einen<br />

der Ausarbeitung dieser Kriterien und zum anderen der Erstellung eines Profils für jedes<br />

Verfahren –so Informationen ausreichend vorhanden- anhand dieser.<br />

Folgende Kriterien werden in der Betrachtung Eingang finden:<br />

6.3.1 Plattformunabhängigkeit<br />

Durch die Einführung virtueller Maschinen und PlugIns bieten moderne Verfahren<br />

Plattformunabhängigkeit generell an. Es kann jedoch sein, dass ältere Systeme aus<br />

kostentechnischen Gründen noch <strong>im</strong>mer aktiv sind. Für diese müssen noch spezifisch<br />

angepasste Applikationen entwickelt werden, dass das elektronische Zahlungssystem<br />

unabhängig von einer best<strong>im</strong>mten Betriebssystem- oder Prozessor-Architektur lauffähig ist.<br />

6.3.2 Transaktionskosten<br />

Unterschiedliche Algorithmen schließen die Möglichkeit eines zeitlich standardisierten<br />

Datenverkehrs aus. Je nach Entwicklungsphilosophie können daher Applikationen mit höchst<br />

differierenden Zeitunterschieden <strong>im</strong> Datenverkehr entstehen. Diese müssen daher betrachtet<br />

werden, denn es st<strong>im</strong>mt nicht unbedingt, dass das zeiteffektivste Verfahren auch das<br />

Zahlungssysteme <strong>im</strong> Internet


6 Workflowmodelle für ePayment Verfahren 110<br />

günstigste ist. Zahlungsverfahren dessen Transaktionsdaten sich nur auf das Versenden<br />

relevanter Informationen beschränken, mögen eine hohe Performance besitzen, aber<br />

Datensicherheit sowohl <strong>im</strong> Sinne von Datenschutz und Verhinderung von Datenkorruption<br />

können sie nur in einen für heutigen Anforderungen nicht mehr ausreichenden Maße<br />

gewähren. Allerdings wäre ein System mit zahlreichen Sicherungs- und<br />

Kontrollmechanismen ökonomisch sowohl für den Entwickler als auch für den Anwender<br />

nicht mehr tragbar.<br />

6.3.3 Betragsl<strong>im</strong>it<br />

Es gibt billige Waren und es gibt teure Waren, daher können bei der Verkaufsabwicklung die<br />

Preise stark variieren. Eigentlich eine Banalität. Jetzt würde man annehmen, dass schon<br />

alleine wegen des finanziellen Aufwandes Payment Verfahren nur ab einem großen<br />

Zahlungsvolumen überhaupt interessant erscheinen. Zugegeben das trifft bei den meisten<br />

Zahlungsverfahren zu, dennoch und vielleicht gerade deswegen wurden aber auch<br />

Zahlungssysteme entwickelt die sich auf eine unproblematische Abwicklung geringerer<br />

Kaufpreise spezialisieren. So ist der Markt mit digitalen Gütern trotz des gewaltigen<br />

Preisabfalls der letzten Jahre eine wichtige Marktsparte für den sich einige<br />

Zahlungssystemanbieter spezialisiert haben.<br />

Zahlungsvolumen bedeutet aber nicht nur, dass der finanzielle Rahmen nach unten begrenzt<br />

sein kann sondern auch nach oben l<strong>im</strong>itiert ist. Zum einen da er für den Händler eine<br />

Sicherheit bietet Geschäftsabschlüsse mit irreal großen Geldmengen ohne größeren Aufwand<br />

zu blockieren, zum anderen aber auch die Geschäftsabwicklung in einem rational<br />

vertraulichen Rahmen bleiben kann.<br />

Für den Geschäftsmodellentwurf ist daher eine Selektion der Zahlungsverfahren nach den<br />

jeweilig garantierten Zahlungsvolumen unabdingbar. Der Softwareentwickler sollte schon in<br />

der Planungsphase Zahlungsverfahren, die für die Geschäftsabwicklung notwendigen<br />

Geldmengen nicht bearbeiten können, ausscheiden können.<br />

6.3.4 Backofficefähigkeit<br />

Spätestens seit dem Erfolg komplexer Managementsysteme, wie der deutschen Firma SAP, ist<br />

es jedem Wirtschaftstreibenden bewusst, dass ein gesamtes auf EDV-basiertes System<br />

integrativ sein muss beziehungsweise nicht mehr isoliert sein kann. Integrativ in diesem<br />

Sinne, dass sich neue Bauteile in das bestehende System einfügen lassen können und dieses<br />

auch in der Funktionalität auch erweitern. Damit ist gemeint, dass ein Payment Verfahren<br />

befähigt ist durch Aufzeichnung der Transaktionsdaten diese für weiterführende Services<br />

verwendbar zu machen. So kann zum Beispiel ein einfaches durch den Zahlungsdienstleister<br />

zur Verfügung gestelltes komma-seperiertes CSV-File zur Weiterverarbeitung <strong>im</strong> eigenen<br />

Buchhaltungssystem verwendet werden. Der Händler bekommt die Zahlungsdaten in digitaler<br />

Form ohne diese erneut manuell erfassen zu müssen, was vor allem Fehler durch Neueingabe<br />

verhindert.<br />

6.3.5 Forderungsmanagement<br />

Eines der herausstechendsten Kennzeichen der modernen sozialen Marktwirtschaft des 3.<br />

Jahrtausends ist eine derartig komplexe Differenzierung an Waren und Dienstleistungen wie<br />

sie noch vorher nie bestanden hatte. Das dadurch der Zahlungsverkehr ein hohes Bedürfnis an<br />

Automatisierung besitzt ist offensichtlich. Zur Automatisierung des Zahlungsverkehrs gehört<br />

auch die elektronische Handhabe dessen Ausfall durch Ausbleiben von Kundenforderungen.<br />

Zahlungssysteme <strong>im</strong> Internet


6 Workflowmodelle für ePayment Verfahren 111<br />

Für künftige Entwicklungen wird daher ein hohes Augenmerk auf eine möglichst umfassende<br />

vollständige Abwicklung des Debitorenwesens gelegt. Will sich ein Verfahren auf den Markt<br />

behaupten, so wird der Entwickler nicht drum herum kommen diese Faktor<br />

mitzuberücksichtigen.<br />

6.3.6 Zeitpunkt des Zahlungseingangs<br />

Allgemein gilt, je größer der transferierte Betrag pro Transaktion desto besser das Verhältnis<br />

zwischen Aufwand und Nutzen des Einsatzes des Zahlungsverfahrens. Daher sind die<br />

Anbieter bestrebt Geschäftsabwicklungen mit großen Geldsummen attraktiv zu halten,<br />

diejenigen mit kleinen Summen wirtschaftlich lukrativ. Es ist daher offensichtlich, dass für<br />

den ersten Fall der Zahlungszeitpunkt möglichst bald erfolgen muss. Im zweiten Fall eher<br />

zeitversetzt, da die Möglichkeit besteht mehrere anfallende Zahlungssummen kumuliert<br />

bearbeiten zu können.<br />

Dies gilt aber nur als Faustregel. Es haben sich aber daneben Verfahren etablieren können die<br />

aus strategischen Überlegungen heraus, die jedoch <strong>im</strong> einzelnen schwer nachvollziehbar sind,<br />

den Zahlungszeitpunkt bezüglich des Abwicklungsprozesses willkürlich festgelegt haben.<br />

Sollte bei der Modellierung des Verfahrens so ein Fall eintreten wird dieser Punkt besondere<br />

Erwähnung finden. So muss dem Entwickler bei prepaid Verfahren bewusst sein, dass sowohl<br />

der Käufer als auch der Händler einen Zinsverlust einkalkulieren müssen.<br />

6.3.7 Personalisierbarkeit<br />

Es ist eine Tatsache, dass eine möglichst umstandsfreie Bedienbarkeit einer Shopapplikation<br />

deren Attraktivität und Akzeptanz fördert. Darunter fällt vor allem eine möglichst einfache<br />

Identifizierung die eine mühsame monotone Dateneingabe ersetzt. Damit das funktioniert<br />

muss dem Kunden <strong>im</strong> Shopsystem ein hoher Grad an Personalisierung gewährleistet werden.<br />

Auf die Frage hin welche Daten ein Zahlungssystem wie von einem Kunden personalisieren<br />

kann, geben die Anbieter verschiedene Antworten. So gibt es Verfahren die von Kunden die<br />

Handynummer als Identifikationsschlüssel verlangen andere wiederum operieren mit<br />

Kreditkartennummern.<br />

Eine dritte Gruppe lässt den Händler überhaupt unberührt, da die ganzen relevanten<br />

personalisierten Daten über einen Bankserver freigegeben werden. Es ist somit offensichtlich<br />

das Personalisierbarkeit direkt von der gewählten Grundarchitektur eines Zahlungsverfahrens<br />

abhängt. Dieses Faktum muss der Softwareentwickler daher unbedingt ins Kalkül ziehen.<br />

6.3.8 Warenart<br />

Einige Verfahren sind nicht universell auf jede Form von Gütern anwendbar, da sie sich von<br />

vornherein nur für eine best<strong>im</strong>mte Marktsparte spezialisiert haben. Die wohl herausragendste<br />

Gruppe sind die Zahlungsverfahren, die nur zum Handel für digitale Güter entwickelt wurden.<br />

Sollte für ein Zahlungsverfahren solch eine Einschränkung vorliegen muss sie besonders<br />

hervorgehoben erwähnt werden, um sie zweckgerecht einsetzen zu können. Dennoch ist<br />

anzunehmen, dass der Handel mit digitalen Gütern künftig zum gesamten Marktvolumen eine<br />

höhere Gewichtung erfahren wird. Sicherlich werden bestehende Payment Verfahren für diese<br />

Art von Handel erweitert, beziehungsweise lässt die Zukunft die Entstehung komplett neuer<br />

Verfahren zu diesem Zwecke erwarten.<br />

Zahlungssysteme <strong>im</strong> Internet


6 Workflowmodelle für ePayment Verfahren 112<br />

6.3.9 Stornierbarkeit<br />

Je umfassender das Angebot eines Bezahlungsverfahrens ist desto vielseitiger sind deren<br />

Integrationsmöglichkeiten. Bietet eine solche Applikation nicht nur bloß die Möglichkeit der<br />

Geschäftsabwicklung sondern auch dessen Rückabwicklung so ist es deren Interesse ein<br />

integraler Bestandteil des gesamten Geschäftsmodells zu sein, einträglich.<br />

6.3.10 Variables Zahlungsziel<br />

Ein altes Problem vor allem bei großen Warenbestellungen ist, dass der Händler entweder<br />

nicht oder nur teilweise der Bestellanforderung <strong>im</strong> vereinbarten Zeitrahmen gerecht werden<br />

kann. Moderne Payment Verfahren können hierfür ein Alternativmanagement abseits der<br />

üblichen Stornierung mit daraus resultierenden Komplikationen anbieten. So kann durch<br />

einfache Anweisungen die Abbuchung des vollständigen Geldbetrages verhindert werden<br />

beziehungsweise mühsames abwickeln der noch ausstehenden Forderungen kann entfallen.<br />

In den folgenden Tabellen werden die vorgestellten Zahlungsverfahren zusammengefasst und<br />

auf die zuvor diskutierten Richtlinien untersucht:<br />

Kriterien<br />

Zahlungssysteme<br />

Banking Iclear Paybox Mpay<br />

Plattformunabhängigkeit ja ja ja ja<br />

Warenart Digital/Physisch Digital/Physisch Digital/Physisch Digital<br />

Backoffice Retourdatenträger - CSV-Format,<br />

EDIFACT<br />

-<br />

Zahlungszieländerung nein nein ja nein<br />

Zeitpunkt d.<br />

Zahlungseingans<br />

1 Tag 30 Tage 15 Tage 30 Tage<br />

Personalisierbarkeit nein nein ja ja<br />

Transaktionskosten 1,9 % Disagio 3,9 % 3 % – 5% mind. !<br />

+ ! 0,14 /Tx Disagio Disagio 500/mon.<br />

Stornierbarkeit nein nein ja nein<br />

Forderungsmanagement nein ja nein ja<br />

Betragsl<strong>im</strong>it ! 3.000/Tx ! 200/Tx ! 2.500/Tx ! 10/Tx<br />

Tabelle 6-2: Gegenüberstellung – Profilkriterien von Zahlungssystemen (1)<br />

Kriterien<br />

Zahlungssysteme<br />

E-Einkauf @Quick Paysafecard<br />

Plattformunabhängigkeit ja ja ja<br />

Warenart Digital/Physisch Digital/Physisch Digital/Physisch<br />

Backoffice CSV-Format CSV-Format CSV-Format<br />

Zahlungszieländerung nein nein nein<br />

Zeitpunkt d.<br />

Zahlungseingans<br />

7 Tage 1 Tag 30 Tage<br />

Personalisierbarkeit nein nein nein<br />

Transaktionskosten 2,5 % ! 449/2000 Tx 5,5 % - 35 %<br />

Disagio ! 579/4000 Tx<br />

! 999/kein L<strong>im</strong>it<br />

Disagio<br />

Stornierbarkeit nein nein ja<br />

Forderungsmanagement nein nein ja<br />

Zahlungssysteme <strong>im</strong> Internet


6 Workflowmodelle für ePayment Verfahren 113<br />

Betragsl<strong>im</strong>it ! 800/Tx ! 400/Tx ! 1.000/Tx<br />

Tabelle 6-3: Gegenüberstellung – Profilkriterien von Zahlungssystemen (2)<br />

Kriterien<br />

Zahlungssysteme<br />

KK-SET Verified by Visa<br />

Plattformunabhängigkeit ja ja<br />

Warenart Digital/Physisch Digital/Physisch<br />

Backoffice nein nein<br />

Zahlungszieländerung nein nein<br />

Zeitpunkt d.<br />

Zahlungseingans<br />

14 Tage 14 Tage<br />

Personalisierbarkeit nein ja<br />

Transaktionskosten 2,8 % Disagio+ ! 0,1 /Tx ?<br />

Stornierbarkeit ja ja<br />

Forderungsmanagement nein nein<br />

Betragsl<strong>im</strong>it min. ! 15, technisch keine<br />

Obergrenze<br />

?<br />

Tabelle 6-4: Gegenüberstellung – Profilkriterien von Zahlungssystemen (3)<br />

Zahlungssysteme <strong>im</strong> Internet


7 Referenzen 114<br />

7 Referenzen<br />

[ABR] Abrazhevich D.;Classification and characteristics of electronic payment systems 2001<br />

www.ipo.tue.nl/homepages/dabrazhe/ ps/Library/data/ecwebLNCS.pdf, Abruf am 2003-04-02<br />

[AHU97] Ahuja V.; Secure <strong>Commerce</strong> on the Internet, Academic Press, London 1997<br />

[AMO] Amor D.; Die E-Business-(R)Evolution: Das umfassende Executive-Briefing,Galileo<br />

Press GmbH, Bonn 2000<br />

[AON] Schäfer R.; Businessweb – Micropayments <strong>im</strong> Internet<br />

http://www.aon.at/jet2web/FE/LayoutTemplates/FE_Layout_bw_article/0,2531,723-0-<br />

201357-0-0,00.html, Abruf am 2003-04-02<br />

[AON1] Digital World - Professional: Online Shops ziehen Paybox vor<br />

http://www.aon.at/jet2web/FE/LayoutTemplates/FE_Layout/0,2840,100-1-305838-0,00.html<br />

Abruf am 2003-04-02<br />

[ASO] Asokan N., Janson P.; Electronic Payment Systems, IBM Zurich Research Laboratory,<br />

http://citeseer.nj.nec.com/rd/51880026%2C99448%2C1%2C0.25%2CDownload/http://citesee<br />

r.nj.nec.com/cache/papers/cs/688/http:zSzzSzwww.semper.orgzSzsirenezSzlitzSz..zSzpublzS<br />

zAJSW_96Payment.pdf/asokan96electronic.pdf, Abruf am 2003-04-02<br />

[ASO97] Asokan N., Janson P., The State of the Art in electronic Payment Systems 1997<br />

http://citeseer.nj.nec.com/rd/37588819%2C256288%2C1%2C0.25%2CDownload/http://cites<br />

eer.nj.nec.com/cache/papers/cs/11040/http:zSzzSzwww.zurich.ibm.chzSzTechnologyzSzSecu<br />

rityzSzpublicationszSz1997zSzAJSW97.pdf/asokan97state.pdf, Abruf am 2003-04-02<br />

[ASO99] State of the Art in electronic payment systems, Octobre 99<br />

http://citeseer.nj.nec.com/rd/0%2C292329%2C1%2C0.25%2CDownload/http://citeseer.nj.nec<br />

.com/cache/papers/cs/14830/http:zSzzSzwww.semper.orgzSzsirenezSzpeoplezSzasokanzSzre<br />

searchzSzac.pdf/asokan99state.pdf, Abruf am 2003-04-02<br />

[BEC] Beckert J.; Die Notwendigkeit eines sicheren Online-Bezahlsystems; HVB<br />

Luxembourg 2002,<br />

www.ti.fhg.de/trierer_symposien/digitales_geld/vortrage/Vortrag_21_06_02_beckert, Abruf<br />

am 2003-04-02<br />

[BEZ] Homepage von bezahlen.at, http://www.bezahlen.at, Abruf am 2003-04-02<br />

[BÖH] Böhle K., Riehm U.; Blütenträume – Über Zahlungssysteminnovationen und Internet-<br />

Handel in Deutschland, Institut für Technikfolgenabschätzung und Systemanalyse (ITAS),<br />

Forschungszentrum Karlsruhe GmbH, Karlsruhe 1998<br />

http://www.itas.fzk.de/deu/Itaslit/bori98a.pdf, Abruf am 2003-04-02<br />

Zahlungssysteme <strong>im</strong> Internet


7 Referenzen 115<br />

[BUR] Burnett S., Paine S.; Kryptographie – RSA Security’s Official Guide, mitp-Verlag<br />

Bonn 2001<br />

[CAM] Camp J. et al; Token and notational money in electronic commerce, Usenix Workshop<br />

on Electronic <strong>Commerce</strong>, 1995, New York<br />

http://www.ljean.com/file.html, Abruf am 2003-04-02<br />

[CHA] Chaum D.; Achieving Electronic Privacy, Scientific American 1992<br />

http://ntrg.cs.tcd.ie/mepeirce/Project/Chaum/sciam.html, Abruf am 2003-04-02<br />

[COU] Coulouris G., Doll<strong>im</strong>ore J., Kindberg T.; Distributed Systems: concepts and design,<br />

3. editon, Addison-Wesley 2001<br />

[DIE] Diederich B. et al; Mobile Business: Märkte, Techniken, Geschäftsmodelle,<br />

Betriebswirtschaftlicher Verlag Dr. Th. Gabler GmbH, Wiesbaden 2001<br />

[ECI1] Bezahlvorgänge be<strong>im</strong> Online-Shopping werden sicherer,<br />

http://www.ecin.de/news/2002/05/15/04290/, Abruf am 2003-04-02<br />

[ENG] Engel, A., Lessig, A.; Elektronische Zahlungsmittel <strong>im</strong> Internet, Übersicht und<br />

Bewertung aktueller Verfahren unter Berücksichtigung von Kriterien der Sicherheit und<br />

Funktionalität, Studienarbeit am Fachbereich Informatik, Universität Hamburg, Dezember<br />

1997<br />

[FUH] Fuhrberg K., Häger D., Wolf S.; Internet-Sicherheit: Browser, Firewalls und<br />

Verschlüsselung; 3. aktualisierte und erweiterte Auflage, Hanser Verlag München,Wien 2001<br />

[FUR] Furche A., Wrightson G.; Computer Money – Zahlungssysteme <strong>im</strong> Internet, dpunkt<br />

Verlag, Heidelberg 1997<br />

[GOR] Gora W., et al.; Handbuch electronic commerce : Kompendium zum elektronischen<br />

Handel mit 19 Tabellen, 2. überarbeitete Auflage, Springer, Berlin 2001<br />

[HIM] H<strong>im</strong>melspach A. et al; Anforderungen an elektronische Zahlungssysteme; Universität<br />

St. Gallen, Hochschule für Wirtschafts-, Rechts- und Sozialwissenschaften, Institut für<br />

Wirtschaftsinformatik 1996<br />

[HEN01] Henkel J.; Bezahlen auf Draht – E-Payment: Wie der Rubel ins Rollen kommt,<br />

c’t 6/2001, Heise Verlag, Hannover<br />

[ICL] iclear Homepage: http://www.iclear.de, Abruf am 2003-04-02<br />

[ILL] Illik J.; Electronic <strong>Commerce</strong> : Grundlagen und Technik für die Erschließung<br />

elektronischer Märkte - 2., vollst. überarb. Aufl., Verlag Oldenbourg, München 2002<br />

[IZV] Umfrage zu Zahlungsmittel <strong>im</strong> Internet, Institut für Wirtschaftspolitik und<br />

Wirtschaftsforschung der Universität Karlsruhe; http://www.iww.uni-karlsruhe.de/izv4/,<br />

Zahlungssysteme <strong>im</strong> Internet


7 Referenzen 116<br />

Abruf am 2003-04-02<br />

[KON] Zahlungssysteme <strong>im</strong> Internet, http://www.inf-wiss.uni-konstanz.de/ CURR/<br />

summer98/<strong>im</strong>k/Internet-Zahlungssysteme/zahlungssysteme.html, Abruf am 2003-04-02<br />

[KET] Ketterer K., Stroborn K.; Handbuch ePayment: Zahlungsverkehr <strong>im</strong> Internet; Systeme,<br />

Trends und Perspektiven; Köln, Dt. Wirtschaftsdienst 2002<br />

[KÖH] Köhler T., Best R.; Electronic <strong>Commerce</strong> – Konzipierung, Realisierung und Nutzung<br />

<strong>im</strong> Unternehmen, 2. Auflage, Addison-Wesley, München 2000<br />

[LEE] Manho Lee, Kwangjo K<strong>im</strong>; A Micro-payment System for Multiple-Shopping, 2002<br />

http://caislab.icu.ac.kr/paper/2002/lmh/scis2002.pdf, Abruf am 2003-04-02<br />

[LEP] Lepschies G.; E-<strong>Commerce</strong> und Hackerschutz: Leitfaden für die Sicherheit<br />

elektronischer Zahlungssysteme; 2. überarbeitete Auflage,Vieweg-Verlag, Wiesbaden 2000<br />

[LUK] Lukas, S.; Cyber Money: Künstliches Geld <strong>im</strong> Internet und Elekronischen Geldbörsen,<br />

Luchterhand 1997<br />

[MAN] Manninger M. et al; Electronic <strong>Commerce</strong> – Die Technik: Technologie, Design und<br />

Implementierung, Verlag Hüthig, Heidelberg 2001<br />

[MER02] Merz M.; E-<strong>Commerce</strong> und E-Business, dpunkt Verlag, 2. aktualisierte und<br />

erweiterte Auflage, Heidelberg 2002<br />

[MEZ96] Merz M.; Elektronische Märkte <strong>im</strong> Internet, 1. Auflage, Bonn 1996<br />

[NET] Netpay Homepage: Überblick und Funktionsweise, http://www.netpay.at,<br />

Abruf am 2003-04-02<br />

[PAY1] Paybox Austria AG, paybox BASIC Service – Whitepaper, 2001<br />

www.paybox.at/files/paybox_whitepaper_BASIC_Service_April_2001.pdf,<br />

Abruf am 2003-04-02<br />

[PAY2] Paybox Austria AG, paybox STANDARD Service – Whitepaper, 2001<br />

www.paybox.at/files/paybox_whitepaper_STANDARD_Service_April_2001.pdf,<br />

Abruf am 2003-04-02<br />

[PAY3] Paybox Austria AG, paybox PREMIUM Service – Whitepaper, 2001<br />

www.paybox.at/files/paybox_whitepaper_PREMIUM_Service_April_2001.pdf,<br />

Abruf am 2003-04-02<br />

[PER] Pernul G.; Neuer Markt – neues Geld?, Aus: Wirtschaftsinformatik 4/97; Vieweg<br />

Verlag, Wiesbaden 1997<br />

Zahlungssysteme <strong>im</strong> Internet


7 Referenzen 117<br />

[PDT] Internetanwendungen mit Chipkarten: @Quick Standard Pay und Mini Pay,<br />

http://www.pdts.at/produkte/default.asp?n=1, Abruf 2003-04-02<br />

[PSC] paysafecard Homepage: http://www.paysafecard.com/at/de/, Abruf am 2003-04-02<br />

[RAE] Raepple, M.; „Sicherheitskonzepte für das Internet: Grundlagen, Technologien und<br />

Lösungskonzepte für die kommerzielle Nutzung“, dpunkt.Verlag, 2. Auflage,Heidleberg 2001<br />

[REI] Reiser C.; Internet - die Sicherheitsfragen: Antworten für Manager und Techniker,<br />

Wirtschaftsverlab Ueberreuter, Frankfurt/Wien 2000<br />

[RUB] Rubin A.; Hackerabwehr und Datensicherheit: Angriff. Diagnose. Abwehr; Addison-<br />

Wesley, München 2002<br />

[ROB] Robben M.; Bonus durch Bonitätsprüfung & Co.,<br />

http://www.ecin.de/zahlungssysteme/bonitaet/, Abruf am 2003-04-02<br />

[ROB1] Robben M.; Paid Content: Wer soll das bezahlen ...?<br />

http://www.ecin.de/state-of-the-art/paidcontent/, Abruf am 2003-04-02<br />

[SCH] Schuster R. et. al.; „Digital Cash: Zahlungssysteme <strong>im</strong> Internet“, Springer Verlag,<br />

Heidelberg 1997<br />

[SCHI] Schier K.; Sicherheit für multifunktionale Chipkarten: Ein Modell für den<br />

elektronischen Zahlungsverkehr; Knapp Verlag, Frankfurt am Main 2000<br />

[SHA] Shaw M., et. al; Handbook on electronic commerce, Verlag Springer, Berlin 2000<br />

[SIL] Silberer G. et al; Mobile <strong>Commerce</strong>: Grundlagen, Geschäftsmodelle, Erfolgsfaktoren<br />

Gabler Verlag, Wiesbaden 2001<br />

[SIE] Sietmann R.; Electronic Cash: Der Zahlungsverkehr <strong>im</strong> Internet, Schäffer-Poeschesl<br />

Verlag, Stuttgart 1997<br />

[STO] Stolpmann M.; Elektronisches Geld <strong>im</strong> Internet: Grundlagen, Konzepte, Perspektiven,<br />

1. Auflage, O’Reilly Verlag, Köln 1997<br />

[TEI] Teichmann R., E-<strong>Commerce</strong> und E-Payment: Rahmenbedingungen, Infrastruktur,<br />

Perspektiven, 1. Auflage Wiesbaden Gabler 2001<br />

[VISA] SET Secure Electronic Transaction Specificatin – Book 1: Business Description<br />

http://www.setco.org/download/set_bk1.pdf, Abruf am 2003-04-02<br />

[VISA1] Informationen über Ablauf von Verified by Visa<br />

http://www.visaeu.com/press_media/factsheets/3d_secure.html, Abruf am 2003-04-02<br />

[VOD] Vodafone D2 Homepage: http://www.vodafone.de/start.html, Abruf am 2003-04-02<br />

Zahlungssysteme <strong>im</strong> Internet


7 Referenzen 118<br />

[WEB1] Weber, Rolf H.; Elektronisches Geld: Erscheinungsformen und rechtlicher<br />

Problemaufriss, Schulthess Polygraphischer Verlag, Zürich 1999<br />

[WEB] Weber R.; Chablis – Market analysis of digital payment systems, Institut für<br />

Informatik, Technische Universität München 1998<br />

www.cg.cs.tu-bs.de/v3d2/pubs/chablis-marktanalyse.pdf, Abruf am 2003-04-02<br />

[WWW] Webshop-Monitor November 2002; http://www.e-rating.at/download/web-shopmonitor.diagramme-07.pdf,<br />

Abruf am 2003-04-02<br />

[ZDN] Fiutak M.; CeBIT: Paybox präsentiert Handy-Geldautomat,<br />

http://news.zdnet.de/story/0,,t101-s2106604,00.html, Abruf am 2003-04-02<br />

Zahlungssysteme <strong>im</strong> Internet

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!