Methods and systems for facilitating access of interchange parameters to a plurality of digital applications

Systems and methods for facilitating access of interchange parameter data files through a centralized microservice system that integrates a plurality of interchange network systems with a plurality of payment processing applications. The microservice system comprises a plurality of microservices and a plurality of payment processing application modules hosting the plurality of payment processing applications. The microservice system accesses interchange related information sourced from the plurality of interchange network systems and stores the interchange related information in the plurality of microservices. A plurality of financial entities gets registered with the microservice system for availing services associated with the plurality of payment processing applications. The plurality of payment processing application sends a request to the microservice system to access the interchange related information required for processing of the payment transactions requested by the financial entities. The microservice system provides access of the interchange related information in response to receipt of the request.

CROSS REFERENCE TO RELATED APPLICATION

This application claims priority to Singapore Patent Application No. 10201903109Y, filed Apr. 8, 2019, entitled “Methods and Systems for Facilitating Access of Interchange Parameters to a Plurality of Digital Applications”, the entirety of which is incorporated by reference.

TECHNICAL FIELD

The present disclosure generally relates to processing of card payment transaction. More particularly, the disclosure relates to methods and systems for providing quick access of data or information related to different payment servers using a central processing platform, where the information is required for the processing of the card payment transaction.

BACKGROUND

Users perform financial transactions, whether in store or online, to purchase any product/services, withdraw cash, perform a business deal etc. The authorization, clearing and settlement processing for any financial transaction are handled by financial entities and interchanges. Different interchanges have different set of data files which they publish on a regular basis to their members such as acquiring banks, issuing banks etc. The acquiring banks and issuing banks utilize multiple processing applications which handle payment processing operations for different kind of financial transactions. For example, an automated teller machine (ATM) processing application specifically handles operations required for ATM transactions. The multiple processing applications interact with multiple interchanges to gather data required for performing the operations related to the financial transaction.

In the conventional scenario, multiple processing applications operate in individual manners in terms of uploading the set of data files published by the interchanges, managing and updating those set of data files in their local system. The multiple processing applications, even though working under a common platform, do not share the set of data files and hence work as separate teams. This results in high level of redundancy in terms of uploaded data files in each processing application, maintenance of the data files etc.

SUMMARY

Various example embodiments of the present disclosure provide methods, systems, user devices and computer program products for facilitating access of interchange parameter data files through a centralized microservice system that integrates a plurality of interchange network systems with a plurality of payment processing applications. Various example embodiments further provide a platform architecture facilitated by the microservice system that facilitates storage of the interchange related data files in a central database. Further, the platform architecture facilitates access of the interchange related data files from the central database to each of the plurality of payment processing applications.

In an embodiment, a microservice system for facilitating access of interchange parameter data files of a plurality of interchange network systems to a plurality of payment processing applications is disclosed. The microservice system includes a database comprising a memory and a plurality of microservices. The memory stores instructions and the plurality of microservices stores interchange related information sourced from a plurality of interchange network systems. The microservice system includes the plurality of payment processing applications configured to process payment transactions. The microservice system includes a processor configured to execute the stored instructions. The microservice system is caused to perform accessing the interchange related information sourced from the plurality of interchange network systems. The microservice system is further caused to perform storing the interchange related information in the plurality of microservices. The microservice system is further caused to perform facilitating registration of a plurality of financial entities with the microservice system for availing services associated with the plurality of payment processing applications. The microservice system is further caused to perform receiving a request from a payment processing application of the plurality of payment processing applications to access the interchange related information, upon registration of a financial entity of the plurality of financial entities with the microservice system. The microservice system is further caused to provide the interchange related information to the payment processing application.

In another embodiment, a method for facilitating access of interchange parameter data files of a plurality of interchange network systems to a plurality of payment processing applications is disclosed. The method includes, by a microservice system, accessing the interchange related information sourced from the plurality of interchange network systems. The method includes storing, by the microservice system, the interchange related information in the plurality of microservices. The method further includes facilitating, by the microservice system, registration of a plurality of financial entities with the microservice system for availing services associated with the plurality of payment processing applications. The method further includes upon registration, by the microservice system, of a financial entity of the plurality of financial entities with the microservice system, receiving a request from a payment processing application of the plurality of payment processing applications to access the interchange related information. The method further includes providing, by the microservice system, the interchange related information to the payment processing application

In another embodiment, another method for facilitating access of interchange parameter data files of a plurality of interchange network systems to a plurality of payment processing applications is disclosed. The method includes, by a microservice system, accessing the interchange related information sourced from the plurality of interchange network systems. The method includes storing, by the microservice system, the interchange related information in the plurality of microservices. The method further includes facilitating, by the microservice system, registration of a plurality of financial entities with the microservice system for availing services associated with the plurality of payment processing applications. The method further includes upon registration, by the microservice system, of a financial entity of the plurality of financial entities with the microservice system, receiving a service request from at least one financial entity for accessing at least one payment processing application of the plurality of payment processing applications. The method further includes sending, by the microservice system, the service request to the at least one payment processing application. The method further includes receiving, by the microservice system, a request from a payment processing application of the plurality of payment processing applications to access the interchange related information. The method further includes providing, by the microservice system, the interchange related information to the payment processing application

DETAILED DESCRIPTION

The term “financial entity” used throughout the description refers to server which corresponds to, but not limited to, at least one of an issuing bank or an acquiring bank.

