Claims:CLAIMS:

We claim:

1. A computer-implemented method, the computer-implemented method comprising:
accessing, by a payment transaction terminal, a Bank Identification Number (BIN) of an issuer associated with a payment card of a cardholder;
identifying, by the payment transaction terminal, whether the BIN is present among a plurality of BINs of a BIN table associated with the payment transaction terminal;
generating, at the payment transaction terminal, a payment transaction request comprising the BIN;
in response to identifying that the BIN is unavailable with the payment transaction terminal, transmitting, by the payment transaction terminal, the payment transaction request and a BIN unavailable message to a server system associated with the payment transaction terminal; and
receiving, by the payment transaction terminal, an authorization response message, wherein the authorization response message is received from the server system when the BIN is available with the server system or with a payment server.

2. The computer-implemented method of claim 1, wherein the server system is an acquirer server, and wherein the payment transaction terminal is one of a Point-of-Sale (POS) terminal, a payment gateway application hosted at a user device, and an Automatic Teller Machine (ATM).

3. The computer-implemented method of claim 2, wherein the authorization response message comprises a payment transaction response received from the issuer and a message indicating that the BIN is available with the server system or with the payment server.

4. The computer-implemented method of claim 2, further comprising:
receiving, by the payment transaction terminal, an authorization response message for declining the payment transaction request from the acquirer server when the BIN is not available with the acquirer server and the payment server.

5. The computer-implemented method of any of the claims 1 to 4, further comprising
updating, by the payment transaction terminal, the BIN table by adding the BIN in a list of the plurality of BINs upon receiving the authorization response message.

6. The computer-implemented method of claim 5, wherein the payment transaction request further comprises at least one of a payment transaction identifier, a payment transaction amount, a payment transaction time, a payment transaction terminal identifier, and an acquirer identifier.

7. The computer-implemented method of claim 5, wherein the BIN unavailable message comprises a data field indicating non-identifiability of the BIN in the BIN table associated with the payment transaction terminal.

8. A computer-implemented method, comprising:
receiving, by a server system, a payment transaction request and a Bank Identification Number (BIN) unavailable message from a payment transaction terminal, the payment transaction request comprising at least a BIN of an issuer associated with a payment card of a cardholder;
identifying, by the server system, whether the BIN is present among a plurality of BIN ranges stored in a database associated with the server system;
in response to identifying that the BIN is not stored in the database, transmitting, by the server system, an authorization request message to a payment server, the authorization request message comprising at least a data element indicating unavailability of the BIN in the database; and
transmitting, by the server system, an authorization response message to the payment transaction terminal, wherein the authorization response message is transmitted to the payment transaction terminal when the BIN is available with the server system or with the payment server.

9. The computer-implemented method of claim 8, wherein the server system is an acquirer server, and wherein the payment transaction terminal is a Point-of-Sale (POS) terminal.

10. The computer-implemented method of claim 8, wherein the server system is an acquirer server, and wherein the payment transaction terminal is a payment gateway application.

11. The computer-implemented method of claim 8, wherein the server system is an acquirer server, and wherein the payment transaction terminal is an Automatic Teller Machine (ATM).

12. The computer-implemented method of any of the claims 9 to 11, wherein the authorization response message comprises a payment transaction response received from the issuer and a message indicating that the BIN is available with the server system or with the payment server.

13. The computer-implemented method of claim 8, further comprising
receiving, by the server system, an authorization response message for declining the payment transaction request, wherein the authorization response message is received from the payment server when the BIN is not available with the payment server and the server system.

14. The computer-implemented method of claim 13, further comprising
storing, by the server system, the BIN in the database in response to receiving the authorization response message for declining the payment transaction request.

15. The computer-implemented method of claim 8, wherein the authorization request message further comprises the payment transaction request, the payment transaction request further comprising at least one of a payment transaction identifier, a payment transaction amount, a payment transaction time, a payment transaction terminal identifier, and an acquirer identifier.

16. The computer-implemented method of claim 8, wherein the BIN unavailable message comprises a data field indicating non-identifiability of the BIN in a BIN table associated with the payment transaction terminal.

17. A system comprising:
a server system; and
a payment transaction terminal communicably coupled with the server system, the payment transaction terminal comprising
a processor, and
a memory storing executable instructions that, when executed by the processor, configure the payment transaction terminal to
access a Bank Identification Number (BIN) of an issuer associated with a payment card of a cardholder,
identify whether the BIN is present among a plurality of BINs of a BIN table associated with the payment transaction terminal,
generate a payment transaction request comprising the BIN,
in response to identification that the BIN is unavailable with the payment transaction terminal, transmit the payment transaction request and a BIN unavailable message to the server system associated with the payment transaction terminal, and
receive an authorization response message, wherein the authorization response message is received from the server system when the BIN is available with the server system or with a payment server, and
wherein the server system comprises
at least one processor, and
a memory storing executable instructions that, when executed by the at least one processor, configure the server system to
receive a payment transaction request and the BIN unavailable message from the payment transaction terminal,
identify whether the BIN is present among a plurality of BIN ranges stored in a database associated with the server system,
in response to identification that the BIN is not stored in the database, transmit an authorization request message to a payment server, the authorization request message comprising at least a data element indicating unavailability of the BIN in the database, and
transmit the authorization response message to the payment transaction terminal.

18. The system of claim 17, wherein the server system is an acquirer server and the payment transaction terminal is one of a Point-of-Sale (POS) terminal, a payment gateway application hosted at a user device, and an Automatic Teller Machine (ATM).

19. The system of claim 17, wherein the server system is an acquirer server and wherein the payment transaction terminal is further configured to receive an authorization response message for declining the payment transaction request, wherein the authorization response message is received from the acquirer server when the BIN is not available with the acquirer server and the payment server.

20. The system of claim 17, wherein the BIN unavailable message comprises a data field indicating non-identifiability of the BIN in a BIN table associated with the payment transaction terminal. , Description:FORM 2
THE PATENTS ACT 1970
(39 of 1970)
&
The Patent Rules 2003
COMPLETE SPECIFICATION
(refer section 10 & rule 13)

1. TITLE OF THE INVENTION:
ELECTRONIC METHODS AND SYSTEMS FOR REAL-TIME IDENTIFICATION AND ACCEPTANCE OF PAYMENT CARDS AT TRANSACTION TERMINALS

2. APPLICANT(S):

(a) Name:

(b) Nationality:

(c) Address:

MASTERCARD INTERNATIONAL INCORPORATED

United States of America

2000 Purchase Street, Purchase, NY 10577, United States of America

3. PREAMBLE TO THE DESCRIPTION

The following specification particularly describes the invention and the manner in which it is to be performed.

4. DESCRIPTION
(See next page)

ELECTRONIC METHODS AND SYSTEMS FOR REAL-TIME IDENTIFICATION AND ACCEPTANCE OF PAYMENT CARDS AT TRANSACTION TERMINALS

TECHNICAL FIELD

[0001] The present disclosure relates to electronic methods and systems for real-time identification and acceptance of payment cards at payment transaction terminals and, more particularly to, real-time validation of a bank identification number (BIN) of an issuer associated with a payment card during a payment transaction and providing a real-time update to merchant terminals/acquirers corresponding to issuer identifiers.

BACKGROUND

[0002] Merchant acquiring is an integral part of card payment transactions processing. Merchant acquirers enable merchants to accept card payments by acting as a link among merchants, issuers, and payment networks-providing authorization, clearing and settlement, dispute management, and information services to merchants. Additionally, merchant acquirers enable merchants to process credit, debit, and prepaid card payments and help in increasing sales by accepting the most popular cards to attract customers to their businesses.
[0003] Generally, a payment card number includes a sixteen-digit account number and is allocated in accordance with International Organization for Standardization (ISO). The sixteen-digit card number may include a four-digit or six-digit Issuer Identification Number (IIN) or Bank Identification Number (BIN), which may be a variable length account number of up to twelve digits and a single check digit. The first digit of the six digits BIN may include a Major Industry Identifier (MII), which represents the category of an entity that issued the payment account. For example, a value of the MII digit equal to 3, 4, 5, or 6 currently implies a banking or financial institution. The BIN or IIN number may serve to identify a financial institution that issued a payment card to an account holder. For example, a BIN range of 51-55 (i.e., all BIN values beginning with 51, 52, 53, 54, or 55) may indicate that the associated issuing network is Mastercard®. Thus, different issuing networks may use different BIN values and/or ranges to identify the payment network.
[0004] BIN values are often used to assist in determining how to “route” financial transaction data to an issuer of a payment account. Generally, merchant terminals and merchant acquirers utilize BIN tables to determine which payment network is to be used to route a transaction. These BIN tables, also commonly referred to as BIN routing tables or BIN databases, often include entries such that each entry maps a BIN of a payment card to a particular payment network (or, to a specific endpoint within the payment network within which it resides) to be used for routing transactions having that BIN of an issuer. Thus, upon receipt of transaction information (e.g., a payment transaction request message) from a merchant terminal including a card number of the payment card in the transaction, a merchant acquirer may identify the BIN portion of the card number and use it as an index into the BIN table to identify the payment network to be used to route the transaction information towards a correct issuer.
[0005] When a BIN is issued to an issuer by a payment network, the BIN is added to a payment network database and respective payment network broadcasts files containing newly added/modified BINs along with Product code. These files are shared with all the acquiring banks at their end points through a file transfer mechanism on a periodic basis (weekly) to make them aware of the new BIN issuance. Then, the acquirers manually download the broadcasted BINs and upload or configure the newly issued BINs to merchant terminals and payment gateways to ensure smooth acceptance of payment cards issued by the issuer at POS terminals and/or at e-commerce interface.
[0006] However, sometimes, the acquirer misses to update a BIN file to the acquiring terminals and payment gateways associated with the acquirer. Therefore, the acquiring terminals and payment gateways fail to recognize a payment transaction request through a payment card of which BIN is not available at the acquiring terminals and payment gateways. In such scenarios, the payment transaction may get failed. Further, as the payment transaction request is not sent to the acquirers, it leads to non-awareness about payment failure at acquires, issuers, and payment networks. Based on the foregoing, it is noted that payment card acceptance at the merchant terminals and the payment gateways is decreased due to non-identifiability of the BIN of the payment card. Further, when the cardholder reports about the payment failure to issuers and payment networks, it becomes a cumbersome manual task for payment networks/issuers to spot the right merchant and track the associated acquirer to request for updating the newly issued BINs.
[0007] Therefore, there is a need for a technical solution to increase payment card acceptance at acquiring terminals and to limit failure payment transaction scenarios due to non-identifiability of the BIN at acquiring terminals.
SUMMARY

