International Finance Bank LTD

Transfers to your Accounts and payments of upfront Fees to IFB/IFC per Credit Card

How do credit cards actually work?

The processes involved in a credit card transaction are pretty complex, involving multiple parties and layers of communication. 

Process

Here is a detailed explanation of how these protocols and standards work together:

  1. Initiation: A cardholder initiates a transaction by either swiping, dipping, or tapping their card on a POS terminal or entering their card details for an online transaction.
  2. Data transmission: The POS terminal or e-commerce gateway captures the transaction details, including the card number, expiry date, transaction amount, and a unique transaction identifier. For EMV transactions, the chip generates a unique cryptogram for each transaction.
  3. Tokenization (optional): If tokenization is enabled, the card data is replaced with a unique token before transmission. This helps protect sensitive card information during the transaction process.
  4. Authorization request: The transaction details are formatted according to the ISO 8583 messaging standard and sent by the merchant's acquiring bank (or payment processor) to the card network (e.g., Visa or Mastercard).
  5. Card network routing: The card network identifies the issuing bank responsible for the card and forwards the authorization request to the issuer.
  6. Issuer processing: The issuing bank checks the transaction details against the cardholder's account, verifying the available balance, card status, and any applicable fraud rules. For online transactions using 3D Secure, the issuer may also prompt the cardholder to authenticate the transaction with a password or biometric data.
  7. Authorization response: The issuing bank generates an authorization response, which may approve or decline the transaction. This response is sent back through the card network to the acquiring bank (or payment processor), and then back to the merchant.
  8. Completion: If the transaction is approved, the merchant completes the sale and provides the goods or services to the cardholder. The transaction details are then included in a batch of transactions that the merchant submits to the acquiring bank (or payment processor) for settlement.
  9. Settlement: The acquiring bank (or payment processor) submits the transaction batch to the card network for settlement. The card network calculates the net settlement amounts between the acquiring and issuing banks, and the funds are transferred accordingly. Finally, the issuing bank posts the transaction to the cardholder's account, and the cardholder receives a statement with the transaction details.


Throughout this process, the various parties involved must adhere to the PCI DSS requirements to ensure the secure handling of cardholder data. Additionally, the communication between the entities is encrypted to maintain the confidentiality and integrity of the transaction data.

4 or 6 Digit PINs

Generally, PINs are 4-digit codes, but in some regions or financial institutions, 6-digit PINs may also be used. The primary purpose of a PIN is to verify that the person initiating the transaction is the authorized cardholder.

In the context of a credit card transaction, a customer may be prompted to enter their PIN when using a chip-and-PIN card at a POS terminal. This is more common in some regions, like Europe, while other regions, like the United States, primarily use chip-and-signature cards that require a signature instead of a PIN.


Here is how a PIN, either 4-digit or 6-digit, is used in a transaction:

  1. The customer inserts their chip-and-PIN card into the POS terminal.
  2. The terminal prompts the customer to enter their PIN.
  3. The customer enters their PIN, which is then encrypted by the POS terminal.
  4. The encrypted PIN is sent along with the transaction data to the issuing bank for verification.
  5. The issuing bank compares the encrypted PIN with the one stored in their system. If the PINs match, the transaction is authorized.


In some cases, the PIN is verified locally by the card's chip instead of being sent to the issuer. This is known as Offline PIN verification, and it can speed up the transaction process.

It is important to note that the PIN is not the same as the 3 or 4 digit Card Verification Value (CVV) or Card Verification Code (CVC) found on the back of the card. CVV/CVC codes are used for card-not-present transactions, like online purchases, to verify that the person making the transaction has physical possession of the card.


Protocols and Processes

When a credit card transaction occurs, several protocols and processes are used to check the amount to be charged and to authorize the transaction. 

Some of the key components involved in the process are:

  1. ISO 8583: A messaging standard used by most payment networks, such as Visa and Mastercard, to communicate transaction details between different entities involved in the process (e.g., merchants, acquirers, issuers, and payment processors).
  2. EMV (Europay, Mastercard, Visa): A global standard for chip-based credit and debit card transactions. EMV cards have an embedded microprocessor chip that provides enhanced security by encrypting transaction data and generating unique authentication codes for each transaction. EMV compliance is important for reducing card-present fraud.
  3. PCI DSS (Payment Card Industry Data Security Standard): A set of security standards designed to protect cardholder data and ensure the secure processing, storage, and transmission of card information. All merchants, payment processors, and other entities handling card data must comply with PCI DSS requirements.
  4. Tokenization: A process that replaces sensitive card data (like the card number) with a unique token, ensuring that the actual card data is not exposed during a transaction. This helps to reduce the risk of data breaches and fraudulent transactions.
  5. 3D Secure (e.g., Verified by Visa, Mastercard SecureCode): An additional layer of security for online (card-not-present) transactions. It requires the cardholder to authenticate the transaction by entering a password or using biometric data, thus reducing the risk of unauthorized use.


These protocols and standards work together to ensure that credit card transactions are secure, and that the appropriate amount is charged to the cardholder's account.

The communication between the POS (Point of Sale) terminal and the card network routing involves several steps and utilizes various protocols and technologies. 

Data Communication