In a conventional payment system, a financial entity called the “issuer bank” or “issuing bank” is associated with an issuing server that issues a payment card, such as a credit card, to a consumer, who uses the payment card to tender payment for a purchase from a merchant. To accept payment with the payment card, the merchant must normally establish an account with another financial entity that is part of the payment system. This financial entity is usually called the “acquiring bank.” When the consumer tenders payment for a purchase with the payment card, the merchant requests authorization from the acquiring bank for the amount of the purchase. The request may be performed over the telephone, but is usually performed through the use of a point-of-sale (POS) terminal, which reads the consumer's account information from the magnetic stripe or chip present in the payment card and communicates electronically with the transaction processing computers of the merchant bank. Alternatively, the merchant bank may authorize a third party to perform transaction processing on its behalf. In this case, the point-of-sale terminal will be configured to communicate with the third party. Such a third party is usually called a “payment server” or an “interchange network system.”

The term “issuing bank” used herein refers to a financial entity associated with an issuing server that holds a financial account that is used to fund the financial transaction (interchangeably referred to as “card payment transaction”) of a cardholder. Further, the term “acquiring bank” used herein refers to a financial entity associated with an acquiring server that holds a financial account of a merchant or any entity which receives the fund from the issuing server. The financial accounts in each of the issuing server and the acquiring server 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, the financial 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 PayPal®, and the like.

The term “payment card” herein refers to a physical or virtual card linked with a financial or payment account that may be presented to a merchant or any such facility in order to fund a financial transaction via the associated payment account. Examples of the payment card includes, but are not limited to, debit cards, credit cards, prepaid cards, digital wallet, virtual payment numbers, virtual card numbers, forex card, charge cards and stored-value cards. A payment card may be a physical card that may be presented to the merchant for funding the payment. Alternatively, or additionally, the payment card may be embodied in form of data stored in a user device, where the data is associated with payment account such that the data can be used to process the financial transaction between the payment account and a merchant's financial account.

The term “interchange network system”, used herein, refers to a network or collection of systems used for transfer of funds through use of cash-substitutes. Interchange network systems 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 an interchange network system may include product or service purchases, credit purchases, debit transactions, fund transfers, account withdrawals, etc. Interchange network systems 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 interchange network system include those operated by Mastercard®, VISA®, Discover®, American Express®, etc.

Overview

Various example embodiments of the present disclosure provide methods, systems, and computer program products for facilitating access of interchange parameter data files through a centralized microservice system, wherein the microservice system integrates a plurality of interchange network systems with a plurality of payment processing applications. Various example embodiments further provide a platform architecture facilitated by the microservice system, wherein the platform facilitates storage of the interchange parameter data files in a central database. Further, the platform architecture facilitates access of the interchange parameter data files from the central database to each of the plurality of payment processing applications. The interchange parameter data files include interchange related information such as bin range, merchant category codes, currency conversion rates, business service rules, message reason codes, country codes, region codes, currency codes, stop list reasons/warning bulletins etc.

The central database in the microservice system includes a plurality of microservices. Each microservice stores a type of interchange parameter of the interchange parameter data files published by respective interchange network system for example, but not limited to, Microservice1 stores VISA® Bin range, Microservice2 stores VISA® currency conversion rates, Microservice3 stores Mastercard® Bin range, Microservice4 stores Mastercard® currency conversion rates etc.

The payment processing applications may not be limited to only mobile or web applications, but also include, cloud applications, or any other interaction channel which can perform operations for financial transactions, and through which a user/customer can interact with the microservice system. The payment processing applications may be managed and hosted by the microservice system and can be accessed by users via user devices such as mobile phones, desktop computer, or any electronic device with communication capabilities. In some scenarios, the payment processing applications can be made available on application store hosted by respective organization and are downloadable from the application stores to be accessed on user devices.

The microservice system sends a first registration request to get registered at different interchange network systems located in different operating regions to get access of their respective interchange related data files. Upon registration in each interchange network system per operating region, the microservice receives a unique processor identification (ID) from each interchange network system per operating region. For example, if an interchange_1 is operating at three different regions (e.g. region1, region2, and region3), the microservice system will get registered at each of the regions i.e. region1, region2, and region3, and receives a unique ID i.e. IDA, IDB, and IDC) from the region1, region2, and region3, respectively.

The microservice system further facilitates registration of a plurality of financial entities, who are interested in services provided by the plurality of payment processing applications hosted by the microservice system, based on receiving a second registration request from the plurality of financial entities. A unique member ID is assigned to each financial entity of the plurality of financial entities who are registered with the microservice system.

The plurality of payment processing applications can be broadly classified into, but not limited to, two categories i.e. issuing applications and acquiring applications. The issuing applications handle payment processing related to operations performed at the issuing banks such as operations related to debit card payments, credit card payment or prepaid card payments. Therefore, the issuing applications can be categorized into, but not limited to, Credit Application (App), Debit App and Prepaid App which handle operations respective to credit card, debit card and prepaid card. The acquiring applications handle payment processing related to operations performed at acquiring banks such as operations related to ATM, POS and payment gateway (PG). Therefore, the acquiring applications can be categorized into, but not limited to, ATM App, POS App, and PG App.

Whenever a service request is received from at least one financial entity of the plurality of financial entities for an operation related to a payment transaction, the microservice system authenticates the service request and determines whether the financial entity has opted for the service required for the operation related to the payment transaction. During the registration at the microservice system the financial entity should select the services it would like to use and accordingly the financial entity is authorized to use respective payment processing applications for the selected services. Upon successful authentication, the microservice system directs the service request to respective payment processing application for performing the operation. Alternatively, the financial entity can have a portal installed at its local system to access the payment processing application.

