Claims:CLAIMS
We claim:

1. A method for processing a payment performed at a merchant terminal of a first merchant for a second merchant, the method comprising:
receiving, by a server system associated with a payment network, a payment transaction request from the merchant terminal of the first merchant, the payment transaction request comprising a merchant information of the second merchant, a payment card information of a payment card of a customer and a transaction amount to be paid to an acquirer account of the second merchant from an issuer account associated with the payment card;
upon successful verification of the payment transaction request, by the server system, processing the payment of the transaction amount from the issuer account to the acquirer account of the second merchant; and
sending, by the server system, a notification of the payment to a merchant device associated with the second merchant.

2. The method as claimed in claim 1, further comprising provisioning, by the server system, an application interface on the merchant device to register the second merchant to the merchant terminal, wherein registering comprises at least providing the merchant information of the second merchant to the merchant terminal.

3. The method as claimed in claim 2, further comprising generating a unique reference code in the application interface for the second merchant based on the merchant information, wherein the unique reference code is readable at the merchant terminal to access the merchant information of the second merchant.

4. The method as claimed in claim 3, wherein the unique reference code is a Quick Response (QR) code.

5. The method as claimed in claim 1, further comprising:
accessing, by the server system, a location of the merchant device of the second merchant;
identifying, by the server system, one or more merchant terminals associated with one or more first merchants present within a pre-defined area of the location of the merchant device; and
storing, by the server system, the merchant information of the second merchant on at least one merchant terminal of the one or more merchant terminals.

6. The method as claimed in claim 1, wherein receiving the payment transaction request further comprises:
receiving, by the server system, at least a merchant identifier flag for determining a merchant, the merchant being one of the first merchant and the second merchant; and
sending, by the server system, the payment transaction request to an acquirer server associated with the acquirer account of the second merchant if the merchant is the second merchant based on the merchant identifier flag.

7. The method as claimed in claim 1, further comprising:
receiving, by the server system, a refund request from the merchant terminal of the first merchant, the refund request comprising the merchant information of the second merchant, the payment card information of the payment card of the customer and a refund amount to be paid from the acquirer account of the second merchant to the issuer account associated with the payment card;
sending, by the server system, an approval request to the merchant device of the second merchant for processing a refund of the refund amount from the acquirer account of the second merchant to the issuer account of the customer, the refund initiated by the customer at the merchant terminal; and
upon receiving a successful approval of the refund request from the merchant device, by the server system, sending a notification of the refund to the merchant device associated with the second merchant.

8. A method performed at a merchant terminal associated with a first merchant, the method comprising:
accessing, by the merchant terminal, an identifier of a second merchant;
sending, by the merchant terminal, a payment transaction request to a server system associated with a payment network, the payment transaction request comprising:
a merchant information comprising at least the identifier of the second merchant;
a payment card information of a customer; and
a transaction amount to be paid to an acquirer account of the second merchant from an issuer account based on the payment card information of the customer; and
receiving, by the merchant terminal, an acknowledgement of a payment to the acquirer account from the issuer account.

9. The method as claimed in claim 8, wherein accessing the identifier comprises:
reading, by the merchant terminal, a unique reference code, the unique reference code generated at a merchant device of the second merchant based on the merchant information; and
identifying, by the merchant terminal, the merchant information associated with the second merchant by decoding the unique reference code.

10. The method as claimed in claim 8, wherein accessing the identifier comprises:
causing, by the merchant terminal, display of a list of second merchants on the merchant terminal of the first merchant upon receiving the payment transaction request, the list of second merchants registered with the merchant terminal of the first merchant; and
provisioning, by the merchant terminal, selection of at least one second merchant from the list of second merchants by the customer.

11. The method as claimed in claim 8, further comprising:
modifying, by the merchant terminal, at least a merchant identifier flag for identifying a merchant, the merchant being one of the first merchant and the second merchant; and
sending, by the merchant terminal, the payment transaction request to an acquirer server associated with the acquirer account of the second merchant if the merchant is the second merchant based on the merchant identifier flag.

12. The method as claimed in claim 8, wherein the merchant terminal is a Point Of Sale (POS) terminal.

13. The method as claimed in claim 8, further comprising:
sending, by the merchant terminal, a refund request received from the customer associated with the second merchant to the server system, the refund request comprising the merchant information of the second merchant and a refund amount to be paid to the issuer account of the customer from the acquirer account of the second merchant;
facilitating, by the merchant terminal, sending of a refund approval request to the merchant device of the second merchant, the refund request initiated by the customer for processing a refund of the refund amount from the acquirer account of the second merchant to the issuer account of the customer; and
upon receiving a successful refund approval of the refund request from the merchant device, displaying, by the merchant terminal, a notification of the refund to the customer.

14. The method as claimed in claim 13, further comprising:
modifying, by the merchant terminal, at least a merchant identifier flag for identifying a merchant, the merchant being one of the first merchant and the second merchant; and
sending, by the merchant terminal, the refund request to an acquirer server associated with the acquirer account of the second merchant if the merchant is the second merchant based on the merchant identifier flag.

15. A server system for processing a payment performed at a merchant terminal of a first merchant for a second merchant, the server system comprising:
a memory to store instructions; and
at least one processor, configured to execute the stored instructions to cause the server system to perform at least:
receiving a payment transaction request from the merchant terminal of the first merchant, the payment transaction request comprising a merchant information of the second merchant, a payment card information of a payment card of a customer and a transaction amount to be paid to an acquirer account of the second merchant from an issuer account associated with the payment card;
upon successful verification of the payment transaction request, processing the payment of the transaction amount from the issuer account to the acquirer account of the second merchant; and
sending a notification of the payment to a merchant device associated with the second merchant.

16. The server system as claimed in claim 15, wherein the server system is further caused at least to perform:
provisioning an application interface on the merchant device to register the second merchant to the merchant terminal, wherein registering comprises at least providing the merchant information of the second merchant to the merchant terminal.

17. The server system as claimed in claim 16, wherein the server system is further caused at least to perform:
generating a unique reference code in the application interface for the second merchant based on the merchant information, wherein the unique reference code is readable at the merchant terminal to access the merchant information of the second merchant.

18. The server system as claimed in claim 15, wherein the server system is further caused at least to perform:
accessing a location of the merchant device of the second merchant;
identifying one or more merchant terminals associated with one or more first merchants present within a pre-defined area of the location of the merchant device; and
storing the merchant information of the second merchant on at least one merchant terminal of the one or more merchant terminals.

19. The server system as claimed in claim 15, wherein for receiving the payment transaction the server system is further configured to at least perform:
receiving at least a merchant identifier flag for determining a merchant, the merchant being one of the first merchant and the second merchant; and
sending the payment transaction request to an acquirer server associated with the acquirer account of the second merchant if the merchant is the second merchant based on the merchant identifier flag.

20. The server system as claimed in claim 15, wherein the server system is further configured to at least perform:
receiving a refund request from the merchant terminal of the first merchant, the refund request comprising the merchant information of the second merchant, the payment card information of the payment card of the customer and a refund amount to be paid from the acquirer account of the second merchant to the issuer account associated with the payment card;
sending an approval request to the merchant device of the second merchant for processing a refund of the refund amount from the acquirer account of the second merchant to the issuer account of the customer, the refund initiated by the customer at the merchant terminal; and
upon receiving a successful approval of the refund request from the merchant device, sending a notification of the refund to the merchant device associated with the second merchant. , 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:
PAYMENT METHODS AND SYSTEMS AT MERCHANT TERMINAL OF FIRST MERCHANT FOR PAYMENT TO SECOND MERCHANT

2. APPLICANT(S):

(a) Name:

(b) Nationality:

(c) Address:

MASTERCARD INTERNATIONAL INCORPORATED

United States

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)

PAYMENT METHODS AND SYSTEMS AT MERCHANT TERMINAL OF FIRST MERCHANT FOR PAYMENT TO SECOND MERCHANT

TECHNICAL FIELD

[0001] The present disclosure relates to payment transactions at a merchant terminal and, more particularly to, payment methods and systems at a merchant terminal of a first merchant for payment to a second merchant.
BACKGROUND
[0002] Digital payments for goods/services have gained momentum worldwide and specifically the use of payment cards, such as debit or credit cards for performing financial transactions are ubiquitous. Moreover, the use of payment cards for financial transactions at Point of Sale (POS) terminals at merchant locations have surged, reflecting an ease of conducting financial transactions using the payment cards, in addition to providing secure payments and increased operational efficiency for sellers. Although, the payment cards are among the most widely used payment methods and come with various features and benefits such as security of payments, convenience, there are still barriers and limitations as the payment cards are restricted to a limited number of compatible vendors equipped with electronic payment infrastructures.
[0003] Traditionally, developing countries have a large number of small retailers who lack sufficient resources to invest in electronic payment infrastructures such as swipe card facilities of POS terminals. For example, small retailers such as hawkers or street vendors have small-scale businesses, and they prefer payment by cash for goods/services as deploying electronic payment infrastructures may not be feasible for such low volume of transactions. Moreover, the payment amount for goods may be less and managing network and technical failures may seem to be a daunting task for such small retailers. Also, even merchants equipped with electronic payment infrastructures mostly face issues, such as faulty connectivity of merchant terminals and inconsistent power supply for the merchant terminals. In such scenarios, the merchants may prefer an alternative measure to enable their customers to make payments using payment cards which is going to be important for both businesses and customers.
[0004] Accordingly, there is a need for a method to obviate disadvantages of the above-mentioned problems and provide a solution where customers can use payment cards to perform a financial transaction without a need for the electronic payment infrastructure at an outlet of every retailer.

SUMMARY
[0005] Various embodiments of the present disclosure provide systems, methods, electronic devices and computer program products for processing payment transactions performed at a merchant terminal of a first merchant for a second merchant.
[0006] In an embodiment, a method is disclosed. The method includes receiving, by a server system associated with a payment network, a payment transaction request from a merchant terminal of a first merchant. The payment transaction request comprises a merchant information of a second merchant, a payment card information of a payment card of a customer and a transaction amount to be paid to an acquirer account of the second merchant from an issuer account associated with the payment card. The method includes processing a payment of the transaction amount from the issuer account to the acquirer account of the second merchant, by the server system, upon successful verification of the payment transaction request. The method further includes sending, by the server system, a notification of the payment to a merchant device associated with the second merchant.
[0007] In another embodiment, a method performed at a merchant terminal associated with a first merchant is disclosed. The method includes accessing, by the merchant terminal, an identifier of a second merchant. The method includes sending, by the merchant terminal, a payment transaction request to a server system associated with a payment network. The payment transaction request comprises a merchant information comprising at least the identifier of the second merchant, a payment card information of a customer, and a transaction amount to be paid to an acquirer account of the second merchant from an issuer account based on the payment card information of the customer. The method further includes receiving, by the merchant terminal, an acknowledgement of a payment to the acquirer account from the issuer account.
[0008] In yet another embodiment, a server system for processing a payment performed at a merchant terminal of a first merchant for a second merchant is disclosed. The server system comprises a memory to store instructions and at least one processor. The processor is configured to execute the stored instructions to cause the server system to perform a method. The method includes receiving a payment transaction request from a merchant terminal of a first merchant. The payment transaction request comprises a merchant information of a second merchant, a payment card information of a payment card of a customer and a transaction amount to be paid to an acquirer account of the second merchant from an issuer account associated with the payment card. The method includes processing a payment of the transaction amount from the issuer account to the acquirer account of the second merchant upon successful verification of the payment transaction request. The method further includes sending a notification of the payment to a merchant device associated with the second merchant.
[0009] Other aspects and example embodiments are provided in the drawings and the detailed description that follows.