[0008] Various embodiments of the present disclosure provide systems, methods, electronic devices and computer program products for facilitating real-time validation of a Bank Identification Number (BIN) of an issuer associated with a payment card during a payment transaction.
[0009] In an embodiment, a computer-implemented method is disclosed. The computer-implemented method performed at a payment transaction terminal includes accessing a Bank Identification Number (BIN) of an issuer associated with a payment card of a cardholder, identifying whether the BIN is present among a plurality of BINs of a BIN table associated with the payment transaction terminal. The computer-implemented method includes generating, at the payment transaction terminal, a payment transaction request comprising the BIN, and transmitting the payment transaction request and a BIN unavailable message to a server system associated with the payment transaction terminal in response to identifying that the BIN is unavailable with the payment transaction terminal. The computer-implemented method includes receiving an authorization response message from the server system when the BIN is available with the server system or with a payment server.
[0010] In another embodiment, a computer-implemented method is disclosed. The computer-implemented method performed at a server system includes receiving a payment transaction request and a Bank Identification Number (BIN) unavailable message from a payment transaction terminal. The payment transaction request includes at least a BIN of an issuer associated with a payment card of a cardholder. The computer-implemented method includes identifying whether the BIN is present among a plurality of BIN ranges stored at a database associated with the server system. In response to identifying that the BIN is not stored at the database, the computer-implemented method includes transmitting an authorization request message to a payment server. The authorization request message includes at least a data element indicating unavailability of the BIN in the database. Further, the computer-implemented method includes transmitting an authorization response message to the payment transaction terminal, when the BIN is available with the server system or with the payment server.
[0011] In yet another embodiment, a system is disclosed. The system includes a server system and a payment transaction terminal. The payment transaction terminal, communicably coupled with the server system, includes a processor and a memory storing executable instructions. The processor executes the executable instructions stored in the memory to configure the payment transaction terminal to access a Bank Identification Number (BIN) of an issuer associated with a payment card of a cardholder, identify whether the BIN is present among a plurality of BINs of a BIN table associated with the payment transaction terminal, and generate a payment transaction request comprising the BIN. The payment transaction terminal is configured to transmit the payment transaction request and a BIN unavailable message to the server system associated with the payment transaction terminal in response to identification that the BIN is unavailable with the payment transaction terminal, and receive an authorization response message from the server system when the BIN is available with the server system or with a payment server. The server system includes at least one processor and a memory storing executable instructions. The at least one processor executes the executable instructions to configure the server system to receive a payment transaction request and the BIN unavailable message from the payment transaction terminal and identify whether the BIN is present among a plurality of BIN ranges stored in a database associated with the server system. The server system is configured to transmit an authorization request message to a payment server, the authorization request message comprising at least a data element indicating unavailability of the BIN in the database in response to identification that the BIN is not stored in the database. The server system is further configured to transmit the authorization response message to the payment transaction terminal.

BRIEF DESCRIPTION OF THE FIGURES

[0012] For a more complete understanding of example embodiments of the present technology, reference is now made to the following descriptions taken in connection with the accompanying drawings in which:
[0013] FIG. 1 is an example representation of an environment, related to at least some example embodiments of the present disclosure;
[0014] FIG. 2A is a sequence flow diagram for real-time validation a Bank identification Number (BIN) corresponding to a payment card of a cardholder, in accordance with an example embodiment;
[0015] FIG. 2B is a sequence flow diagram for real-time validation the BIN corresponding to the payment card of the cardholder, in accordance with another example embodiment;
[0016] FIG. 3A represents an example representation for validating the BIN of the payment card on a real-time basis using a POS terminal, in accordance with an example embodiment;
[0017] FIG. 3B represents an example representation for validating the BIN of a payment card on a real-time basis using a user device hosting a payment gateway application, in accordance with an example embodiment;
[0018] FIG. 4 represents a flow diagram of a method performed at a payment transaction terminal for real-time validation of the BIN corresponding to the payment card of the cardholder, in accordance with an example embodiment.
[0019] FIG. 5 represents a flow diagram of a method performed at a server system for real-time validation of a BIN corresponding to the payment card of the cardholder, in accordance with an example embodiment.
[0020] FIG. 6 is a simplified block diagram of a server system for real-time validation of the BIN corresponding to the payment card of the cardholder, in accordance with one embodiment of the present disclosure;
[0021] FIG. 7 is a simplified block diagram of a POS terminal for real-time validation of the BIN corresponding to the payment card of the cardholder, in accordance with one embodiment of the present disclosure;
[0022] FIG. 8 is a simplified block diagram of an acquirer server used for real-time validation of the BIN corresponding to the payment card of the cardholder, in accordance with an embodiment of the present disclosure
[0023] FIG. 9 is a simplified block diagram of a payment server used for real-time validating the BIN corresponding to the payment card of the cardholder, in accordance with one embodiment of the present disclosure; and
[0024] FIG. 10 is a simplified block diagram of a user device associated with the cardholder capable of implementing at least some embodiments of the present disclosure.
[0025] The drawings referred to in this description are not to be understood as being drawn to scale except if specifically noted, and such drawings are only exemplary in nature.

DETAILED DESCRIPTION