When the payment processing application receives the service request to perform the operation related to the payment transaction, the payment processing application sends a request to the microservice system for access of interchange parameter data files required to perform the operation. The microservice system determines the respective microservices storing the interchange parameter data files requested by the payment processing application and provides the access of the determined microservices to the payment processing application.

Therefore, the plurality of payment processing applications can directly access the interchange parameter data files required for performing operations related to the payment transactions without the need of storing and maintaining the interchange parameter data files on their own. Only one file per interchange parameter per interchange per region is stored instead of multiple files for same interchange parameter per interchange per region. Hence various embodiments provide technical effect of eliminating redundancy of uploading, storing and maintaining of interchange parameter data files, and these embodiments are described herein with reference toFIGS.1to10.

FIG.1illustrates an example representation of an environment100related to at least some example embodiments of the present disclosure. The environment100is exemplarily shown including a microservice system102, interchange network systems104a,104b. . .104n, and financial entities106a,106b. . .106m. Each of the financial entities106a-nincludes at least one of an acquiring bank and an issuing bank. For instance, as illustrated, the financial entity106ais shown as with an acquiring bank108aand an issuing bank110a, the financial entity106bis shown as with an acquiring bank108b, and the financial entity106mis shown as with an issuing bank110m. The interchange network systems104acomprises a payment server114to communicate with the microservice system102. Please note that the payment server114is shown only in interchange network systems104afor the purpose of clarity, however remaining interchange network systems104b, . . .104nmay also comprise the payment server114.

An issuing bank such as the issuing bank110aof the financial entity106a, in which a cardholder may have an issuer account, issues one or more payment cards, such as a credit card, a debit card or a prepaid card, is associated with an issuing server. The payment cards are linked to an issuer account associated with a unique payment account number of the cardholder. The cardholder can use any of the payment cards to tender payment for the purchase. The issuing bank is responsible for determining whether a customer's issuer account is in good standing and whether the purchase is covered by the customer's available credit line or account balance. Based on these determinations, the payment transaction associated with the payment transaction request is approved or declined. The payment cards used by the cardholder are issued by the issuing bank110ain also in association with an interchange payment network, for example, the interchange payment network104a.

An acquiring bank such as acquiring bank108bof the financial entity106b, in which the merchant may have a merchant account, is associated with an acquiring server which communicates with the issuing server via the payment server114to determine whether the cardholder's account is in good standing and whether the transaction amount of the purchase is covered by the cardholder's available account balance. Based on these determinations, authorization of the transaction is declined or accepted. When the authorization is accepted, the available balance of cardholder's account is decreased.

The microservice system102, the interchange network systems104a-nand the financial entity106a-mare communicatively coupled with each other via the network112.

In an example embodiment, the microservice system102sends a first registration request for registration to the interchange network systems104a-nto access interchange parameter data files. Upon receiving the first registration request, each of the interchange network systems104a-nperforms registration and assigns a unique processor ID to the microservice system102. Each of the interchange network systems104a-nsends the approval message of registration along with the assigned unique processor ID to the microservice system.102

The interchange network systems104a-npublish their interchange parameter data files to their registered member on a daily basis, at predetermined intervals, or based on change in any of the parameter in the interchange parameter data files. The interchange parameter data files include interchange related information such as bin range, merchant category codes, currency conversion rates, business service rules, message reason codes, country codes, region codes, currency codes, stop list reasons/warning bulletins etc. The microservice system102being the registered member also receives the interchange parameter data files on a daily basis, at the predetermined intervals, or based on change in any of the parameter in the interchange parameter data files. The microservice system102uploads the received interchange parameter data files in its central database post verifying the parameters in the interchange parameter data files. The microservice system102uploads, tests and maintains the interchange parameter data files.

Each of the financial entities106a-msends a second registration request to the microservice system102for getting registered with the microservice system102to avail the services provided by the microservice system102. The services are related to processing of the payment transaction.

During the registration process, each of the financial entities106a-mprovides details such as name of the financial entity, operating region of the financial entity, name of the interchange network system with which the financial entity is associated, services in which the financial entity is interested. Upon successful registration, the microservice system102assigns a unique member ID to each of the financial entities106a-m. The details provided by the financial entities106a-mare stored in the central database for future reference along with the assigned unique member ID. The microservice system102sends an approval of registration to the financial entities106a-malong with the assigned unique member ID to the financial entities106a-m.

Each of the financial entities106a-msends a service request for availing a service selected during the registration with the microservice system102. An example of the service request includes, but not limited to, a request for a credit card payment processing settlement. The microservice system102selects an appropriate payment processing application of a plurality of payment processing applications310(shown inFIG.3) hosted by the microservice system102for performing operations related to processing of the payment transaction, for example, but not limited to Credit application. The service request is directed to the selected payment processing application.

The plurality of payment processing applications can be broadly classified into, but not limited to, two categories i.e. issuing applications and acquiring applications. The issuing applications handle payment processing related to operations performed at the issuing banks such as operations related to debit card payments, credit card payment or prepaid card payments. Therefore, the issuing applications can be categorized into, but not limited to, Credit App, Debit App and Prepaid App which handle operations respective to credit card, debit card and prepaid card. The acquiring applications are configured to handle payment processing related to operations performed at acquiring banks such as operations related to ATM, POS and payment gateway (PG). The acquiring applications can be categorized into, but not limited to, ATM App, POS App, and PG App.