BRIEF DESCRIPTION OF THE FIGURES
[0010] 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:
[0011] FIG. 1 illustrates an example representation of an environment, in which at least some example embodiments of the present disclosure can be implemented;
[0012] FIGS. 2A and 2B represent a sequence flow diagram of a payment transaction performed at a merchant terminal of a first merchant for payment to a second merchant, in accordance with an example embodiment of the present disclosure;
[0013] FIGS. 2C and 2D illustrate a sequence flow diagram of a payment transaction performed at a merchant terminal of a first merchant for payment to a second merchant, in accordance with another example embodiment of the present disclosure;
[0014] FIG. 3 illustrates a sequence flow diagram of a payment transaction performed at a merchant terminal of a first merchant for payment to a second merchant, in accordance with yet another example embodiment of the present disclosure;
[0015] FIG. 4A illustrates a sequence flow diagram of a refund from a merchant account of a second merchant to an acquirer account of a customer where transaction is performed at a merchant terminal of a first merchant, in accordance with an example embodiment of the present disclosure;
[0016] FIG. 4B illustrates a sequence flow diagram of a refund from a merchant account of a second merchant to an acquirer account of a customer where transaction is performed at a merchant terminal of a first merchant, in accordance with another example embodiment of the present disclosure;
[0017] FIG. 5A illustrates an example representation of a UI displayed to a second merchant on a display screen of a merchant device by an application interface for receiving merchant information, in accordance with an example embodiment of the present disclosure;
[0018] FIG. 5B illustrates an example representation of a UI displayed to a second merchant on a display screen of a merchant device by an application interface depicting one or more merchant terminals in a pre-defined area of the second merchant, in accordance with an example embodiment of the present disclosure;
[0019] FIG. 5C illustrates an example representation of a UI displayed to a second merchant on a display screen of a merchant device by an application interface providing location information of a merchant terminal selected by the second merchant, in accordance with an example embodiment of the present disclosure;
[0020] FIG. 5D illustrates an example representation of a UI displayed to a second merchant on a display screen of a merchant device by an application interface displaying a machine-readable encrypted code, in accordance with an example embodiment of the present disclosure;
[0021] FIG. 6A illustrates an example representation of a UI displayed on a display screen of a merchant terminal for managing payments/refunds of one or more second merchants, in accordance with an example embodiment of the present disclosure;
[0022] FIG. 6B illustrates an example representation of a UI displayed on a merchant terminal for processing payment to a second merchant, in accordance with an example embodiment of the present disclosure;
[0023] FIG. 7A illustrates an example representation of a UI displayed on a merchant terminal for processing refund from a second merchant, in accordance with an example embodiment of the present disclosure;
[0024] FIG. 7B illustrates an example representation of a UI displayed to a second merchant on a display screen of a merchant device by an application interface displaying a refund approval request, in accordance with an example embodiment of the present disclosure;
[0025] FIG. 8 illustrates a flow diagram depicting a method for payment at a merchant terminal of a first merchant for a second merchant, in accordance with an example embodiment of the present disclosure;
[0026] FIG. 9 illustrates a flow diagram depicting a method for payment at a merchant terminal of a first merchant for a second merchant, in accordance with another example embodiment of the present disclosure;
[0027] FIG. 10 is a simplified block diagram of a server system for performing payment to a second merchant using a merchant terminal of a first merchant, in accordance with an example embodiment of the present disclosure;
[0028] FIG. 11 is a simplified block diagram of a POS terminal of a first merchant used for payment transactions to a second merchant, in accordance with an example embodiment of the present disclosure;
[0029] FIG. 12 is a simplified block diagram of an issuer server used for payment transaction with a payment card, in accordance with an example embodiment of the present disclosure;
[0030] FIG. 13 is a simplified block diagram of an acquirer server used for processing payment transactions to a second merchant using a merchant terminal of a first merchant, in accordance with an example embodiment of the present disclosure;
[0031] FIG. 14 is a simplified block diagram of a payment server used for processing payment transactions to a second merchant using a merchant terminal of a first merchant, in accordance with an example embodiment of the present disclosure; and
[0032] FIG. 15 shows simplified block diagram of a merchant device, for example, a mobile phone capable of implementing the various embodiments of the present disclosure.
[0033] 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
[0034] 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.
[0035] 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.
[0036] 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.
[0037] The term "payment account" used throughout the description 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 PayPal®, and the like.
[0038] The term "payment card", used throughout the description, 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 include, but are not limited to, debit cards, credit cards, prepaid cards, virtual payment numbers, digital wallet cards, virtual card numbers, forex cards, 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.
[0039] 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 Mastercard®.
[0040] The term ‘first merchant’ as used hereinafter refers to a merchant facility equipped with electronic payment infrastructure, such as POS terminals for performing financial transactions in exchange for goods/services. Accordingly, the ‘first merchant’ is also referred to herein as a ‘big merchant’. An example of the big merchant may be a restaurant, a book store, a coffee shop or a supermarket.
[0041] The term ‘second merchant’ as used hereinafter refers to a merchant selling goods and/or providing services on a small scale with no access to electronic payment infrastructure. It shall be noted that in some cases, merchant facilities with no access to payment facilities due to faulty machines, technical glitches or power failure may also be addressed as ‘second merchant’. Accordingly, the ‘second merchant’ is also referred to herein as a ‘small merchant’. An example of the small merchant may be a street vendor, a hawker or any other individual business entity that do not have a merchant terminal for financial transactions using payment cards.
OVERVIEW
[0042] In many example scenarios, a consumer may buy goods/services from a second merchant who may not have provisions of electronic payment infrastructure (e.g., a merchant terminal such as a POS machine) to enable financial transactions using payment cards. In such cases, the consumer may be forced to pay for the goods/services using cash. In addition, the consumer may have to tender exact amount pertaining to the goods/services availed from the second merchant. Moreover, cash transactions preclude use of payment cards for financial transactions that require merchant terminals equipped with electronic payment infrastructures. As the electronic payment infrastructures increase cost and maintenance of the merchant terminals for the second merchant having a small margin of gain, there is a need to obviate the installation of a merchant terminal for every second merchant.
[0043] Various example embodiments of the present disclosure provide methods, systems, user devices and computer program products for performing payment transactions to the second merchant using a merchant terminal of a first merchant. More specifically, techniques disclosed herein enable performing payments/refunds for goods/services purchased from the second merchant at the POS terminal of the first merchant.
[0044] In an embodiment, the consumer may purchase goods/services from the second merchant and pay for the goods/services at the merchant terminal of the first merchant. For example, the consumer can buy fruits from a fruit vendor and pay for the fruits at the merchant terminal of a supermarket processing payment transactions to a merchant account of the fruit vendor. In an embodiment, a server system associated with a payment network provides a software application, referred to herein as an application interface. The application interface is configured to acquire merchant information of the second merchant and facilitate registration of the second merchant with one or more merchant terminals associated with one or more first merchants for processing payment transaction to the second merchant from at least one merchant terminal associated with the first merchant. The merchant information includes information such as, name of the second merchant, merchant identifier and account details of the second merchant such as, merchant account, and acquirer bank of the second merchant. In another embodiment, the server system generates a unique reference code in the application interface for the second merchant based on the merchant information. The unique reference code is provided by the second merchant to the customer for performing payment transaction at the merchant terminal of the first merchant for the goods/services purchased from the second merchant. The unique reference code is readable at the merchant terminal of the first merchant to access the merchant information of the second merchant.
[0045] In at least one embodiment, the second merchant can access the application interface on the merchant device to identify one or more merchant terminals associated with one or more first merchants present within a pre-defined area of the location of the merchant device. For instance, the server system accesses location of the merchant device of the second merchant for identifying the one or more merchant terminals associated with one or more first merchants in the pre-defined area. The server system is further configured to automatically store the merchant information of the second merchant on at least one merchant terminal of the one or more merchant terminals for processing the payment transaction for the goods/services purchased by the customer from the second merchant.
[0046] Illustrating an example use, the customer reaches the merchant terminal of the first merchant for performing payment transaction for the purchases made at the second merchant, and the customer presents his payment card at the payment terminal. The server system receives a payment transaction request from the merchant terminal of the first merchant. The payment transaction request includes the merchant information of the second merchant, a payment card information of a payment card of the customer and a transaction amount to be paid to an acquirer account of the second merchant from an issuer account associated with the payment card. The merchant terminal of the first merchant accesses an identifier of the second merchant for identifying the merchant information of the second merchant. In an embodiment, the identifier may be the unique reference code generated by the second merchant via the application interface. Alternatively, the customer may verbatim communicate the merchant identifier of the second merchant or name of the second merchant if the second merchant is either registered with the first merchant or if the merchant information is stored in the merchant terminal of the first merchant. In such cases, the merchant terminal is caused to display a list of second merchants on a display screen of the merchant terminal of the first merchant upon receiving the payment transaction request. The customer can select at least one second merchant from the list of second merchants.
[0047] The payment transaction request is validated by the server system and upon successful verification of the payment transaction request, the transaction amount is transferred from the issuer account of the customer to the acquirer account of the second merchant. The server system thereafter sends a notification of the payment transaction to the merchant device associated with the second merchant.
[0048] Various example embodiment of the payment transaction for the second merchant using the merchant terminal of the first merchant are further explained in detail with reference to FIGS. 1 to 15.
[0049] FIG. 1 illustrates an example representation of an environment 100, in which at least some example embodiments of the present disclosure can be implemented. The environment 100 is exemplarily shown as a commercial arena 102 depicting a plurality of merchants such as a first merchant 104 and a second merchant 112. In the illustrated embodiment, the first merchant 104 is a merchant facility shown as equipped with a merchant terminal/POS terminal 110 and a merchant interface device 108. The merchant interface device 108 can be a telephone or a computer system operated by an agent 106 for performing payment transactions on behalf of a customer. As seen in FIG. 1, the merchant interface device 108 is a computer system operated by the agent 106. It shall be noted that herein the POS terminal 110 refers to a POS machine which is used to swipe payment cards and not the entire setup including, cash drawers, printers and barcode scanners. Examples of the first merchant 104 may include any retail shop, restaurant, supermarket or establishment, government and/or private agencies, or any such place equipped with POS terminals, such as the merchant terminal 110 where customers visit for performing financial transaction in exchange for any goods and/or services or any transaction that requires financial transaction between customers and a merchant. It shall be noted that more than one such POS terminal can be present in the merchant facility of the first merchant 104.
[0050] The commercial arena 102 depicts a customer 118 purchasing products from the second merchant 112. Examples of the second merchant 112 may include a street vendor, a hawker, a cobbler, a mobile food merchant, any other individual business entity that do not have a merchant terminal for financial transactions using payment cards or any merchant facility with no access to merchant terminals due to faulty machines, technical glitches or power failure, etc. The second merchant 112 may request the customer 118 to pay for the products at the merchant terminal 110 of the first merchant 104. The second merchant 112 is equipped with a merchant device 114. In an example embodiment, the merchant device 114 is equipped with an instance of an application installed therein. The application and its components rest in a server system such as a payment server 128 and the merchant device 114 can communicate with the payment server 128 through the application installed in the merchant device 114. The application is a set of computer executable codes configured to acquire merchant information from the second merchant 112 and generate a unique reference code based on the merchant information. The set of computer executable codes may be stored in a non-transitory computer-readable medium of the merchant device 114. The application may be a mobile application or a web application. The terms ‘application’ is interchangeably referred to as ‘application interface’ throughout the present description.
[0051] To accept payment transactions from customers, the first merchant 104 and the second merchant 112 must normally establish an account with a financial institution that is part of the financial payment system. This financial institution is usually called the “merchant bank” or the “acquiring bank” or “acquirer bank” or simply “acquirer”. For the purposes of the present description, the acquirer of the first merchant 104 is referred to as a first acquirer and the acquirer of the second merchant 112 is referred to as a second acquirer. It shall be noted that the first acquirer and the second acquirer may be the same acquirer or different acquirers.
[0052] In an embodiment, the second merchant 112 may register with the merchant terminal 110 of the first merchant 104 for processing payment transactions at the merchant terminal 110. For instance, the second merchant 112 may contact the first acquirer associated with the first merchant 104 to register with the merchant terminal 110 so as to enable payment transactions from customers (e.g., the customer 118) to the second acquirer associated with the second merchant 112. The second merchant 112 registers with the merchant terminal 110 of the first merchant 104 by providing merchant information of the second merchant 112 to a first acquirer server 122. The merchant information may include, among other things, name of the second merchant 112, information of an acquirer of the second merchant 112 and account number of the second merchant 112. The first acquirer uses the merchant information provided at the first acquirer server 122 to configure the merchant terminal 110 of the first merchant 104.
[0053] In another embodiment, the second merchant 112 may provide the unique reference code to the customer 118 for payment at the merchant terminal 110 of the first merchant 104. The unique reference code is a generated at the application interface of the merchant device 114 and is readable at the merchant terminal 110 to access the merchant information of the second merchant 112. In an example, the customer 118 can display the unique reference code at the merchant terminal 110 of the first merchant 104. The unique reference code is readable by the merchant terminal 110 to retrieve merchant information of the second merchant 112.
[0054] In one embodiment, the second merchant 112 can search for one or more merchant terminals in a vicinity of the small merchant 112 via the application interface on the merchant device 114. When the second merchant 112 initiates a search request for one or more merchant terminals via the application interface, the search request is received by the payment server 128. The payment server 128 accesses location of the merchant device 114 of the second merchant 112 for identifying the one or more merchant terminals associated with one or more first merchants present within a pre-defined area of the location of the merchant device 114. The pre-defined area may be configured depending upon the geographical area, size of a city, density of merchants in the geographical area etc. In an embodiment, the payment server 128 stores the merchant information of the second merchant 112 on at least one merchant terminal (e.g., the merchant terminal 110) of the one or more merchant terminals identified in the pre-defined area.
[0055] A payment transaction request is initiated at the merchant terminal 110 for the purchase made by the customer 118 at the second merchant 112. In an embodiment, the first acquirer server 122 receives the payment transaction request from the merchant terminal 110. The payment transaction request comprises the merchant information of the second merchant 112, a payment card information of the payment card of the customer 118 and the transaction amount to be paid to the acquirer account of the second merchant 112 from an issuer account associated with the payment card of the customer 118. The merchant information of the second merchant 112 is either accessed from the unique reference code or a merchant identifier of the second merchant 112 provided by the customer 118. The customer 118 may verbatim communicate the merchant identifier of the second merchant 112 or name of the second merchant 112 if the second merchant 112 is either registered with the first acquirer of the first merchant 104 or if the merchant information of the second merchant 112 is stored in the merchant terminal 110 of the first merchant 104 by the payment server 128. In such cases, the merchant terminal 110 is caused to display of a list of second merchants on a display screen of the merchant terminal 110 of the first merchant 104 upon receiving the payment transaction request. The customer 118 can select at least one second merchant (e.g., the second merchant 112) from the list of second merchants.
[0056] The first acquirer server 122 sends the payment transaction request to the payment server 128 that filters the payment transaction request to the second acquirer server 124 associated with second acquirer of the second merchant 112. The payment server 128 validates the payment transaction request and upon successful verification of the payment transaction request, the transaction amount is transferred using an issuer server 126 and the second acquirer server 124 via the payment network 130. For instance, the transaction amount is settled between an issuer account of the customer 118 to the acquirer account of the second merchant 112. It shall be noted that the terms, "issuer bank" or "issuing bank" or simply "issuer", indicate a bank in which the customer 118 may have the issuer account and the issuer bank issues a payment card, such as a credit card or a debit card, to the customer 118.
[0057] The payment network 130 generates a notification including a payment transaction approval/decline message of the payment transaction to the merchant device 114 associated with the second merchant 112. The payment system interchange network 130 is hereinafter referred to as the payment network 130. Simultaneously or subsequently, the issuer server 126 debits funds equal in amount to the transaction amount from the issuer account of the customer 118. The payment is passed to a merchant account of the second merchant 112 to complete the payment transaction.
[0058] Some non-exhaustive example embodiments of performing the payment transaction to the second merchant 112 using the merchant terminal 110 of the first merchant 104 are described with reference to FIGS. 2A-2B to 15.
[0059] FIGS. 2A and 2B represent a sequence flow diagram 200 of a payment transaction performed at the merchant terminal 110 of the first merchant 104 for the second merchant 112, in accordance with an example embodiment of the present disclosure.
[0060] At 202, the second merchant 112 initiates a registration request to the first acquirer server 122. In a non-limiting example, it is assumed that the first acquirer server 122 provides a platform at the merchant terminal 110 such that customers (e.g., the customer 118) of the second merchant 112 can perform payment at the merchant terminal 110 for the purchase made at the second merchant 112. The registration request includes merchant information of the second merchant 112 such as name of the second merchant 112, acquirer (e.g., the second acquirer) of the second merchant 112, account number and optionally a merchant identifier for identifying the second merchant 112.
[0061] At 204, the first acquirer server 122 validates the merchant information of the second merchant 112.
[0062] At 206, the first acquirer server 122 stores the merchant information of the second merchant 112 in the merchant terminal 110 of the first merchant 104. The merchant terminal 110 has a storage device for storing the merchant information of one or more second merchants (e.g., the second merchant 112) who may register with the first acquirer server 122 of the merchant terminal 110 for facilitating payment transactions to one or more acquirer servers (e.g., the second acquirer server 124 of the second merchant 112) associated with the one or more second merchants. For example, storing the merchant information of the second merchant 112 in the merchant terminal 110 of the first merchant 104 enables the customer 118 to perform payment transactions at the merchant terminal 110.
[0063] At 208, the customer 118 purchases goods/services from the second merchant 112. At 210, the second merchant 112 requests the customer 118 to pay at the merchant terminal 110 of the first merchant 104. For instance, the customer 118 may offer to perform payment using a payment card provided by an issuer. The lack of electronic payment infrastructure such as, the merchant terminal 110 prompts the second merchant 112 to request the customer 118 to make the payment at the merchant terminal 110 of the second merchant 112.
[0064] At 212, the merchant terminal 110 is caused to display a list of second merchants on a display screen of the merchant terminal 110. For instance, upon arrival of the customer 118 at the merchant terminal 110, the customer 118 may communicate to an agent (e.g., the agent 106) operating the merchant terminal 110 that the payment is for the second merchant 112. The agent 106 may key in an input to indicate that the payment is for a different merchant (e.g., the second merchant 112) other than the first merchant 104. In an embodiment, the merchant terminal 110 has a merchant identifier flag amongst other flags for identifying if the payment transaction is for the first merchant 104 or for any other second merchant such as, the second merchant 112. When the agent 106 provides the input to indicate that the payment is for a different merchant, the merchant identifier flag is modified automatically. Upon modification of the merchant identifier flag, the merchant terminal 110 is caused to display the list of the second merchants registered with the merchant terminal 110.
[0065] At 214, the merchant terminal 110 receives a selection input on at least one second merchant (e.g., the second merchant 112). The customer 118 may select a second merchant (e.g., the second merchant 112) from the list of second merchants displayed on the merchant terminal 110. Alternatively, the customer 118 may verbatim communicate name of the second merchant 112 and the agent 106 may provide the selection input on the second merchant 112 in the list of second merchants. In an embodiment, the merchant identifier flag may also include the merchant information of the second merchant 112. Upon receipt of the selection input, the merchant identifier flag in the merchant terminal 110 is automatically modified to indicate that the payment is for the second acquirer server 124 associated with the second merchant 112.
[0066] At 216, the merchant terminal 110 sends a payment transaction request and the merchant identifier flag to the first acquirer server 122. The payment transaction request includes, among other things, the merchant information of the second merchant 112, a payment card information of the payment card of the customer 118 and a transaction amount to be paid to the acquirer account of the second merchant 112 from an issuer account associated with the payment card of the customer 118. It shall be noted that the merchant terminal 110 scan/reads customer data stored in the payment card to identify the issuer account. The agent 106 may key-in the transaction amount on the merchant terminal 110 and the merchant information is accessed from the merchant identifier flag and/or the storage space on the merchant terminal 110 based on the selection input.
[0067] At 218, the first acquirer server 122 forwards the payment transaction request and the merchant identifier flag to the payment server 128. When the first acquirer server 122 receives the merchant identifier flag, the first acquirer server 122 identifies that the payment transaction is for a different merchant (e.g., the second merchant 112) from the merchant identifier flag and forwards the payment transaction request along with the merchant identifier to the payment server 128.
[0068] At 220, the payment transaction request is verified and filtered for the second merchant 112 by the payment server 128. The payment server 128 reads the merchant identifier flag to determine that the payment transaction request is intended for the second acquirer server 124. The second acquirer server 124 is associated with a merchant account of the second merchant 112 to which the transaction amount will be credited from the issuer account of the customer 118. The payment server 128 may maintain a master database which includes transaction processing data. The transaction processing data includes details such as issuer ID, POS ID, country code, first acquirer ID, second acquirer ID, among others. Upon receiving the payment transaction request from the first acquirer server 122, the payment server 128 may perform a lookup into the transaction processing data to check the authenticity of the POS terminal 110.
[0069] At 222, the payment transaction request is sent to the issuer server 126. At 224, the issuer server 126 authorizes the payment transaction request. The issuer server 126 verifies the payment card information of the customer 118, approves the payment transaction request, and processes the payment from the issuer account to the acquirer account via the payment server 128. Details of the payment transaction from the issuer account to the merchant account are not provided herein in detail for the sake of brevity. For instance, in a non-limiting example, upon receiving a correct fixed character length PIN or a fixed character length one-time password (OTP) from the customer 118, the customer 118 is validated and authenticated by the issuer server 126 and the transaction amount is settled between the issuer account and the acquirer account of the second merchant 112 via the payment server 128.
[0070] At 226, a notification including a payment transaction approval or decline message is sent to the payment server 128 from the issuer server 126 via the payment network 130. At 228, the notification including the payment transaction approval or decline message is sent to the second acquirer server 124 from the payment server 128. At 230, the notification including the payment transaction approval or decline message is sent to the merchant terminal 110 as well as the merchant device 114 of the second merchant 112 from the payment server 128 via the payment network 130.
[0071] Referring now to FIGS. 2C and 2D, a sequence flow diagram 240 of a payment transaction performed at the merchant terminal 110 of the first merchant 104 for the second merchant 112 is illustrated in accordance with another example embodiment of the present disclosure.
[0072] At 242, the customer 118 makes a purchase from the second merchant 112. The customer 118 may offer to perform payment for the goods/services using a payment card provided by an issuer associated with the customer 118. The lack of electronic payment infrastructure such as, the merchant terminal 110 prompts the second merchant 112 to request the customer 118 to pay at the merchant terminal 110 of the second merchant 112. At 244, the customer 118 is requested to pay at the merchant terminal 110 of the first merchant 104 which is in vicinity of the second merchant 112.
[0073] At 246, the merchant terminal 110 is caused to display a list of second merchants on a display screen of the merchant terminal 110. For instance, when the customer 118 arrives at the merchant terminal 110 to perform payment using his payment card, the customer 118 may communicate to an agent (e.g., the agent 106) operating the merchant terminal 110 that the payment is for the second merchant 112. The agent 106 may key in an input to indicate that the payment is for a different merchant (e.g., the second merchant 112) other than the first merchant 104 that causes the merchant terminal 110 to modify the merchant identifier flag and display the list of second merchants registered with the merchant terminal 110.
[0074] At 248, the merchant terminal 110 receives a selection input on at least one second merchant (e.g., the second merchant 112). Upon receipt of the selection input, the merchant identifier flag in the merchant terminal 110 is automatically modified to indicate that the payment is for the second acquirer server 124 associated with the second merchant 112. In an embodiment, the merchant identifier flag also includes the merchant information of the second merchant 112. The merchant information is retrieved based on the selection input.
[0075] At 250, the merchant terminal 110 sends a payment transaction request to the second acquirer server 124. The second acquirer server 124 associated with an acquirer of the second merchant 112 is identified from the merchant information. The payment transaction request comprises the merchant information of the second merchant 112, a payment card information of the payment card of the customer 118 and a transaction amount to be paid to the acquirer account of the second merchant 112 from an issuer account associated with the payment card of the customer 118.
[0076] At 252, the second acquirer server 124 forwards the payment transaction request to the payment server 128 via the payment network 130. At 254, the payment transaction request is verified by the payment server 128. In an embodiment, the payment server 128 may maintain a master database which includes transaction processing data. The transaction processing data includes details such as issuer ID, POS ID, country code, first acquirer ID, second acquirer ID, among others. Upon receiving the payment transaction request from the first acquirer server 122, the payment server 128 may perform a lookup into the transaction processing data to check the authenticity of the POS terminal 110.
[0077] At 256, the payment transaction request is sent to the issuer server 126 by the payment server 128. At 258, the issuer server 126 authorizes the payment transaction request. The issuer server 126 validates the payment card information of the customer 118 for processing the payment from the issuer account of the customer 118 to the acquirer account of the second merchant 112 associated with the second acquirer server 124 via the payment server 128.
[0078] At 260, a notification including a payment transaction approval or decline message is sent to the payment server 128 from the issuer server 126 via the payment network 130. At 262, the notification including the payment transaction approval or decline message is sent to the second acquirer server 124 from the payment server 128. At 264, the notification including the payment transaction approval or decline message is sent to the merchant terminal 110 as well as the merchant device 114 of the second merchant 112 from the payment server 128 via the payment network 130.
[0079] Referring now to FIG. 3, a sequence flow diagram 300 of a payment transaction performed at the merchant terminal 110 of the first merchant 104 for the second merchant 112 is illustrated in accordance with yet another example embodiment of the present disclosure.
[0080] At 302, the customer 118 makes a purchase at the second merchant 112.
[0081] At 304, the second merchant 112 accesses an application interface to provide a search request for identifying one or more merchant terminals (e.g., associated with first merchants) for processing payment transactions. The search request includes merchant information and a location of the second merchant 112 to the payment server 128. In an example, the customer 118 may offer to pay for the goods/services using a payment card. As the second merchant 112 is not equipped with electronic payment infrastructure, the second merchant 112 may request the customer 118 to pay at a merchant facility equipped with a merchant terminal (e.g., the merchant terminal 110 of the first merchant 104). The second merchant 112 may have a device, for example, the merchant device 114 equipped with the application interface installed therein. The second merchant 112 accesses the application interface to provide the merchant information such as, name, an acquirer, a merchant account number and optionally a merchant identifier of the second merchant 112. Additionally, the location of the second merchant 112 is also accessed via the merchant device 114. An example of providing the search request is shown and explained with reference to FIG. 5A.
[0082] At 306, the merchant information of the second merchant 112 is validated by the payment server 128. At 308, the payment server 128 identifies the one or more merchant terminals in a pre-defined area around the location of the second merchant 112. In an example, the payment server 128 maintains a master database which includes transaction processing data and location information associated with a plurality of merchant terminals. For example, the master database includes details such as POS ID, country code, acquirer ID, details of second merchant registered with the POS, location information, among others. Upon receiving the search request from the merchant device 114 of the second merchant 112 via the application interface, the payment server 128 may perform a lookup into the master table to identify the one or more merchant terminals in close proximity of the location of the second merchant 112. For example, if the second merchant 112 is a mobile food truck, the location of the second merchant 112 may not be fixed and changes dynamically with time. When the second merchant 112 is on the move, a customer (e.g., the customer 118) may buy food from the second merchant at a first location. The second merchant 112 may access the application interface on the merchant device 114 to place a search request for nearby merchant terminals where the customer 118 can pay using his/her payment card. The payment server 128 receives the search request to identify the one or more merchant terminals, for example, terminal 1, terminal 2 and terminal 3 in close proximity to the first location.
[0083] At 310, details of the one or more merchant terminals are sent to the second merchant 112 on the merchant device 114 via the application interface. The details of the one or more merchant terminals (terminal 1, terminal 2 and terminal 3) are provided to the second merchant 112 via the application interface. In an embodiment, the second merchant 112 may share the details of the one or more merchant terminals (terminal 1, terminal 2 and terminal 3) with the customer 118 and requests the customer 118 to pay at any of these merchant terminals (terminal 1, terminal 2 and terminal 3). In another embodiment, the second merchant 112 may share the details of a specific merchant terminal (e.g., the terminal 2) for performing the payment transaction. In an example, the second merchant 112 may request the customer 118 to pay at the merchant terminal 110 of the first merchant 104. An example of the application interface displaying merchant terminals of first merchants in the pre-defined area is shown and explained with reference to FIG. 5B.
[0084] At 312, subsequently or simultaneously, the payment server 128 stores the merchant information of the second merchant 112 on the one or more merchant terminals (terminal 1, terminal 2 and terminal 3) of the one or more first merchants. The storing of the merchant information of the second merchant 112 enables the customer 118 to perform payment transaction at any of the merchant terminals (terminal 1, terminal 2 and terminal 3) for the goods bought at the second merchant 112. In an embodiment, the second merchant 112 may choose a specific merchant terminal (e.g., the merchant terminal 110) and the payment server 128 stores the merchant information at the merchant terminal 110.
[0085] At 314, the second merchant 112 provides details of the merchant terminal 110 and/or a unique reference code to the customer 118. The unique reference code is a machine-readable code and is generated by the payment server 128 based on the merchant information. For example, the unique reference code encrypts the merchant information of the second merchant 112. In an embodiment, the unique reference code is a onetime code generated by the payment server 128 for the second merchant 112. The unique reference code is provided to the second merchant 112 via the application interface and may be stored locally in a memory of the merchant device 114. Examples of the unique reference code include a bar code, a QR code or the likes, in an example embodiment. In another example embodiment, the unique reference code can be a blockchain hash or a hash. For the purposes of this disclosure, the unique reference code is assumed to be a QR code. The customer 118 may have a user device provisioned with image capturing modules using which photographs of the unique reference code can be captured or scanned and stored in the user device. It shall be noted that there may exist other methods for receiving the unique reference code from the second merchant, such as a printed version of the unique reference code.
[0086] At 316, the second merchant 112 requests the customer 118 to pay at the merchant terminal 110 of the first merchant 104 using unique reference code. At 318, the unique reference code is read at the merchant terminal 110. The merchant terminal 110 is equipped with scanners that are configured to read the unique reference code. Alternatively, the customer 118 may communicate details of the second merchant 112, such as, name or the merchant identifier of the second merchant 112 that may cause the merchant terminal 110 to display a list of second merchants. It shall be noted that the list of second merchants is not limited to second merchants registered with the merchant terminal 110 but additionally includes second merchants (e.g., the second merchant 112) whose merchant information have been stored in a cache memory of the merchant terminal 110 by the payment server 128. The merchant information of a second merchant (e.g., the second merchant 112) is stored in a merchant terminal (e.g., the merchant terminal 110) when the second merchant 112 places a search request to the payment server 128 for processing payment to the merchant account of the second merchant 112. The customer 118/the agent 106 may provide a selection input on at least one second merchant, such as, the second merchant 112 of the list of second merchants. The merchant terminal 110 automatically retrieves the merchant information of the second merchant 112 from the memory upon receipt of the selection input.
[0087] At 320, the merchant terminal 110 identifies the merchant information associated with the second merchant 112 by decoding the unique reference code. For instance, the unique reference code is decoded to determine the merchant information such as, merchant name, acquirer, and merchant account of the second merchant 112. In an embodiment, the merchant information is mapped onto the merchant information already stored in the merchant terminal 110 by the payment server 128 for identifying the second merchant 112. Subsequently, the merchant terminal 110 sends the payment transaction to the second acquirer server 124 associated with the merchant account of the second merchant 112 based on the merchant information.
[0088] At 322, the merchant terminal 110 sends a payment transaction request to the second acquirer server 124. The payment transaction request comprises the merchant information of the second merchant 112, a payment card information of the payment card of the customer 118 and a transaction amount to be paid to the acquirer account of the second merchant 112 from an issuer account associated with the payment card of the customer 118.
[0089] At 324, the second acquirer server 124 forwards the payment transaction request to the payment server 128 via the payment network 130. At 326, the payment transaction request is verified and filtered for the second merchant 112 by the payment server 128. Upon receiving the payment transaction request from the second acquirer server 124, the payment server 128 may perform a lookup into the master processing table to check the authenticity of the merchant terminal 110.
[0090] At 328, the payment transaction request is sent to the issuer server 126. At 330, the issuer server 126 authorizes the payment transaction request. The issuer server 126 verifies the payment card information of the customer 118, approves the payment transaction request, and processes the payment from the issuer account to the merchant account via the payment server 128.
[0091] At 332, a message including a payment transaction approval or decline is sent to the payment server 128 from the issuer server 126 via the payment network 130. At 334, the notification including the payment transaction approval or decline message is sent to the second acquirer server 124 from the payment server 128. At 336, the notification including the payment transaction approval or decline message is sent to the merchant terminal 110 as well as the merchant device 114 of the second merchant 112 from the payment server 128 via the payment network 130.
[0092] Referring now to FIG. 4A, a sequence flow diagram 400 of a refund from merchant account of the second merchant 112 to an acquirer account of the customer 118 performed at the merchant terminal 110 of the first merchant 104 is illustrated in accordance with an example embodiment of the present disclosure.
[0093] At 402, the customer 118 presents a transaction identifier at the merchant terminal 110 for initiating a refund from the second merchant 112. The transaction identifier may be a string of alphabets and numbers and is used to search and identify a transaction/payment made by the customer 118 at the merchant terminal 110.
[0094] At 404, a refund request is sent to the first acquirer server 122. The refund request includes, among other things, the merchant information of the second merchant 112, the payment card information of the payment card of the customer 118 and a refund amount to be paid from an acquirer account of the second merchant 112 to the issuer account associated with the payment card of the customer 118. Additionally or optionally, the merchant terminal 110 may send a merchant identifier flag to the first acquirer server 122. The merchant identifier flag is modified to indicate that the refund is intended for the second acquirer server 124 and comprises the merchant information of the second merchant 112. In an embodiment, the transaction identifier is used to retrieve the merchant information of the second merchant 112. The refund amount can either be credited to the issuer account associated with the payment card of the customer 118 provided during the payment or the customer 118 may provide an alternate issuer account for transferring the refund amount.
[0095] At 406, the refund request is forwarded to the payment server 128. When the first acquirer server 122 receives the merchant identifier flag, the first acquirer server 122 identifies that the payment transaction is for a different merchant (e.g., the second merchant 112) from the merchant identifier flag and forwards the payment transaction request along with the merchant identifier to the payment server 128.
[0096] At 408, the payment server 128 filters transactions to the second acquirer server 124. The payment server 128 reads the merchant identifier flag to determine that the payment transaction request is intended for the second acquirer server 124. In an embodiment, the payment server 128 may maintain a master database which includes transaction processing data. The transaction processing data includes details such as transaction identifier, issuer ID, POS ID, country code, first acquirer ID, second acquirer ID, among others. Upon receiving the payment transaction request from the first acquirer server 122, the payment server 128 may perform a lookup into the transaction processing data to check the authenticity of the merchant terminal 110.
[0097] At 410, the refund request is sent to the second acquirer server 124. The second acquirer server 124 may be associated with the merchant account of the second merchant 112 from which the refund amount will be debited and credited to the issuer account of the customer 118.
[0098] At 412, a refund approval request is sent to the merchant device 114 associated with the second merchant 112 via an application interface. An example of the refund approval request displayed on the application interface is shown and explained with reference to FIG. 7B.
[0099] At 414, the merchant device 114 may optionally review goods returned by the customer 118. At 416, an approval of the refund request is sent to the second acquirer server 124 from the merchant device 114. The second merchant 112 can choose to approve or decline the refund based on the goods returned by the customer 118.
[00100] At 418, a refund amount is sent to the payment server 128. The second acquirer server 124 further verifies the acquirer account of the second merchant 112 and the refund request, approves the refund request, and processes the refund from the acquirer account to the issuer account via the payment server 128.
[00101] At 420, the payment server 128 settles the refund amount to the issuer server 126 via the payment network 130. The refund amount is credited to the issuer account of the customer 118 from the merchant account of the second merchant 112. At 422, a notification of the refund is sent to the merchant terminal 110 as well as the merchant device 114 of the second merchant 112.
[00102] Referring now to FIG. 4B, a sequence flow diagram 450 of a refund from merchant account of the second merchant 112 to an acquirer account of the customer 118 performed at the merchant terminal 110 of the first merchant 104 is illustrated in accordance with another example embodiment of the present disclosure.
[00103] At 452, the customer 118 returns goods to the second merchant 112 and requests for a refund from the second merchant 112. At 454, the second merchant 112 reviews and approves the goods returned by the customer 118. For instance, if the customer 118 is not satisfied with the goods he/she purchased, the customer 118 may return the goods to the second merchant 112 and request for the refund of a payment amount he paid for the goods to the issuer account associated with the customer 118.
[00104] At 456, the second merchant 112 accesses an application interface to provide a search request to the payment server 128 for identifying one or more merchant terminals associated with one or more first merchants for processing the refund. The search request includes merchant information and a location of the second merchant 112. In an example, as the second merchant 112 is not equipped with electronic payment infrastructure, the second merchant 112 may request the customer 118 to initiate the refund at a merchant facility equipped with a merchant terminal (e.g., the merchant terminal 110 of the first merchant 104). The second merchant 112 may access the application interface on a device, for example, the merchant device 114 equipped with the application interface installed therein. The second merchant 112 provides the merchant information such as, name, an acquirer, a merchant account number and optionally a merchant identifier of the second merchant 112. Additionally, the location of the second merchant 112 is also accessed, for example geo-coordinates of the merchant device 114 from GPS. An example of providing the search request is shown and explained with reference to FIG. 5A.
[00105] At 458, the merchant information of the second merchant 112 is validated by the payment server 128 and the one or more merchant terminals in a pre-defined area of the location of the second merchant 112 are identified. For instance, the payment server 128 upon receipt of the search request, validates credentials of the second merchant 112 based on the merchant information stored in a master database of the payment server 128. When the merchant information is validated, the payment server 128 uses the location of the second merchant 112 to identify the one or more merchant terminals in vicinity of the second merchant 112 accepting payment transactions for other merchants, such as, the merchant terminal 110 of the first merchant 104. It shall be noted that the pre-defined area conforms to a relative distance measure between the second merchant 112 and the one or more merchant terminals and may be preset in the application interface. In an embodiment, the second merchant 112 is provided with options to change/ modify the pre-defined area in the application interface. For example, if the second merchant 112 is at a first location, he/she may choose to provide the pre-defined area as 100 meters, indicating that the one or more merchant terminals within a radius of 100 meters of the first location can be identified for initiating the refund on behalf of the second merchant 112 from an associated merchant account. In an embodiment, the pre-defined area is a fixed value and defined by the payment server 128 for identifying the one or more merchant terminals.
[00106] At 460, the payment server 128 stores the merchant information of the second merchant 112 on the one or more merchant terminals of the one or more first merchants. In an example, the payment server 128 determines that merchant terminals (terminal 1, terminal 2, terminal 3) of first merchants (merchant 1, merchant 2, merchant 3) within the pre-defined area and the merchant information of the second merchant 112 is stored in the merchant terminals (terminal 1, terminal 2, terminal 3). In an embodiment, the merchant information of the second merchant 112 is stored in at least one merchant terminal of the one or more merchant terminals. In an example, the application interface may display the merchant terminals (terminal 1, terminal 2, terminal 3) of the first merchants (merchant 1, merchant 2, merchant 3) on the application interface (see, FIG. 5B) of the merchant device 114. Further, the application interface may prompt the second merchant 112 to select at least one merchant terminal. Upon receiving a selection input on at least one merchant terminal, for example, the terminal 2 (e.g., the merchant terminal 110) displayed on the application interface, the payment server 128 is prompted to store the merchant information in the terminal 2 (the merchant terminal 110) of the first merchant (merchant 2). In an embodiment, the merchant information of the second merchant 112 is stored in a cache memory corresponding to each terminal of the one or more merchant terminals.
[00107] At 462, subsequently or simultaneously, details of the one or more merchant terminals are notified to the second merchant 112 on the merchant device 114 via the application interface. The details of the one or more merchant terminals may include name of the first merchants (e.g., Restaurant) associated with the merchant terminal 110, location of the merchant terminal 110 and optionally a contact number. An example of the application interface displaying details of the merchant terminal 110 in the pre-defined area is shown and explained with reference to FIG. 5C.
[00108] At 464, the details of the one or more merchant terminals and a unique reference code are provided to the customer 118 by the second merchant 112. The second merchant 112 may share the details of the one or more merchant terminals, such as location and name of the merchant terminal, for example, the merchant terminal 110. Optionally, the second merchant 112 may share a unique reference code with the customer 118 for identifying the merchant information of the second merchant 112. The unique reference code is a machine-readable code and encrypts the merchant information such as, merchant account number, acquirer bank and name of the second merchant 112. It shall be noted that in some embodiments, the second merchant 112 shares only name of the second merchant 112 with the customer 118 and the customer 118 initiates the refund at the merchant terminal 110 by communicating the name of the second merchant 112. Upon communication of the refund initiation from a different merchant (e.g., the second merchant 112) at the merchant terminal 110, the merchant terminal 110 may be caused to display a list of second merchants associated with the merchant terminal 110. In such cases, either the customer 118 or the agent 106 operating the merchant terminal 110 may provide a selection input on the second merchant 112. Upon receiving the selection input, the merchant information is retrieved from the cache memory of the merchant information for initiating the refund.
[00109] At 466, the second merchant 112 requests the customer 118 to initiate the refund at the merchant terminal 110 of the first merchant 104. At 468, a refund request initiated at the merchant terminal 110 is sent to the second acquirer server 124. The refund request comprises the merchant information of the second merchant 112, the payment card information of the payment card of the customer 118 and a refund amount to be paid from an acquirer account of the second merchant 112 to the issuer account associated with the payment card of the customer 118. In an embodiment, a merchant identifier flag is modified at the merchant terminal 110 indicating that the refund request is for the second merchant 112. In an example, the merchant identifier flag includes the merchant information of the second merchant 112.
[00110] At 470, a refund approval request is sent to the merchant device 114 associated with the second merchant 112 via an application interface. An example of the refund approval request displayed on the application interface is shown and explained with reference to FIG. 7B. At 472, an approval successful for the refund request is sent to the second acquirer server 124 from the merchant device 114 of the second merchant 112.
[00111] At 474, a refund amount is sent to the payment server 128. The second acquirer server 124 verifies the acquirer account of the second merchant 112 and the refund request, approves the refund request, and processes the refund from the acquirer account to the issuer account via the payment server 128.
[00112] At 476, the payment server 128 settles the refund amount to the issuer server 126 via the payment network 130. The refund amount is credited to the issuer account of the customer 118 from the merchant account of the second merchant 112. At 478, a notification of the refund is sent to the merchant terminal 110 as well as the device of the second merchant 112 and the customer 118.
[00113] In an embodiment, the application interface causes display of one or more user interfaces (UIs) for receiving user input related to merchant information from the second merchant 112 for (1) generating a unique reference code readable at the merchant terminal 110, and (2) generating a search request for identifying one or more merchant terminals in a pre-defined area of location of the second merchant. Example UIs displayed to the second merchant 112 for provisioning the merchant information and searching for merchant terminals in the pre-defined area are shown in FIGS. 5A and 5B.
[00114] Referring now to FIG. 5A, an example representation of a UI 510 displayed to the second merchant 112 on a display screen of the merchant device 114 by an application interface 500 for receiving merchant information, is shown in accordance with an example embodiment of the present disclosure. It is noted that the second merchant 112 and the merchant device 114 are shown in FIG. 1. In an example scenario, after downloading of the application interface 500 from the payment server 128 (shown in FIG. 1), an application icon may be displayed to the second merchant 112 on the display screen of the merchant device 114. The application icon is not shown in FIG. 5A. The second merchant 112 may provide a selection input on the application icon to invoke the application interface 500. The application interface 500, after invoking, may present one or more UIs for creating an account of the second merchant 112.
[00115] The application interface 500 may also provide an option associated with a label ‘Merchant Information’ to provide merchant information for processing payment/refund initiated from a merchant terminal, such as the merchant terminal 110 shown in FIG. 1, and for generating the QR code on the merchant device 114. The UI 510 may be displayed to the second merchant 112 upon user selection of the option associated with the label ‘Merchant Information’. It is noted that the provisioning of the Merchant Information options is explained herein for illustration purposes and it may be designed in various possible ways. Indeed, the UI 510 may be displayed to the second merchant 112, either directly upon invoking the application interface 500 or by selection of other options or options with different labels than the labels explained herein.
[00116] The UI 510 is depicted to include a header portion 512 and a content portion 514. The header portion 512 is depicted to exemplarily display a title associated with text ‘MERCHANT INFORMATION’.
[00117] The content portion 514 of the UI 510 is depicted to display four fields such as name of the second merchant (shown as ‘MERCHANT NAME’), an identifier of the second merchant (shown as ‘MERCHANT IDENTIFIER’), an acquirer of the second merchant (shown as ‘ACQUIRER BANK’) and a merchant account (shown as ‘MERCHANT ACCOUNT NUMBER’) for providing the merchant information of the second merchant. Each field from among the fields is depicted to be associated with a text box. For example, the field ‘MERCHANT NAME is associated with a text box 516, the field ‘MERCHANT IDENTIFIER’ is depicted to be associated with a text box 518, the field ‘ACQUIRER BANK’ is associated with the text box 520 and the field ‘MERCHANT ACCOUNT NUMBER’ is depicted to be associated with a text box 522. It is noted that the fields are shown herein for illustration purpose and that the UI 510 may include more of fewer fields than those depicted in the content portion 514.
[00118] The second merchant may provide the name of the second merchant in the text box 516. The merchant identifier in the text box 518 is a string of alphabets and numbers that identify the second merchant associated with a business. The acquirer bank is name of the financial institution associated with the merchant account of the second merchant. The second merchant provides name of the financial institution in the text box 520. The account number of the second merchant is provided in the text box 522. It is noted that the merchant information provided by the second merchant 112 may be changed or updated at a later point in time as per change in acquirer information.
[00119] The content portion 514 of the UI 510 is further configured to depict a tab 524 associated with text ‘GENERATE QR CODE’ and a tab 526 associated with text ‘SEARCH MERCHANT TERMINAL’. The second merchant 112 may provide a touch or a click input on the tab 524 to generate a QR code for encrypting the merchant information provided in the fields 516, 518, 520 and 522. The selection of the tab 524 may cause display of another UI displaying the QR code encoding the merchant information. An example UI provisioned to the second merchant 112 is shown in FIG. 5D. The second merchant 112 may provide a touch or a click input on the tab 526 to search for one or more merchant terminals in a pre-defined area of location of the second merchant 112. The selection of the tab 526 may cause display of another UI displaying the one or more merchant terminals in proximity of the second merchant. An example UI provisioned to the second merchant 112 is shown in FIG. 5B.
[00120] Referring now to FIG. 5B, an example representation of a UI 530 displayed to the second merchant on a display screen of the merchant device 114 by an application interface 500 depicting one or more merchant terminals in a pre-defined area of the second merchant, is shown in accordance with an example embodiment of the present disclosure. The UI 530 may be presented to the second merchant 112 in response to the selection of the tab 526 shown in FIG. 5A.
[00121] The UI 530 is depicted to include a header portion and a content portion. The header portion is depicted to exemplarily display a title associated with text indicating name of the second merchant as ‘MERCHANT X’ and an option 544 associated with text ‘Tap to select a merchant’.
[00122] The content portion displays a map 532 depicting location of the second merchant 112 as a location icon 536 and a pre-defined area shown by a geo-fence 534. The geo-fence 534 may be configured by the second merchant or may be pre-defined in form of default setting on the application interface 500. The map 532 also displays the first merchants associated with merchant terminals and accepting payment or initiating refunds on behalf of the second merchant 112 as location icons 538, 540, 542 within the geo-fence 532 depicting the pre-defined area. For example, first merchants associated with merchant terminals are shown in the map, such as text indicating ‘MERCHANT 1’ depicted to be associated with the location icon 538, text indicating ‘MERCHANT 2’ depicted to be associated with the location icon 540 and text indicating ‘MERCHANT 3’ depicted to be associated with the location icon 542. The merchant 112 may have an option to expand the pre-defined area in the application interface 500.
[00123] The second merchant 112 may provide a touch or a click input on any of the locations icons 538, 540, 542 to select a merchant terminal for processing payment/refund for the second merchant 112. The selection of any of the location icons 538, 540, 542 may cause display of another UI displaying the location, such as, address of the merchant terminal. An example UI provisioned to the second merchant 112 when the second merchant provides the click input on the location icon 540 is shown in FIG. 5C.
[00124] Referring now to FIG. 5C, an example representation of a UI 550 displayed to the second merchant on a display screen of the merchant device 114 by an application interface 500 providing location information of a merchant terminal selected by the second merchant 112, is shown in accordance with an example embodiment of the present disclosure. The UI 550 may be presented to the second merchant 112 in response to the click input received on the location icon 540 shown in FIG. 5B.
[00125] The UI 550 is depicted to include a header portion 552 and a content portion 554. The header portion 552 is depicted to exemplarily display a title associated with text indicating name of the second merchant 112 as ‘MERCHANT X’. As seen from FIG. 5C, the content portion 554 depicts text 556 corresponding to the location of the merchant terminal associated with text ‘MERCHANT 2’ as below:
“MERCHANT 2
ADDRESS : 555, 2ND CROSS,
1st MAIN STREET,
CITY-01”
[00126] The text 556 providing location information of the merchant terminal accepting payment for the second merchant 112 is shared with the customer 118 to process payment or initiate refund.
[00127] FIG. 5D is an example representation of a UI 560 displayed to the second merchant on a display screen of the merchant device 114 by an application interface 500 displaying a machine-readable encrypted code 562, in accordance with an example embodiment of the present disclosure. The UI 560 may be presented to the second merchant 112 in response to the click input received on the tab 524 shown in FIG. 5A.
[00128] As already explained upon providing the merchant information of the second merchant 112 on the application interface 500 (see, FIG. 5A), a machine-readable encrypted code 562 is generated by the payment server 128. The machine-readable encrypted code 562 comprises the merchant information of the second merchant 112. The machine-readable encrypted code 562 generated by the payment server 128 is displayed on the application interface of the merchant device 114. The machine-readable encrypted code 562 displayed at the application interface 500 is a QR code, as an example. In some examples, the machine-readable encrypted code 562 may be a blockchain hash or a hash. The machine-readable encrypted code 562 is provided to the customer 118 to initiate payment/refund at the merchant terminal 110 of the second merchant 112. The machine-readable encrypted code can be printed or shared digitally with the customers. The merchant terminal 110 may be equipped with suitable reading modules such as, scanners to decrypt the merchant information of the second merchant from the machine-readable encrypted code displayed at the merchant terminal 110 of the first merchant 104.
[00129] The UI 560 is further configured to depict a tab 564 associated with text ‘SHARE’. The second merchant 112 may provide a touch or a click input on the tab 564 to share the machine-readable encrypted code with one or more user devices associated with customers, for example the customer 118 purchasing goods from the second merchant 112. The selection of the tab 564 may cause digital sharing of the machine-readable encrypted code via messaging tools with the customer 118.
[00130] In an embodiment, the merchant terminal 110 is caused to display one or more user interfaces (UIs) for receiving user input related to (1) managing one or more second merchants, (2) initiating payments to the one or more second merchants, and (3) initiating refund for the one or more second merchants on the merchant terminal 110. Example UIs displayed on the merchant terminal 110 for provisioning the user inputs for managing payments or initiating refunds for the second merchant 112 are shown in FIGS. 6A and 6B.
[00131] FIG. 6A is an example representation of a UI 610 displayed on a display screen of the merchant terminal 110 for managing payments/refunds of one or more second merchants, in accordance with an example embodiment of the present disclosure. The UI 610 may be presented to an agent, such as, the agent 106 in response to a click input received on a tab (not shown in FIG. 6A) for managing one or more merchants associated with the merchant terminal 110.
[00132] The UI 610 is depicted to display a header portion 612 and a content portion 614. The header portion 612 is depicted to include a title associated with text ‘OPTIONS’.
[00133] The content portion 614 of the UI 610 depicts a plurality of options, such as option 616, 618, 620 and 622 related to managing the one or more second merchants availing access of the merchant terminal 110 for processing payment to a second merchant (shown as ‘PAY DIFFERENT MERCHANT’), processing refund from a second merchant (shown as ‘REFUND REQUEST’), adding new second merchants (shown as ‘ADD NEW MERCHANT’) and manage accounts of the one or more second merchants (shown as ‘MANAGE MERCHANTS’) respectively. It is noted that the options 616 – 622 are shown herein for illustration purpose and that the UI 610 may include more of fewer options than those depicted in the content portion 614.
[00134] The option 616 enables the merchant terminal 110 to perform a payment for a different merchant (e.g., the second merchant 112) by modifying a merchant identifier flag such that the payment server 128 identifies that the payment is for an acquirer associated with the second merchant 112. The agent 106 may provide a touch or a click input on the option 616 to place a payment transaction request to a different merchant, for example, the second merchant 112. The selection of the option 616 may cause display of another UI provisioning options for providing the merchant information of the second merchant 112. An example UI provisioned on the merchant terminal 110 when the agent 106 provides the click input on the option 616 is shown in FIG. 6B.
[00135] The option 618 enables the merchant terminal 110 to perform a refund for a different merchant (e.g., the second merchant 112) by modifying a merchant identifier flag such that the payment server 128 identifies that the refund is for an acquirer associated with the second merchant 112. The agent 106 may provide a touch or a click input on the option 618 to place a refund request to a different merchant, for example, the second merchant 112. The selection of the option 618 may cause display of another UI provisioning options for providing the merchant information of the second merchant 112. An example UI provisioned on the merchant terminal 110 when the agent 106 provides the click input on the option 618 is shown in FIG. 7A.
[00136] The option 620 enables the agent 106 operating the merchant terminal 110 to add new merchants (second merchants) to the merchant terminal 110. When a second merchant (e.g., the second merchant 112) places a registration request to either the merchant terminal 110 or an acquirer associated with the merchant terminal 110, the registration request is validated and the second merchant 112 and the agent 106 manually adds merchant information of the second merchant in the merchant terminal 110 by accessing the option 620. The option 620 upon selection may provide multiple fields to enable the agent 106 provide the merchant information of the second merchant 112 for completing the registration and accepting terms and conditions of the registration.
[00137] The option 622 enables the agent 106 to manage the one or more second merchants utilizing the facilities of the merchant terminal 110. The option 622 upon selection may provide multiple options to enable the agent 106 modify/change the merchant information, delete/remove second merchants and optionally clear the cache memory of the merchant terminal 110.
[00138] FIG. 6B is an example representation of a UI 630 displayed on the merchant terminal 110 for processing payment to a second merchant (e.g., the second merchant 112), in accordance with an example embodiment of the present disclosure. The UI 630 may be presented on the merchant terminal 110 in response to the click input/touch received on the option 616 shown in FIG. 6A.
[00139] The UI 630 is depicted to display a header portion 632 and a content portion 634. The header portion 632 is depicted to include a title associated with text ‘PAYMENT’.
[00140] The content portion 634 of the UI 630 is depicted to display fields such as name of the second merchant (shown as ‘SELECT MERCHANT’) and an identifier of the second merchant (shown as ‘MERCHANT IDENTIFIER’). Each field from among the fields is depicted to be associated with a text box. For example, the field ‘SELECT MERCHANT’ is associated with a text box 636 and the field ‘MERCHANT IDENTIFIER’ is depicted to be associated with a text box 638. It shall be noted that field for acquiring name of the second merchant 112 may be a drop down menu displaying a list of second merchants and an associated merchant identifier. The agent 106 can select a second merchant from the list of second merchants by providing a click input on a corresponding second merchant (e.g., the second merchant 112) based on the customer communicating payment for the second merchant 112. The content portion 634 is depicted to include a tab 640. The agent 106 may provide a touch or a click input on the tab 640 to scan a machine-readable encrypted code such as, the QR code provided to the customer 118 for performing the payment. The machine-readable encrypted code may be generated by the payment server 128 and provided on the merchant device 114 via the application interface (see, 562 of FIG. 5D). It shall be noted that providing input on any one of the fields 636, 638 or click input on the tab 640 would suffice to retrieve the merchant information of the second merchant 112.
[00141] The content portion 634 of the UI 630 also includes a field for providing a transaction amount payable to the second merchant (shown as ‘TRANSACTION AMOUNT’) associated with a text box 642. The payment amount for goods purchased at the second merchant 112 may be provided in the text box 642 for initiating the payment transaction request to either an acquirer server associated with the merchant terminal 110 of the first merchant 104 or the acquirer server of the second merchant 112.
[00142] The content portion 634 of the UI 630 is further configured to depict a tab 644 associated with text ‘PAY’ and a tab 646 associated with text ‘CANCEL’. The agent 106 may provide a touch or a click input on the tab 644 to initiate the payment transaction request. The selection of the tab 644 may cause display of another UI displaying payment gateway for authenticating payment card of the customer 118. The agent 106 may cancel the current payment upon providing a click input/touch on the tab 646. It is noted that the fields are shown herein for illustration purpose and that the UI 630 may include more of fewer fields than those depicted in the content portion 634.
[00143] FIG. 7A is an example representation of a UI 710 displayed on the merchant terminal 110 for processing refund from a second merchant (e.g., the second merchant 112), in accordance with an example embodiment of the present disclosure. The UI 710 may be presented on the merchant terminal 110 in response to the click input/touch received on the option 618 shown in FIG. 6A.
[00144] The UI 710 is depicted to display a header portion 712 and a content portion 714. The header portion 712 is depicted to include a title associated with text ‘REFUND’.
[00145] The content portion 714 of the UI 710 is depicted to display fields such as name of the second merchant (shown as ‘SELECT MERCHANT’) and an identifier of the transaction (shown as ‘TRANSACTION ID’). Each field from among the fields is depicted to be associated with a text box. For example, the field ‘SELECT MERCHANT’ is associated with a text box 716 and the field ‘TRANSACTION ID’ is depicted to be associated with a text box 718. It shall be noted that field (the text box 716) for acquiring name of the second merchant 112 and the text box 718 may be a drop down menu displaying a list of second merchants and an associated merchant identifier. The agent 106 can select a second merchant from the list of second merchants by providing a click input on a corresponding second merchant (e.g., the second merchant 112) based on the customer communicating refund from the second merchant 112. The transaction identifier is a string of alphabets and numbers provided for every transaction at the merchant terminal 110. The transaction identifier is used to identify the details of the payments such as, the merchant information and the payment card information of the customer 118. The refund may be initiated at the merchant terminal 110 by providing the transaction identifier in the text box 718. The content portion 714 is depicted to include a tab 720. The agent 106 may provide a touch or a click input on the tab 720 to scan a machine-readable encrypted code such as, the QR code provided to the customer 118 for identifying the second merchant 112 and performing the refund. It shall be noted that providing input on any one of the fields 716, 718 or click input on the tab 720 would suffice to retrieve the merchant information of the second merchant 112.
[00146] The content portion 714 of the UI 710 also includes a field for providing a refund amount payable to the customer 118 (shown as ‘REFUND AMOUNT’) associated with a text box 722. The refund amount for goods returned to the second merchant 112 may be provided in the text box 722 for initiating the refund request to either an acquirer server associated with the merchant terminal 110 of the first merchant 104 or the acquirer server of the second merchant 112.
[00147] The content portion 714 of the UI 710 is further configured to depict a tab 724 associated with text ‘SEND APPROVAL REQUEST’. The agent 106 may provide a touch or a click input on the tab 724 to send an approval request (see, 732 shown in FIG. 7B) to the merchant device 114 of the second merchant 112 via the application interface 500. An example UI provisioned on the merchant device 114 when the agent 106 provides the click input on the tab 724 is shown in FIG. 7B.
[00148] The content portion 714 is further configured to depict a tab 726 associated with text ‘INITIATE REFUND’. It shall be noted that the tab 726 is enabled only upon receiving a successful approval of the refund request from the merchant device 114 of the second merchant 112. The agent 106 may provide a touch or a click input on the tab 726 to initiate the refund request. It is noted that the fields are shown herein for illustration purpose and that the UI 710 may include more of fewer fields than those depicted in the content portion 714.
[00149] FIG. 7B is an example representation of a UI 730 displayed to the second merchant on a display screen of the merchant device 114 by an application interface 500 displaying a refund approval request, in accordance with an example embodiment of the present disclosure. The UI 730 may be presented to the second merchant 112 in response to the click input provided by the agent 106 on tab received on the tab 724 shown in FIG. 7A.
[00150] The UI 730 displays a notification 732 for the refund approval request initiated by the customer 118 at the merchant terminal 110. The notification 732 is depicted to include a text snippet 734 associated with text ‘REFUND FOR $ 100 INITIATED FOR TRANSACTION NUMBER LU62245 AT POS MERCHANT 1’. The notification 732 further includes two tabs 736 and 738 associated with text ‘APPROVE’ and ‘DECLINE’, respectively. The second merchant 112 may provide a selection of the tab 736 to approve the refund and initiate the refund request. Alternatively, the second merchant 112 may provide a selection of the tab 738 to decline the refund initiated at the merchant terminal 110.
[00151] Referring now to FIG. 8, a flow diagram depicting a method 800 for payment at a merchant terminal of a first merchant for the second merchant is illustrated in accordance with an example embodiment. The method 800 depicted in the flow diagram may be executed by a server system, for example, the payment server 128. Operations of the flow diagram 800, 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 operations of the method 800 are described herein with help of the payment server 128. It is noted that the operations of the method 800 can be described and/or practiced by using a system other than the payment server 128, such as the first acquirer server 122 or the second acquirer server 124. The method 800 starts at operation 802.
[00152] At operation 802, the method 800 includes receiving, by a server system associated with a payment network, a payment transaction request from the merchant terminal of the first merchant. The payment transaction request comprises a merchant information of the second merchant, a payment card information of a payment card of a customer and a transaction amount to be paid to an acquirer account of the second merchant from an issuer account associated with the payment card. The merchant information includes details of merchant account at an acquirer (e.g., the second acquirer server 124) of the second merchant 112. In an embodiment, the payment transaction request is sent from the merchant terminal 110 to an acquirer server (e.g., the first acquirer server 122) associated with the merchant terminal 110 along with a merchant identifier flag. The merchant identifier flag is used to identify if the payment transaction is for the first merchant or the second merchant. The merchant identifier flag also includes the merchant information of the second merchant if the payment transaction is for the second merchant. In another embodiment, the merchant terminal 110 sends the payment transaction request to an acquirer server (e.g., the second acquirer server 124) upon reading the merchant identifier flag and identifying that the payment transaction request is for the second merchant associated with the second acquirer server 124. The payment transaction request is received at a payment server (e.g., the payment server 128) from at least one of the first acquirer server 122 or the second acquirer server 124. Further, the payment transaction request is received at an issuer server (such as, the issuer server 126) from the payment server 128. The transmission of the payment transaction request is facilitated between the servers through a payment network (such as the payment network 130).
[00153] At operation 804, the method 800 includes processing, by the server system, the payment of the transaction amount from the issuer account to the acquirer account of the second merchant upon successful verification of the payment transaction request. The payment transaction request is validated by the second acquirer server 124 and sent to the issuer server (e.g., the issuer server 126) associated with an issuer account of the customer 118. The issuer server 126 authorizes the payment transaction request by verifying the issuer account of the customer 118, approves the payment transaction request, and processes the payment from the issuer account to the acquirer account of the second merchant via the payment server 128.
[00154] At operation 806, the method 800 includes sending, by the server system, a notification of the payment to a merchant device associated with the second merchant. The notification including a payment approval or decline is shared with second merchant via the merchant device.
[00155] The sequence of operations of the method 800 need 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.
[00156] Referring now to FIG. 9, a flow diagram depicting a method 900 for payment at a merchant terminal of a first merchant for a second merchant is illustrated in accordance with another example embodiment. The method 900 depicted in the flow diagram may be executed by, for example, the merchant terminal or the POS terminal 110. Operations of the flow diagram 900, and combinations of operation in the flow diagram 900, 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 operations of the method 900 are described herein with help of the merchant terminal 110. It is noted that the operations of the method 900 can be described and/or practiced by using a system other than the merchant terminal 110, such as the merchant interface device 108. The method 900 starts at operation 902.
[00157] At operation 902, the method 900 includes accessing, by the merchant terminal, an identifier of a second merchant. The identifier provides merchant information, such as, name, merchant account number, acquirer associated with the second merchant that may be used to perform refund/payment from an issuer account of a customer to a merchant account of the second merchant. In an embodiment, the identifier is a unique reference code, such as, a QR code that is machine readable and encrypts the merchant information of the second merchant. The merchant terminal may be equipped with suitable scanners to read the machine-readable unique reference code and identify the merchant information. In another embodiment, the second merchant may register with the merchant terminal associated with a first merchant and the identifier comprising the merchant information may be accessed from a memory of the merchant terminal. For example, the second merchant may request an acquirer associated with the merchant terminal to provide a platform for the second merchant such that the merchant terminal can accept payments/initiate refunds on behalf of the second merchant. In such cases, the identifier of the second merchant is stored in the merchant terminal and is accessed whenever a customer places a payment transaction request/refund request for the second merchant. In some example embodiments, the identifier of the second merchant is stored in a cache memory of the merchant terminal by a payment server (e.g., the payment server 128). The second merchant associated with an application interface installed on a merchant device may place a search request to identify a nearby merchant terminal where a customer can pay for the goods purchased from the second merchant. The payment server receives the search request comprising the merchant information and location of the second merchant and identifies at least one merchant terminal in a pre-defined area of the location of the second merchant. Upon identifying at least one merchant terminal in proximity of the second merchant, the payment server stores the merchant information in the cache memory of the at least one merchant terminal. The merchant information in the cache memory is an identifier that is accessed by the merchant terminal for initiating the payment transaction request for the second merchant.
[00158] At operation 904, the method 900 includes sending, by the merchant terminal, a payment transaction request to a server system associated with a payment network. The payment transaction request comprises a merchant information comprising at least the identifier of the second merchant, a payment card information of a customer and a transaction amount to be paid to an acquirer account of the second merchant from an issuer account based on the payment card information of the customer. In an embodiment, the payment transaction request is sent from the merchant terminal 110 to an acquirer server (e.g., the first acquirer server 122) associated with the merchant terminal 110 along with a merchant identifier flag that identifies if the payment transaction is for the first merchant or the second merchant. In another embodiment, the merchant terminal 110 sends the payment transaction request directly to an acquirer server (e.g., the second acquirer server 124) upon reading the merchant identifier flag. The payment transaction request is received at a payment server (e.g., the payment server 128) from at least one of the first acquirer server 122 or the second acquirer server 124. Further, the payment transaction request is received at an issuer server (such as, the issuer server 126) from the payment server.
[00159] At operation 906, the method 900 includes receiving, by the merchant terminal, an acknowledgement of the payment to the acquirer account from the issuer account. The acknowledgement includes a payment approval or decline message indicating a status of the payment from the issuer account of the customer to the acquirer account of the second merchant.
[00160] The sequence of operations of the method 900 need 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.
[00161] FIG. 10 is a simplified block diagram of a server system 1000 for performing payment transactions to a second merchant (e.g., the second merchant 112) using a merchant terminal (e.g., the merchant terminal 110) of a first merchant (e.g., the first merchant 104), in accordance with an embodiment of the present disclosure. Examples of the server system 1000 include, but not limited to, the first acquirer server 122, the second acquirer server 124, the payment server 128 and the issuer server 126 illustrated in FIG. 1. The server system 1000 includes a computer system 1005 and a database 1010.
[00162] The computer system 1005 includes at least one processor 1015 for executing instructions. Instructions may be stored in, for example, but not limited to, a memory 1020. The processor 1015 may include one or more processing units (e.g., in a multi-core configuration).
[00163] The processor 1015 is operatively coupled to a communication interface 1025 such that the computer system 1005 is capable of communicating with a remote device such as a merchant terminal 1035 (e.g., the merchant terminal 110), a merchant device 1040 (e.g., the merchant device 114) or communicates with any entity within the payment network 130. For example, the communication interface 1025 may receive a search request from the merchant device 1040 for identifying a merchant terminal (e.g., the merchant terminal 1035) for initiating a payment transaction request or a refund request at the merchant terminal 1035.
[00164] The processor 1015 may also be operatively coupled to the database 1010. The database 1010 is any computer-operated hardware suitable for storing and/or retrieving data, such as, but not limited to, transaction data generated as part of sales activities conducted over the bankcard network including data relating to merchants, account holders or customers, and purchases. The database 1010 may also store information related to a plurality of user's issuer accounts. Each user account data includes at least one of a cardholder name, a cardholder address, an account number, MPIN, and other account identifier. The database 1010 may also store information of a plurality of merchants, plurality of merchant terminals installed at merchant facilities, such as merchant terminal ID, location of merchant terminals etc. The database 1010 may also include instructions for settling transactions including merchant bank account information. The database 1010 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 1010 may include a storage area network (SAN) and/or a network attached storage (NAS) system.
[00165] In some embodiments, the database 1010 is integrated within the computer system 1005. For example, the computer system 1005 may include one or more hard disk drives as the database 1010. In other embodiments, the database 1010 is external to the computer system 1005 and may be accessed by the computer system 1005 using a storage interface 1030. The storage interface 1030 is any component capable of providing the processor 1015 with access to the database 1010. The storage interface 1030 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 1015 with access to the database 1010.
[00166] The processor 1015 is configured to process a payment transaction from an issuer account of a customer (e.g., the customer 118) to an acquirer account (merchant account). The processor 1015 is configured to perform one or more of the functions such as: validate credentials of the second merchant requesting registration, identify one or more merchant terminals (such as, the merchant terminal 1035) in a pre-defined area upon receiving a search request from the merchant device 1040, authenticate a customer (e.g., the customer 118), verify payment card details and cause generation of the machine-readable code, among others. The processor 1015 is further configured to facilitate the authentication of the customer 118 by verifying the payment card number, PIN/OTP or QR code, validity of the payment card by accessing respective information from the database 1010. Thereafter, the processor 1015 is configured to process the payment transaction of the transaction amount from the issuer account of the customer 118 to the acquirer account of the second merchant 112. The processor 1015 may also be configured to notify the merchant terminal 1035 and/or the merchant device 1040 of the transaction status via the communication interface 1025.
[00167] FIG. 11 is a simplified block diagram of a merchant terminal 1100 of a first merchant (e.g., the first merchant 104) used for payment transactions to a second merchant (e.g., the second merchant 112), in accordance with an embodiment of the present disclosure. The term merchant terminal 1100 (also referred to as ‘POS terminal 1100’) 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 1100 is referred to the POS machine which is used to swipe payment cards.
[00168] The POS terminal 1100 includes at least one processor 1105 communicably coupled to a memory 1110, a card reader module 1115, a communication interface 1120, and a printer 1140. The components of the POS terminal 1100 provided herein may not be exhaustive, and that the POS terminal 1100 may include more or fewer components than that of depicted in FIG. 11. 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 1100 may be configured using hardware elements, software elements, firmware elements and/or a combination thereof.
[00169] The card reader module 1115 runs scripts such as or similar to EMV scripts (GET scripts) that allow reading of information from a chip of a payment card. The card reader module 1115 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 1100 that each of which may be configured to read information stored in different types of storages, such as chips and magnetic stripes.
[00170] The I/O interface 1125 is configured to receive inputs from an end-user and provide outputs to the end-user (i.e. the agent 106 and/or the customer 118) of the POS terminal 1100. For instance, the I/O interface 1125 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 may be used to provide transaction amount, a PIN, a reference code, merchant selection from a list of merchants and merchant identifier (MID). 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 be used to display a list of second merchants and the customer 118 (or the agent 106) may provide a selection input on at least one second merchant via the input interface. Further, the output interface may also display a merchant information of the second merchant, a transaction amount and optionally an acknowledgement of a payment to an acquirer account from an issuer account.
[00171] The printer 1140 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.
[00172] The memory 1110 can be any type of storage accessible to the processor 1105. For example, the memory 1110 may include volatile or non-volatile memories, or a combination thereof. In some non-limiting examples, the memory 1110 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.
[00173] For instance, the volatile memories include a cache for storing the merchant information of the second merchant 112 so as to process payment transactions to the acquirer account (the merchant account) of the second merchant 112. The merchant information of the second merchant 112 is automatically deleted by the processor 1105 upon completion of payment/refund. Alternatively, if the second merchant 112 is registered to use the merchant terminal 110 then the information of the second merchant 112 is stored in the memory 1110. Moreover, the memory 1110 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 processor 1105 using the communication interface 1120 to determine potential future failures and the like.
[00174] The POS terminal 1100 is capable of communicating with one or more POS peripheral devices such as a merchant interface terminal 1135 and an external server system 1130 such as an acquirer server (e.g., the first acquirer server 122 and/or the second acquirer server 124 of FIG. 1) via the communication interface 1120 over a communication network (not shown). The merchant interface terminal 1135 can provide functionality which is used by a consumer (e.g., the customer 118) at a merchant facility (e.g., the first merchant 104), such as unique reference code (e.g., QR code) entry, merchant identifier entry, selection of the second merchant 112 from a list of second merchants, PIN entry, clear text entry, signature capture, and the like. The POS terminal 1100 includes a scanner 1145 configured to read a machine-readable encrypted code such as the unique reference code generated by the merchant device 114. The scanner 1145 may be a barcode scanner or a QR code scanner. The merchant interface terminal 1135 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 terminal 1135 may be mounted near a cash register at a check-out counter at a merchant facility, while the POS terminal 1100 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.
[00175] The communication interface 1120 is further configured to cause display of one or more user interfaces on the POS terminal 1100 for receiving user input from an agent (e.g., the agent 106) operating the POS terminal 1100 so as to process payment/refund to a different merchant (e.g., the second merchant 112). In one embodiment, the communication interface 1120 includes a transceiver for wirelessly communicating information (transaction amount, merchant identifier, etc.) to, or receiving information from, the external server system 1130 or other suitable display device, and/or another type of remote processing device. In another embodiment, the communication interface 1120 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.
[00176] The processor 1105 is capable of sending the payment transaction request or the refund request received from the end-user via the communication interface 1120 to the external server system 1130 for processing the payment transaction. For example, the processor 1105 is configured to receive the PIN, the unique reference code, the merchant information, the transaction amount, and the merchant identifier using the UIs. The processor 1105 can access the memory 1110 to retrieve the merchant information of the second merchant 112 that are required to be sent along with the payment transaction request to the external server system 1130. Further, the processor 1105 is caused to modify a merchant identifier flag so as to identify if the payment/refund is for the first merchant 104 or the second merchant 112 based on the merchant information.
[00177] Additionally, the POS terminal 1100 can include an operating system and various software applications that can provide various functionalities to the POS terminal 1100. For example, in some embodiments, the POS terminal 1100 is addressable with an Internet protocol and includes an application. In such embodiments, the processor 1105 includes software adapted to support such functionality. In some embodiments, the processor 1105 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 1100 over the payment network 130.
[00178] FIG. 12 is a simplified block diagram of an issuer server 1200 used for payment transaction with a payment card, in accordance with an embodiment of the present disclosure. The issuer server 1200 is an example of the issuer server 126 of FIG. 1, or may be embodied in the issuer server 126. The issuer server 1200 is associated with an issuer bank/issuer, in which a customer (e.g., the customer 118) may have an account, which provides a payment card. The issuer server 1200 includes a processing module 1205 operatively coupled to a storage module 1210, a verification module 1215, and a communication module 1220. The components of the issuer server 1200 provided herein may not be exhaustive and that the issuer server 1200 may include more or fewer components than that of depicted in FIG. 12. 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 issuer server 1200 may be configured using hardware elements, software elements, firmware elements and/or a combination thereof.
[00179] The storage module 1210 is configured to store machine executable instructions to be accessed by the processing module 1205. Additionally, the storage module 1210 stores information related to, contact information of the customer, bank account number, availability of funds in the account, payment card details, transaction details and/or the like. This information is retrieved by the processing module 1205 for validation during payment/refund.
[00180] The processing module 1205 is configured to communicate with one or more remote devices such as a remote device 1230 using the communication module 1220 over a network such as the payment network 130 of FIG. 1. The examples of the remote device 1230 include the merchant terminal 110, the payment server 128, the first acquirer server 122, the second acquirer server 124 and an external database (not shown) or other computing systems of issuer and the payment network 130 and the like. The communication module 1220 is capable of facilitating such operative communication with the remote devices and cloud servers using API (Application Program Interface) calls. The communication module 1220 is configured to receive payment transaction request from the merchant terminal 110 via the payment network 130. The communication module 1220 is configured to send notification of approval or decline of a transaction/refund to the merchant terminal 110 via the payment network 130. The processing module 1205 receives the transaction amount, the merchant information, the PIN and optionally the unique reference code from the remote device 1230 (i.e. the merchant terminal 110 or the payment server 128).
[00181] FIG. 13 is a simplified block diagram of an acquirer server 1300 used for processing payment transactions to a second merchant (e.g., the second merchant 112) using a merchant terminal (e.g., the merchant terminal 110) of a first merchant (e.g., the first merchant 104), in accordance with an embodiment of the present disclosure. The acquirer server 1300 is associated with an acquirer bank, which may be associated with a merchant, such as, the first merchant 104 or the second merchant 112 at whose facility the customer 118 is purchasing items. The merchant may have established an account to accept payment for purchase of items from customers. The acquirer server 1300 is an example of the first acquirer server 122 and the second acquirer server 124 of FIG. 1 or may be embodied in the first acquirer server 122 and the second acquirer server 124. Further, the acquirer server 1300 is configured to process payment/refund with the issuer server 1200 using a payment network, such as the payment network 130 of FIG. 1.
[00182] The acquirer server 1300 includes a processing module 1305 communicably coupled to a merchant database 1310 and a communication module 1315. The components of the acquirer server 1300 provided herein may not be exhaustive, and that the acquirer server 1300 may include more or fewer components than that of depicted in FIG. 13. For instance, the acquirer server 1300 may include a registration module that facilitates registration of the second merchant 112 for using the merchant terminal 110 of the first merchant 104. 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 1300 may be configured using hardware elements, software elements, firmware elements and/or a combination thereof.
[00183] The merchant database 1310 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, terminal identification numbers (TIDs) associated with merchant terminals (e.g., the POS terminal 110 or any other merchant electronic devices) used for processing transactions. The processing module 1305 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 1305 may be configured to store and update the merchant parameters in the merchant database 1310 for later retrieval. In an embodiment, the communication module 1315 is capable of facilitating operative communication with a remote device 1320, such as, the merchant terminal 110. The communication module 1315 is configured to receive the payment transaction request/refund request from the remote device 1320 (e.g., the merchant terminal 110) and optionally a merchant identifier flag for identifying if the payment transaction request/refund request is for the first merchant 104 or the second merchant 112.
[00184] FIG. 14 is a simplified block diagram of a payment server 1400 used for processing payment transactions to a second merchant (e.g., the second merchant 112) using a merchant terminal (e.g., the merchant terminal 110) of a first merchant (e.g., the first merchant 104), in accordance with an embodiment of the present disclosure. The payment server 1400 is an example of the payment server 128 of FIG. 1. The payment network 130 may be used by the payment server 1400, the issuer server 1200 and the acquirer server 1300 as a payment interchange network.. The payment server 1400 includes a processing system 1405 configured to extract programming instructions from a memory 1410 to provide various features of the present disclosure. The components of the payment server 1400 provided herein may not be exhaustive and that the payment server 1400 may include more or fewer components than that of depicted in FIG. 14. 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 1400 may be configured using hardware elements, software elements, firmware elements and/or a combination thereof.
[00185] Via a communication interface 1415, the processing system 1405 receives request from a remote device 1445 such as the acquirer server 1300, the POS terminal 1100 or a merchant device (e.g., the merchant device 114) associated with the second merchant 112. The request may be a search request to identify POS terminals within a pre-defined area of the merchant device 114, a request for payment transaction or a request for refund. The communication may be achieved through API calls, without loss of generality. The payment server 1400 includes a master database 1430 embodied in a database 1425. The master database 1430 includes transaction processing data and location data of POS terminals. The transaction processing data includes details such as Issuer ID, POS ID, country code, acquirer ID, MID, among others. The location data includes list of first merchant associated with POS terminals, POS ID of each POS terminal and location of POS terminals. Optionally, the master database 1430 may store details of one or more POS terminals determined within a pre-defined area of a merchant (e.g., the second merchant 112). The one or more POS terminals are determined by the processing system 1405 based on a search request received from the remote device 1445 such as, the merchant device equipped with an application interface. In addition, the processing system 1405 may store the merchant information of the second merchant 112 in the POS terminal (e.g., the merchant terminal 110) that is identified in the pre-determined area.
[00186] When the payment server 1400 receives a payment transaction request or a refund request from the acquirer server 1300 or the POS terminal 1100, the payment server 1400 may perform a lookup into the master database 1430 to process payment/refund to the second merchant 112. The master database 1430 stores transaction identifiers for identifying transaction details such as, transaction amount, payment card details, acquirer account information, transaction records, merchant account information, refund information and the like.
[00187] The customer details, the payment card details, the issuer account balance, etc., are validated using a validation module 1440. The validation module 1440 may include one or more pre-defined rule sets using which the processing system 1405 can process the validation. Further, the processing system 1405, upon successful validation, sends transaction amount and the merchant parameters to the acquirer server 1300 for crediting the merchant account with the transaction amount. The processing system 1405 is further configured to generate unique reference codes for second merchants (e.g., the second merchant 112) based on merchant information through a code generation module 1420 for identifying the second merchant 112 and processing payment transactions from the remote device 1445 (e.g., the POS terminal 1100). The processing system 1405 is further configured to notify the remote device 1445 of the transaction status via the communication interface 1415. In one embodiment, the processing system 1405 may provision a dedicated application interface capable of being installed on the merchant device 114. The merchant (e.g., the second merchant 112) may be enabled to view the transaction status using the application interface on the merchant device 114. The merchant may access the application interface using a web link as well, instead of having a need to install the application on the merchant device 114. Further, the merchant may access the application interface on the merchant device 114 for sending a search request to the payment server 1400 for identifying one or more merchant terminals in a pre-defined area.
[00188] FIG. 15 shows simplified block diagram of a merchant device 1500, for example, a mobile phone capable of implementing at least some embodiments of the present disclosure. The merchant device 1500 is depicted to include one or more applications 1506. The merchant device 1500 is an example of the merchant device 114.
[00189] It should be understood that the merchant device 1500 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 merchant device 1500 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. 15. As such, among other examples, the merchant device 1500 could be any of an 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.
[00190] The illustrated merchant device 1500 includes a controller or a processor 1502 (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 1504 controls the allocation and usage of the components of the merchant device 1500 and support for one or more applications programs (see, applications 1506), such as an application interface 500 for processing payment/refund to a second merchant (e.g., the second merchant 112). Additionally, the application interface may be accessed to provide merchant information of the second merchant and search for merchant terminals in a pre-defined area of the second merchant 112. In addition to the application interface, the applications 1506 may include common mobile computing applications (e.g., telephony applications, email applications, calendars, contact managers, web browsers, messaging applications such as USSD messaging or SMS messaging or SIM Tool Kit (STK) application) or any other computing application.
[00191] The illustrated merchant device 1500 includes one or more memory components, for example, a non-removable memory 1508 and/or a removable memory 1510. The non-removable memory 1508 and/or the removable memory 1510 may be collectively known as database in an embodiment. The non-removable memory 1508 can include RAM, ROM, flash memory, a hard disk, or other well-known memory storage technologies. The removable memory 1510 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 1504 and the applications 1506. The merchant device 1500 may further include a user identity module (UIM) 1512. The UIM 1512 may be a memory device having a processor built in. The UIM 1512 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 1512 typically stores information elements related to a mobile subscriber. The UIM 1512 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).
[00192] The merchant device 1500 can support one or more input devices 1520 and one or more output devices 1530. Examples of the input devices 1520 may include, but are not limited to, a touch screen / a screen 1522 (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 1524 (e.g., capable of capturing voice input), a camera module 1526 (e.g., capable of capturing still picture images and/or video images) and a physical keyboard 1528. Examples of the output devices 1530 may include, but are not limited to a speaker 1532 and a display 1534. 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 1522 and the display 1534 can be combined into a single input/output device.
[00193] A wireless modem 1540 can be coupled to one or more antennas (not shown in the FIG. 15) and can support two-way communications between the processor 1502 and external devices, as is well understood in the art. The wireless modem 1540 is shown generically and can include, for example, a cellular modem 1542 for communicating at long range with the mobile communication network, a Wi-Fi compatible modem 1544 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 1546. The wireless modem 1540 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 merchant device 1500 and a public switched telephone network (PSTN).
[00194] The merchant device 1500 can further include one or more input/output ports 1550 for establishing connection with peripheral devices including the POS terminal 1100, a power supply 1552, one or more sensors 1554 for example, an accelerometer, a gyroscope, a compass, or an infrared proximity sensor for detecting the orientation or motion of the merchant device 1500 and biometric sensors for scanning biometric identity of an authorized user, a transceiver 1556 (for wirelessly transmitting analog or digital signals) and/or a physical connector 1560, 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.
[00195] With the application (see, the applications 1506) and/or other software or hardware components, the merchant device 1500 can implement the technologies described herein. For example, the processor 1502 can cause generation of one or more UIs for receiving the merchant information of the second merchant 112, displaying a QR code corresponding to the merchant information and searching for one or more merchant terminals processing payment/refund to second merchants.
[00196] The disclosed methods with reference to FIGS. 1 to 7A-7B, or one or more operations of the flow diagram 800 or 900 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.
[00197] Although the disclosure 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 disclosure. 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).
[00198] Particularly, the server system 1000 (e.g. servers 122, 124, 126 and 128) and its various components such as the computer system 1005 and the database 1010 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.
[00199] Various embodiments of the disclosure, 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 disclosure 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 disclosure.
[00200] Although various exemplary embodiments of the disclosure 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.