Credit Card Transfers to your Accounts with us

Now you can transfer funds of any magnitude to your accounts with us, in IFC or IFB, sourced from a broad range of credit or prepaid card systems. This includes globally recognized providers such as Visa, Mastercard, American Express, Diners, Union Pay, Discover, among others. 

Impressively, this process can be completed utilizing any transaction protocol, eliminating the necessity for a physical terminal. This seamless digital infrastructure in the cloud facilitates secure and convenient fund transfers from virtually anywhere.

Credit Card transfer to your accounts with us 

  • in your local currency


Other Currencies

And for any other currency, please contact us, we will probably be able to create a custom made link for you:

  • AED - United Arab Emirates Dirham
  • AFN - Afghan Afghani
  • ALL - Albanian Lek
  • AMD - Armenian Dram
  • ANG - Netherlands Antillean Guilder
  • AOA - Angolan Kwanza
  • ARS - Argentine Peso
  • AUD - Australian Dollar
  • AWG - Aruban Florin
  • AZN - Azerbaijani Manat
  • BAM - Bosnia-Herzegovina Convertible Mark
  • BBD - Barbadian Dollar
  • BDT - Bangladeshi Taka
  • BGN - Bulgarian Lev
  • BIF   - Burundian Franc
  • BMD - Bermudan Dollar
  • BND - Brunei Dollar
  • BOB - Bolivian Boliviano
  • BRL - Brazilian Real
  • BSD - Bahamian Dollar
  • BWP - Botswanan Pula
  • BYN - Belarusian Rouble
  • BZD - Belize Dollar
  • CAD - Canadian Dollar
  • CDF - Congolese Franc
  • CHF - Swiss Franc
  • CLP - Chilean Peso
  • CNY - Chinese Yuan
  • COP - Colombian Peso
  • CRC - Costa Rican Colón
  • CVE - Cape Verdean Escudo
  • CZK - Czech Koruna
  • DJF - Djiboutian Franc
  • DKK - Danish Krone
  • DOP - Dominican Peso
  • DZD - Algerian Dinar
  • EGP - Egyptian Pound
  • ETB - Ethiopian Birr
  • FJD - Fijian Dollar
  • FKP - Falkland Islands Pound
  • GEL - Georgian Lari
  • GIP  - Gibraltar Pound
  • GMD - Gambian Dalasi
  • GNF - Guinean Franc
  • GTQ - Guatemalan Quetzal
  • GYD - Guyanaese Dollar
  • HKD - Hong Kong Dollar
  • HNL - Honduran Lempira
  • HRK - Croatian Kuna
  • HTG - Haitian Gourde
  • HUF - Hungarian Forint
  • IDR  - Indonesian Rupiah
  • ISK  - Icelandic Króna
  • JMD - Jamaican Dollar
  • KES - Kenyan Shilling
  • KGS - Kyrgystani Som
  • KHR - Cambodian Riel
  • KMF - Comorian Franc
  • KRW - South Korean Won
  • KYD - Cayman Islands Dollar
  • KZT - Kazakhstani Tenge
  • LAK - Laotian Kip
  • LBP - Lebanese Pound
  • LKR - Sri Lankan Rupee
  • LRD - Liberian Dollar
  • LSL - Lesotho Loti
  • MAD - Moroccan Dirham
  • MDL - Moldovan Leu
  • MGA - Malagasy Ariary
  • MKD - Macedonian Denar
  • MMK - Myanmar Kyat
  • MNT - Mongolian Tugrik
  • MOP - Macanese Pataca
  • MRO - Mauritanian Ouguiya (1973–2017)
  • MUR - Mauritian Rupee
  • MVR - Maldivian Rufiyaa
  • MWK - Malawian Kwacha
  • MXN - Mexican Peso
  • MYR - Malaysian Ringgit
  • MZN - Mozambican Metical
  • NAD - Namibian Dollar
  • NGN - Nigerian Naira
  • NIO  - Nicaraguan Córdoba
  • NOK - Norwegian Krone
  • NPR - Nepalese Rupee
  • NZD - New Zealand Dollar
  • PAB - Panamanian Balboa
  • PEN - Peruvian Sol
  • PGK - Papua New Guinean Kina
  • PHP - Philippine Piso
  • PKR - Pakistani Rupee
  • PLN - Polish Zloty
  • PYG - Paraguayan Guarani
  • QAR - Qatari Rial
  • RON - Romanian Leu
  • RSD - Serbian Dinar
  • RWF - Rwandan Franc
  • SBD - Solomon Islands Dollar
  • SCR - Seychellois Rupee
  • SEK - Swedish Krona
  • SGD - Singapore Dollar
  • SHP - St Helena Pound
  • SLE - Sierra Leonean Leone
  • SOS - Somali Shilling
  • SRD - Surinamese Dollar
  • STD - São Tomé & Príncipe Dobra (1977–2017)
  • SZL - Swazi Lilangeni
  • TJS - Tajikistani Somoni
  • TOP - Tongan Paʻanga
  • TTD - Trinidad & Tobago Dollar
  • TWD - New Taiwan Dollar
  • TZS - Tanzanian Shilling
  • UAH - Ukrainian Hryvnia
  • UGX - Ugandan Shilling
  • UYU - Uruguayan Peso
  • UZS - Uzbekistani Som
  • VND - Vietnamese Dong
  • VUV - Vanuatu Vatu
  • WST - Samoan Tala
  • XAF - Central African CFA Franc
  • XCD - East Caribbean Dollar
  • XOF - West African CFA Franc
  • XPF - CFP Franc
  • YER - Yemeni Rial
  • ZAR - South African Rand
  • ZMW - Zambian Kwacha