Whenever the service request is received from at least one financial entity of the plurality of financial entities106a-mfor an operation related to a payment transaction, the microservice system102authenticates the service request and determines whether the financial entity has opted for the service required for the operation related to the payment transaction. During the registration at the microservice system102, a financial entity of the financial entities106a-mshould select the services it would like to use and accordingly the financial entity is authorized to use respective payment processing applications for the selected services. Upon successful authentication, the microservice system102directs the service request to respective payment processing application for performing the operation. Alternatively, the financial entity can have a portal installed at its local system to access the payment processing application.

The microservice system102includes a plurality of microservices314(shown inFIG.3) as a part of the central database. Each microservice of the plurality of microservices314stores a type of interchange parameter of the interchange parameter data files published by respective interchange network system for example, but not limited to, Microservice1 stores VISA® Bin range, Microservice2 stores VISA® currency conversion rates, Microservice3 stores Mastercard® Bin range, Microservice4 stores Mastercard® currency conversion rates etc. It should be noted that the plurality of payment processing applications can be part of the microservice system102or they can be separate entity.

Once the payment processing application receives the service request for processing of the payment transaction, the payment processing application sends a request to access interchange parameter data files stored in at least one microservice of the plurality of microservices314. The microservice system102provides access of the requested interchange parameter data files stored in at least one microservice of the plurality of microservices314to the payment processing application. Since the interchange parameter data files are stored in separate microservices based on type of the interchange parameter, name of the interchange and region of the interchange, the plurality of the payment processing applications can access same parameter data files stored in the at least one microservice of the plurality of microservices simultaneously in real time. This minimizes the real time required to perform operations of the payment transaction.

FIG.2illustrates a sequence flow diagram representing a method200of facilitating access of interchange parameter data files to a plurality of payment processing applications simultaneously in accordance with an example embodiment. The sequence of operations of the flow diagram200may 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 flow diagram200is explained herewith using the microservice system102, an interchange network system104, a financial entity106and a payment processing application310. The interchange network system104is an example of interchange network systems104a-n, and the financial entity106is an example of any of the financial entities106a-m.

At202, the microservice system102sends a first registration request for registration to at least one interchange network system104to access interchange parameter data files. At204, upon receiving the request, the interchange network system104performs registration of the microservice system102. At206, the interchange network system104assigns a unique processor ID to the microservice system102.

At208, the interchange network system104sends the approval message of registration along with the assigned unique processor ID to the microservice system102.

At210, the interchange network system104publishes its interchange parameter data files to the microservice system102. The interchange parameter data files include interchange related information such as bin range, merchant category codes, currency conversion rates, business service rules, message reason codes, country codes, region codes, currency codes, stop list reasons/warning bulletins etc. The interchange network system104publishes its interchange parameter data files to its registered member on a daily basis (or as per predefined intervals) or based on change in any of the parameter in the interchange parameter data files. The microservice system102, being the registered member, also receives the interchange parameter data files on a daily basis or based on change in any of the parameter in the interchange parameter data files.

At212, the microservice system102uploads the received interchange parameter data files in its central database post verifying the parameters in the interchange parameter data files. The microservice system102uploads, tests and maintains the interchange parameter data files on a daily basis or based on change in any of the parameter in the interchange parameter data files.

At214, the financial entity106sends a second registration request for registration to the microservice system102to avail the services provided by the microservice system102. Typically, the services are related to processing of the payment transactions. During the registration process, the financial entity106provides details such as name of the financial entity, operating region of the financial entity, name of the interchange network system with which the financial entity is associated, services in which the financial entity106is interested.

At216, the microservice system102perform registration of the financial entity106. In this step of registration, the microservice system102registers the financial entity106for the services provided in the second registration request. For instance, the financial entity106is authorized to use respective payment processing applications for the services registered with the microservice system102.

At218, upon successful registration, the microservice system102assigns a unique member ID to the financial entity106. The details provided by the financial entity106are stored in the central database for future reference along with the assigned unique member ID.

At220, the microservice system102sends an approval message of registration to the financial entity106along with the assigned unique member ID.

At222, the financial entity106sends a service request for availing a service related to operations for processing of the payment transaction. For example, the financial entity106requests for a card payment processing settlement.

At224, the microservice system102authenticates the service request and determines whether the financial entity106has opted for the service required for the operation related to the payment transaction. During the registration at the microservice system102the financial entity106should select the services it would like to use and accordingly the financial entity106is authorized to use respective payment processing applications310for the selected services.

At226, upon successful authentication the microservice system102selects an appropriate payment processing application of the plurality of payment processing applications310hosted by the microservice system102for performing operations related to processing of the payment transaction. At220, the microservice system102sends the service request to the selected payment processing application. Alternatively, the financial entity106can have a portal installed at its local system to access the payment processing application.

The microservice system102includes a plurality of microservices314(shown inFIG.3) as a part of the central database. As shown inFIG.4, each microservice of the plurality of microservices314stores a type of interchange parameter of the interchange parameter data files published by respective interchange network system104. It should be noted that the plurality of payment processing applications can be part of the microservice system102or they can be separate entity.