[0026] In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present disclosure. It will be apparent, however, to one skilled in the art that the present disclosure can be practiced without these specific details.
[0027] Reference in this specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. The appearance of the phrase “in an embodiment” in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Moreover, various features are described which may be exhibited by some embodiments and not by others. Similarly, various requirements are described which may be requirements for some embodiments but not for other embodiments.
[0028] Moreover, although the following description contains many specifics for the purposes of illustration, anyone skilled in the art will appreciate that many variations and/or alterations to said details are within the scope of the present disclosure. Similarly, although many of the features of the present disclosure are described in terms of each other, or in conjunction with each other, one skilled in the art will appreciate that many of these features can be provided independently of other features. Accordingly, this description of the present disclosure is set forth without any loss of generality to, and without imposing limitations upon, the present disclosure.
[0029] The term "payment account" used throughout the description and refers to a financial account that is used to fund the financial transaction (interchangeably referred to as "payment transaction"). Examples of the payment account include, but are not limited to a savings account, a credit account, a checking account and a virtual payment account. The payment account may be associated with an entity such as an individual person, a family, a commercial entity, a company, a corporation, a governmental entity, a non-profit organization and the like. In some scenarios, a payment account may be a virtual or temporary payment account that can be mapped or linked to a primary payment account, such as those accounts managed by payment wallet service providers.
[0030] The term “bank identification number” and “BIN”, commonly used throughout the description, refer to an identifier in a card number for identifying a card issuer (and such terms are used for convenience herein) where the card issuer needs not to be a “bank,” but rather could be any financial institution or other organization that issues prepaid debit cards. Thus, as used herein, “BIN” may refer to any kind of issuer identifier, whether the issuer is a bank or not.
[0031] The term "payment network", used throughout the description, refers to a network or collection of systems used for transfer of funds through use of cash-substitutes. Payment networks may use a variety of different protocols and procedures in order to process the transfer of money for various types of transactions. Transactions that may be performed via a payment network may include product or service purchases, credit purchases, debit transactions, fund transfers, account withdrawals, etc. Payment networks may be configured to perform transactions via cash-substitutes, which may include payment cards, letters of credit, checks, financial accounts, etc. Examples of networks or systems configured to perform as payment networks include those operated by various payment interchange networks such as Mastercard®.
[0032] The term "payment transaction terminal" used throughout the description, refer to point of sale (POS) terminals, computers or data processing devices for processing payment at merchant locations, payment gateways and/or merchant online interface for allowing customers, cardholders, or account holders to make offline and/or online purchases. The payment transaction terminal may be construed as any virtual or physical electronic system that accepts the cardholder's payment transaction requests, and forwards such requests to any of the entities such as acquirer server, payment interchange servers (e.g., payment server) and/or issuer server for the purposes of carrying out the payment transaction.
OVERVIEW
[0033] Various example embodiments of the present disclosure provide methods, systems, user devices and computer program products for real-time validation of the BIN associated with a payment card during a payment transaction, thereby increasing payment card acceptance rate at payment transaction terminals and curtailing dependency on merchant acquirers to provide an updated BIN file to their respective payment transaction terminals.
[0034] In an embodiment, a cardholder or a customer presents his/her payment card at a payment transaction terminal of a merchant for purchasing goods or services. In one non-limiting example, the payment transaction terminal maybe, but not limited to, a Point-of-Sale (POS) terminal, an online payment gateway, a merchant computer, an Automatic Teller Machine (ATM) terminal, etc. The payment transaction terminal is configured to access card details associated with the payment card. The payment transaction terminal is configured to access the BIN associated with the payment card and identify whether the BIN is present among a plurality of BINs available in a BIN table of the payment transaction terminal. In one embodiment, the payment transaction terminal is configured to compare the BIN with the plurality of BINs. Thereafter, the payment transaction terminal is configured to generate a payment transaction request. The payment transaction request may include, but is not limited to, the BIN of an issuer associated with the payment card, a payment transaction identifier, a payment transaction amount, a payment transaction date/time, a payment transaction terminal identifier, an acquirer identifier, etc. If the BIN is not available with the payment transaction terminal, the payment transaction terminal is configured to generate a BIN unavailable message indicating non-identifiability of the BIN. The payment transaction terminal is further configured to transmit the BIN unavailable message along with the payment transaction request to a server system (i.e., “an acquirer server”) associated with the payment transaction terminal.
[0035] The acquirer server is configured to identify whether the BIN is available or stored in an acquirer database associated with the acquirer server or not. If the BIN is available with the acquirer server, the acquirer server is configured to determine a payment network to which the payment transaction request should be routed based at least on the BIN and other cost optimizing factors and transmit the payment transaction request to the payment network for routing the payment transaction request to the issuer of the payment card.
[0036] In one embodiment, if the BIN is not available with the acquirer server, the acquirer server is configured to send an authorization request message, including the payment transaction request and a message indicating that the BIN is not available with the acquirer server, to a payment server of the payment network. Then, the payment server is configured to determine the validity of the BIN. For determining the validity of the BIN, the payment server is configured to determine the availability of the BIN in a payment network database associated with the payment server.
[0037] If the BIN is available with the payment server (i.e., “the BIN is assigned to an issuer”), the payment transaction request is sent to the issuer. If the issuer approves the payment transaction, the acquirer server is configured to receive an authorization response message from the payment server for successful authorization and then the authorization response message is sent to the payment transaction terminal.
[0038] If the BIN is unavailable with the payment server (i.e., “the BIN is not assigned to any issuer”), the acquirer server is configured to receive an authorization response message from the payment server for declining the payment transaction request and then the authorization response message is sent to the payment transaction terminal. Further, the acquirer server is configured to store the BIN at its end for tracking failure payment transactions due to the unavailability of the BIN at the acquirer server and the payment server.
[0039] Various embodiments of the present disclosure offer multiple advantages and technical effects. For instance, the present disclosure provides an automated system for a real-time update of BINs to payment transaction terminals to address any BIN related issues on the payment transaction terminals, while performing payment transactions using payment cards. Further, the present disclosure eliminates payment card non-acceptance issues, resulting in a boost in revenue and transaction volumes for payment networks considerably. Additionally, the present disclosure provides an alternative way for payment networks of updating the BIN file at associated acquirers and reduces dependency on acquirers for updating the BIN file at payment transaction terminals.
[0040] Various example embodiments of present disclosure are described hereinafter with reference to FIGS. 1 to 10.
[0041] FIG. 1 illustrates an exemplary representation of an environment 100 related to at least some example embodiments of the present disclosure. The environment 100 generally includes an acquirer server 102, one or more issuer servers 104 (others not shown for the sake of clarity), multiple payment networks 106a and 106b each coupled to, and in communication with (and/or with access to) a network 110. The multiple payment networks 106a and 106b may be associated with payment servers 108a and 108b, respectively. The network 110 may include, without limitation, a local area network (LAN), a wide area network (WAN) (e.g., the Internet), a mobile network, a virtual network, and/or another suitable public and/or private network capable of supporting communication among two or more of the entities illustrated in FIG. 1, or any combination thereof. For example, the network 110 may include multiple different networks, such as a private network made accessible by the multiple payment networks 106a and 106b to the acquirer server 102 and the issuer server 104, and, separately, a public network (e.g., the Internet) through which the acquirer server 102, the issuer server 104, and the payment servers 108a and 108b may communicate. In one embodiment, the payment servers 108a and 108b have payment network databases 114a and 114b, respectively.
[0042] In one embodiment, the acquirer server 102 is associated with a financial institution (e.g., a bank) that processes credit card transactions. This can be an institution that facilitates the processing of transactions for physical stores, merchants, or an institution that owns platforms that make online purchases or purchases made via software applications possible (e.g., shopping cart platform providers and in-app payment processing providers).
[0043] The environment 100 also includes a payment transaction terminal 116 that communicate directly or indirectly with the acquirer server 102. Examples of the payment transaction terminal 116 include, but are not limited to a Point-of-Sale (POS) terminal 122 and a payment gateway application 124. The payment transaction terminal 116 is usually located at stores or facilities of a merchant. A merchant can have more than one payment transaction terminal. The payment transaction terminal 116 (the POS terminal 122 and the payment gateway application 124) should support various Bank Identification Number (BIN) range table provided by the acquirer server 102. In general, a BIN range table is a list of instructions that provides acquirers accurate and current account range assignment information for routing payment transactions globally.
[0044] In one embodiment, the payment transaction terminal 116 may be, but not limited to, a Point-of-Sale (POS) terminal, an ecommerce internet website, an Automatic Teller Machine (ATM) terminal, a payment card reader such as a magnetic card reader or smart card reader (e.g., an EMV card reader or a contactless card reader) or a virtual wallet reader.
[0045] The environment 100 also includes a cardholder 120 who may operate a user device 126 to conduct payment transaction through the payment gateway application 124. The cardholder 120 may also use a payment card 118 (e.g., “swipe” or present the payment card 118) at the POS terminal 122.
[0046] The cardholder 120 may be any individual buyer, representative of a corporate entity, or any other person that is presenting credit or debit card during a transaction with a merchant representative or other seller. The cardholder 120 may have a payment account issued by an issuing bank (associated with the issuer server 104) and may be provided the payment card 118 with financial or other account information encoded onto the payment card 118 such that the cardholder 120 may use the payment card 118 to initiate and complete a transaction using a bank account at the issuing bank 104. Non-financial transactions may also be completed using the payment card 118 provided by an issuer but in the interest of brevity, the system of FIG. 1 focuses on a payment transaction.
[0047] The user device 126 may be any electronic device such as, but not limited to, a personal computer (PC), a tablet device, a Personal Digital Assistant (PDA), a voice activated assistant, a Virtual Reality (VR) device, a smartphone, or a laptop.
[0048] In one embodiment, the issuer server 104 is associated with a financial institution normally called as an "issuer bank" or "issuing bank" or simply "issuer", in which the cardholder 120 may have a payment account, (which also issues a payment card, such as a credit card or a debit card), and provides microfinance banking services (e.g., payment transaction using credit/debit cards) for processing electronic payment transactions, to the cardholder 120.
[0049] In one embodiment, the payment network 106a or the payment network 106b may be used by the payment cards issuing authorities as a payment interchange network. Examples of payment interchange network include, but are not limited to, Mastercard® payment system interchange network. The Mastercard® payment system interchange network is a proprietary communications standard promulgated by Mastercard International Incorporated® for the exchange of financial transaction data between issuers and acquirers that are members of Mastercard International Incorporated®. (Mastercard is a registered trademark of Mastercard International Incorporated located in Purchase, N.Y.).
[0050] The payment card 118 may interact with the payment transaction terminal 116 (e.g., a point-of-sale (POS) terminal) in order to initiate the processing of a transaction. The payment card 118 may have the account information encoded (or otherwise contained) on the payment card 118, which may be accessible to the payment transaction terminal 116. The account information may be encoded or contained on the payment card 118 through any suitable method such as in form or chip, or as magnetic storage. Further, a payment card 118 may include any suitable element, component, or mechanism for initiating a payment transaction. For example, the payment card 118 may have a magnetic stripe, near-field communication (NFC) element, security cards, access cards, 2-D barcodes, or any other communication components to transfer information to the payment transaction terminal 116.
[0051] In an exemplary purchase transaction, the cardholder 120 purchases a good or service from a merchant using the payment card 118. The cardholder 120 may utilize the payment card 118 to effectuate payment by presenting/swiping the payment card 118 to the POS terminal 122. Upon presentation of the physical or virtual payment card, account details (i.e., account number) are accessed by the POS terminal 122.
[0052] In one example, the cardholder 120 may tap the payment card 118 on an NFC reader present in the POS terminal 122. Alternatively, in another example, the cardholder 120 may provide payment details to the merchant electronically, via a digital wallet (e.g., the payment gateway application 124) or through an online transaction, using the user device 126.
[0053] To initiate the payment transaction, the payment transaction terminal 116 is configured to access the BIN of the payment card 118. The payment transaction terminal 116 is configured to identify whether the BIN associated with the payment card is present among a plurality of BINs available with the payment transaction terminal 116. The plurality of BINs has already been stored in a BIN table at the payment transaction terminal 116 by the acquirer server 102 using file transfer mechanisms (or other data transfer mechanism) on a periodic or need basis. In one embodiment, the payment transaction terminal 116 is configured to compare or look-up the BIN against the plurality of BINs stored at the payment transaction terminal 116.
[0054] Thereafter, a payment transaction request may be generated by the payment transaction terminal 116. The payment transaction request may include, but is not limited to, BIN of the issuer (e.g., issuer server 104) of the payment card 118, a payment transaction identifier, a payment transaction amount, a payment transaction date/time, a payment transaction terminal identifier, an acquirer identifier etc. In one embodiment, the payment transaction request may be an electronic message that is sent via the payment network 106a to the issuer of the payment card (e.g., issuer server 104) to request authorization for a payment transaction. The payment transaction request may comply with a message type defined by an International Organization for Standardization (ISO) 8583 standard, which is a standard for systems that exchange electronic transaction information associated with payments made by users using the payment card 118, or the payment account.
[0055] In one embodiment, upon identifying that the BIN is not available with the payment transaction terminal 116, the payment transaction terminal 116 is configured to send the payment transaction request to a server system such as the acquirer server 102. Generally, the payment transaction terminal 116 is configured to send the payment transaction request to the acquirer server 102 with which it is affiliated. The acquirer server 102 uses the BIN in the card number (alone or in conjunction with other factors, such as least cost routing) to look up or determine a payment network (i.e., the payment network 106a) to which the payment transaction should be routed. The payment network 106a checks card security features, determines the cardholder's bank, and sends the payment transaction request to the cardholder's issuing bank 104 for transaction approval. The cardholder issuing bank 104 then decides whether to approve the purchase and sends a message containing its approval or decline back to the acquirer server 102. In turn, the acquirer server 102 sends the approval or decline message back to the merchant. If approved, the cardholder 120 completes the purchase.
[0056] In another embodiment, upon identifying that the BIN is not available with the payment transaction terminal 116, the payment transaction terminal 116 is configured to transmit the payment transaction request along with a BIN unavailable message, to the acquirer server 102. The BIN unavailable message represents a data element indicating non-identifiability of the BIN associated with the payment card 118 at the payment transaction terminal 116. After receiving the BIN unavailable message, the acquirer server 102 is configured to determine availability of the BIN at an acquirer database 112. The acquirer database 112 is configured to store a plurality of BIN ranges received from a payment server on a periodic basis.
[0057] If the BIN is stored at the acquirer database 112, the acquirer server 102 is configured to route the payment transaction request to the issuer server 104 through the payment network 106a for completing the payment transaction.
[0058] If the BIN is not stored at the acquirer database 112, the acquirer server 102 is configured to send an authorization request message to the payment server 108a associated with the payment network 106a. The acquirer server 102 uses the BIN in the card number (alone or in conjunction with other factors, such as least cost routing) to look up or determine the payment network 106a to which the transaction should be routed. The authorization request message includes, but is not limited to, the payment transaction request and a message indicating unavailability of the BIN among the plurality of BIN ranges at the acquirer database 112. It should be noted that messages within a payment network such as payment networks 106a and 106b may, in at least some examples, conform to International Organization for Standardization (ISO) Standard or any such standard in force from time to time. For instance, the authorization request message may comply with a message type defined by the International Organization for Standardization (ISO) 8583 standard.
[0059] The payment server 108a is configured to determine validity of the BIN. For determining validity, the payment server 108a is configured to check availability of the BIN in a payment network database 114a. If the BIN is available at the payment network database 114a, the BIN is valid. Thereafter, the payment server 108a is configured to route the payment transaction request to the issuer server 104 for completing the payment transaction.
[0060] After the issuer server 104 receives transaction information (e.g., a payment transaction request), the issuer server 104 sends transaction response information (e.g., a response message) back to the payment network 106a to indicate whether or not current transaction is authorized. Such transaction response information is not illustrated herein to avoid obscuring aspects of some embodiments, but may be easily implemented by those of ordinary skill in the art. A “response message” may be an electronic message reply to a payment transaction request message generated by an issuing financial institution or a payment processing network, and may comply with the ISO 8583 standard. The response message may include, by way of example only, one or more of the following status indicators: Approval-transaction was approved; Decline-transaction was not approved. The response message may also include a code, which may be a code that an issuer returns in response to the payment transaction request message in an electronic message (either directly or through the payment processing network) to the merchant's payment transaction terminal 116 (e.g., a POS terminal) that indicates an approval of a transaction.
[0061] In one embodiment, after reception of transaction approval response message from the issuer server 104, the payment server 108a is configured to send an authorization response to the payment transaction terminal 116 through the acquirer server 102 for successful authorization. Thus, the payment transaction terminal 116 is able to validate issuer identification associated with the payment card 118 even if the BIN is not available with the payment transaction terminal 116 during the payment transaction. Hence, failure of payment transactions due to non-identifiability of the BIN at the payment transaction terminal 116 can be decreased, thereby enhancing payment card acceptance rate at payment transaction terminals.
[0062] In one embodiment, if the BIN is not available at the payment network database 114a (i.e., “the BIN is not assigned to any issuer”), the payment server 108a is configured to send an authorization response to the acquirer server 102 for declining the payment transaction request. In response, the acquirer server 102 is configured to send a response message indicating failure of the payment transaction to the payment transaction terminal 116.
[0063] In one embodiment, the acquirer server 102 is configured to facilitate storing the BIN associated with the payment transaction request for traceability of failure payment transactions in a payment ecosystem.
[0064] Turning now to FIG. 2A, a sequence flow diagram 200 for real-time validation of the BIN associated with the payment card 118 during a payment transaction process, is shown, in accordance with an example embodiment. The sequence of operations of the sequence flow diagram 200 may not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped together and performed in form of a single step, or one operation may have several sub-steps that may be performed in parallel or in sequential manner.
[0065] At 205, a cardholder (e.g., the cardholder 120) presents his/her payment card 118 at a payment transaction terminal 116 (e.g., POS terminal 122) associated with a merchant. In one non-limiting example, the cardholder 120 may enter card details on a payment transaction terminal 116 (e.g., online payment gateway). For the sake of convenience, the sequence flow diagram 200 is described in view of the POS terminal 122. In one example, a customer swipes his credit card with a card number “4546210071562187” belonging to an issuer “XYZ NATIONAL BANK” at a POS terminal located at a supermarket. The first four digits of the card number (i.e., “4546”) represent a BIN or an issuer identifier of the issuer.
[0066] At 210, the POS terminal 122 accesses the BIN (i.e., “4546”) associated with the payment card 118.
[0067] At 215, the POS terminal 122 identifies whether the BIN (i.e., “4546”) is present among a plurality of BINs stored in a BIN table associated with the POS terminal 122.
[0068] At 220, the POS terminal 122 initiates a payment transaction request. The POS terminal accesses the card details for initiating the payment transaction request. The payment transaction request may include, but not limited to, BIN (i.e., “4546”) of the issuer, a transaction identifier, a transaction amount, a transaction date/time, a payment transaction terminal identifier and an acquirer identifier.
[0069] At 225, if the BIN is not stored in the BIN table associated with the POS terminal 122, the POS terminal 122 sends the payment transaction request along with a BIN unavailable message to the acquirer server 102. The BIN unavailable message indicates that the POS terminal 122 is not able to identify the BIN (i.e., “4546”) of the payment card 118.
[0070] At 230, the acquirer server 102 identifies whether the BIN (i.e., “4546”) is stored at the acquirer database 112 or not. The acquirer database 112 stores a BIN file which is received from the payment server (i.e., payment server 108a) on a regularly basis. In one embodiment, if the BIN is available at the acquirer database 112, the acquirer server 102 forwards the payment transaction request to the payment server 108a for routing the payment transaction request to the issuer. In one embodiment, the acquirer server 102 sends an authorization response to the POS terminal 122 for successful authorization when the issuer approves the payment transaction.
[0071] At 235, if the BIN (i.e., “4546”) is not available at the acquirer database 112, the acquirer server 102 sends an authorization request message to the payment server 108a. The authorization request message includes, but is not limited to, the payment transaction request and a data field indicating that the acquirer server 102 is not aware of the BIN (i.e., “4546”) associated with the payment card 118. In one embodiment, the acquirer server 102 determines a payment server (e.g., “the payment server 108a”) to which the payment transaction should be routed, based on the BIN (i.e., “4546”).
[0072] At 240, the payment server 108a checks validity of the BIN (i.e., “4546”) by determining availability of the BIN (i.e., “4546”) at the payment network database 114a.
[0073] At 245, if the BIN (i.e., “4546”) is available at the payment network database 114a (i.e., “the BIN is valid”), the payment server 108a forwards the payment transaction request to the issuer server 104 for transaction approval.
[0074] At 250, the payment server 108a sends an authorization response to the POS terminal 116 for successful authorization of the BIN (i.e., “4546”) to the POS terminal 116.
[0075] At 255, the POS terminal 116 updates the BIN table by adding the BIN (i.e., “4546”). In one embodiment, the acquirer server 102 may also broadcast the BIN (i.e., “4546”) to all other payment transaction terminals associated with the acquirer bank 102.
[0076] Referring now to FIG. 2B, a sequence flow diagram 202 for real-time validation of the BIN associated with the payment card 118 during a payment transaction process, is shown, in accordance with an example embodiment. The sequence of operations of the sequence flow diagram 200 may not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped together and performed in form of a single step, or one operation may have several sub-steps that may be performed in parallel or in sequential manner. The process in FIG. 2B remains same till step 240 as described with reference to FIG. 2A. At the step 240, the payment server 108a checks validity of the BIN (i.e., “4546”) by determining availability of the BIN (i.e., “4546”) at the payment network database 114a. For the sake of brevity, the detailed explanation till the step 240 is omitted herein with reference to FIG. 2B.
[0077] At 260, if the BIN (i.e., “4546”) is not available at the payment network database 114a (i.e., “the BIN is invalid”), the payment server 108a sends an authorization response to the POS terminal 116 via the acquirer server 102 for declining the payment transaction request. The authorization response represents a data element indicating that the BIN is not assigned to any valid issuer.
[0078] At 265, the acquirer server 102 stores the BIN (i.e., “4546”) associated with declined payment transaction in the acquirer database 112 for tracking the failure payment transactions occurred due to unavailability of the BIN associated with the payment card 118.
[0079] FIG. 3A represents an example representation 300 for validating the BIN of the payment card 118 on a real-time basis using the POS terminal 122, in accordance with an example embodiment.
[0080] In one example implementation, face of the payment card 118 displays 16-digit card number including the BIN (see 302, “4147”). The BIN is associated with an issuer (see 304, “XYZ Bank”). The issuer (see 304, “XYZ Bank”) is a recently registered bank with the payment network 106a. During registration, the issuer gets an issuer identifier or the BIN (see 302, “4147”) from the payment network 106a or the payment network 106b. When the customer swipes/dips the payment card 118 at the POS terminal 122, the POS terminal 122 extracts the BIN associated with the payment card 118 for determining issuer identification. Then, the POS terminal 122 checks availability of the BIN in a BIN table 306, which is associated with the POS terminal 122. The BIN table 306 includes a plurality of BIN ranges associated with card issuers, which is received from the acquirer server 102 on a periodic basis. Thereafter, the POS terminal 122 generates a payment transaction request (see 308) using accessed payment card details and merchant information.
[0081] As, the BIN (see 302, “4147”) is not present in the BIN table 306 associated with the POS terminal 116, therefore, the POS terminal 122 triggers a BIN unavailable message (see 310) indicating non-identifiability of the BIN (i.e., “4147”) along with the payment transaction request (see 308) to the acquirer server 102. The acquirer server 102 checks whether the BIN is available in a BIN file 318 stored at the acquirer database 112. If the BIN is not stored in the BIN file 318 associated with acquirer database 112, the acquirer server 102 sends an authorization request message (see 312) including the payment transaction request and a data element indicating non-awareness of the BIN at the acquirer server 102, to the payment server 108a. In one embodiment, the acquirer server 102 determines a payment server (e.g., payment server 108a) through which the payment transaction should be routed, based on the BIN. The payment server 108a determines availability of the BIN in the payment network database 114a. If the BIN is available in the payment network database 114a, the payment transaction request is forwarded to the issuer server 104. An authorization response (see 314) for successful authorization is sent to the acquirer server 102 that is further communicated to the POS terminal 116 when the BIN is available with the payment server 108a and a response message (see 316) indicates a payment transaction approval.
[0082] FIG. 3B represents an example representation 320 for validating the BIN of the payment card 118 on a real-time basis using the user device 126 hosting a payment gateway application 124, in accordance with an example embodiment.
[0083] In one example implementation, the payment gateway application 124 (see 322) is installed on the user device 126. The payment gateway application 124 provides an interactive user interface which allows the cardholder 120 to enter a card number including the BIN (i.e., “4147”) on the user device 126. The payment gateway application 124 sends payment card details to a payment gateway server 324 associated with the payment gateway application 124. Then, the payment gateway server 324 initiates a payment transaction request (see 308) and accesses the BIN associated with the payment card. The payment gateway server 324 then determines availability of the BIN in its own database. If the BIN is not available with the payment gateway server 324, the payment gateway server 324 sends the payment transaction request (see 308) along with the BIN unavailable message (see 310) to the acquirer server 102. Thereafter, the process remains same as described with reference to FIG. 3A. For the sake of brevity, the detailed explanation is omitted herein with reference to FIG. 3B.
[0084] FIG. 4 illustrates a flow diagram of a method 400 for validating a BIN associated with a payment card of a cardholder on a real-time basis, in accordance with an example embodiment. The method 400 depicted in the flow diagram may be executed by, for example, the at least one payment transaction terminal 116 such as, a POS terminal 122 or a merchant payment gateway application 124 through the user device 126. Operations of the method 400, and combinations of operation in the method 400, may be implemented by, for example, hardware, firmware, a processor, circuitry and/or a different device associated with the execution of software that includes one or more computer program instructions. The method 400 starts at operation 402.
[0085] At 402, the method 400 includes accessing, by the payment transaction terminal 116, a BIN associated with the payment card. The payment transaction terminal 116 accesses the BIN by extracting first four digit of a card number of the payment card 118.
[0086] At 404, the method 400 includes identifying, by the payment transaction terminal 116, whether the BIN is present among a plurality of BINs of a BIN table associated with the payment transaction terminal. The BIN table may be associated with the payment transaction terminal 116 and stores a plurality of BIN ranges of card issuers.
[0087] At 406, the method 400 includes generating, at the payment transaction terminal 116, a payment transaction request associated with the payment card 118 of the cardholder 120. The payment transaction request includes, but is not limited to, the BIN of an issuer associated with the payment card, a payment transaction identifier, a payment transaction amount, a payment transaction date/time, a payment transaction terminal identifier, an acquirer identifier etc.
[0088] At 408, the method 400 includes transmitting, by the payment transaction terminal 116, the payment transaction request and a BIN unavailable message to a server system (i.e. “the acquirer server 102”) associated with the payment transaction terminal 116 in response to determining that the BIN is unavailable with the payment transaction terminal 116. The BIN unavailable message indicates that the payment transaction terminal 116 could not identify the BIN associated with the payment card 118.
[0089] At 410, the method 400 includes receiving, by the payment transaction terminal 116, an authorization response message from the acquirer server 102. The authorization response message is received from the server system (i.e., “acquirer server 102”), when the BIN is available at the server system (i.e., “acquirer server 102”) or at a payment server 108a. The authorization response message may include, but not limited to, a payment transaction response received from the issuer server 104 and a data element indicating that the BIN is available at the payment server 108a.
[0090] In one embodiment, the method 400 includes updating the BIN table by adding the BIN associated with the payment card 118, when the BIN is available at the acquirer server 102 or at the payment server 108a.
[0091] In one embodiment, the method 400 includes receiving an authorization response message for declining the payment transaction request when the BIN is unavailable at the payment server 108a.
[0092] Referring now to FIG. 5, illustrates a flow diagram of a method for real-time validation of a BIN corresponding to the payment card 118 of the cardholder 120, in accordance with an example embodiment. The method 500 depicted in the flow diagram may be executed by, for example, a server system such as, the acquirer server 102. Operations of the flow diagram 500, and combinations of operation in the flow diagram 500, may be implemented by, for example, hardware, firmware, a processor, circuitry and/or a different device associated with the execution of software that includes one or more computer program instructions. The method 500 starts at operation 502.
[0093] At 502, the method 500 includes receiving, by the server system (i.e., “acquirer server 102”), a payment transaction request and a BIN unavailable message from a payment transaction terminal 116. The payment transaction request includes, but is not limited to, a BIN of an issuer (e.g., issuer server 104) associated with the payment card 118, a transaction identifier, a transaction amount, a transaction date/time, a payment transaction terminal identifier, an acquirer identifier etc. The BIN unavailable message indicates that the payment transaction terminal 116 could not identify the BIN associated with the payment card 118.
[0094] At 504, the method 500 includes identifying, by the server system (i.e., “acquirer server 102”), whether the BIN is present among a plurality of BINs stored at an acquirer database 112 associated with the acquirer server 102. The plurality of BINs is stored in form of a BIN file (see 318 of FIG. 3A) at the acquirer database 112. The BIN file is utilized for routing the payment transaction request to a correct issuer.
[0095] At 506, the method 500 includes transmitting, by the server system (i.e., “acquirer server 102”), an authorization request message to a payment server 108a or a payment server 108b, when the BIN is not stored at the acquirer database 112. The authorization request message includes, but is not limited to, the payment transaction request and a data field indicating unavailability of the BIN in the acquirer database 112. In one embodiment, the method 500 further includes determining a payment network (e.g., “payment server 108a”) to which the payment transaction request should be routed, based at least on the BIN associated with the payment card and other various parameters.
[0096] At 508, the method 500 includes transmitting, by the server system (i.e., “acquirer server 102”), an authorization response message to the payment transaction terminal 116. The server system (i.e., “acquirer server 102”) receives the authorization response message from the payment server when the BIN is available with the payment server 108a or the server system (i.e., “acquirer server 102”). The authorization response message may include, but not limited to, a payment transaction response received from the issuer server 104 and a data element indicating that the BIN is available at the payment server 108a.
[0097] Alternatively, in one embodiment, the method 500 includes receiving, by the server system (i.e., “acquirer server 102”), an authorization response message for declining the payment transaction from the payment server 108a, when the BIN is unavailable with the payment server 108a. The method 500 further includes storing, by the server system (i.e., “acquirer server 102”), the BIN associated with the payment card 118 for traceability purposes. In one embodiment, the BIN corresponding to the declined payment transaction may be stored at either the server system or the payment server 108a.
[0098] FIG. 6 is simplified block diagram of a server system 600 for real-time validation of the BIN corresponding to the payment card 118 of the cardholder 120, in accordance with an embodiment of the present disclosure. The server system 600 includes a computer system 602 and a database 604. In an embodiment, the server system 600 is integrated, but not limited to, in the acquirer server 102 (referring to FIG. 1).
[0099] The computer system 602 includes at least one processor 606 configured to execute executable instructions for providing various features of the present disclosure. The executing instructions are stored in a memory 608. The components of the computer system 602 provided herein may not be exhaustive and that the computer system 602 may include more or fewer components than that of depicted in FIG. 6. Further, two or more components may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the computer system 602 may be configured using hardware elements, software elements, firmware elements and/or a combination thereof.
[00100] The processor 606 is operatively coupled to a communication interface 610 such that the computer system 602 is capable of communicating with a remote device 614 such as a user device 126, the payment transaction terminal 116, the issuer server 104, one or more payment servers 108a and 108b associated with multiple payment networks 106a and 106b, respectively or communicated with any entity connected to the network 110 (shown in FIG. 1) or any constituents of the acquirer server 102. In an embodiment, the communication interface 610 is configured to receive a payment transaction request and a BIN unavailable message from the payment transaction terminal 116. The BIN unavailable message represents a data field which indicates a BIN unavailability at the payment transaction terminal 116. The BIN is associated with the payment card 118 which is utilized for the payment transaction at the payment transaction terminal 116. In other embodiments, the database 604 is external to the computer system 602 and may be accessed by the computer system 602 using a storage interface 612. The storage interface 612 is configured to fetch a BIN file 616 from an acquirer database 604 for determining availability of the BIN in the BIN file 616.
[00101] The processor 606 may also be operatively coupled to the acquirer database 604. The database 604 is an example of the acquirer database 112. The acquirer database 604 is any computer-operated hardware suitable for storing and retrieving data, such as, but not limited to, information of the card issuers, information of a merchant, transaction data generated as part of sales activities conducted over a payment network including data relating to merchants, payees, or customers, and purchases. The database 604 may also store a BIN file. The BIN file includes a plurality of BIN ranges of issuers. The database 604 may also include instructions for settling transactions including merchant bank account information. The database 604 may include multiple storage units such as hard disks and/or solid-state disks in a redundant array of inexpensive disks (RAID) configuration. The database 604 may include a storage area network (SAN) and/or a network attached storage (NAS) system.
[00102] In some embodiments, the database 604 is integrated within computer system 602. For example, the computer system 602 may include one or more hard disk drives as the database 604. The storage interface 612 is any component capable of providing the processor 606 with access to the acquirer database 604. The storage interface 612 may include, for example, an Advanced Technology Attachment (ATA) adapter, a Serial ATA (SATA) adapter, a Small Computer System Interface (SCSI) adapter, a RAID controller, a SAN adapter, a network adapter, and/or any component providing the processor 606 with access to the acquirer database 604.
[00103] The processor 606 is configured to identify whether the BIN is stored in the BIN file 616 associated with the database 604. When the BIN is not stored in the BIN file, the processor 606 is configured to generate an authorization request message including the payment transaction request and a data field indicating BIN unavailability at the server system (i.e., “acquirer server 102”). Further, the processor 606 is configured to determine a payment network (e.g., 106a of FIG. 1) to which the payment transaction should be routed based on the BIN associated with the payment card. Thereafter, the processor 606 is configured to transmit the authorization request message to the payment server (e.g., 108a of FIG. 1) associated with the payment network (e.g., 106a of FIG. 1) for validating the BIN. The payment server (e.g., 108a of FIG. 1) determines availability of the BIN in a payment network database 114a. If it is determined that the BIN is assigned to an issuer (for example, “issuer server 104”), the payment server forwards the payment transaction request to the issuer server (for example, “issuer server 104”). The processor 606 is configured to receive an authorization response for successful authorization, when the BIN is available with the payment server (e.g., 108a of FIG. 1) and/or the issuer approves the payment transaction. In an example embodiment, the processor 606 is configured to receive an authorization response for declining the payment transaction, when the BIN is not available with the payment server (e.g., 108a of FIG. 1) (i.e. “the BIN is not assigned to any issuer”). In response to reception of the authorization response, the processor 606 is configured to store the BIN corresponding to failure payment transaction in the database 604 for traceability purposes.
[00104] FIG. 7 is a simplified block diagram of a payment transaction terminal 700 (i.e., “POS terminal”) for real-time validation of the BIN corresponding to the payment card 118 of the cardholder 120, in accordance with an embodiment of the present disclosure. The payment transaction terminal 700 (also referred to as a ‘POS terminal 700’) may refer to a system including a host computer connected to several peripheral devices, such as a keyboard, and a mouse, a card reader, a barcode scanner, a receipt printer, a cash drawer, and a weighing scale. However, it shall be noted that herein the POS terminal 700 is referred to the POS machine which is used to swipe payment cards.
[00105] The POS terminal 700 includes at least one processing module 705 communicably coupled to a memory 710, a card reader module 715, a communication interface 720, and a printer 740. The components of the POS terminal 700 provided herein may not be exhaustive, and that the POS terminal 700 may include more or fewer components than that of depicted in FIG. 7. Further, two or more components may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the POS terminal 700 may be configured using hardware elements, software elements, firmware elements and/or a combination thereof.
[00106] The card reader module 715 runs scripts such as or similar to EMV scripts (GET scripts) that allow reading of information from a chip of a payment card (e.g., the payment card 118). The card reader module 715 is also configured to read information stored within magnetic stripes provided in some payment cards. There may be as many as two card reader modules in the POS terminal 700 such that each of which may be configured to read information stored in different types of storages, such as chips and magnetic stripes.
[00107] An I/O interface 725 is configured to receive inputs from an end-user and provide outputs to the end-user (i.e. a merchant representative and/or the cardholder 120) of the POS terminal 700. For instance, the I/O interface 725 may include at least one input interface and/or at least one output interface. Examples of the input interface may include, but are not limited to, a keyboard, a keypad, a touch screen, soft keys and the like. The input interface (also referred to as ‘input module’) may be used to provide transaction amount, and PIN. Examples of the output interface may include, but are not limited to, a UI display (such as a light emitting diode display, a thin-film transistor (TFT) display, a liquid crystal display, an active-matrix organic light-emitting diode (AMOLED) display, etc.) and the like. The output interface may optionally display a notification depicting payment transaction status such as, payment transaction approval or decline upon transferring the transaction amount to an acquirer account of the merchant.
[00108] The printer 740 is configured to print receipts of the transaction. The receipt includes an acquirer bank name, the transaction amount, merchant name, date on which the receipt is printed and a payment card type, among other information.
[00109] The memory 710 can be any type of storage accessible to the processing module 705. For example, the memory 710 may include volatile or non-volatile memories, or a combination thereof. In some non-limiting examples, the memory 710 can be four to sixty-four Megabytes (MB) of Dynamic Random-Access Memory (“DRAM”) or Static Random-Access Memory (“SRAM”). In addition, some examples may include supplementary flash memory installed via a PCMCIA slot. Moreover, the memory 710 is capable of storing and/or retrieving data, such as, but not limited to, smart card insertions, user/customer information, merchant information, card swipes, touch-screen key depressions, keypad key depressions, number of dots printed by the slip and roll printers, check read errors, and the like. Such information can be accessed by the processing module 705 using the communication interface 720 to determine potential future failures and the like.
[00110] The POS terminal 700 is capable of communicating with one or more POS peripheral devices such as a merchant interface device 735 and an external server system 730 such as the acquirer server 102 (shown in FIG. 1) via the communication interface 720 over a communication network (not shown). The merchant interface device 735 can provide functionality which is used by a cardholder (e.g., the cardholder 120) at a merchant facility, such as unique reference code (e.g., QR code) entry corresponding to the payment card of the cardholder 120, PIN entry, clear text entry, signature capture, and the like. The POS terminal 700 includes a scanner 745 configured to read a machine-readable encrypted code such as the unique reference code that may be generated by the user device 126 for the payment card information. The scanner 745 may be a barcode scanner or a QR code scanner. The merchant interface device 735 may be connected to several peripheral devices including cash drawers, receipt printers, PIN pads, signature capture devices and the like. In some embodiments, the merchant interface device 735 may be mounted near a cash register at a check-out counter at a merchant facility, while the POS terminal 700 may be mounted on the check-out counter such that it is accessible to customers. In this way, both the merchant and the user/customer can interact with similar devices to process the payment transaction.
[00111] In one embodiment, the communication interface 720 includes a transceiver for wirelessly communicating information (transaction amount, merchant identifier, etc.) to, or receiving information from, the external server system 730 or other suitable display device, and/or another type of remote processing device. In another embodiment, the communication interface 720 is capable of facilitating operative communication with the remote devices and a cloud server using Application Program Interface (API) calls. The communication may be achieved over a communication network.
[00112] The processing module 705 is capable of sending the payment transaction request received from the end-user via the communication interface 720 to the external server system 730 (e.g., acquirer server 102) for processing the payment transaction. For example, the processing module 705 is configured to access the BIN of an issuer associated with the payment card. The processing module 705 is configured to identify whether the BIN is present among a plurality of BINs available in a BIN table 750. The BIN table 750 is stored in the memory 710. The processing module 705 is configured to generate the payment transaction request. The processing module 705 can access the memory 710 to retrieve the merchant information of the merchant such as, merchant identifier merchant account details that are required to be sent along with the payment transaction request to the external server system 730. When the BIN is not available in the BIN table 750, the processing module 705 is configured to transmit the payment transaction request along with a BIN unavailable message indicating non-identifiability of the BIN, to the external server system 730 (e.g., acquirer server 102). The processing module 705 is configured to receive an authorization response message from the external server system 730 (e.g., acquirer server 102), when the BIN is available at the external server system 730 (e.g., acquirer server 102) and a payment server.
[00113] Additionally, the POS terminal 700 can include an operating system and various software applications that can provide various functionalities to the POS terminal 700. For example, in some embodiments, the POS terminal 700 is addressable with an Internet protocol and includes an application. In such embodiments, the processing module 705 includes software adapted to support such functionality. In some embodiments, the processing module 705 executes software to support network management. In particular, this capacity allows software to be downloaded to a plurality of such systems to provide new applications such as application for various possible payment methods using POS terminals and/or updates to existing applications. The operating system and software application upgrades are distributed and maintained through communication to the POS terminal 700 over the payment network 106a or the payment network 106b.
[00114] FIG. 8 is a simplified block diagram of an acquirer server 800 for real-time validation the BIN corresponding to a payment card of a cardholder 120, in accordance with an embodiment of the present disclosure. The acquirer server 800 is associated with an acquirer bank, which may be associated with a merchant, such as, the merchant at whose facility the cardholder 120 is purchasing items. The merchant may have established an account to accept payment for purchase of items from customers. The acquirer server 800 is an example of the acquirer server 102 of FIG. 1 or may be embodied in the acquirer server 102. Further, the acquirer server 800 is configured to facilitate payment/refund with the issuer server 104 using a payment network, such as the payment network 106a, or the payment network 106b of FIG. 1.
[00115] The acquirer server 800 includes a processing module 805 communicably coupled to a merchant database 810, a BIN database 825, and a communication module 815. The components of the acquirer server 800 provided herein may not be exhaustive, and that the acquirer server 800 may include more or fewer components than that of depicted in FIG. 8. For instance, the acquirer server 800 may include the BIN database 825 that facilitates payment transaction processing and routing to an issuer of a payment card. Further, two or more components may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the acquirer server 800 may be configured using hardware elements, software elements, firmware elements and/or a combination thereof.
[00116] The merchant database 810 includes data of one or more merchant parameters, such as, but not limited to, a merchant primary account number (PAN), a merchant name, a merchant ID (MID), a merchant category code (MCC), a merchant city, a merchant postal code, a merchant brand name, payment transaction terminal identification numbers (TIDs) associated with merchant terminals (e.g., the POS terminal 122 or any other merchant electronic devices) used for processing transactions. The processing module 805 is configured to use the MID or any other merchant parameter such as the merchant PAN to identify the merchant during the normal processing of payment transactions, refunds, adjustments, chargebacks, end-of-month fees, loyalty programs associated with the merchant and so forth. The processing module 805 may be configured to store and update the merchant parameters in the merchant database 810 for later retrieval.
[00117] The BIN database 825 includes a plurality of BIN ranges associated with card issuers. The BIN database 825 includes entries that each map a BIN of a payment card to a payment network (or, to a specific issuer within the payment network within which it resides) to be used for routing transactions having that BIN of the specific issuer. Thus, upon receipt of transaction information (e.g., an authorization request message) from a payment transaction terminal including a card number of the cardholder in the transaction, an acquirer may identify the BIN portion of the card number and use it as an index (or “key”) into the BIN database 825 to identify the payment network to be used to route the transaction information toward a correct issuer.
[00118] In an embodiment, the communication module 815 is capable of facilitating operative communication with a remote device 820, such as, the payment transaction terminal 116. The communication module 815 is configured to receive the payment transaction request from the remote device 820 (e.g., the payment transaction terminal 116) and optionally a BIN unavailable message if the BIN is not available with the remote device 820 (e.g., the payment transaction terminal 116).
[00119] FIG. 9 is a simplified block diagram of a payment server 900 used for real-time validating the BIN associated with a payment card (e.g., “the payment card 118”) of a cardholder (e.g., “the cardholder 120”) during a payment transaction at a payment transaction terminal 116, in accordance with an embodiment of the present disclosure. The payment server 900 is an example of the payment server 108a of FIG. 1. The payment network 106a may be used by the payment server 900, the issuer server 104 and the acquirer server 800 as a payment interchange network. Examples of payment interchange network include, but not limited to, Mastercard® payment system interchange network. The payment server 900 includes a processing system 905 configured to extract programming instructions from a memory 910 to provide various features of the present disclosure. The components of the payment server 900 provided herein may not be exhaustive and that the payment server 1300 may include more or fewer components than that of depicted in FIG. 13. Further, two or more components may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the payment server 900 may be configured using hardware elements, software elements, firmware elements and/or a combination thereof.
[00120] Via a communication interface 915, the processing system 905 receives request from a remote device 920 such as the acquirer server 800, the POS terminal 700, a merchant device (e.g., the merchant interface device) associated with a merchant, or a user device hosting a payment gateway application. The request may be a request for payment transaction, and optionally a request to identify validity of the BIN associated with the payment card 118 of the cardholder 120. The communication may be achieved through API calls, without loss of generality. The payment server 900 includes a BIN table 930 embodied in a database 925. The BIN table 930 includes a plurality of BIN ranges associated with the card issuers. The database 925 also includes transaction processing data such as, Issuer ID, POS ID, country code, acquirer ID, MID, among others.
[00121] When the payment server 900 receives a payment transaction request from the acquirer server 800 or the POS terminal 700, the payment server 900 may perform a lookup into the BIN table 930 to route the payment transaction request to the issuer server (for example, “issuer server 104”). The database 925 stores transaction identifiers for identifying transaction details such as, transaction amount, payment card details, acquirer account information, transaction records, merchant account information, and the like.
[00122] When the BIN associated with the payment card 118 is not identified at the POS terminal 700 and the acquirer server 800, the acquirer server 800 is configured to send an authorization request message to the payment server 900. The authorization request message includes, but is not limited to, the payment transaction request and a data field indicating the BIN unavailability at the acquirer server 800.
[00123] The processing system 905 determines whether the BIN is available in the BIN table 930 or not. If the BIN is stored in the BIN table, the BIN is valid and the processing system 905 sends the payment transaction request to the issuer server 104 for facilitating payment transaction from the remote device 920 (e.g., the POS terminal 700). The processing system 905 is further configured to notify the remote device 920 of the transaction status in form of an authorization response message via the communication interface 915. The authorization response message includes, but is not limited to, a payment transaction response received from the issuer server 104 and a message indicating that the BIN is available with the payment server 900. Alternatively, in one embodiment, if the BIN is not assigned to any issuer (i.e., “the BIN is invalid”), the processing system 905 is configured to send an authorization response message for declining the payment transaction request, via the communication interface 915, to the acquirer server 800.
[00124] FIG. 10 is a simplified block diagram of a user device 1000 for example a mobile phone or a desktop computer capable of implementing the various embodiments of the present disclosure. For example, the user device 1000 may correspond to the user device 126 of FIG. 1 or a merchant device. The user device 1000 is depicted to include one or more applications such as a payment gateway application 1006 which is an example of the payment gateway application 124 of FIG. 1. The payment gateway application 1006 can be an instance of an application downloaded from a third-party server or a payment gateway server. The payment gateway application 1006 is capable of communicating with the acquirer server 102 or the payment gateway server for facilitating payment transaction processing.
[00125] It should be understood that the user device 1000 as illustrated and hereinafter described is merely illustrative of one type of device and should not be taken to limit the scope of the embodiments. As such, it should be appreciated that at least some of the components described below in connection with that the user device 1000 may be optional and thus in an example embodiment may include more, less or different components than those described in connection with the example embodiment of the FIG. 10. As such, among other examples, the user device 1000 could be any of a mobile electronic device, for example, cellular phones, tablet computers, laptops, mobile computers, personal digital assistants (PDAs), mobile televisions, mobile digital assistants, or any combination of the aforementioned, and other types of communication or multimedia devices.
[00126] The illustrated user device 1000 includes a controller or a processor 1002 (e.g., a signal processor, microprocessor, ASIC, or other control and processing logic circuitry) for performing such tasks as signal coding, data processing, image processing, input/output processing, power control, and/or other functions. An operating system 1004 controls the allocation and usage of the components of the user device 1000 and support for one or more payment transaction applications programs (see, the applications 1006) such as the payment gateway application, that implements one or more of the innovative features described herein. In addition, to the payment gateway application, the applications 1006 may include common mobile computing applications (e.g., telephony applications, email applications, calendars, contact managers, web browsers, messaging applications) or any other computing application.
[00127] The illustrated user device 1000 includes one or more memory components, for example, a non-removable memory 1008 and/or removable memory 1010. The non-removable memory 1008 and/or the removable memory 1010 may be collectively known as a database in an embodiment. The non-removable memory 1008 can include RAM, ROM, flash memory, a hard disk, or other well-known memory storage technologies. The removable memory 1010 can include flash memory, smart cards, or a Subscriber Identity Module (SIM). The one or more memory components can be used for storing data and/or code for running the operating system 1004 and the applications 1006. The user device 1000 may further include a user identity module (UIM) 1012. The UIM 1012 may be a memory device having a processor built in. The UIM 1012 may include, for example, a subscriber identity module (SIM), a universal integrated circuit card (UICC), a universal subscriber identity module (USIM), a removable user identity module (R-UIM), or any other smart card. The UIM 1012 typically stores information elements related to a mobile subscriber. The UIM 1012 in form of the SIM card is well known in Global System for Mobile Communications (GSM) communication systems, Code Division Multiple Access (CDMA) systems, or with third-generation (3G) wireless communication protocols such as Universal Mobile Telecommunications System (UMTS), CDMA9000, wideband CDMA (WCDMA) and time division-synchronous CDMA (TD-SCDMA), or with fourth-generation (4G) wireless communication protocols such as LTE (Long-Term Evolution).
[00128] The user device 1000 can support one or more input devices 1020 and one or more output devices 1030. Examples of the input devices 1020 may include, but are not limited to, a touch screen / a display screen 1022 (e.g., capable of capturing finger tap inputs, finger gesture inputs, multi-finger tap inputs, multi-finger gesture inputs, or keystroke inputs from a virtual keyboard or keypad), a microphone 1024 (e.g., capable of capturing voice input), a camera module 1026 (e.g., capable of capturing still picture images and/or video images) and a physical keyboard 1028. Examples of the output devices 1030 may include, but are not limited to a speaker 1032 and a display 1034. Other possible output devices can include piezoelectric or other haptic output devices. Some devices can serve more than one input/output function. For example, the touch screen 1022 and the display 1034 can be combined into a single input/output device.
[00129] A wireless modem 1040 can be coupled to one or more antennas (not shown in the FIG. 10) and can support two-way communications between the processor 1002 and external devices, as is well understood in the art. The wireless modem 1040 is shown generically and can include, for example, a cellular modem 1042 for communicating at long range with the mobile communication network, a Wi-Fi compatible modem 1044 for communicating at short range with an external Bluetooth-equipped device or a local wireless data network or router, and/or a Bluetooth-compatible modem 1046. The wireless modem 1040 is typically configured for communication with one or more cellular networks, such as a GSM network for data and voice communications within a single cellular network, between cellular networks, or between the user device 1000 and a public switched telephone network (PSTN).
[00130] The user device 1000 can further include one or more input/output ports 1050, a power supply 1052, one or more sensors 1054 for example, an accelerometer, a gyroscope, a compass, or an infrared proximity sensor for detecting the orientation or motion of the user device 1000 and biometric sensors for scanning biometric identity of an authorized user, a transceiver 1056 (for wirelessly transmitting analog or digital signals) and/or a physical connector 1060, which can be a USB port, IEEE 1294 (FireWire) port, and/or RS-232 port. The illustrated components are not required or all-inclusive, as any of the components shown can be deleted and other components can be added.
[00131] The disclosed method with reference to FIGS. 4 and 5, or one or more operations of the methods 400 and 500 may be implemented using software including computer-executable instructions stored on one or more computer-readable media (e.g., non-transitory computer-readable media, such as one or more optical media discs, volatile memory components (e.g., DRAM or SRAM)), or nonvolatile memory or storage components (e.g., hard drives or solid-state nonvolatile memory components, such as Flash memory components) and executed on a computer (e.g., any suitable computer, such as a laptop computer, net book, Web book, tablet computing device, smart phone, or other mobile computing device). Such software may be executed, for example, on a single local computer or in a network environment (e.g., via the Internet, a wide-area network, a local-area network, a remote web-based server, a client-server network (such as a cloud computing network), or other such network) using one or more network computers. Additionally, any of the intermediate or final data created and used during implementation of the disclosed methods or systems may also be stored on one or more computer-readable media (e.g., non-transitory computer-readable media) and are considered to be within the scope of the disclosed technology. Furthermore, any of the software-based embodiments may be uploaded, downloaded, or remotely accessed through a suitable communication means. Such suitable communication means include, for example, the Internet, the World Wide Web, an intranet, software applications, cable (including fiber optic cable), magnetic communications, electromagnetic communications (including RF, microwave, and infrared communications), electronic communications, or other such communication means.
[00132] Although the invention has been described with reference to specific exemplary embodiments, it is noted that various modifications and changes may be made to these embodiments without departing from the broad spirit and scope of the invention. For example, the various operations, blocks, etc., described herein may be enabled and operated using hardware circuitry (for example, complementary metal oxide semiconductor (CMOS) based logic circuitry), firmware, software and/or any combination of hardware, firmware, and/or software (for example, embodied in a machine-readable medium). For example, the apparatuses and methods may be embodied using transistors, logic gates, and electrical circuits (for example, application specific integrated circuit (ASIC) circuitry and/or in Digital Signal Processor (DSP) circuitry).
[00133] Particularly, the server system 600 and its various components such as the computer system 602 and the database 604 may be enabled using software and/or using transistors, logic gates, and electrical circuits (for example, integrated circuit circuitry such as ASIC circuitry). Various embodiments of the invention may include one or more computer programs stored or otherwise embodied on a computer-readable medium, wherein the computer programs are configured to cause a processor or computer to perform one or more operations. A computer-readable medium storing, embodying, or encoded with a computer program, or similar language, may be embodied as a tangible data storage device storing one or more software programs that are configured to cause a processor or computer to perform one or more operations. Such operations may be, for example, any of the steps or operations described herein. In some embodiments, the computer programs may be stored and provided to a computer using any type of non-transitory computer readable media. Non-transitory computer readable media include any type of tangible storage media. Examples of non-transitory computer readable media include magnetic storage media (such as floppy disks, magnetic tapes, hard disk drives, etc.), optical magnetic storage media (e.g. magneto-optical disks), CD-ROM (compact disc read only memory), CD-R (compact disc recordable), CD-R/W (compact disc rewritable), DVD (Digital Versatile Disc), BD (BLU-RAY® Disc), and semiconductor memories (such as mask ROM, PROM (programmable ROM), EPROM (erasable PROM), flash memory, RAM (random access memory), etc.). Additionally, a tangible data storage device may be embodied as one or more volatile memory devices, one or more non-volatile memory devices, and/or a combination of one or more volatile memory devices and non-volatile memory devices. In some embodiments, the computer programs may be provided to a computer using any type of transitory computer readable media. Examples of transitory computer readable media include electric signals, optical signals, and electromagnetic waves. Transitory computer readable media can provide the program to a computer via a wired communication line (e.g., electric wires, and optical fibers) or a wireless communication line.
[00134] Various embodiments of the invention, as discussed above, may be practiced with steps and/or operations in a different order, and/or with hardware elements in configurations, which are different than those which, are disclosed. Therefore, although the invention has been described based upon these exemplary embodiments, it is noted that certain modifications, variations, and alternative constructions may be apparent and well within the spirit and scope of the invention.
[00135] Although various exemplary embodiments of the invention are described herein in a language specific to structural features and/or methodological acts, the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as exemplary forms of implementing the claims.