Differences between Credit and Debit Cards

The differences between debit and credit cards are significant, and it's important to understand each one's functionalities and impact.

Here's a more detailed explanation:

  1. Source of funds: This is the most fundamental difference between the two.
    • Debit Card: When you use a debit card, the money is directly taken from your linked checking account almost instantly. It's like electronic cash - you're using your own money that you already have in your bank account.
    • Credit Card: On the other hand, a credit card is essentially a line of credit or loan provided by the card issuer. When you make a transaction with a credit card, the card issuer pays for the transaction. You're borrowing money with the promise that you'll repay it either in full or over time.
  2. Impact on Credit Score:
    • Debit Card: Debit card usage has no impact on your credit score because you're not borrowing money. It's the equivalent of paying with cash or a check.
    • Credit Card: Credit card usage, on the other hand, directly impacts your credit score. The amount of credit you use relative to your credit limit (credit utilization ratio), your payment history, and the length of your credit history, among other factors, can either positively or negatively impact your credit score.
  3. Protection Against Fraudulent Charges:
    • Debit Card: Debit cards offer fewer protections than credit cards. If your debit card is lost or stolen, the maximum liability could be all the money in your account, depending on how long it takes you to report the loss.
    • Credit Card: Credit cards come with stronger protections. Under federal law in the United States, your maximum liability for unauthorized use of your credit card tops out at $50.
  4. Fees and Interest:
    • Debit Card: Debit cards don't typically come with any form of interest because you're spending your own money. However, they may come with various fees like overdraft or transaction fees.
    • Credit Card: Credit cards often have high interest rates for unpaid balances after your due date, and they may also come with an array of fees such as annual fees, late payment fees, and cash advance fees.

Understanding these differences can help you make informed decisions about when to use each type of card and how to use them responsibly.

Where are the funds lodged with prepaid cards in contrast to credit and debit cards?

Prepaid Cards

Funds on prepaid cards are stored directly on the bank of the issuer of the credit card itself and are associated with the card number in the card issuer’s system. Before a transaction, the cardholder loads money assigned to his card to the bank account of the issuer, which can then be spent at accepting merchants or withdrawn at ATMs. The card’s balance decreases with each transaction and can be reloaded as needed.

Debit Cards

Debit cards are linked directly to a cardholder’s bank account. When a transaction occurs, funds are transferred in real time or near-real time from the cardholder’s account to the merchant’s account. The cardholder’s spending limit is determined by the available balance in the associated bank account.

Credit Cards

Credit cards are issued with a revolving line of credit established by the card issuer. When a transaction occurs, the card issuer pays the merchant on behalf of the cardholder, who then owes the issuer the transaction amount. The cardholder can carry a balance from month to month, subject to interest charges, or pay off the balance in full each month. 

What is the role of Visa, Mastercard, American Express, Diners, Union Pay, etc..?

Visa, Mastercard, American Express, Diners, Union Pay, etc. (also called bank card associates) act as a conduit for banks and other financial institutions, providing, clearing, and settlement services for transactions between consumers, merchants, and banks as payment networks, but this does not involve holding funds themselves.

  • Visa, Mastercard, and Union Pay are payment networks. Only the banks that issued the credit, debit and prepaid cards can authorize payments.
  • American Express and Discover are both payment networks and card issuers. They authorize payments for their own cards.