At230, once the payment processing application310receives the service request for processing the payment transaction, the payment processing application310analyzes the service request. At232, the payment processing application310sends a request to access interchange parameter data files stored in at least one microservice of the plurality of microservices based on the analysis of the service request.

At234, the microservice system102provides access of the requested interchange parameter data files stored in at least one microservice of the plurality of microservices314to the payment processing application310.

Referring toFIG.3, a simplified block diagram of a server system such as a microservice system300is shown in accordance with one embodiment of the present disclosure. The microservice system300is used for facilitating access of interchange parameter data files to a plurality of payment processing applications. Such access may be provided simultaneously to the payment processing applications. The microservice system300is an example of the microservice system102shown inFIG.1.

The microservice system300includes a processor302, a communication interface304, a central database306, an application interface308, and a plurality of payment processing application modules316hosting a plurality of payment processing applications310. The central database306includes including a memory312and a plurality of microservices314. The one or more of the components in this example may be combined or may be replaced by the processor302. The components described herein (e.g., the communication interface304, the processor324, the central database306, the application interface308and the plurality of payment processing application modules316) may include hardware and/or software that are configured or programmed to perform the steps described herein.

The communication interface304is configured to receive or transmit information between the microservice system300and external entities such as the interchange network system104and the financial entity106via the network112. The communication interface304may receive the interchange parameter data files from the interchange network system104, via the network112. The communication interface304may further transmit an output information such as the approval and the unique member ID to the financial entity106via the network112.

The communication interface304sends a first registration request to the interchange network system104for availing access of the interchange parameter data files. The communication interface304also receives a second registration request from the financial entity106and sends an approval message along with a unique member ID to the financial entity106. The communication interface304may include an Ethernet interface, a radio interface, a microwave interface, or some other type of wireless and/or wired interface. The communication interface304may include a transmitter and a receiver. The communication interface304may support various wireless and/or wired protocols and standards. For example, the communication interface308may support Ultra WideBand (UWB) communication, Bluetooth®, Wireless Fidelity (Wi-Fi), Transport Control Protocol/Internet Protocol (TCP/IP), Institute of Electrical and Electronics Engineers (IEEE) 802.X, Wireless Application Protocol (WAP), or any other type of wireless and/or wired protocol or standard. For example, the communication interface304may include a transceiver device (e.g., a modem, a microwave antenna), a remote command unit interface (RCU-IF) or any other types of I/O interface.

The central database306includes the memory312and the plurality of microservices314. The central database is a non-relational and flexible database. Examples of the central database306may include, but not limited to, NoSQL database such as MongoDB, CouchDB, OrientDB etc. The central database306provides quick access to the interchange parameter data files in real time to the plurality of payment processing applications simultaneously.

The memory312is configured to store computer-programmable instructions executed by the processor302to perform the steps described herein. The memory312also stores the unique processor ID assigned to the microservice system300from the interchange network system104and the unique member IDs assigned to each registered financial entity106with the microservice system300. The memory312further stores details provided by the plurality of financial entities during registration with the microservice system300. Examples of the details include, but not limited to, name of the financial entity, operating region of the financial entity, name of the interchange network system with which the financial entity is associated, services in which the financial entity106is interested. Examples of the memory312may include a non-removable memory and/or removable memory. The non-removable memory can include RAM, ROM, flash memory, or other well-known memory storage technologies. The removable memory can include flash memory and smart cards. In this example, the memory312is a chip (e.g., Integrated Circuit) based storage/memory.

The interchange network system104publishes its interchange parameter data files to its registered member on a daily basis or based on change in any of the parameter in the interchange parameter data files. The processor302receives the interchange parameter data files via the communication interface304on a daily basis or based on change in any of the parameter in the interchange parameter data files. The processor302is configured to verify the parameters in the interchange parameter data files. Post verifying the parameters in the interchange parameter data files, the processor302uploads the received interchange parameter data files in respective microservice of the plurality of microservices314.

For uploading the received interchange parameter data files in respective plurality of microservices314, the processor302segregates the interchange parameter data files based on type of interchange parameter for example, but not limited to, bin range, currency conversion rate, merchant current codes, country codes, dispute processing parameters, stop listing reasons, warning bulletins, business service rules etc., type of interchange per region such as Mastercard® Asia region, Mastercard® middle eastern area, VISA® region1 etc. Accordingly, the processor302uploads the segregated interchange parameter data files into each microservice of the plurality of microservices314. The processor302uploads, tests and maintains the interchange parameter data files on a daily basis or based on change in any of the parameter in the interchange parameter data files.

The plurality of microservices314stores the interchange parameter data files published by different interchange network systems per region. Each microservice of the plurality of microservices stores a type of interchange parameter of the interchange parameter data files published by respective interchange network system104. It should be noted that the plurality of payment processing application modules316can be part of the microservice system300or they can be separate entity.

The processor302is further configured to receive a service request from the financial entity106for availing a service related to operations for processing of the payment transaction, for example, but not limited to, the financial entity106requests for a card payment processing settlement. The processor302authenticates the service request and determines whether the financial entity106has opted for the service required for the operation related to the payment transaction.

The processor302is further configured to select an appropriate payment processing application of the plurality of payment processing applications for performing operations related to the processing of the payment transaction. The service request is directed to the selected payment processing application. Alternatively, the financial entity106can have a portal installed at its local system to access the payment processing application via the application interface308.

