ISO 8583 is an international standard for financial transaction card originated interchange messaging. It is the International Organization for Standardization standard for systems that exchange electronic transactions initiated by cardholders using payment cards.
ISO 8583 defines a message format and a communication flow so that different systems can exchange these transaction requests and responses. The vast majority of transactions made when a customer uses a card to make a payment in a store (EFTPOS) use ISO 8583 at some point in the communication chain, as do transactions made at ATMs. In particular, both the MasterCard and Visa networks base their authorization communications on the ISO 8583 standard, as do many other institutions and networks.
Although ISO 8583 defines a common standard, it is not typically used directly by systems or networks. It defines many standard fields (data elements) which remain the same in all systems or networks, and leaves a few additional fields for passing network-specific details. These fields are used by each network to adapt the standard for its own use with custom fields and custom usages.
The ISO 8583 specification has three parts:
A card-based transaction typically travels from a transaction-acquiring device, such as a point-of-sale terminal or an automated teller machine (ATM), through a series of networks, to a card issuing system for authorization against the card holder's account. The transaction data contains information derived from the card (e.g., the account number), the terminal (e.g., the merchant number), the transaction (e.g., the amount), together with other data which may be generated dynamically or added by intervening systems. Based on this information, the card issuing system will either authorize or decline the transaction and generate a response message which must be delivered back to the terminal within a predefined time period.
An ISO 8583 message is made of the following parts:
The placements of fields in different versions of the standard varies; for example, the currency elements of the 1987 and 1993 versions of the standard are no longer used in the 2003 version, which holds currency as a sub-element of any financial amount element. As of June 2017, however ISO 8583:2003 has yet to achieve wide acceptance. ISO 8583 messaging has no routing information, so is sometimes used with a TPDU header.
Cardholder-originated transactions include purchase, withdrawal, deposit, refund, reversal, balance inquiry, payments and inter-account transfers. ISO 8583 also defines system-to-system messages for secure key exchanges, reconciliation of totals, and other administrative purposes.
The message type indicator is a four-digit numeric field which indicates the overall function of the message. A message type indicator includes the ISO 8583 version, the Message Class, the Message Function and the Message Origin, as described below.
The first digit of the MTI indicates the ISO 8583 version in which the message is encoded.
|3xxx||Reserved by ISO|
Position two of the MTI specifies the overall purpose of the message.
|x0xx||Reserved by ISO|
|x1xx||Authorization message||Determine if funds are available, get an approval but do not post to account for reconciliation. Dual message system (DMS), awaits file exchange for posting to the account.|
|x2xx||Financial messages||Determine if funds are available, get an approval and post directly to the account. Single message system (SMS), no file exchange after this.|
|x3xx||File actions message||Used for hot-card, TMS and other exchanges|
|x4xx||Reversal and chargeback messages||Reversal (x4x0 or x4x1): Reverses the action of a previous authorization.|
Chargeback (x4x2 or x4x3): Charges back a previously cleared financial message.
|x5xx||Reconciliation message||Transmits settlement information message.|
|x6xx||Administrative message||Transmits administrative advice. Often used for failure messages (e.g. message reject or failure to apply).|
|x7xx||Fee collection messages|
|x8xx||Network management message||Used for secure key exchange, logon, echo test and other network functions.|
|x9xx||Reserved by ISO|
Position three of the MTI specifies the message function which defines how the message should flow within the system. Requests are end-to-end messages (e.g., from acquirer to issuer and back with time-outs and automatic reversals in place), while advices are point-to-point messages (e.g., from terminal to acquirer, from acquirer to network, from network to issuer, with transmission guaranteed over each link, but not necessarily immediately).
|xx0x||Request||Request from acquirer to issuer to carry out an action; issuer may accept or reject|
|xx1x||Request response||Issuer response to a request|
|xx2x||Advice||Advice that an action has taken place; receiver can only accept, not reject|
|xx3x||Advice response||Response to an advice|
|xx4x||Notification||Notification that an event has taken place; receiver can only accept, not reject|
|xx5x||Notification acknowledgement||Response to a notification|
|xx8x||Reserved for ISO use||Some implementations (such as MasterCard) use for positive acknowledgment.|
|xx9x||Some implementations (such as MasterCard) use for negative acknowledgement.|
Position four of the MTI defines the location of the message source within the payment chain.
|xxx6||Reserved by ISO|
Given an MTI value of 0110, the following example lists what each position indicates:
Therefore, MTI 0110 is an authorization response message sent by the acquirer.
Bearing each of the above four positions in mind, an MTI will completely specify what a message should do, and how it is to be transmitted around the network. Unfortunately, not all ISO 8583 implementations interpret the meaning of an MTI in the same way. However, a few MTIs are relatively standard:
|0100||Authorization Request||Request from a point-of-sale terminal for authorization for a cardholder purchase|
|0110||Authorization Response||Request response to a point-of-sale terminal for authorization for a cardholder purchase|
|0120||Authorization Advice||When the point-of-sale device breaks down and you have to sign a voucher|
|0121||Authorization Advice Repeat||If the advice times out|
|0130||Issuer Response to Authorization Advice||Confirmation of receipt of authorization advice|
|0200||Acquirer Financial Request||Request for funds, typically from an ATM or pinned point-of-sale device|
|0210||Issuer Response to Financial Request||Issuer response to request for funds|
|0220||Acquirer Financial Advice||e.g. Checkout at a hotel. Used to complete transaction initiated with authorization request|
|0221||Acquirer Financial Advice Repeat||If the advice times out|
|0230||Issuer Response to Financial Advice||Confirmation of receipt of financial advice|
|0320||Batch Upload||File update/transfer advice|
|0330||Batch Upload Response||File update/transfer advice response|
|0400||Acquirer Reversal Request||Reverses a transaction|
|0510||Batch Settlement response||Card acceptor reconciliation request response|
|0800||Network Management Request||Hypercom terminals initialize request. Echo test, logon, logoff etc.|
|0810||Network Management Response||Hypercom terminals initialize response. Echo test, logon, logoff etc.|
|0820||Network Management Advice||Key change|
In ISO 8583, a bitmap is a field or subfield within a message, which indicates whether other data elements or data element subfields are present elsewhere in the message.
A field is considered to be present only when the corresponding bit in the bitmap is set. For example, a hex with value 0x82 (decimal 130) is binary 1000 0010, which means fields 1 and 7 are present in the message and fields 2, 3, 4, 5, 6 and 8 are not.
The bitmap may be represented as 8 bytes of binary data or as 16 hexadecimal characters (0-9, A-F) in the ASCII or EBCDIC character sets. A message will contain at least one bitmap, called the primary bitmap, which indicates which of data elements 1 to 64 are present. The presence of an optional secondary bitmap is also indicated by the first bit in the primary bitmap. If present, the secondary bitmap indicates whether data elements 65 to 128 are present. Similarly, a tertiary bitmap can be used to indicate the presence of fields 129 to 192, although these data elements are rarely used.
Given a bitmap value of 22 10 00 11 02 C0 48 04,
Therefore, the given bitmap defines the following fields present in the message:
3, 7, 12, 28, 32, 39, 41, 42, 50, 53, 62
Data elements are the individual fields carrying the transaction information. There are up to 128 data elements specified in the original ISO 8583:1987 standard, and up to 192 data elements in later releases. The 1993 revision added new definitions, deleted some, while leaving the message format itself unchanged.
While each data element has a specified meaning and format, the standard also includes some general purpose data elements and system- or country-specific data elements which vary enormously in use and form from implementation to implementation.
Each data element is described in a standard format which defines the permitted content of the field (numeric, binary, etc.) and the field length (variable or fixed), according to the following table:
|a||Alpha, including blanks|
|n||Numeric values only|
|x+n||Numeric (amount) values, where the first byte is either 'C' to indicate a positive or Credit value, or 'D' to indicate a negative or Debit value, followed by the numeric value (using n digits)|
|s||Special characters only|
|as||Alpha & special characters only|
|ns||Numeric and special characters only|
|ans||Alphabetic, numeric and special characters.|
|z||Tracks 2 and 3 code set as defined in ISO/IEC 7813 and ISO/IEC 4909 respectively|
|. or .. or ...||variable field length indicator, each . indicating a digit.|
|x or xx or xxx||fixed length of field, or maximum length in the case of variable length fields.|
Additionally, each field may be either fixed or variable length. If variable, the length of the field will be preceded by a length indicator.
|Fixed||no field length used|
|LLVAR or (..xx)||Where 0 < LL < 100, means two leading digits LL specify the field length of field VAR|
|LLLVAR or (...xxx)||Where 0 < LLL < 1000, means three leading digits LLL specify the field length of field VAR|
|LL and LLL are hex or ASCII. A VAR field can be compressed or ASCII depending of the data element type.||LL can be one or two bytes. For example, if compressed as one hex byte, '27x means there are 27 VAR bytes to follow. If ASCII, the two bytes '32x, '37x mean there are 27 bytes to follow. Three-digit field length LLL uses two bytes with a leading '0' nibble if compressed, or three bytes if ASCII. The format of a VAR data element depends on the data element type. If numeric it will be compressed, e.g. 87456 will be represented by three hex bytes '087456x. If ASCII then one byte for each digit or character is used, e.g. '38x, '37x, '34x, '35x, '36x.|
|n 6||Fixed length field of six digits|
|n.6||LVAR numeric field of up to 6 digits in length|
|a..11||LLVAR alpha field of up to 11 characters in length|
|b...999||LLLVAR binary field of up to 999 bits in length|
|1||b 64||Second Bitmap|
|2||n ..19||Primary account number (PAN)|
|3||n 6||Processing code|
|4||n 12||Amount, transaction|
|5||n 12||Amount, settlement|
|6||n 12||Amount, cardholder billing|
|7||n 10||Transmission date & time|
|8||n 8||Amount, cardholder billing fee|
|9||n 8||Conversion rate, settlement|
|10||n 8||Conversion rate, cardholder billing|
|11||n 6||System trace audit number (STAN)|
|12||n 6||Local transaction time (hhmmss)|
|13||n 4||Local transaction date (MMDD)|
|14||n 4||Expiration date|
|15||n 4||Settlement date|
|16||n 4||Currency conversion date|
|17||n 4||Capture date|
|18||n 4||Merchant type, or merchant category code|
|19||n 3||Acquiring institution (country code)|
|20||n 3||PAN extended (country code)|
|21||n 3||Forwarding institution (country code)|
|22||n 3||Point of service entry mode|
|23||n 3||Application PAN sequence number|
|24||n 3||Function code (ISO 8583:1993), or network international identifier (NII)|
|25||n 2||Point of service condition code|
|26||n 2||Point of service capture code|
|27||n 1||Authorizing identification response length|
|28||x+n 8||Amount, transaction fee|
|29||x+n 8||Amount, settlement fee|
|30||x+n 8||Amount, transaction processing fee|
|31||x+n 8||Amount, settlement processing fee|
|32||n ..11||Acquiring institution identification code|
|33||n ..11||Forwarding institution identification code|
|34||ns ..28||Primary account number, extended|
|35||z ..37||Track 2 data|
|36||n ...104||Track 3 data|
|37||an 12||Retrieval reference number|
|38||an 6||Authorization identification response|
|39||an 2||Response code|
|40||an 3||Service restriction code|
|41||ans 8||Card acceptor terminal identification|
|42||ans 15||Card acceptor identification code|
|43||ans 40||Card acceptor name/location (1-23 street address, 24-36 city, 37-38 state, 39-40 country)|
|44||an ..25||Additional response data|
|45||an ..76||Track 1 data|
|46||an ...999||Additional data (ISO)|
|47||an ...999||Additional data (national)|
|48||an ...999||Additional data (private)|
|49||a or n 3||Currency code, transaction|
|50||a or n 3||Currency code, settlement|
|51||a or n 3||Currency code, cardholder billing|
|52||b 64||Personal identification number data|
|53||n 16||Security related control information|
|54||an ...120||Additional amounts|
|55||ans ...999||ICC data – EMV having multiple tags|
|56||ans ...999||Reserved (ISO)|
|57||ans ...999||Reserved (national)|
|60||ans ...999||Reserved (national) (e.g. settlement request: batch number, advice transactions: original transaction amount, batch upload: original MTI plus original RRN plus original STAN, etc)|
|61||ans ...999||Reserved (private) (e.g. CVV2/service code transactions)|
|62||ans ...999||Reserved (private) (e.g. transactions: invoice number, key exchange transactions: TPK key, etc.)|
|63||ans ...999||Reserved (private)|
|64||b 64||Message authentication code (MAC)|
|65||b 1||Extended bitmap indicator|
|66||n 1||Settlement code|
|67||n 2||Extended payment code|
|68||n 3||Receiving institution country code|
|69||n 3||Settlement institution country code|
|70||n 3||Network management information code|
|71||n 4||Message number|
|72||n 4||Last message's number|
|73||n 6||Action date (YYMMDD)|
|74||n 10||Number of credits|
|75||n 10||Credits, reversal number|
|76||n 10||Number of debits|
|77||n 10||Debits, reversal number|
|78||n 10||Transfer number|
|79||n 10||Transfer, reversal number|
|80||n 10||Number of inquiries|
|81||n 10||Number of authorizations|
|82||n 12||Credits, processing fee amount|
|83||n 12||Credits, transaction fee amount|
|84||n 12||Debits, processing fee amount|
|85||n 12||Debits, transaction fee amount|
|86||n 16||Total amount of credits|
|87||n 16||Credits, reversal amount|
|88||n 16||Total amount of debits|
|89||n 16||Debits, reversal amount|
|90||n 42||Original data elements|
|91||an 1||File update code|
|92||an 2||File security code|
|93||an 5||Response indicator|
|94||an 7||Service indicator|
|95||an 42||Replacement amounts|
|96||b 64||Message security code|
|97||x+n 16||Net settlement amount|
|99||n ..11||Settlement institution identification code|
|100||n ..11||Receiving institution identification code|
|101||ans ..17||File name|
|102||ans ..28||Account identification 1|
|103||ans ..28||Account identification 2|
|104||ans ...100||Transaction description|
|105||ans ...999||Reserved for ISO use|
|112||ans ...999||Reserved for national use|
|120||ans ...999||Reserved for private use|
|128||b 64||Message authentication code|
The following is a table specifying the message type and processing code for each transaction type.
|Transaction||Message type||Processing code|
|Authorization||0100||00 a0 0x|
|Balance inquiry||31 a0 0x|
|Sale||0200||00 a0 0x|
|Cash||01 a0 0x|
|Void||02 a0 0x|
|Mobile topup||57 a0 0x|
The following table shows response codes and their meanings.
|00||Successful approval/completion or that VIP PIN verification is valid|
|01||Refer to card issuer|
|02||Refer to card issuer, special condition|
|03||Invalid merchant or service provider|
|05||Do not honor|
|07||Pickup card, special condition (other than lost/stolen card)|
|08||Honor with identification|
|09||Request in progress|
|13||Invalid amount (currency conversion field overflow) or amount exceeds maximum for card program|
|14||Invalid account number (no such number)|
|15||No such issuer|
|21||No action taken (unable to back out prior transaction)|
|25||Unable to locate record in file, or account number is missing from the inquiry|
|28||File is temporarily unavailable|
|41||Merchant should retain card (card reported lost)|
|43||Merchant should retain card (card reported stolen)|
|52||No checking account|
|53||No savings account|
|57||Transaction not permitted to cardholder|
|58||Transaction not allowed at terminal|
|61||Activity amount limit exceeded|
|62||Restricted card (for example, in country exclusion table)|
|65||Activity count limit exceeded|
|68||Response received too late|
|75||Allowable number of PIN-entry tries exceeded|
|76||Unable to locate previous message (no match on retrieval reference number)|
|77||Previous message located for a repeat or reversal, but repeat or reversal data are inconsistent with original message|
|78||’Blocked, first used’—The transaction is from a new cardholder, and the card has not been properly unblocked.|
|80||Visa transactions: credit issuer unavailable. Private label and check acceptance: Invalid date|
|81||PIN cryptographic error found (error found by VIC security module during PIN decryption)|
|82||Negative CAM, dCVV, iCVV, or CVV results|
|83||Unable to verify PIN|
|85||No reason to decline a request for account number verification, address verification, CVV2 verification; or a credit voucher or merchandise return|
|91||Issuer unavailable or switch inoperative (STIP not applicable or available for this transaction)|
|92||Destination cannot be found for routing|
|93||Transaction cannot be completed, violation of law|
|96||System malfunction, System malfunction or certain field error conditions|
|B1||Surcharge amount not permitted on Visa cards (U.S. acquirers only)|
|N3||Cash service not available|
|N4||Cashback request exceeds issuer limit|
|N7||Decline for CVV2 failure|
|P2||Invalid biller information|
|P5||PIN change/unblock request declined|
|Q1||Card authentication failed|
|R0||Stop payment order|
|R1||Revocation of authorization order|
|R3||Revocation of all authorizations order|
|XA||Forward to issuer|
|XD||Forward to issuer|
|Z3||Unable to go online|
The point of service entry mode value consists of 2 parts:
1. PAN entry mode, the first 2 digits
2. PIN entry capability, the third digit
The following table shows PAN entry modes and their meanings.
|PAN Entry Mode||Meaning|
|05||Integrated circuit card (ICC). CVV can be checked.|
|07||Auto entry via contactless magnetic stripe.|
|80||Fallback from integrated circuit card (ICC) to magnetic stripe|
|90||Magnetic stripe as read from track 2. CVV can be checked.|
|91||Auto entry via contactless magnetic stripe|
|95||Integrated circuit card (ICC). CVV may not be checked.|
|99||Same as original transaction.|
The following table shows PIN entry capabilities and their meanings.
|PIN Entry Capability||Meaning|
|1||Terminal can accept PINs|
|2||Terminal cannot accept PINs|
API testing is a type of software testing that involves testing application programming interfaces (APIs) directly and as part of integration testing to determine if they meet expectations for functionality, reliability, performance, and security. Since APIs lack a GUI, API testing is performed at the message layer. API testing is now considered critical for automating testing because APIs now serve as the primary interface to application logic and because GUI tests are difficult to maintain with the short release cycles and frequent changes commonly used with Agile software development and DevOps.AS 2805
AS 2805 Electronic funds transfer - Requirements for interfaces is the Australian standard for financial messaging. It is near-exclusively used in Australia for the operation of card-based financial transactions among banks, automatic teller machines and EFTPOS devices.
It is closely related to ISO 8583, but pre-dates it by two years (1985 vs 1987).Card security code
A card security code (CSC; also called card verification data [CVD], card verification number, card verification value [CVV], card verification value code, card verification code [CVC], verification code [V-code or V code], or signature panel code [SPC]) is a security feature for "card not present" payment card transactions instituted to reduce the incidence of credit card fraud.
The CSC is in addition to the bank card number which is embossed or printed on the card. The CSC is used as a security feature, in situations where a PIN cannot be used. The PIN is not printed or embedded on the card but is manually entered by the cardholder during point-of-sale (card present) transactions. Contactless card and chip cards may electronically generate their own code, such as iCVV or a dynamic CVV.
CSC was originally developed in the UK as an eleven character alphanumeric code by Equifax employee Michael Stone in 1995. After testing with the Littlewoods Home Shopping group and NatWest bank, the concept was adopted by APACS (the UK Association of Payment Clearing Services) and streamlined to the three-digit code known today. MasterCard started issuing CVC2 numbers in 1997 and Visa in the United States issued them by 2001. American Express started to use the CSC in 1999, in response to growing Internet transactions and card member complaints of spending interruptions when the security of a card has been brought into question.
In 2016, a new e-commerce technology called Motioncode was introduced, designed to automatically refresh the CVV code to a new one every hour or so.EFTPOS
Electronic funds transfer at point of sale (EFTPOS ) is an electronic payment system involving electronic funds transfers based on the use of payment cards, such as debit or credit cards, at payment terminals located at points of sale. EFTPOS technology originated in the United States in 1981 and was adopted by other countries. In Australia and New Zealand, it is also the brand name of a specific system used for such payments; these systems are mainly country specific and do not interconnect.
Debit and credit cards are embossed plastic cards complying with ISO/IEC 7810 ID-1 standard. The cards have an embossed bank card number conforming with the ISO/IEC 7812 numbering standard.ISO 19092-2
ISO 19092 Financial Services - Biometrics - Part 2: Message syntax and cryptographic requirements is an ISO standard that describes the techniques, protocols, cryptographic requirements, and syntax for using biometrics as an identification and verification mechanism in a wide variety of security applications in the financial industry. This standard provides support for policy based matching decisions for remote authentication and allows biometrics to be used securely with the ISO 8583 retail transaction messaging standard. A secure review and audit event journal syntax is provided that allows many of the security controls specified in ISO 19092-1 to be implemented.JPOS
jPOS is a free and open source library/framework that provides a high-performance bridge between card messages generated at the point of sale or ATM terminals and internal systems along the entire financial messaging network. jPOS is an enabling technology that can be used to handle all card processing from messaging, to processing, through reporting.It can be used to implement financial interchanges based on the ISO 8583 standard and related protocols and currently supports versions 1987, 1993 and 2003 of the standard as well as multiple ANSX9.24 standards.Magnetic stripe card
A magnetic stripe card is a type of card capable of storing data by modifying the magnetism of tiny iron-based magnetic particles on a band of magnetic material on the card. The magnetic stripe, sometimes called swipe card or magstripe, is read by swiping past a magnetic reading head. Magnetic stripe cards are commonly used in credit cards, identity cards, and transportation tickets. They may also contain an RFID tag, a transponder device and/or a microchip mostly used for business premises access control or electronic payment.
Magnetic recording on steel tape and wire was invented in Denmark around 1900 for recording audio. In the 1950s, magnetic recording of digital computer data on plastic tape coated with iron oxide was invented. In 1960, IBM used the magnetic tape idea to develop a reliable way of securing magnetic stripes to plastic cards, under a contract with the US government for a security system. A number of International Organization for Standardization standards, ISO/IEC 7810, ISO/IEC 7811, ISO/IEC 7812, ISO/IEC 7813, ISO 8583, and ISO/IEC 4909, now define the physical properties of the card, including size, flexibility, location of the magstripe, magnetic characteristics, and data formats. They also provide the standards for financial cards, including the allocation of card number ranges to different card issuing institutions.Mastercard
Mastercard Incorporated (stylized as MasterCard from 1979 to 2016 and mastercard from 2016 to 2019) is an American multinational financial services corporation headquartered in the Mastercard International Global Headquarters in Purchase, New York, United States. The Global Operations Headquarters is located in O'Fallon, Missouri, United States, a municipality of St. Charles County, Missouri. Throughout the world, its principal business is to process payments between the banks of merchants and the card issuing banks or credit unions of the purchasers who use the "Mastercard" brand debit, credit and prepaid to make purchases. Mastercard Worldwide has been a publicly traded company since 2006. Prior to its initial public offering, Mastercard Worldwide was a cooperative owned by the more than 25,000 financial institutions that issue its branded cards.
Mastercard, originally known as "Interbank" from 1966 to 1969 and "Master Charge" from 1969 to 1979, was created by an alliance of several regional bankcard associations in response to the BankAmericard issued by Bank of America, which later became the Visa credit card issued by Visa Inc.Merchant category code
A Merchant Category Code (MCC) is a four-digit number listed in ISO 18245 for retail financial services. MCC is used to classify the business by the type of goods or services it provides. MCCs are assigned by merchant type (e.g. one for hotels, one for office supply stores, etc.) or by merchant name (e.g. 3000 for United Airlines).
An MCC is assigned to a merchant by the card company when the business first starts accepting cards as a form of payment.
The code reflects the primary category in which the merchant does business and may be used:
to determine the interchange fee paid by the merchant, with riskier lines of business paying higher fees.
by credit card companies to offer cash back rewards or reward points, for spending in specific categories.
by card networks to define rules and restrictions for card transactions (for example, Automated Fuel Dispensers (MCC 5542) have specific rules for authorization and clearing messages).
in the United States, to determine whether a payment is primarily for “services”, which needs to be reported by the payor to the Internal Revenue Service for tax purposes, or for “merchandise”, which does not.Nibble
In computing, a nibble (occasionally nybble or nyble to match the spelling of byte) is a four-bit aggregation, or half an octet. It is also known as half-byte or tetrade.
In a networking or telecommunication context, the nibble is often called a semi-octet, quadbit, or quartet.
A nibble has sixteen (24) possible values. A nibble can be represented by a single hexadecimal digit and called a hex digit.A full byte (octet) is represented by two hexadecimal digits; therefore, it is common to display a byte of information as two nibbles. Sometimes the set of all 256 byte values is represented as a 16×16 table, which gives easily readable hexadecimal codes for each value.
Four-bit computer architectures use groups of four bits as their fundamental unit. Such architectures were used in early microprocessors, pocket calculators and pocket computers. They continue to be used in some microcontrollers.Payment card
Payment cards are part of a payment system issued by financial institutions, such as a bank, to a customer that enables its owner (the cardholder) to access the funds in the customer's designated bank accounts, or through a credit account and make payments by electronic funds transfer and access automated teller machines (ATMs). Such cards are known by a variety of names including bank cards, ATM cards, MAC (money access cards), client cards, key cards or cash cards.
There are a number of types of payment cards, the most common being credit cards and debit cards. Most commonly, a payment card is electronically linked to an account or accounts belonging to the cardholder. These accounts may be deposit accounts or loan or credit accounts, and the card is a means of authenticating the cardholder. However, stored-value cards store money on the card itself and are not necessarily linked to an account at a financial institution.
It can also be a smart card that contains a unique card number and some security information such as an expiration date or CVVC (CVV) or with a magnetic strip on the back enabling various machines to read and access information. Depending on the issuing bank and the preferences of the client, this may allow the card to be used as an ATM card, enabling transactions at automatic teller machines; or as a debit card, linked to the client's bank account and able to be used for making purchases at the point of sale; or as a credit card attached to a revolving credit line supplied by the bank.
Most payment cards, such as debit and credit cards can also function as ATM cards, although ATM-only cards are also available. Charge and proprietary cards cannot be used as ATM cards. The use of a credit card to withdraw cash at an ATM is treated differently to a POS transaction, usually attracting interest charges from the date of the cash withdrawal. Interbank networks allow the use of ATM cards at ATMs of private operators and financial institutions other than those of the institution that issued the cards.
All ATM machines, at a minimum, will permit cash withdrawals of customers of the machine's owner (if a bank-operated machine) and for cards that are affiliated with any ATM network the machine is also affiliated. They will report the amount of the withdrawal and any fees charged by the machine on the receipt. Most banks and credit unions will permit routine account-related banking transactions at the bank's own ATM, including deposits, checking the balance of an account, and transferring money between accounts. Some may provide additional services, such as selling postage stamps.
For other types of transactions through telephone or online banking, this may be performed with an ATM card without in-person authentication. This includes account balance inquiries, electronic bill payments, or in some cases, online purchases (see Interac Online).
ATM cards can also be used on improvised ATMs such as "mini ATMs", merchants' card terminals that deliver ATM features without any cash drawer. These terminals can also be used as cashless scrip ATMs by cashing the receipts they issue at the merchant's point of sale.Payment gateway
A payment gateway is a merchant service provided by an e-commerce application service provider that authorizes credit card or direct payments processing for e-businesses, online retailers, bricks and clicks, or traditional brick and mortar. The payment gateway may be provided by a bank to its customers, but can be provided by a specialised financial service provider as a separate service, such as a payment service provider.
A payment gateway facilitates a payment transaction by the transfer of information between a payment portal (such as a website, mobile phone or interactive voice response service) and the front end processor or acquiring bank.RRN
RRN can refer to:
Relative record number
Resident registration number
Retrieval Reference Number, a key to uniquely identify a card transaction based on the ISO 8583 standard.
Route reestablishment notification
Run River North, a indie folk-rock band from Los Angeles, California.
Rural Reconstruction Nepal, a social development NGO in Nepal.Registration authority
Registration authorities exist for many standards organizations, such as ANNA (Association of National Numbering Agencies for ISIN), the Object Management Group, W3C, IEEE and others. In general, registration authorities all perform a similar function, in promoting the use of a particular standard through facilitating its use. This may be by applying the standard, where appropriate, or by verifying that a particular application satisfies the standard's tenants. Maintenance agencies, in contrast, may change an element in a standard based on set rules – such as the creation or change of a currency code when a currency is created or revalued (i.e. TRL to TRY for Turkish lira). The Object Management Group has an additional concept of certified provider, which is deemed an entity permitted to perform some functions on behalf of the registration authority, under specific processes and procedures documented within the standard for such a role.
An ISO registration authority (RAs) is not authorized to update standards but provides a registration function to facilitate implementation of an International Standard (e.g. ISBN number for books). Frequently, facilitating the implementation of an ISO standard’s requirements is best suited, by its nature, to one entity, an RA. This, de facto, creates a monopoly situation and this is why care needs to be taken with respect to the functions carried out and the fees charged to avoid an abuse of such a situation. In most cases, there is a formal legal contract in place between the standards body, such as the ISO General Secretariat, and the selected registration authority.
ISO registration authorities differ from a maintenance agency. Maintenance agencies are authorized to update particular elements in an International Standard and as a matter of policy, the secretariats of MAs are assigned to bodies forming part of the ISO system (member bodies or organizations to which a member body delegates certain tasks in its country). The membership of MAs and their operating procedures are subject to approval by the Technical Management Board.
While registration authorities for a particular standard typically do not change, the position is not formally guaranteed and is subject to review and reassignment to a different firm or organization. In some cases, the concept of a registration authority may not exist for a standard at all.
By further example, the equivalent registration authority organization for Internet standards is the Internet Assigned Numbers Authority.Semantic service-oriented architecture
A Semantic Service Oriented Architecture (SSOA) is an architecture that allows for scalable and controlled Enterprise Application Integration solutions. SSOA describes a sophisticated approach to enterprise-scale IT infrastructure. It leverages rich, machine-interpretable descriptions of data, services, and processes to enable software agents to autonomously interact to perform critical mission functions. SSOA is technically founded on three notions:
The principles of Service-oriented architecture (SOA);
Standards Based Design (SBD); and
Semantics-based computing.SSOA combines and implements these computer science concepts into a robust, extensible architecture capable of enabling complex, powerful functions.
ISO standards by standard number