Visa, Mastercard, American Express, Diners, Union Pay, Discover, etc.  also set standards for merchants, payment facilitators, and marketplaces.

In summary, Visa, Mastercard, Diners, Union Pay, American Express, Discover, etc., do not hold funds themselves but instead act only as a conduit for banks and other financial institutions to facilitate transactions between parties.

How does a POS (Point of Sale) terminal process your card information? 

A point-of-sale (POS) terminal is an electronic device that processes card payments at retail locations. Here's a basic rundown of how a POS terminal works:

  1. Card Reading: When a customer presents a credit or debit card for payment, the card's information is read by the POS terminal. This can be done by swiping the magnetic strip, inserting the chip into the terminal (for EMV cards), or using contactless payment methods like NFC (Near Field Communication) for mobile payment apps.
  2. Transaction Details: The POS terminal then captures the transaction details - this includes the card information, the transaction amount, and sometimes other details like the merchant ID.
  3. Communication with the Acquirer: These details are then encrypted and sent via a phone or Internet to the merchant's acquiring bank or acquirer. The acquirer is a bank or financial institution that processes credit and debit card transactions on behalf of the merchant.
  4. Requesting Authorization: The acquirer sends this information to the card issuer (the bank that issued the customer's card) through the card network (such as Visa, Mastercard, etc.) to request authorisation for the transaction. This step is to check that the card is valid and has enough credit or funds available. This MTI is used when the point-of-sale terminal at a merchant needs to get authorization for a payment transaction according to the ISO 8583 standard: 0100
  5. Authorisation Response: The card issuer sends an authorisation response to the acquirer, either approving or declining the transaction. This response is then sent back to the POS terminal. This MTI is used when the Point-of-sale terminal at the merchant receives the authorization or denial of authorization for a payment transaction according to the ISO 8583 standard: 0101.
  6. Completion of Transaction: If the transaction is approved, the customer's account is charged for the amount of the purchase, and the merchant's account is credited with the same amount, minus any fees charged by the acquirer and card network. If the transaction is declined, no funds are transferred.

General Overview how Cards are Processed

  • When a credit card payment is accepted by a business, the business's payment processor sends an authorization request to the card issuer, which evaluates the transaction's validity by communicating with the cardholder's issuing bank and the business's merchant account. During authorization, the issuer checks to confirm that the cardholder has sufficient funds or available credit to cover the amount being requested for the transaction. 
  • If the transaction is approved, the issuer will immediately reduce the balance or available credit on the account associated with the card, even though the funds won’t be transferred to the business right away. 
  • After the payment is authorized, the payment processor communicates the approval back to the acquirer and the business's payment terminal, online or in person. 
  • When the sales order is invoiced, the credit card is charged (captured) for the invoice amount. 

Why Credit Cards are better

In the nuanced world of international finance, distinguishing between debit and credit cards is paramount, especially for those embarking on travels abroad. Despite bearing the Visa or Mastercard logo, many cards issued by banks today are debit cards, not true credit cards, and this distinction can significantly impact a traveler’s experience.

Debit cards, often provided without additional cost with a checking account, do not offer the same financial flexibility as credit cards. This limitation becomes starkly apparent in scenarios requiring a deposit, such as securing a rental car or hotel amenities abroad—situations where debit cards may be outright rejected. Such rejections can lead to unforeseen expenses, as alternative arrangements typically incur higher costs and immediate account debits.

On the other hand, true credit cards defer charges and often come with a pre-set spending limit, offering a buffer that is particularly useful in managing travel-related expenditures. These cards facilitate transactions by allowing for pre-authorizations on funds— a critical feature in many travel situations, from car rentals to hotel stays, ensuring services are both booked and secured without immediate financial detriment.

For travelers, especially those venturing outside the Eurozone, possessing a true credit card is not merely a convenience but a necessity. It ensures smoother financial transactions and avoids the pitfalls and penalties associated with debit card usage. Thus, the astute traveler is advised to secure a genuine credit card and to preemptively notify their issuer of international travel plans to avert any temporary freezes due to suspected fraud. This proactive approach enables a seamless, financially secure travel experience.

How do credit, debit and prepaid cards work in detail?

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.

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 processes involved in a credit card transaction are pretty complex, involving multiple parties and layers of communication. 


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. Tokenisation (optional): If tokenisation 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.

Credit and Debit Card Security

Credit and debit cards are secured through a combination of physical and digital security features.

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.

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.

Physical Security on the Card

On the card itself, the user's name, card number, expiration date, and card verification value (CVV) are printed. The CVV is a three-digit or four-digit number, depending on the bank issuing the card, that provides an extra layer of security during transactions. 

Card Verification Value (CVV): The 3- or 4-digit number is printed on the physical card but not embedded in the card's magnetic stripe. It's often required for online and over-the-phone transactions, where the card isn't physically present. It serves to verify that the person making the transaction has the physical card.

There is also a magnetic stripe and/or an embedded chip on the card. The magnetic stripe contains encoded cardholder data, while the embedded chip (used in chip-and-PIN and chip-and-signature cards) holds information in a secure, encrypted format, making it difficult for unauthorized users to access or counterfeit. 

Digital Security for the Card

On the service provider's side, they use several layers of security to protect against fraudulent activities. This includes the Secure Socket Layer (SSL) and Transport Layer Security (TLS) protocols that encrypt data during transmission. They may also use fraud detection systems that use machine learning algorithms to detect unusual patterns of behavior that may indicate fraudulent activity.

  1. Address Verification Service (AVS): This service checks the address provided by the customer with the address on file at the credit card company. If they don't match, the transaction can be declined. This helps prevent fraud from stolen credit card numbers.
  2. Two-Factor Authentication (2FA): 2FA requires two types of identification before a transaction can be approved. Usually, these two factors involve something you know (like a password), something you have (like your phone to receive a one-time password), or something you are (like your fingerprint).
  3. Biometric Authentication: This type of authentication uses unique biological characteristics, like fingerprints or facial recognition, to verify identities. Some mobile payment systems like Apple Pay and Google Pay use biometric authentication for transaction authorization.
  4. Risk-Based Authentication (RBA): This method calculates the risk profile of an online transaction and then requires additional verification for higher-risk transactions. RBA might consider factors like the user's IP address, the device being used, the amount of the transaction, and the user's behavior patterns.
  5. Tokenization: Tokenization protects card information by replacing the card number with a randomly generated string of characters, or "token". This token can safely be transmitted over the internet, and is useless if intercepted by fraudsters, since it can't be reverse-engineered to find the original card number.
  6. Contactless Payments: Many cards now also support contactless payments, which use Near Field Communication (NFC) or Radio Frequency Identification (RFID) to communicate with payment terminals. These transactions are secured with dynamic encryption, meaning a new encryption key is generated for each transaction, making it extremely difficult for fraudsters to intercept and misuse the data.
  7. 3-D Secure (3DS) Authentication (e.g., Verified by Visa, Mastercard SecureCode): 3-D Secure is an XML-based protocol designed to be an additional security layer for online credit and debit card transactions. The protocol is known by various names, depending on the card type: Verified by Visa (Visa), Mastercard SecureCode (Mastercard), American Express SafeKey (American Express), and so on. How It Works: 3-D Secure adds an additional step to the online payment process. When you make a purchase, after you've entered your card details, the 3DS system checks if your bank or card issuer is enrolled in 3DS. If it is, a pop-up window appears in your browser, which is connected directly to your bank or issuer. You are then asked to verify your identity—this could be through a password, a fingerprint scan if your bank offers biometric authentication, or a one-time code sent to your mobile phone. Only after successful authentication will the transaction proceed. 3-D Secure 2.0: This is the newer version of 3-D Secure, which improves upon the original system by making it more user-friendly and efficient. 3DS 2.0 is designed to use a risk-based approach, meaning that it only asks for additional authentication when a transaction appears risky. It also works smoothly on mobile devices, which was a limitation of the original 3DS.

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.

Tap to Pay

Technological Bedrock: NFC and Its RFID Genesis

Central to the tap-to-pay schema is Near Field Communication (NFC), a technology that refines and specializes the broader Radio Frequency Identification (RFID) framework. NFC operates through electromagnetic induction between two loop antennas, engineered in a configuration reminiscent of a racetrack, situated within a proximity not exceeding a scant four centimeters. This limited spatial engagement fosters a secure and expeditious data exchange, tailor-made for the exigencies of payment transactions.

Passive and Active Symbiosis

The transactional interplay between the payment instrument (whether a card or NFC-enabled device) and the reader is predicated on a delineation of roles: the reader as the active initiator, imbued with the capacity to autonomously forge communication; contrasted with the card as a passive respondent, devoid of self-contained power, yet responsive to the reader’s solicitations. This interaction catalyzes the conveyance of payment data, a process that diverges fundamentally from the static data transmission inherent in magnetic stripe engagements.

Cryptographic Fortifications: Security Par Excellence

A cornerstone of the security architecture within tap-to-pay technology is the generation of a transaction-specific cryptogram. This cryptogram emerges from a cryptographic fusion of transactional data and card information, orchestrated under the auspices of a cryptographic key stored in the chip of the card. This process engenders a formidable barrier against the replication of payment credentials for nefarious purposes, substantially elevating the security stature of each transaction.

The intercommunication between the payment board and the main board within the reader apparatus is instrumental in the assembly of transaction data into a fortified encrypted package. This encryption, maintained throughout the data’s journey to and from payment processors and networks, serves as a bulwark against intrusion and unauthorized data access, preserving the sanctity of transactional confidentiality from inception to resolution.

Comparative Security Analysis and Adoption Trajectories

In juxtaposition with its antecedents—magnetic stripe and chip insert modalities—tap-to-pay technology embodies a quantum leap in transactional security. The dynamic encryption and limited-range communication protocols innately diminish the avenues for data compromise, effectively countering the specter of skimming and unauthorized data exfiltration that have historically plagued point-of-sale transactions.

Notwithstanding its manifest advantages in terms of transaction speed and security, the adoption curve of tap-to-pay technology in certain markets, notably the U.S., has exhibited a degree of reticence. This reluctance is attributable to an amalgam of factors, encompassing infrastructural investment requirements, consumer behavioral inertia, and the perceived marginality of the technology’s value proposition in compelling a behavioral shift.

In summation, tap-to-pay technology, through its sophisticated confluence of NFC technology, cryptographic rigor, and encrypted data conveyance, heralds a paradigmatic shift in the domain of secure and efficient payment methodologies. Its progressive integration into the fabric of daily transactions promises to elevate the standard of transactional security and convenience, marking a pivotal evolution in the commerce and payment sectors.

Reservation of funds or deferred payment works in a credit, debit or prepaid card transaction 


The transaction begins with an authorization request. When you present your credit card for payment, the merchant sends a request to the acquiring bank. 

The acquiring bank forwards this request to the card network, which in turn sends it to the issuing bank. The issuing bank checks the available credit and other transaction details for validity. If everything checks out, it reserves the amount of the transaction against your credit limit. This is known as authorization hold or pre-authorization. It's a way to ensure that the funds are available and to set them aside for this particular transaction. 

Authorization Code Generation

When a customer presents a credit card for payment, the merchant's point-of-sale (POS) system sends an authorization request to the acquiring bank. The acquiring bank forwards this request to the card network, which then routes it to the issuing bank. If the issuing bank approves the transaction (e.g., sufficient credit or funds available, card not reported lost/stolen), it generates an authorization code and sends it back through the card network and acquiring bank to the merchant's POS system. 

The length of authorization codes, also known as approval codes, can vary by card network or issuing bank. These codes serve as a confirmation that a transaction has been approved and they are used as a reference in the settlement process. The length and format of the authorization code can be determined based on the operational requirements of the card networks and the banks involved. Some systems use 6-digit codes, while others may use 8-digit codes or even other lengths.


Capture of Transaction

 Thei merchant receives the authorization code, which confirms that the funds are available and reserved for this transaction. At the end of the day, or sometimes later depending on the merchant's process, the merchant sends a batch of transactions to the acquiring bank for settlement. This process is known as "capture." During the capture process, the merchant includes the authorization code for each transaction, which serves as proof of authorization and allows the acquiring bank to match each transaction with its authorization. 



The acquiring bank then sends the transactions, along with the authorization codes, to the card networks for settlement. The card networks route the transactions to the issuing banks, which then transfer the funds for the approved transactions to the acquiring bank. Finally, the acquiring bank deposits the funds into the merchant's bank account. 


At the end of the business day, the merchant sends all the day's authorized transactions to the acquiring bank in a batch. The acquiring bank then sends these transactions through the card network to the issuing bank for settlement. 

The issuing bank transfers the funds to the acquiring bank, which then deposits the funds into the merchant's account. At this point, the transaction is complete, and the reserved funds are now officially transferred from your credit line to the merchant. 

Record Keeping 

The authorization code is a crucial piece of information for record-keeping and dispute resolution. In case of a dispute, the authorization code helps trace the transaction back through the various steps in the processing chain to verify its validity. This process ensures that the funds are properly reserved, transferred, and recorded, providing a secure and traceable method of handling credit card transactions. 


The issuing bank will then reflect this transaction on your monthly statement, at which point you are required to pay.

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.


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 / Protocols

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.