In an example, the processor302may include one or more processors, microprocessors, data processors, co-processors, network processors, application specific integrated circuits (ASICs), controllers, programmable logic devices, chipsets, field programmable gate arrays (FPGAs), and/or some other component(s) that may interpret and/or execute instructions and/or data. The processor304may control the overall operation of the microservice system300based on an operating system and/or various applications.

The payment processing applications310correspond to digital applications. The payment processing applications310are configured to process payment transactions associated with the financial entities106registered with the microservice system300. The payment processing applications310can be broadly classified into, but not limited to, two categories i.e. issuing applications and acquiring applications.

Examples of the payment processing applications310includes, but not be limited to, mobile or web applications, cloud applications, or any other interaction channel which can perform operations for financial transactions, and through which a user/customer can interact with the microservice system300.

Alternatively, the payment processing applications310may be managed and hosted by the microservice system300and can be accessed by users via user devices such as mobile phones, desktop computer, or any electronic device with communication capabilities. In some scenarios, the payment processing applications310can be made available on application store hosted by respective organization and are downloadable from the application stores to be accessed on user devices.

The application interface308is configured to receive the service request from the financial entity106made via a portal installed at the financial entity system and directs the request to the respective payment processing application310. Examples of the application interface includes, but not limited to, remote API, web API, REST API etc.

FIG.4illustrates example of the plurality of microservices314in conjunction withFIG.3, in accordance with an example embodiment of the present disclosure.

In an example embodiment, the plurality of microservices314includes microservices314a,314b,314c,314d,314e,314f, . . .314nstoring interchange parameter data files related to interchange1_region1 bin range, Interchange1_region1 currency conversion rates, interchange1_region2 bin range, interchange1_region2 currency conversion rates, Interchange2_region1 bin range, Interchange2_region1 currency conversion rates, and so on respectively.

The interchange network system104per operating region (for example, Interchange 1 in Asian region) publishes on daily basis its interchange parameter data files to the registered member including the microservice system300.

The plurality of microservices314stores the interchange parameter data files in organized manner and further provides access of the interchange parameter data files to the plurality of payment processing applications110simultaneously. The plurality of microservices314and the plurality of payment processing applications work under single processor302in the microservice system300as shown inFIG.3and therefore the real-time response for any request for payment transaction processing is faster than conventional processing platform.

FIGS.5A and5Billustrate examples of the payment processing applications310, in accordance with an example embodiment of the present disclosure.

The plurality of payment processing applications310corresponds to digital applications. The plurality of payment processing applications310are configured to process payment transactions associated with the financial entities106registered with the microservice system102. The payment processing applications310can be broadly classified into, but not limited to, two categories i.e. issuing applications and acquiring applications.

FIG.5Aillustrates the acquiring applications502configured to handle payment processing related to operations performed at acquiring banks such as operations related to ATM, POS and payment gateway (PG). Therefore, the acquiring applications can be categorized into, but not limited to, ATM App502a, POS App502b, and PG App502c.

FIG.5Billustrates the issuing applications504configured to handle payment processing related to operations performed at the issuing banks such as operations related to debit card payments, credit card payment or prepaid card payments. Therefore, the issuing applications can be categorized into, but not limited to, Credit App504a, Debit App504band Prepaid App504cwhich handle operations respective to credit card, debit card and prepaid card.

FIG.6illustrates a flow diagram representing a method600of facilitating access of interchange parameter data files to a plurality of payment processing applications simultaneously, in accordance with an example embodiment. The sequence of operations of the flow diagram of the method600may 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.

At step602, the processor302sends a first registration request, via the communication interface304, for registration to a plurality of interchange network systems to access respective interchange parameter data files. Upon receiving the first registration request, the interchange network system104perform registration and assigns a unique processor ID to the microservice system102. The interchange network system104sends the approval message of registration along with the assigned unique processor ID to the microservice system102.

At step604, upon successful registration at each interchange network system of the plurality of interchange network systems104, the processor302receives, via the communication interface304, the unique processor ID from each interchange network system of the plurality of interchange network systems along with an approval message for the registration request. The interchange network system104publishes its interchange parameter data files to its registered members on a daily basis or based on change in any of the parameter in the interchange parameter data files. The microservice system102, being the registered member, also receives the interchange parameter data files on a daily basis or based on change in any of the parameter in the interchange parameter data files.

At step606, the processor302uploads the received interchange parameter data files in the plurality of microservices314post verifying the parameters in the interchange parameter data files. The processor302uploads, tests and maintains the interchange parameter data files on a daily basis or based on change in any of the parameter in the interchange parameter data files.

At step608, the processor302facilitates registration of a plurality of financial entities106a-mwith the microservice system102for availing services associated with a plurality of payment processing applications. The services are related to the processing of the payment transactions.

During the registration process, the financial entities106a-mprovides details such as name of the financial entity, operating region of the financial entity, name of the interchange network system with which the financial entity is associated, services in which the financial entities106a-mis interested. Upon successful registration, the processor302assigns a unique member ID to the financial entity106. The details provided by the financial entities106a-mare stored in the central database306for future reference.

At step610, the processor302, via the communication interface304, sends an approval of registration to the financial entity106along with the assigned member ID.

At step612, the processor302, via the communication interface304, receives a service request from at least one financial entity106afor availing a service selected during the registration with the microservice system102for example, but not limited to, the financial entity106arequests for a credit card payment processing settlement.

