GICC

GICC (German ISO 8583 Credit Card-Protokoll) ist ein Protokoll zur bargeldlosen Zahlungsabwicklung mit Kreditkarte. Es baut auf ISO 8583 auf, und ist damit auch dem ZVT-Protokoll verwandt, welches auch bei POZ und ec-cash verwendet wird.

Verbreitung und Akzeptanz

Das Protokoll wird nur in Deutschland eingesetzt. Ausnahmen sind einige Cross-Border-Abwicklungen bei Händlerfilialen in Nachbarländern. Die Netzbetreiber bzw. Acquirer sitzen dabei trotzdem in Deutschland.

GICC wurde in gemeinsamer Zusammenarbeit von American Express, B+S Card Service GmbH, ConCardis und Elavon Merchant Services entwickelt. Es wird entsprechend auch von allen diesen Gesellschaften unterstützt. Minimale Auslegungsspielräume im Protokollstandard können allerdings dazu führen, dass ein GICC-konformes Terminal nicht zwingend sofort bei allen Acquirern funktioniert.

GICC ist relativ weit verbreitet, insbesondere in Bereichen, die traditionell stark kreditkartenorientiert sind (z. B. Autovermietungen, Hotels, Reisebüros). Bei Einzelhändlern findet man oft POZ/ec-cash- und GICC-Installationen parallel, oder nur reine POZ-Lösungen, da Kreditkartenzahlungen meistens auch über POZ-Protokolle abgewickelt werden können (je nach Netzbetreiber).

Merkmale

Das GICC-Protokoll bietet spezielle Funktionen, die über das reine Bezahlen hinausgehen. Es gibt Funktionen zur Vorautorisierung eines Betrages. Hierbei findet eine Limitreservierung für die betreffende Kreditkarte statt. Dieser vorautorisierte Betrag kann später noch ggf. aufgestockt und dann schließlich endgültig autorisiert (und damit bezahlt) werden. Vorteil ist, dass der Händler bereits einen Autorisierungscode erhält und somit die spätere Einlösung des Betrages garantiert ist. Trotzdem bleibt die Kreditkarte vorerst unbelastet. Nur das verfügbare Limit wird um den vorautorisierten Betrag verringert.

Dies wird z. B. von Autovermietungen genutzt, die einen Pauschalbetrag als Sicherheit vorautorisieren und nach Rückgabe des Wagens den tatsächlichen Preis belasten. Ein anderes Beispiel ist der Internetversand: Der Betrag wird vorautorisiert und damit die Bestellung erfolgreich beendet. Aber erst bei Versand der Ware wird der Betrag endgültig belastet. Eine Vorautorisierung bleibt meistens ca. 7 Tage gültig (abhängig vom Acquirer).

GICC kann sowohl im Buchungs- als auch im reinen Autorisierungsbetrieb arbeiten. Beim reinen Autorisierungsbetrieb werden die autorisierten Zahlungen nicht automatisch ins Clearing eingeleitet. Der Händler muss stattdessen regelmäßig (im Allgemeinen täglich) eine Datei mit den autorisierten Zahlungen anliefern. Beim Buchungsbetrieb werden alle Zahlungen auch beim Acquirer bzw. Netzbetreiber gespeichert (sog. Capturing). Sie müssen also nicht noch einmal eingereicht werden, sondern werden durch einen Tagesabschluss automatisch ins Clearing eingeleitet.

Nachteile

GICC ist ein terminalorientiertes Verfahren. Dies bedeutet, dass beim Netzbetreiber/Acquirer jedes Terminal, welches Zahlungen einreichen kann, administriert werden muss. Auch beim Händler bzw. Servicepartner entsteht bei einer großen Anzahl von Terminals (Kassen im Einzelhandel) ein nicht unerheblicher Aufwand. Dies insbesondere, da flexible Terminals oft verschiedene Kartentypen an verschiedene Netzbetreiber routen können. Hierbei sind pro Netzbetreiber alle Terminals anzumelden, zu administrieren und mit Parametern zu versehen.

Auffällig wird dieser Nachteil bei Softwareterminals, insbesondere bei Anbietern für Zahlungen im Internet. Obwohl es hier physisch gar keine Terminals gibt, muss ein gewisser Pool an Terminalnummern beantragt und eingerichtet werden, da ohne gültige Terminalnummer keine Zahlung abgewickelt werden kann.

GICC ist als reines Terminal-to-Host Protokoll spezifiziert. Im Backendbereich existiert für die Verbindungen von Host zu Host das dem GICC-Protokoll verwandte KAAI. Der Hauptunterschied zu GICC ist, dass KAAI zwar weniger Nachrichtentypen unterstützt, jedoch keine Terminal-ID-Nummern benötigt.