Here's a summary of how the communication takes place:

  1. Data capture: When a cardholder initiates a transaction, the POS terminal captures the card information (card number, expiry date, CVV, etc.) by swiping, dipping, tapping, or manually entering the card details.
  2. Secure transmission: The captured card data is securely transmitted from the POS terminal to the merchant's acquiring bank or payment processor. This transmission typically uses the TLS (Transport Layer Security) protocol, which encrypts the data to ensure its confidentiality and integrity during transmission.
  3. ISO 8583 messaging: The acquiring bank or payment processor formats the transaction data according to the ISO 8583 messaging standard. This standard defines the structure and content of the messages exchanged between the different entities involved in the transaction process, such as merchants, acquirers, issuers, and card networks.
  4. Communication with card networks: The acquiring bank or payment processor sends the ISO 8583-formatted authorization request to the card network (e.g., Visa, Mastercard) via dedicated communication channels. These channels are typically private networks that securely connect the different parties involved in the transaction process.
  5. Card network routing: The card network identifies the issuing bank responsible for the card and forwards the authorization request to the issuer. The card network may use additional communication protocols and technologies, such as TCP/IP and VPNs (Virtual Private Networks), to ensure secure and reliable transmission of the transaction data.


Throughout the communication process, multiple layers of security are employed, including encryption, secure protocols, and adherence to industry standards like PCI DSS. This ensures the confidentiality, integrity, and availability of the transaction data as it moves from the POS terminal to the card network routing and beyond.

ISO 8583

ISO 8583 is a messaging standard used for financial transaction communication, particularly for payment card transactions. It defines the message format, data elements, and processing codes required for exchanging transaction information between different entities, such as merchants, acquirers, issuers, and card networks.

An ISO 8583-formatted authorization request contains various data elements organized in a structured message format. The message is composed of a Message Type Identifier (MTI), Bitmaps, and Data Elements.


Here's a simplified example of an ISO 8583 authorization request message:

  1. Message Type Identifier (MTI): A 4-digit numeric code representing the message's purpose. For an authorization request, the MTI is usually "0100" or "0110".
  2. Bitmaps: A series of bits (usually 64 bits or sometimes 128 bits) indicating which Data Elements are present in the message. Each bit in the bitmap corresponds to a specific data element.
  3. Data Elements: The actual transaction information, organized into fields numbered from 1 to 128. Each data element has a specific meaning and format, such as numeric, alphanumeric, or binary.


Dataelements

Here's an example of some common Data Elements in an ISO 8583 authorization request:

  • DE 2: Primary Account Number (PAN) - The card number used for the transaction.
  • DE 3: Processing Code - A 6-digit code specifying the transaction type (e.g., purchase, refund) and the account to be used (e.g., checking, credit).
  • DE 4: Transaction Amount - The transaction amount, typically represented as a 12-digit numeric value with implied decimal point.
  • DE 7: Transmission Date and Time - The date and time the transaction was initiated, usually in the format YYMMDDhhmmss.
  • DE 11: System Trace Audit Number (STAN) - A unique transaction identifier generated by the terminal or payment system.
  • DE 22: Point of Service Entry Mode - A code indicating how the card data was captured (e.g., swiped, chip read, manual entry).
  • DE 25: Point of Service Condition Code - A code representing specific conditions related to the transaction (e.g., customer present, e-commerce).
  • DE 41: Card Acceptor Terminal Identification - A unique identifier for the POS terminal.
  • DE 42: Card Acceptor Identification Code - A unique identifier for the merchant or card acceptor.
  • DE 49: Currency Code, Transaction - A 3-digit code representing the currency used for the transaction.


In the context of the ISO 8583 financial messaging standard, the term "MTI" stands for Message Type Identifier. It is a 4-digit numeric code that represents the message's purpose and is the first field in an ISO 8583 message.

MTI

The MTI is composed of 4 positions (each having a range of 0-9) with the following meanings:

  1. Version (first position): Indicates the ISO 8583 version used for the message.
    • 0: ISO 8583:1987
    • 1: ISO 8583:1993
    • 2: ISO 8583:2003
    • 3-9: Reserved for future use or custom versions
  2. Class (second position): Represents the message's primary purpose.
    • 0: Reserved for ISO use
    • 1: Authorization
    • 2: Financial transactions (e.g., cash withdrawal, balance inquiry)
    • 3: File actions (e.g., file updates)
    • 4: Reversal and chargeback
    • 5: Reconciliation
    • 6: Administrative
    • 7: Fee collection
    • 8: Network management
    • 9: Reserved for ISO use
  3. Function (third position): Specifies the message's specific function.
    • 0: Request
    • 1: Request response
    • 2: Advice
    • 3: Advice response
    • 4: Notification
    • 5: Notification acknowledgment
    • 6-9: Reserved for ISO use
  4. Origin (fourth position): Indicates the message initiator.
    • 0: Acquirer
    • 1: Acquirer repeat
    • 2: Issuer
    • 3: Issuer repeat
    • 4-9: Reserved for ISO use


Some examples of MTIs in ISO 8583 messages:

  • 0100: Authorization Request
  • 0110: Authorization Response
  • 0200: Financial Transaction Request
  • 0210: Financial Transaction Response
  • 0420: Reversal Request
  • 0421: Reversal Request Repeat
  • 0430: Reversal Response
  • 0500: Acquirer Reconciliation Request
  • 0510: Acquirer Reconciliation Response
  • 0800: Network Management Request
  • 0810: Network Management Response


Please note that these examples are based on the standard ISO 8583 message types. However, individual implementations and customizations may exist based on the specific requirements of different payment systems or financial institutions.