At step614, upon receiving the service request from the financial entity106a, the processor302authenticates the service request and determines whether the financial entity106ahas opted for the service required for the operation related to the payment transaction. During the registration at the microservice system102the financial entity106ashould select the services it would like to use and accordingly the financial entity106ais authorized to use respective payment processing applications for the selected services.

At616, if the financial entity106ahas opted for the service then the method600proceeds to step620otherwise the method600proceeds to step618.

At step620, the processor302selects an appropriate payment processing application of the plurality of payment processing applications310hosted by the microservice system102for performing operations related to payment transaction processing and directs the service request to the selected payment processing application.

At step618, the processor302, via the communication interface304, sends an error message to the financial entity106astating the non-registration of the financial entity106afor the requested service during the registration process. Along with the approval message the processor302may also send a fresh link to select the requested service using the unique member ID given to the financial entity106a.

Upon receiving the service request from the microservice system102, the payment processing application310analyzes the service request and determines the required interchange parameter data files to perform the operation for the payment transaction processing.

At step622, the processor302receives a request from the payment processing application for the access of the interchange parameter data files required to perform the operation for processing the payment transaction.

At step624, the processor302determines the microservices314which store the requested interchange parameter data files and provide access of the microservices to the payment processing application310.

Since the interchange parameter data files are stored in separate microservices based on type of the interchange parameter, name of the interchange and region of the interchange, the plurality of the payment processing applications can access same parameter data files stored in the at least one microservice of the plurality of microservices simultaneously in real time. This minimizes the real time required to perform operations of processing the payment transaction.

FIG.7illustrates a flow diagram representing yet another method700of facilitating access of interchange parameter data files to a plurality of payment processing application simultaneously, in accordance with an example embodiment.

At step702, the microservice system102accesses interchange parameter data files from a plurality of interchange network systems. The interchange network system104performs registration and assigns a unique processor ID to the microservice system102. The interchange network system104sends the approval message of registration along with the assigned unique processor ID to the microservice system102.

The interchange network system104publishes its interchange parameter data files to its registered member on a daily basis or based on change in any of the parameter in the interchange parameter data files. The microservice system102being the registered member also receives the interchange parameter data files on a daily basis or based on change in any of the parameter in the interchange parameter data files.

At706, the microservice system102facilitates registration of a plurality of financial entities106with the microservice system102for availing services associated with a plurality of payment processing applications. The services are related to processing of the payment transactions.

During the registration process, the financial entity106provides details such as name of the financial entity, operating region of the financial entity, name of the interchange network system with which the financial entity is associated, services in which the financial entity106is interested.

At708, upon registration of a financial entity of the plurality of financial entities with the microservice system102, the microservice system102receives a request from a payment processing application of the plurality of payment processing applications310to access the interchange related information for a financial entity of the plurality of financial entities.

The plurality of payment processing applications310can be broadly classified into, but not limited to, two categories i.e. issuing applications and acquiring applications. The issuing applications handle payment processing related to operations performed at the issuing banks such as operations related to debit card payments, credit card payment or prepaid card payments. Therefore, the issuing applications can be categorized into, but not limited to, Credit App, Debit App and Prepaid App which handle operations respective to credit card, debit card and prepaid card. The acquiring applications handles payment processing related to operations performed at acquiring banks such as operations related to ATM, POS and payment gateway (PG). Therefore, the acquiring applications can be categorized into, but not limited to, ATM App, POS App, and PG App.

At710, the microservice system102provides the interchange related information to the payment to the payment processing application310in response to receipt of the request.

Referring now toFIG.8, a simplified block diagram of an issuing server800, in accordance with one embodiment of the present disclosure. The issuing server800is an example of server associated with the issuing banks110a,110mofFIG.1. The issuing server800is associated with an issuer bank/issuer, in which a cardholder may have an account, which provides a payment card. The issuing server800includes a processing module805operatively coupled to a storage module810, a verification module820and a communication module825. The components of the issuing server800provided herein may not be exhaustive and that the issuing server800may include more or fewer components than that of depicted inFIG.8. 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 issuing server800may be configured using hardware elements, software elements, firmware elements and/or a combination thereof.

The storage module810is configured to store machine executable instructions to be accessed by the processing module805. Additionally, the storage module810stores information related to, contact information of the customer, bank account number, availability of funds in the account, payment card details, and/or the like. This information is retrieved by the processing module805.

The processing module805is configured to communicate with one or more remote devices such as a remote device830using the communication module825over a network such as the network112ofFIG.1. The examples of the remote device830include the interchange network system104, the microservice system102and the network120and the like. The communication module825is capable of facilitating such operative communication with the remote devices and cloud servers using API (Application Program Interface) calls. The communication module825is configured to send a registration request for using services of the microservice system102. The communication module825is further configured to receive an approval message from the microservice system102for the registration request and an assigned unique member ID from the microservice system102to access the services of the plurality of payment processing applications310.

The verification module820is configured to verify and validate a customer, the payment card associated with the customer and a PIN of the payment card for approving the transaction. The verification module820may also verify if an issuer account of the customer associated with the payment card have good standing balance. The communication module825is configured to send notification of approval or decline of a transaction to the merchant.

In some embodiments, the issuing server800includes a portal to access the plurality of payment processing applications310, described with reference toFIGS.1and3. In an example embodiment, an instance of the payment processing applications310may be provided by the interchange network system104for deploying the payment processing applications310in the issuing server800.

