GICC
GICC ( General ISO 8583 Credit Card Protocol) is a protocol for cashless payment processing, mainly with credit cards . It is based on ISO 8583 and is therefore related to the ZVT protocol , which is also used for POZ and ec-cash .
Dissemination and acceptance
The protocol is only used in Germany. Exceptions are some cross-border transactions at dealer branches in neighboring countries. The network operators or acquirers are still based in Germany.
GICC was developed in a joint collaboration between American Express, B + S Card Service GmbH, ConCardis and Elavon Merchant Services. It is accordingly supported by all of these societies. However, minimal leeway in the protocol standard can mean that a GICC-compliant terminal does not necessarily work immediately with all acquirers.
GICC is relatively widespread, especially in areas that are traditionally heavily credit card oriented (e.g. car rentals, hotels, travel agencies). At retailers you can often find POZ / ec-cash and GICC installations in parallel, or just pure POZ solutions, as credit card payments can usually also be processed via POZ protocols (depending on the network operator).
features
The GICC protocol offers special functions that go beyond pure payment. There are functions for pre-authorizing an amount. A limit reservation is made for the credit card in question. This pre-authorized amount can be topped up later if necessary and then finally authorized (and thus paid). The advantage is that the retailer already receives an authorization code and thus the later redemption of the amount is guaranteed. Nevertheless, the credit card remains uncharged for the time being. Only the available limit is reduced by the pre-authorized amount.
This is z. B. used by car rental companies who pre-authorize a lump sum as security and charge the actual price after the car has been returned. Another example is internet shipping: The amount is pre-authorized and the order is thus successfully completed. But the amount will only be finally charged when the goods are dispatched. A pre-authorization usually remains valid for approx. 7 days (depending on the acquirer).
GICC can work in both booking and authorization operations. In the pure authorization operation, the authorized payments are not automatically initiated into clearing. Instead, the merchant must regularly (generally daily) submit a file with the authorized payments. When booking, all payments are also saved by the acquirer or network operator (so-called capturing). They do not have to be submitted again, but are automatically initiated into the clearing by a daily closing.
disadvantage
GICC is a terminal-oriented procedure. This means that each terminal that can submit payments must be administered by the network operator / acquirer. Even with a large number of terminals (cash registers in retail stores), a not inconsiderable expense arises for dealers or service partners. Especially since flexible terminals can often route different types of cards to different network operators. Here, all terminals per network operator are to be registered, administered and given parameters.
This disadvantage is noticeable with software terminals, especially with providers of payments on the Internet. Although there are no physical terminals here, a certain pool of terminal numbers must be requested and set up, as no payment can be processed without a valid terminal number.
GICC was specified as a terminal-to-host protocol. But it is also used for host-to-host connections. The KAAI (Key Accounts Authorization Interface), which is related to the GICC protocol, exists in the backend area for the connections from host to host. The main difference to GICC is that while KAAI supports fewer message types, it does not require terminal ID numbers.