Referring now toFIG.9, a simplified block diagram of an acquiring server900, in accordance with one embodiment of the present disclosure. The acquiring server900is associated with the acquiring bank108ofFIG.1, which may be associated with a merchant at whose facility the cardholder110is purchasing goods. The merchant may have established an account to accept payment for purchase of goods from customers. Further, the acquiring server900is configured to facilitate transaction with the issuing server800using a network, such as the network112ofFIG.1. The acquiring server900includes a processing module905communicably coupled to a merchant database810and a communication module915. The components of the acquiring server900provided herein may not be exhaustive, and that the acquiring server900may include more or fewer components than that of depicted inFIG.9. 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 acquiring server900may be configured using hardware elements, software elements, firmware elements and/or a combination thereof.

The merchant database910includes a table which stores 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, an MAID, a merchant brand name, terminal identification numbers (TIDs) associated with merchant terminals (e.g., the POS terminals or any other merchant electronic devices) used for processing transactions, among others. The processing module905is 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, adjustments, chargebacks, end-of-month fees, loyalty programs associated with the merchant and so forth. The processing module905may be configured to store and update the merchant parameters in the merchant database910for later retrieval. In an embodiment, the communication module915is capable of facilitating operative communication with a remote device920such as the microservice system102.

In some embodiments, the acquiring server900includes a portal to access the plurality of payment processing applications310, described with reference toFIGS.1and3. In an example embodiment, an instance of the payment processing applications310may be provided by the interchange network system104for deploying the payment processing applications310in the acquiring server900.

FIG.10is a simplified block diagram of a payment server1000used for facilitating access of interchange parameter data files to a plurality of payment processing applications simultaneously, in accordance with one embodiment of the present disclosure. The payment server1000may be an example of the payment server114, and may correspond to the interchange network system104ofFIG.1. The network112may be used by the payment server1000, the issuing server800and the acquiring server900as a payment interchange network. Examples of payment interchange network include, but not limited to, Mastercard® payment system interchange network. The payment server1000includes a processor1005configured to extract programming instructions from a memory1010to provide various features of the present disclosure. The components of the payment server1000provided herein may not be exhaustive and that the payment server900may include more or fewer components than that of depicted inFIG.10. 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 server1000may be configured using hardware elements, software elements, firmware elements and/or a combination thereof.

Via a communication interface1020, the processor1005receives a transaction request from a remote device1035such as the acquiring server900or the merchant terminal. The communication may be achieved through API calls, without loss of generality. A keypad settings database1015is embodied in a database1008of the payment server1000. The keypad settings database1015stores information corresponding to a customized electronic number pad settings of an electronic number pad from a plurality of customers. The keypad settings database1015is in operative communication with a validation module1030, an analysis module1055, and a determination module1060.

The determination module1060is configured to determine whether microservice system102is a registered member or not based on information (for example the unique processor ID) stored in the database1008during registration of the microservice system102via the communication interface1020. The determination module1060is configured to determine several financial entities associated with the microservice system102. In some embodiments, the analysis module1055receives the registration request from the microservice system102and based on analysis of the service request assigns a unique processor ID to the microservice system via the communication interface1020.

The memory1010stores interchange parameter details such as Issuer ID, POS ID, country code, acquirer ID, payment card details, acquirer account information, transaction records, merchant account information, and the like. The customer details, the payment card details, the issuer account balance, etc. are validated using the validation module1030. The validation module1030may include one or more predefined rule sets using which the processor1005can process the validation. Further, the processor1005, upon successful validation, sends interchange parameter to the microservice system102.

The processor1005is further configured to receive the registration request from the microservice system102via the communication interface1020. In one embodiment, the processor1005may facilitate a dedicated software application (also referred to as ‘the application interface’) capable of being installed on the acquiring server108or the issuing server110. The acquiring server900(e.g., the acquiring server108) and the issuing server800(e.g., the acquiring server110) may access the application interface for registration and request for the interchange parameter data files. The acquiring server900and the issuing server800may access the application interface using a web link as well, instead of having a need to install the application on the acquiring server900and the issuing server800.

Without in any way limiting the scope, interpretation, or application of the claims appearing below, a technical effect of one or more of the example embodiments disclosed herein is to provide methods and systems for facilitating access of interchange parameter data files through a centralized microservice system that integrates a plurality of interchange network systems with a plurality of payment processing applications. Various example embodiments further provide a platform architecture facilitated by the microservice system that facilitates storage of the interchange related data files in a central database. Further, the platform architecture facilitates access of the interchange related data files from the central database to each of the plurality of payment processing applications. Since the interchange parameter data files are stored in separate microservices based on type of the interchange parameter, name of the interchange and region of the interchange, the plurality of the payment processing applications can access same parameter data files stored in the at least one microservice of the plurality of microservices simultaneously in real time. This minimizes the real time required to perform operations of processing the payment transaction. Further, the plurality of payment processing applications can directly access the interchange parameter data files required for performing operations related to the payment transactions without the need of storing and maintaining the interchange parameter data files on their own. Therefore, only one file per interchange parameter per interchange per region is stored instead of multiple files for same interchange parameter per interchange per region, hence eliminating redundancy of uploading, storing and maintaining of interchange parameter data files. This results in efficient storage of data and further minimizes the response time, in real time processing, required to perform operations of processing the payment transaction.

The disclosed methods with reference toFIGS.1to10, or one or more operations of the flow diagrams600and700may 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.

Particularly, the server systems (e.g., the components104, and106) and its various components such as the computer system and the database 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 disclosure 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.

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.