The present disclosure generally relates to digital payment means for paying for goods and services purchased from the merchants and, more particularly to, a method and system for processing digital payments to merchants using automated teller machines.
BACKGROUND
[0002] Many consumers use digital means of payment to pay for goods and/or services purchased from merchants. For example, a consumer may electronically transfer funds from a consumer payment account to the merchant's payment account, thereby precluding any need to exchange cash for executing a purchase transaction. Typically, the consumer's payment account is linked with a banking card, such as a credit card or a debit card, capable of facilitating financial transactions, such as the purchase transaction. Such cards facilitating financial transactions are referred to hereinafter as payment cards. The consumer may use a payment card at a merchant outlet to initiate the electronic transfer of funds.
[0003] Many merchants are equipped with one or more point-of-sale (POS) terminals, which are capable of processing card-based payments for the goods or services purchased from the merchants. More specifically, a POS terminal may be configured to receive the payment card details as an input, such as by swiping, inserting, or contactless communication, and thereby initiate exchange of payment card and transaction amount information with a payment network to facilitate transfer of funds from the consumer's payment account to the merchant's payment account.
[0004] Some merchants, however, will not have POS terminals and, as such, cannot extend digital means of payment to their customers, thereby leading to loss of business. More specifically, the lack of an option to pay using digital means may attract

only those customers, who can make payment in cash while dissuading customers who do not have cash handy to engage in purchase transactions, thereby leading to loss of business.
[0005] In some example scenarios, some small merchants may move from one location to another to sell their wares. Such merchants also do not have access to power or network access, to offer an option to pay using digital means to their customers.
[0006] Accordingly, there is a need to enable merchants with no access to digital means of payment such as POS terminals, to provide digital means of payment to their customers.
SUMMARY
[0007] Various embodiments of the present disclosure provide methods and systems for processing digital payments to merchants using automated teller machines (ATMs).
[0008] In an embodiment, a method for processing digital payments to merchants using ATMs is disclosed. The method includes providing an option to a merchant to register a merchant payment account for receiving payments from customers by using an automated teller machine (ATM). The ATM is located in vicinity of a merchant location. The method includes registering the merchant payment account in response to a selection of the option by the merchant. The registration links the merchant payment account to the ATM. The method includes receiving an input from a customer at the ATM. The input is indicative of a customer intent to make a payment to the merchant for a purchase transaction. The method includes processing the payment to the merchant payment account in response to an input from a customer at the ATM. The payment to the merchant payment account is processed based on the input and the linking of the merchant payment account to the ATM.
[0009] In another embodiment, a server system in a payment network configured to process digital payments to merchants using automated teller machines is disclosed. The

server system includes a memory comprising stored instructions and a processor communicably coupled to memory. The processor is configured to execute the stored instructions to cause the server system to provide an option to a merchant to register a merchant payment account for receiving payments from customers by using one or more automated teller machines (ATMs). The one or more ATMs are located in vicinity of a merchant location. The server system is configured to register the merchant payment account in response to the selection of the option by the merchant. The registration links the merchant payment account to the one or more ATMs. The server system receives an input provided by a customer at a linked ATM. The input is indicative of a customer intent to make a payment to the merchant for a purchase transaction. The server system processes, in response to receiving the input, the payment to the merchant payment account based on the input and the linking of the merchant payment account to the ATM.
[0010] In an embodiment, another method for processing digital payments to merchants using ATMs is disclosed. The method includes displaying a user interface (UI) to a merchant by an automated teller machine (ATM). The UI includes an option to register a merchant payment account for receiving payments from customers by using the ATM. The method includes registering the merchant payment account, by the ATM, in response to the selection of the option by the merchant. The registration links the merchant payment account to the ATM. The method includes receiving an input from a customer by the ATM. The input is indicative of a customer intent to make a payment to the merchant for a purchase transaction. The method includes processing the payment to the merchant payment account in response to receiving the input. The payment to the merchant payment account is processed based on the input and the linking of the merchant payment account to the ATM.
BRIEF DESCRIPTION OF THE FIGURES
[0011] 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:
[0012] FIG. 1 illustrates an example representation of an environment, in which at

least some example embodiments of the present disclosure can be implemented;
[0013] FIG. 2 is a representation of a sequence flow for illustrating a registration of a merchant payment account for linking of the merchant payment account to an ATM, in accordance with an example embodiment of the present disclosure;
[0014] FIG. 3 is a representation of a sequence flow for illustrating a registration of a merchant payment account for linking of the merchant payment account to one or more ATMs, in accordance with an example embodiment of the present disclosure;
[0015] FIG. 4A shows an example UI presented to a user of an ATM upon entry of a payment card into the ATM, in accordance with an example embodiment of the present disclosure;
[0016] FIG. 4B shows an example UI displaying an option to register a merchant payment account, in accordance with an example embodiment of the present disclosure;
[0017] FIG. 4C shows an example UI of an application for illustrating a registration of a merchant payment account, in accordance with an example embodiment of the present disclosure;
[0018] FIG. 5 shows an example QR code including the information representative of the purchase transaction, in accordance with an example embodiment of the present disclosure;
[0019] FIG. 6 shows a representation of a notification provided to the merchant subsequent to the successful payment to the merchant payment account, in accordance with an example embodiment of the present disclosure;
[0020] FIG. 7 is a representation of a sequence flow for illustrating a digital payment to a merchant based on the customer input and the linking of the merchant payment account to the ATM, in accordance with an example embodiment of the present disclosure;
[0021] FIG. 8 illustrates a flow diagram of a method for processing digital payments to a merchant using an automated teller machine (ATM), in accordance with an

example embodiment of the present disclosure;
[0022] FIG. 9 is a simplified block diagram of a server system used for processing digital payments to merchants using ATMs, in accordance with an example embodiment of the present disclosure;
[0023] FIG. 10 is a simplified block diagram of an automated teller machine (ATM) used for processing digital payments to merchants, in accordance with an example embodiment of the present disclosure;
[0024] FIG. 11 is a simplified block diagram of an issuer server for processing digital payments to merchants using ATMs, in accordance with an example embodiment of the present disclosure;
[0025] FIG. 12 is a simplified block diagram of an acquirer server used for processing digital payments to merchants using ATMs, in accordance with an example embodiment of the present disclosure;
[0026] FIG. 13 is a simplified block diagram of a payment server used for processing digital payments to merchants using ATMs, in accordance with an example embodiment of the present disclosure; and
[0027] FIG. 14 shows simplified block diagram of an electronic device capable of implementing the various embodiments of the present disclosure.
[0028] 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
[0029] 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.
[0030] 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.
[0031] 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.
[0032] 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 operator such as a merchant, 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 a digital wallet or other payment application.
[0033] 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 operated to perform transactions via cash-substitutes, which may include payment cards, letters of credit, checks, financial accounts, etc. One example of a payment network includes a payment card operated by Mastercard.
[0034] 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 used to fund a financial transaction to a merchant or any such facility 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, 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 consumer's 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.
OVERVIEW
[0035] Currently, many merchants do not accept payment cards as a means of payment, as maintaining point-of-sale (POS) terminals are either unviable for their business needs or they do not have any other option but to deal in cash transactions.
[0036] Various example embodiments of the present disclosure provide a method and a system that are capable of overcoming the above drawbacks and providing additional advantages. More specifically, various embodiments as disclosed herein enable merchants, especially small merchants, to provide an option to their customers to pay for purchase transactions using digital means. More specifically, the various embodiments as disclosed herein enable the merchants to receive payments from the customers by using automated teller machines (ATMs) in the vicinity of the merchant location.
[0037] In at least one example embodiment, a merchant may request registration of a merchant payment account for receiving customer payments through one or more

automated teller machines near a merchant location. The registration of the merchant payment account may link the merchant payment account to at least one ATM in the vicinity of the merchant location. The merchant payment account may be linked to one or more ATMs near a merchant location in various ways.
[0038] In one embodiment, a merchant may download and install an application provided by a payment network operator, such as from a payment server associated with a payment network. The merchant may provide an input related to payment account information to the application. The application may be configured to interact with location services in a merchant device and identify one or more ATMs within a predefined distance from a current merchant location. The payment network server may then be configured to link the identified ATMs to the merchant payment account. The linking of the merchant payment account to the ATMs in the vicinity of the merchant location enables the merchant to receive customer payment for goods and services purchased from the merchant through the ATMs. More specifically, the ATM serves as the POS terminal enabling the merchant to receive payment through digital means.
[0039] In one embodiment, the merchant may visit a nearby ATM and use the options provided on a UI associated with the ATM to link a merchant payment account to the ATM. In one embodiment, the merchant may visit an interface (either a physical interface or an online interface) of a bank associated with the merchant's payment account and place a request to link the merchant payment account to one or more ATMs in the vicinity of the merchant location to enable the merchant to receive customer payments through the linked ATMs.
[0040] In an illustrative example, a customer may purchase a product from a merchant and wish to pay using digital means. In such a scenario, the merchant may provide payment information to the customer. The payment information may include a merchant identification information as well as an amount associated with the purchase transaction. The customer may visit the nearby ATM and choose options displayed on the UI of the ATM to select the merchant and thereafter initiate payment equivalent to the purchase transaction amount from the customer payment account to the merchant payment account.

[0041] In one embodiment, the merchant may use the application associated with the payment network server, or any such application, to generate a machine-readable code such as a Quick Response (QR) code including the information representative of the purchase transaction. In one embodiment, the information representative of the purchase transaction configuring the QR code includes merchant identification information and an amount associated with the purchase transaction. The merchant may provide the QR code to the customer using any messaging means, such as Email, Chat application, SMS, and the like. The customer may visit a linked ATM, i.e. an ATM in the vicinity of the merchant location and scan the QR code to provide the payment information {i.e. the QR code) to the ATM and thereby initiate payment equivalent to the purchase transaction amount from the customer payment account to the merchant payment account.
[0042] In at least one embodiment, subsequent to the successful payment, the ATM may generate a receipt indicative of the successful transfer of funds from the customer payment account to the merchant payment account. The customer may provide the ATM receipt to the merchant and receive the item(s) purchased from the merchant. In one embodiment, the successful transfer of funds into the merchant payment account may be intimated to the merchant using a messaging notification. The merchant may then hand over the purchased item(s) to the customer.
[0043] Accordingly, the embodiments disclosed herein enable the merchants, especially small merchants or merchants such as hawkers who sell their wares at different locations, to use nearby ATMs for receiving payments from customers, who wish to pay using digital means. This enables such merchants to sell their wares to a wider pool of customers {i.e. customers who choose to pay for purchases using digital means). The processing of payments using ATMs is further explained in detail hereinafter with reference to FIGS. 1 to 14.
[0044] FIG. 1 illustrates an example representation of an environment 100, in which at least some example embodiments of the present disclosure can be implemented. In the illustrated embodiment, a facility 105 is shown. Examples of the facility 105 may include any retail shop, supermarket or establishment, a government and/or private agency, a ticket counter, or any such place or establishment where consumers perform financial transactions in exchange of any goods and/or services or any transaction that requires

financial transaction between the consumer and the facility 105.
[0045] As can be seen from the environment 100, a customer 115 is standing near a payment desk 120 to make a financial transaction to a merchant 110 for a product purchased by the customer 115 from the facility 105. The facility 105 also includes a merchant interface 125. Examples of the merchant interface 125 include a point of sale device or a point of sale terminal 125 (hereinafter interchangeably referred to as a 'POS terminal 125') placed on the payment desk 120 using which the payment transaction can be initiated. In various embodiments, the merchant interface 125 can be a merchant telephone, merchant computer system, and the like.
[0046] Alternatively, or additionally, the merchant interface 125 can also be an online merchant interface such as a merchant Website, a mobile or desktop application or a third-party Website or application using which the customer 115 may purchase goods or service from a remote location or with in-store presence.
[0047] As shown in the environment 100, the customer 115 is entering a personal identification number (PIN) using the POS terminal 125. Alternatively, in the embodiment of the merchant interface being the online merchant interface, the customer 115 may enter payment card details using an electronic device, such as for example his personal computer or a mobile phone or any other electronic device while purchasing a product online from the merchant Website. Some non-exhaustive examples of payment card details entered using the electronic device include payment card number, date of expiry, Card Verification Value (CVV) details, and the like.
[0048] In a non-limiting example, authorization of the customer's bank account with sufficient funds for making a transaction of 'X' amount to complete the payment transaction is performed by a combination of an acquirer server 130, an issuer server 135 and a payment server 140. In one embodiment, the payment server 140 is associated with a payment network 145.
[0049] The issuer server 135 is associated with a financial institution normally called as an "issuer bank" or "issuing bank" or simply "issuer", in which the customer 115 may have an account, which issues a payment card, such as a credit card or a debit card.

The customer 115, being the cardholder, can use the payment card details associated with the payment card to tender payment for a purchase from the merchant 110.
[0050] To accept payment, the merchant 110 will first 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". The acquirer server 130 is associated with the acquirer bank.
[0051] Using the payment network 145, the computers of the acquirer / the acquirer server 130 or the merchant processor will communicate with the computers of the issuer / the issuer server 135 to determine whether the customer's account is in good standing and whether the purchase is covered by the customer's available account balance. Based on these determinations, authorization of the payment transaction is declined or accepted. When the authorization is accepted, the available balance of the customer's account is decreased. According to a process of one payment network operator, a charge is not posted immediately to the customer's account as a merchant will not charge, or "capture," a transaction amount until goods are shipped or services are delivered. When the merchant 110 ships or delivers the goods or services, the merchant 110 captures the transaction amount by, for example, appropriate data entry procedures on the POS terminal 125. If the customer 115 cancels a transaction before it is captured, a "void" is generated. If the customer 115 returns goods after the transaction has been captured, a "credit" is generated.
[0052] After a transaction is captured, the transaction is settled between the merchant 110, the acquirer and the issuer. Settlement refers to the transfer of financial data or funds between the merchant's account, the acquirer, and the issuer, related to the transaction. Transactions may be captured and accumulated into a "batch", which is settled as a group.
[0053] A customer device (e.g., a mobile phone or desktop computer of the customer 115), the merchant device (e.g., the POS terminal 125) associated with the merchant interface, the issuer server 135, the acquirer server 130 and the payment server 140 communicate with one another using a network 150. Examples of the network 150 may include any type of wired network, wireless network, or a combination of wired and wireless networks. A wireless network may be a wireless local area network ("WLAN"), a

wireless wide area network ("WWAN"), or any other type of wireless network now known or later developed. Additionally, the network 150 may be or include the Internet, intranets, extranets, microwave networks, satellite communications, cellular systems, personal communication services ("PCS"), infrared communications, global area networks, or other suitable networks, etc., or any combination of two or more such networks.
[0054] In some example scenarios, a merchant, such as a merchant 165, may not be equipped with means, such as the merchant interface 125 (i.e. POS terminal or the Website), to offer the option of digital payments to the customers. For example, the merchant 165 may not be able maintain a POS terminal as the POS terminal may be unviable for the merchant's business need or the merchant 165 may not have any option but to offer cash transactions.
[0055] Various embodiments of the present disclosure provide mechanisms that enables merchants who do not have merchant interfaces, such as the merchant interface 125, to offer digital means of payments to their customers. More specifically, the various embodiments as disclosed herein enable the merchants to receive payments from the customers by using automated teller machines (ATMs) in the vicinity of the merchant location. One example ATM in the vicinity of the merchant 165, i.e. in the vicinity of the business location of the merchant 165, is shown as ATM 170 for illustration purposes. In at least one example embodiment, the merchant 165 may request registration of a merchant payment account for receiving customer payments through one or more ATMs (such as the ATM 170) near the merchant location. The registration of the merchant payment account may link the merchant payment account to at least one ATM in the vicinity of the merchant location. A sequence flow illustrating linking of a merchant payment account to an ATM in vicinity of a merchant location is explained with reference to FIG. 2.
[0056] FIG. 2 is a representation of a sequence flow 200 for illustrating a registration of a merchant payment account for linking of the merchant payment account to an ATM, in accordance with an example embodiment of the present disclosure. The term 'merchant' as used hereinafter may refer to an individual, a group of individuals or any business operator offering goods and/or services for sale to potential users of the goods and/or services. Preferably, the merchant may currently be offering only a cash transaction option to the customers and wish to extend digital payment means to the customers. One

such merchant is depicted as the merchant 165 in FIG. 1. It is noted that the merchant 165 may conduct daily business at a fixed location or may prefer to sell the items at different locations at different time intervals based on business needs. Accordingly, the term 'merchant location' as used throughout the description refers to a current location of conducting business by the merchant. The sequence flow 200 starts at 202.
[0057] At 202, a merchant 165 visits an ATM in vicinity of a merchant location, such as the ATM 170 shown in FIG. 1. The term 'vicinity' as used throughout the description may imply 'within the same locality', such as within the same business complex housing the merchant business or within a walking distance (or a short driving distance up to one or two miles) from the merchant location. The merchant 165 may thereafter insert or swipe a payment card at the ATM 170.
[0058] At 204, the ATM 170 displays a UI showing an option to register a merchant payment account to the merchant 165. An example UI showing the option to register the merchant payment account is shown in FIG. 4B.
[0059] At 206, the merchant 165 provides a selection of the option to the ATM 170. In at least some embodiments, the ATM 170 may be configured to request a Personal Identification Number (PIN) from the merchant 165 subsequent to the selection of the option by the merchant 165. The merchant 165 may provide the PIN to the ATM 170 at 206.
[0060] At 208, the ATM 170 provides information related to the merchant payment account, i.e. information related to the inserted payment card, to an issuer of the payment card (i.e. a merchant's bank), for validation of the merchant payment account information. More specifically, information such as the payment card details (for example, the card number, account holder name, etc.) and the PIN may be forwarded by the ATM 170 to the payment card issuing bank (i.e. the issuer) for account validation. It is noted that a bank associated with the ATM 170 may forward the information related to the payment card account and the PIN to a server associated with the payment card issuing bank (i.e. the issuer server 135) over the payment network 145 or over the network 150 shown in FIG. 1.
[0061] At 210, the issuer server 135 transmits the status of the validation to the

ATM 170. It is noted that though the intimation of the status of account validation is depicted to be provided by the issuer server 135 to the ATM 170, the status may be intimated to the bank associated with the ATM 170, which may then forward the status to the ATM 170.
[0062] At 212, the ATM 170 displays the status of the validation to the merchant 165. In an exemplary scenario, the account validation may be successful, or in other words, the merchant payment account and the PIN may match the stored values at the issuer server 135, thereby validating the account. Further, at 212, the ATM 170 displays a UI requesting the merchant 165 to select a username (which may serve as a merchant identifier) and, optionally, a password to complete the registration process. In some embodiments, the PIN associated with the merchant's payment card may also serve as the password.
[0063] At 214, the merchant 165 provides the username (and optionally a password) information to the ATM 170. Subsequent to the confirmation of the username (and the password), at 216, the merchant payment account may be stored and registered for receiving customer payments using the ATM 170. The registration of the merchant payment account links the merchant payment account with the ATM 170. More specifically, the username of the merchant 165 may thereafter be displayed in a list of linked merchants (or linked merchant payment accounts) on a UI of the ATM 170 to customers wishing to make a payment to the merchant 165 for a purchase transaction.
[0064] The usernames of the merchants may provide an ease of merchant selection to the customers for processing payment to the merchants, as will be explained in further detail later. Further, the username and the password may enable a merchant to link a respective merchant payment account to multiple other ATMs associated with the bank of the ATM 170 and this, in turn may enable the merchant 165 to provide multiple options of ATMs to the customers to choose from, for making the payment and completing the purchase transaction. The linking of the merchant payment account to the ATM(s) enables the merchant to extend digital payment means to a larger pool of customers and not limit the sale of the goods and services to only those customers who are able to pay in cash for the purchase transactions.

[0065] It is noted that though the registration of the merchant payment account as explained with reference to FIG. 2 involves a physical visit by the merchant 165 to the ATM 170, in some embodiments, the merchant 165 may visit an interface of the bank associated with the merchant payment account to register the merchant payment account. For example, the merchant 165 may visit a physical interface at a bank location or an online interface of the merchant bank to register the merchant payment account. It is understood that the physical interface of the bank may include a banking representative who may provide a physical form including the option to the merchant to register the merchant payment account. The merchant 165 may also be requested to provide documents (such as for example, a driving license, a passport or a national identity card) to authenticate a personal identity for the registration process. Subsequent to the successful authentication, an online request to the bank associated with the ATM 170 may be placed by the banking representative to request linking of the merchant payment account to the ATM 170. If the merchant chooses to visit the online interface of the merchant bank then the steps similar to the sequence flow 200 may be followed to complete the registration process.
[0066] The registration of the merchant payment account as explained in FIG. 2 involves a physical visit to the ATM/ merchant bank or the use of an online interface of the merchant bank, however, in some embodiments, the merchant payment account may be registered using an application as will be explained with reference to a sequence flow in FIG. 3.
[0067] FIG. 3 is a representation of a sequence flow 300 for illustrating a registration of a merchant payment account for linking of the merchant payment account to one or more ATMs, in accordance with an example embodiment of the present disclosure. The registration of the merchant payment account, as will be explained with reference to FIG. 3, involves the use of an application provided by a server system 160 associated with a payment network. The terms 'server system', or 'server' or 'system' are used interchangeably hereinafter. In at least one example embodiment, the term 'server system 160' as used herein corresponds to the payment server 140 associated with the payment network 145 shown in FIG. 1. In some embodiments, the server system may correspond to the issuer server 135 or the acquirer server 130 shown in FIG. 1. In some example

scenarios, the issuer server 135, the acquirer server 130 and the payment server 140 can be a single server, or any two of these servers may be a single server, configuring the server system 160. The sequence flow 300 starts at 302.
[0068] At 302, the merchant 165 using an electronic device accesses an application provided by the server system 160. In one embodiment, the server system 160 may be configured to provide an instance of an application for download and subsequent installation on the merchant device. The installed application may be capable of being in operative communication with the server system 160 to enable registration of the merchant payment account. In one embodiment, the server system 160 may provide the application as a Web service accessible over a communication network, such as the Internet. For example, the application may be Web-based application.
[0069] At 304, the application displays a user interface (UI) upon merchant access. The UI provides an option to the merchant to register a merchant payment account for receiving payments from customers for items purchased from the merchant.
[0070] At 306, the merchant provides a selection of the option to register merchant payment account.
[0071] At 308, the application determines a current location of the merchant 165 and also identifies one or more ATMs within a predefined distance (for example, one or two-mile radius). To that effect, the application may be in operable communication with location services available within the merchant device. The application may be configured to communicate with the location services (for example, using Application Programming Interface (API) calls) to determine the current location of the merchant 165. In some embodiments, the application may provide an option to input a merchant location to the merchant 165 and thereafter identify one or more ATMs in the vicinity of the merchant location.
[0072] At 310, subsequent to the identification of the one or more ATMs in the vicinity of the merchant location, the application displays a UI including a plurality of form fields requesting the merchant 165 to provide information related to the merchant payment account.

[0073] A 312, the merchant 165 provides an input including information related to the merchant payment account to the application. The information related to the merchant payment account may include payment card details (for example, the card number, account holder name, etc.). In some embodiments, the merchant 165 may also provide information related to the registered phone number or registered Email address as part of the information related to the merchant payment account.
[0074] At 314, the server system 160 provides information related to the merchant payment account, i.e. information related to the banking account associated with the payment card, to a payment card issuer {i.e. the issuer), for validation of the merchant payment account information. More specifically, the server system 160 may provide the information to a server associated with the payment card issuer {i.e. the issuer server 135) over an inter-banking network or over a payment network, such as the payment network 145 shown in FIG. 1.
[0075] At 316, the issuer server 135 validates the merchant payment account information and, at 318, the issuer server 135 performs merchant authentication using any 3D secure (3DS) authentication means, such as a One-Time Password (OTP) for instance. At 320, the issuer server 135 intimates the status of the account validation to the server system 160.
[0076] At 322 the application provided by the server system 160 is configured to the display the status of the account validation to the merchant 165. In an exemplary scenario, the merchant authentication may be successful, or in other words, the OTP entry may match the OTP value at the issuer server 135, thereby authenticating the merchant 165. In at least some embodiments, at 322, the application may cause display of a UI requesting the merchant 165 to select a username (which may serve as a merchant identifier) and, optionally, a password to complete the registration purchase. In some embodiments, the PIN associated with the merchant's payment card may also serve as the password.
[0077] At 324, the merchant 165 may provide the username and optionally a password information to the application. Subsequent to the confirmation of the username and the password, at 326, the server system 160 may communicate with the banks

associated with the respective ATMs identified in the vicinity of the merchant location to link the merchant payment account to the ATMs. More specifically, the username of the merchant 165 may thereafter be displayed in a list of linked merchants (or linked merchant payment accounts) on UIs of the respective ATMs to customers wishing to make a payment to the merchants for a purchase transaction.
[0078] As explained with reference to FIGS. 2 and 3, a merchant such as the merchant 165 is provided with an option to register a merchant payment account so as to link the merchant payment account with at least one ATM in the vicinity of the merchant location. An example option provided to a merchant for registering a merchant payment account is explained with reference to FIGS. 4A, 4B and 4C.
[0079] FIG. 4A shows an example UI 400 presented to a user of an ATM upon entry of a payment card into the ATM, in accordance with an example embodiment of the present disclosure. In an example scenario, a merchant may wish to extend digital means of payment to the customers. To this effect, the merchant may visit an ATM in the vicinity of the merchant location to register a merchant payment account for receiving payments from the customers by using the ATM. The merchant may insert or swipe a payment card (for example, a debit card or a credit card) into the ATM. The ATM may be configured to display a UI, such as the UI 400 shown in FIG. 4A.
[0080] The UI 400 is depicted to display a plurality of menu options, such as menu options 402, 404, 406, 408, 410, 412, 414 and 416 associated with text 'FAST CASH', 'CASH WITHDRAWAL', 'BALANCE INQUIRY', 'MINI STATEMENT', 'MERCHANT PAYMENT', 'PIN CHANGE', 'DEPOSIT' and 'OTHERS'. Each menu option from among the menu options 402 - 416 is associated with a button capable of being actuated by a touch or press input by the user of the ATM. A user may physically depress a button or provide a touch input on the screen of the ATM corresponding to the menu option of choice, to select an appropriate menu option. It is noted that the menu options 402 - 416 are depicted herein for illustration purposes and that the ATM may be configured to display different menu options than those depicted in FIG. 4A. Further, a number of menu options presented to the users of the ATM may also vary and that the UI 400 may display fewer or more menu options than those depicted in FIG. 4A.

[0081] In at least one example embodiment, the merchant may select the menu option 410, i.e. a menu option associated with text 'MERCHANT PAYMENT' to initiate the process for registration of the merchant account. In an embodiment, the merchant may be displayed another UI in response to the selection of the menu option 410 by the merchant. Such a UI is exemplarily depicted in FIG. 4B.
[0082] FIG. 4B shows an example UI 420 displaying an option to register a merchant payment account, in accordance with an example embodiment of the present disclosure. In the example scenario described with reference to FIG. 4A, a merchant may wish to receive payments from the customers using the ATM and accordingly may select a menu option 410 on the UI 400 shown in FIG. 4A for initiating the process of registration of the merchant payment account. The UI 420 may be displayed to the merchant subsequent to the selection of the menu option 410.
[0083] The UI 420 is depicted to include two sections, i.e. a section 422 associated with a heading 'FOR CUSTOMERS' and a section 424 associated with a heading 'FOR MERCHANTS'. Each section is exemplarily depicted to include an option. For example, the section 422 is depicted to include an option 430 associated with text 'PAY MERCHANT USING PAYMENT ACCOUNT'. The option 430 may be of interest to a customer, who wish to pay a merchant for purchased items using the payment account associated with the payment card inserted/swiped at the ATM. Accordingly, the customer may provide a selection of a button associated with the option 430 to indicate an intention to pay a merchant. The ATM may then be configured to facilitate a selection of a merchant and enter an amount corresponding to the purchase transaction. Further, the customer may be requested to enter a PIN corresponding to the payment card to authenticate the customer as the rightful payment card holder. Upon successful authentication, the ATM may be configured to facilitate payment for the purchase transaction to the merchant payment account.
[0084] The section 424 is depicted to be associated with an option 440 associated with text 'REGISTER PAYMENT ACCOUNT'. The option 440 may be of interest to merchants and is associated with a button capable of user selection. The selection of the button by the merchant is indicative of the merchant's intention to register the payment account associated with the payment card inserted/swiped at the ATM as the 'merchant

payment account' for receiving payments from the customers. In at least some embodiments, the merchant may be requested to enter a PIN to authenticate a merchant identity. The merchant may also be requested to reconfirm the merchant payment account details for linking the merchant payment account to the ATM so as to receive payments from the customers. Once confirmed, the merchant may be requested to select a username and optionally a password to complete the linking of the merchant payment account to the ATM. The selection of the username and optionally the password completes the registration process and thereafter, the merchant payment account is linked to the ATM. More specifically, the username of the merchant payment account may be displayed in a list of merchants as recipients upon selection of the option 430 by the customers. It is noted that the addition of the username to the list of merchants displayed in the ATM may take a few days depending upon the remote ATM software update cycle followed by the bank associated with the ATM.
[0085] An example registration option provided to the merchant and the
subsequent registration of the merchant involving the use of an ATM has been explained with reference to FIGS. 4A and 4B. As explained with reference to FIGS. 2 and 3, a merchant may also be provided with an application capable of facilitating registration of a merchant payment account for receiving payments from customers using ATMs in the vicinity of the merchant location. An example UI associated with such an application is shown in FIG. 4C.
[0086] FIG. 4C shows an example UI 450 of an application for illustrating a registration of a merchant payment account, in accordance with an example embodiment of the present disclosure. As explained with reference to FIG. 3, the server system 160 associated with a payment network 145 shown in FIG. 1, may be configured to provide an application to merchants to register their respective payment accounts for receiving payments from the customers using ATMs in the vicinity of the respective merchant locations.
[0087] In one embodiment, the application may be configured to display an option, embodied as a user selectable button, to the merchant to register a merchant payment account. In response to the selection of the option to register the merchant payment account, the application may determine a current location of the merchant and also identify

one or more ATMs within a predefined distance (for example, within one or two-mile radius) from the merchant location. The application may be in operable communication with location services available within the merchant device to determine the current location of the merchant. Additionally, or alternatively, the application may provide an option to input a merchant location to the merchant and thereafter identify ATMs in the vicinity of the merchant location. Subsequent to the identification of the ATMs in the vicinity of the merchant location, the application displays a UI, such as the UI 450, including a plurality of form fields requesting the user to provide information related to the merchant payment account.
[0088] The UI 450 is depicted to display a plurality of form fields, such as form fields 452, 454, 456, 458, 460, 462 and 464 for receiving input related to the merchant payment account. Each form field from among the form fields 452 - 464 is capable of receiving a merchant input (for example, a text input or a selection input). For example, the form field 452 is depicted to be associated with text 'PAYMENT CARD ACCOUNT NUMBER'. The merchant may provide a 16-digit numerical input corresponding to the number of the payment card (for example, a debit card or a credit card) in the form field 452. In one embodiment, the form field 452 may be capable of receiving input in form of 'XXXX - XXXX - XXXX - XXXX', where 'X' corresponds to a positive integer. In one embodiment, the merchant may sequentially input the digits of the payment card number and the form field 452 may be configured to align the numbers in the form, depicted above. In some embodiments, the UI 450 may also include another form field, such as the form field 452, requesting the user to reconfirm the payment card account number and the UI 450 may be configured to display an error flag if the payment card account number entered in the two form fields do not match.
[0089] The form field 454 is depicted to be associated with text 'NAME ON THE PAYMENT CARD' and the merchant may provide a string of alphabets corresponding to the name of the individual displayed on the payment card in the form field 454. The form fields 456 and 458 are depicted to be associated with text 'PAYMENT CARD EXPIRY DATE', and the merchant may provide a selection input corresponding to the month and year of the expiry of the payment card displayed on the payment card in the form fields 456 and 458, respectively.

[0090] The form field 460 is depicted to be associated with text 'CW. The form field 460 may be configured to receive a 3-digit numerical input corresponding to the Card Verification Value (CVV) of the payment card. In one embodiment, the form field 460 may be capable of receiving merchant input in form of 'XXX', where 'X' corresponds to a positive integer.
[0091] The UI 450 is further depicted to display form fields 462 and 464 which are configured to receive a phone number and an Email ID from the merchant. The merchant may provide the phone number and the Email ID information registered with the payment card issuer as input in the form fields 462 and 464.
[0092] It is noted that the information provided in the form fields 452 - 464 by the merchant configures the information related to the merchant payment account for the purposes of the description. More specifically, the merchant input in the form fields for payment card account number, name on the card, payment card expiry details, CVV, phone number and the Email ID configure the merchant payment account information.
[0093] The merchant may select the button 470 exemplarily depicted to display text 'REGISTER PAYMENT ACCOUNT' to provide confirmation of the information included in the form fields 452 - 464. Upon selection of the button 470, the UI 450 may be configured to provide the merchant payment account information to the server system 160. Such information may be transmitted over a communication network, such as the network 150 explained with reference to FIG. 1. The server system 160 is configured to communicate with card issuer (or the issuer server 135) to validate the merchant payment account information. In case, the merchant has provided a banking accounting information (for example, a savings account or a current account), then the server system 160 may provide the information related to the banking account to a merchant bank, for validation of the account information. More specifically, the server system 160 may provide the information to a server associated with the merchant bank (i.e. the issuer server 135) over an inter-banking network or over a payment network, such as the payment network 145. The issuer server 135 may perform merchant authentication using any 3D secure (3DS) authentication means, such as a One-Time Password (OTP) for instance. For example, the OTP may be sent to the registered Email address or the registered phone number to validate the merchant identity.

[0094] In scenarios, where the validation of the merchant payment account information is unsuccessful, the merchant may be asked to retry providing the information in the form fields 452 - 464. In an exemplary scenario, the validation of the merchant payment account information may be successful and the OTP entry may match the OTP value at the issuer server 135, thereby authenticating the merchant. In at least some embodiments, the application may cause display of a UI requesting the merchant to select a username (which may serve as a merchant identifier) and, optionally, a password to complete the registration process. In some embodiments, the PIN associated with the merchant's payment card may also serve as the password. The merchant may provide the username and password information to the application. Subsequent to the confirmation of the username and the password, the server system 160 may communicate with the banks associated with the respective ATMs identified in the vicinity of the merchant location to facilitate linking of the merchant payment account to the ATMs. More specifically, the username of the merchant may thereafter be displayed in a list of linked merchants (or linked merchant payment accounts) on UI of the respective ATMs to customers wishing to make a payment to a merchant for a purchase transaction.
[0095] In an illustrative example, a customer may purchase an item from a merchant and wish to pay using digital means. In such a scenario, the merchant may provide payment information to the customer. The payment information may include a merchant identification information, such as for example merchant username, as well as purchase transaction amount. The customer may visit a nearby ATM and choose an option, such as the option 430 shown in FIG. 4B, to initiate the payment to the merchant. In at least some embodiments, the ATM may be configured to display a list of merchants subsequent to the selection of the option 430. The customer may select a merchant based on the merchant username (as provided by the merchant) from the list of merchants and thereafter enter a purchase amount. The ATM may request the customer to enter a PIN for the payment card inserted /swiped in the ATM. The PIN may be validated from the payment card issuer using a payment network 145 as explained with reference to FIG. 1 and thereafter a transfer of a payment equivalent to the purchase transaction amount may be initiated from the customer payment account to the merchant payment account.
[0096] In one embodiment, the merchant may use the application associated with

the payment network server, or any such application, to generate a machine-readable code, which includes the information representative of the purchase transaction and provide the machine-readable code to the customer. An example machine-readable code, embodied as a Quick Response (QR) code, provided to the customer is shown in FIG. 5.
[0097] FIG. 5 shows an example QR code 500 including the information representative of the purchase transaction, in accordance with an example embodiment of the present disclosure. The QR code 500 may be generated by the merchant using an application, such as the application explained with reference to FIGS. 3 and 4C, installed in a merchant device 505. The merchant device 505 is exemplarily depicted to be a smart phone for illustration purposes. In one example embodiment, the application may display a UI (not shown) including at least one form field, such as a form field for receiving the purchase transaction amount, and a submit button. The selection of the submit button may cause generation of a QR code, such as the QR code 500. The QR code 500 may include payment information, such as a merchant identifier and a purchase transaction amount in an encrypted form. For example, the QR code 500 is depicted to be associated with payment information shown in a dotted box 510 including merchant identification information, such as merchant username 512 (exemplarily depicted to be 'JOHN ICE CREAM PARLOR'), a merchant ID 514 (exemplarily depicted to be 'MIC001000521') and an amount 516 (exemplarily depicted to be '$56'). The merchant may provide the QR code 500 to the customer using any messaging means, such as Email, Chat application, SMS, and the like. The customer may visit a linked ATM, i.e. an ATM in the vicinity of the merchant location and scan the QR code 500 to provide the payment information {i.e. information included within the dotted box 510) to the ATM and thereby initiate payment equivalent to the purchase transaction amount from the customer payment account to the merchant payment account. More specifically, using the information included within the QR code 500 and the linked merchant payment amount {i.e., the linking of the merchant username in the ATM to the merchant payment account), an amount equivalent to the purchase transaction amount is transferred from the customer payment account, i.e. an account linked to the customer payment card swiped/inserted in the ATM) to the merchant payment account.
[0098] In some embodiments, a QR code, such as the QR code 500 may be

generated by the customer. The customer may have installed the application provided by the server system 160 on the customer device. The customer may invoke the application and enter the merchant username, merchant ID and the transaction amount in the application to generate the QR code. The customer may scan the QR code at a nearby ATM to make the payment to the merchant. In some embodiments, the customer may generate a single QR code for multiple purchase transactions from a plurality of merchants. In an illustrative example, several merchants may be selling their goods (for example, farmers selling fresh produce in a farmer's market) at a single location. The merchants may have registered their respective payment accounts and accordingly linked their payment accounts with a nearby ATM. A customer after engaging in a purchase transaction with several merchants, may input the purchase transaction information for each purchase and generate a single QR code using the application. The customer may scan the QR code at a nearby ATM to make the payment to the respective merchants.
[0099] In at least one embodiment, subsequent to the successful processing of the payment, the ATM may generate a receipt indicative of the successful transfer of funds from the customer payment account to the merchant payment account. The customer may provide the ATM receipt to the merchant and receive the item(s) purchased from the merchant. In one embodiment, the successful transfer of funds into the merchant payment account may be intimated to the merchant using a messaging notification. The merchant may then hand over the purchased item(s) to the customer. An example notification provided to the merchant is shown in FIG. 6.
[00100] FIG. 6 shows a representation of a notification 600 provided to the merchant subsequent to successful processing of the payment, in accordance with an example embodiment of the present disclosure. As explained with reference to FIG. 5, the customer may either scan the QR code, such as the QR code 500, or manually select the merchant username and enter the purchase transaction amount in the ATM to initiate the payment for the purchased item(s) to the merchant. Subsequent to the successful processing of the payment, i.e. successful transfer of funds from a customer's payment amount to the merchant payment account, a notification may be generated indicative of the successful transfer of funds. The notification may be provided by a server system associated with a payment network 145. For example, the payment server 140 (shown in

FIG. 1) in communication with the bank associated with the ATM may provide a message to the merchant bank, which in turn may provide a notification 600 to the merchant. The notification 600 is exemplarily depicted to be associated with text 'YOUR ACCOUNT ENDING 2213 HAS RECEIVED A REMITTANCE OF $56 FROM XXXX-XXXX-XXX 5136'. On receipt of the notification 600, the merchant may be assured that the payment for the items purchased by the customer has been received and accordingly may release the purchased items to the customer.
[00101] A sequence flow illustrating customer payment at an ATM for a purchase transaction at a merchant location is explained with reference to FIG. 7.
[00102] FIG. 7 is a representation of a sequence flow 700 for illustrating a digital payment to a merchant based on the customer input and the linking of the merchant payment account to the ATM, in accordance with an example embodiment of the present disclosure. The sequence flow 700 starts at 702.
[00103] At 712, a customer 702 visits a merchant outlet and provides a selection of one or more items for purchase to a merchant 704.
[00104] At 714, the merchant 704 generates a QR code, such as the QR code 500, which includes the merchant identification information and the purchase transaction amount.
[00105] At 716, the merchant 704 provides the QR code to the customer 702. The merchant 704 may provide the QR code to the customer 702, using any messaging means, such as a chat message, an Email, an SMS, and the like.
[00106] At 718, the customer 702 visits an ATM 706 in vicinity of the merchant location and inserts/swipes a payment card to provide a customer payment account information to the ATM.
[00107] At 720, the customer 702 scans the QR code at the ATM 706 to provide a selection of the merchant 704 to pay for the purchase transaction, and an amount to pay to the merchant 704.
[00108] At 722, the ATM 706 may provide the customer payment account

information and the merchant payment account information along with the purchase transaction amount to the server system 160. In one embodiment, the server system 160 may be embodied as the payment server 140 explained with reference to FIG. 1. The payment server 140 may validate the customer payment account from the customer's bank (i.e. the issuer) and thereafter facilitate transfer of funds from the customer payment account to the merchant's bank (i.e. acquirer). Subsequent to the successful validation of the customer payment account and the transfer of funds from the customer payment account, the server system 160 (i.e. the payment server 140) may intimate the status of the transfer of funds to the ATM 706 at 724.
[00109] At 726, the ATM 706 generates a receipt indicative of the successful payment transfer and provides the receipt of the payment to the customer 702. As explained with reference to FIG. 6, in some embodiments, the server system 160 may also provide a notification to the merchant 704. Accordingly, at 728, a notification is provided to the merchant 704 by the server system 160.
[00110] At 730, the customer 702 provides the ATM receipt to the merchant 704.
[00111] At 732, the merchant 704 provides the purchased items to the customer 702 upon confirmation of the payment for the purchased items. The sequence flow 700 ends at
732.
[00112] FIG. 8 illustrates a flow diagram of a method 800 for processing digital payments to a merchant using an automated teller machine (ATM), in accordance with an example embodiment of the present disclosure. The method 800 depicted in the flow diagram may be executed by, for example, a server system such as the server system 160 explained with reference to FIG. 3. In one embodiment, the method 800 in the flow diagram may be executed by an ATM (or a bank associated with the merchant). Operations of the flow diagram 800, and combinations of operations in the flow diagram 800, 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. In at least one example embodiment, the server system 160 corresponds to a payment server associated with a payment network, such as the payment network operated by Mastercard. It is noted that the operations of the method 800 can be

described and/or practiced by using other server systems, such as the issuer server 135 or the acquirer server 130 shown in FIG. 1. The method 800 starts at operation 802.
[00113] At 802, the method 800 includes providing an option to a merchant to register a merchant payment account for receiving payments from customers by using an automated teller machine (ATM). The ATM is located in vicinity of a merchant location. In one embodiment, the merchant may visit a nearby ATM and use an option provided on a UI associated with the ATM to request registration of a merchant payment account. The option displayed on a UI of the ATM is shown as option 440 in FIG. 4B.
[00114] In another embodiment, the merchant may visit an interface (either a physical interface or an online interface) of a bank associated with the merchant's payment account and place a request to link the merchant payment account to one or more ATMs in the vicinity of the merchant business location so as to enable the merchant to receive customer payments using the ATMs.
[00115] In one embodiment, a merchant may download and install an application provided by the server system. The application may be configured to interact with location services in a merchant device and identify one or more ATMs within a predefined distance from a current merchant location. The merchant may then provide the merchant payment information and request the registration of the merchant payment account to at least one ATM in the vicinity of the merchant location. To that effect, an application UI may display an option to request registration of a merchant payment account. One such option displayed on the application UI is shown using button 470 in FIG. 4C.
[00116] At 804, the method 800 includes registering the merchant payment account in response to a selection of the option by the merchant. The registration may involve communication between the bank associated with the ATM and the merchant bank (i.e. issuer of payment card swiped/inserted by the merchant) to add the merchant username to the ATM. The registration of the merchant payment account links the merchant payment account to at least one ATM in the vicinity of the merchant location. On linking of the merchant payment account to the ATM, the merchant username may be displayed in a list of merchant recipients in the ATM. A customer may select the merchant using the displayed username to initiate the payment for the purchased items. The linking of the

merchant payment account to the ATMs enables the merchant to receive customer payment for goods and services purchased from the merchant through the ATMs. More specifically, the ATM serves as the POS terminal enabling the merchant to receive payment through digital means.
[00117] At 806, the method 800 includes receiving an input provided by a customer at the ATM. The input is indicative of a customer intent to make a payment to the merchant for a purchase transaction. In an illustrative example, a customer may purchase a product from a merchant and wish to pay using digital means. In such a scenario, the merchant may provide payment information to the customer. The payment information may include a merchant identification information as well as purchase transaction amount. The customer may visit the nearby ATM and choose an option displayed on the UI of the ATM to select the merchant and thereafter initiate payment equivalent to the purchase transaction amount from the customer payment account to the merchant payment account. Such selection of the option and thereafter initiation of the payment (for example, by scanning the machine-readable code including the payment information provided by the merchant) is, for the purposes of the description, considered as the input indicative of the customer intent to make a payment to the merchant for a purchase transaction.
[00118] At 808, the method 800 includes processing the payment to the merchant payment account in response to receiving the input. The payment to the merchant payment account is processed based on the customer input (i.e. input related to the merchant selection and the customer payment account information) and the linking of the merchant payment account to the ATM (i.e. linking of the merchant username in the ATM and the merchant payment account to the merchant name).
[00119] In one embodiment, the merchant may use the application associated with the payment network server to generate a Quick Response (QR) code including the information representative of the purchase transaction. In one embodiment, the information representative of the purchase transaction configuring the QR code includes merchant identification information and an amount associated with the purchase transaction. The merchant may provide the QR code to the customer using any messaging means, such as Email, Chat application, SMS, and the like. The customer may visit a linked ATM, i.e. an ATM in the vicinity of the merchant location and scan the QR code to provide the payment

information (i.e. the QR code) to the ATM and thereby initiate payment equivalent to the purchase transaction amount from the customer payment account to the merchant payment account. The payment to the merchant payment account is thus processed based on the customer input (i.e. input related to the QR code and the customer payment account information) and the linking of the merchant payment account to the ATM (i.e. linking of the merchant name in the ATM and the merchant payment account to the merchant name).
[00120] In at least one embodiment, subsequent to the successful processing of the payment, the ATM may generate a receipt indicative of the successful transfer of funds from the customer payment account to the merchant payment account. The customer may provide the ATM receipt to the merchant and receive the item(s) purchased from the merchant. In one embodiment, the successful transfer of funds into the merchant payment account may be intimated to the merchant using a messaging notification. The merchant may then hand over the purchased item(s) to the customer. The method 800 ends at 806.
[00121] The merchants, especially small merchants or merchants such as hawkers who sell their wares at different locations, may thus be empowered to use nearby ATMs for receiving payments from customers, who wish to pay using digital means. This enables such merchants to sell their wares to a wider pool of customers (i.e. customers who choose to pay for purchases using digital means).
[00122] FIG. 9 is a simplified block diagram of a server system 160 used for processing digital payments to merchants using ATMs, in accordance with an example embodiment of the present disclosure. The server system 160 is an example of a server system that is a part of the payment network. Examples of the server system 160 include, but are not limited to, an issuer server, an acquirer server and a payment server. The server system 160 includes a computer system 905 and a database 910.
[00123] The computer system 905 includes at least one processor 915 for executing instructions. Instructions may be stored in, for example, but not limited to, a memory 920. The processor 915 may include one or more processing units (e.g., in a multi-core configuration).
[00124] The processor 915 is operatively coupled to a communication interface 925

such that the computer system 905 is capable of communicating with remote entities such an ATM bank 935, a merchant device 940 (e.g., electronic device associated with the merchant, such as the merchant device 505 shown in FIG. 5), an issuer server 945 (e.g., the issuer server 135 shown in FIG. 1), or any server within the payment network. For example, the communication interface 925 may enable transmission of an application for downloading and subsequent installation on the merchant device 940. The communication interface 925 may also be configured to facilitate validation of the merchant payment account by enabling communication with the payment card issuer (i.e. the issuer server 945) associated with the merchant's payment card. The communication interface 925 may also enable communication with the banks associated with ATMs in the vicinity of the merchant location so as to link the merchant payment account with the ATMs. In some embodiments, the communication interface 925 may also provide a notification, such as the notification 600, to the merchant.
[00125] The processor 915 may also be operatively coupled to the database 910. The database 910 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 910 may also store information related to ATM locations across localities, towns, cities, and such other geographical locations. The database 910 also store merchant data including a merchant identifier that identifies each merchant registered to use the payment network, and instructions for settling transactions including merchant bank account information (e.g., a plurality of payment accounts related to POS terminals associated with merchants). The database 910 is also configured to store records of merchants who have registered for receiving customer payments through linked ATMs. The database 910 is further configured to store information related to linking of merchant payment accounts to ATMs.
[00126] The database 910 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 910 may include a storage area network (SAN) and/or a network attached storage (NAS) system. In some embodiments, the database 910 is integrated within the computer system 905. For example, the computer system 905 may include one or more

hard disk drives as the database 910. In other embodiments, the database 910 is external to the computer system 905 and may be accessed by the computer system 905 using a storage interface 930. The storage interface 930 is any component capable of providing the processor 915 with access to the database 910. The storage interface 930 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 915 with access to the database 910.
[00127] The computer system 905 in conjunction with the database 910 is configured to perform the various functions as explained with reference to the server system 160 in FIGS. 3 and 4C. For example, the processor 915 of the computer system 905 is configured to provide an application or a Web service configured to register merchants. In some embodiments, the application provided by the processor 915 is configured to receive merchant input related to the purchase transaction amount and generate a QR code. Further, the processor 915 is configured to identify ATMs near a merchant location and link the ATMs to merchant payment account. The processor 915 is also configured to receive the input provided by the customer at an ATM and facilitate transfer of payment from the customer payment account to the merchant payment account. The processor 915 also generates the notification which is then provided to the merchant. The merchant on receipt of the notification releases the purchased items to the customer.
[00128] FIG. 10 is a simplified block diagram of an automated teller machine (ATM) 1000 used for processing digital payments to merchants, in accordance with an example embodiment of the present disclosure. The ATM 1000 includes at least one processor 1005 communicably coupled to a database 1010, an Input / Output (I/O) interface 1015, a communication interface 1020 and a memory 1025. The components of the ATM 1000 provided herein may not be exhaustive, and that the ATM 1000 may include more or fewer components than that of depicted in FIG. 10. Further, two or more components may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the ATM 1000 may be configured using hardware elements, software elements, firmware elements and/or a combination thereof.

[00129] The I/O interface 1015 is configured to receive inputs from and provide outputs to the end-user (i.e. the merchant and/or the customer) of the ATM 1000. For instance, the I/O interface 1015 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 joystick, a keypad, a touch screen, soft keys, a microphone, and the like. 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.), a speaker, a ringer, a vibrator, and the like.
[00130] The memory 1025 can be any type of storage accessible to the processor 1005. For example, the memory 1025 may include volatile or non-volatile memories, or a combination thereof. In some non-limiting examples, the memory 1025 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.
[00131] The database 1010 is capable of storing and/or retrieving data, such as, but not limited to, payment 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, QR codes, and the like. Such information can be accessed by the processor 1005 using the communication interface 1020 to determine potential future failures and the like.
[00132] The ATM 1000 is capable of communicating with one or more ATM peripheral devices such as an ATM peripheral device 1035 and external server system such as the issuer server 945 (an example of the issuer server 135 of FIG. 1) via the communication interface 1020 over a communication network such as the network 150 of FIG. 1. The ATM peripheral device 1035 can provide functionality which is used by a customer signature capture, QR code scan, and the like. Some non-exhaustive examples of the ATM peripheral device 1035 include QR code scanner, bar code scanner, cash drawer, magnetic stripe reader, receipt printer, PIN pad, signature capture device, touchscreen, keyboard, portable data terminal, card reader, and the like. In some embodiments, the ATM peripheral device 1035 may be mounted near the ATM 1000 such that it is accessible

to the users (i.e. to the merchants and the customers).
[00133] The communication interface 1020 is further configured to cause display of user interfaces on the ATM 1000. In one embodiment, the communication interface 1020 includes a transceiver for wirelessly communicating information to, or receiving information from, the issuer server 945 or other suitable display device, and/or another type of remote processing device, such as QR code scanner. In another embodiment, the communication interface 1020 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, such as the network 150.
[00134] The processor 1005 is capable of sending the purchase transaction request received from the end-user via the communication interface 1020 to the ATM bank or directly to the issuer server 945 for processing the payment transaction. For example, the processor 1005 is configured to receive the transaction amount entered by the end-user using the UIs. The processor 1005 can access the database 1010 to retrieve the user information and merchant username and merchant identification information that are required to be sent along with the payment transaction request to the issuer server 945.
[00135] Additionally, the ATM 1000 can include an operating system and various software applications that can provide various functionality to the ATM 1000. For example, in some embodiments, the ATM 1000 is addressable with an Internet protocol and includes a browser application. In such embodiments, the processor 1005 includes software adapted to support such functionality. In some embodiments, the processor 1005 executes software to support network management. In particular, this capacity allows software to be downloaded to a plurality of such ATMs to provide new applications such as application for enabling customer payments to merchants using the respective ATMs and/or updates to existing applications. The operating system and software application upgrades are distributed and maintained through communication to the ATM 1000 over the network 150.
[00136] FIG. 11 is a simplified block diagram of an issuer server 945 for processing digital payments to merchants using ATMs, in accordance with an example embodiment of the present disclosure. The issuer server 945 is an example of the issuer server 135 of FIG.

1 or may be embodied in the issuer server 135. The issuer server 945 is associated with an issuer bank / issuer, in which a merchant may have an account, which provides an option to receive customer payments using ATMs in the vicinity of the merchant location. The issuer server 945 includes a processing module 1105 operatively coupled to a storage module 1110, an ATM linking module 1115, a verification module 1120 and a communication module 1125. The components of the issuer server 945 provided herein may not be exhaustive, and that the issuer server 945 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 issuer server 945 may be configured using hardware elements, software elements, firmware elements and/or a combination thereof.
[00137] The storage module 1110 is configured to store machine executable instructions to be accessed by the processing module 1105. Additionally, the storage module 1110 stores information related to, contact information of the merchant, bank account number (i.e. merchant payment account number), BICs, payment card details, internet banking information, PIN, mobile personal identification number (MPIN) for mobile banking, and the like. This information is retrieved by the processing module 1105 for cross-verification during payment transactions.
[00138] The processing module 1105, in conjunction with the verification module 1120, is configured to verify the payment card information, the PIN (e.g., whether the four-digit numeric code matches the PIN issued by the issuer), and the like. Upon successful verification only, the processing module 1105 is configured to enable registration of the merchant payment account to enable the merchant to receive customer payments using nearby ATMs.
[00139] The processing module 1105 is further configured to communicate with one or more remote devices such as a remote device 1130 using the communication module 1125 over a network such as the network 150 or the payment network 145 of FIG. 1. The examples of the remote device 1130 include, the ATM bank 935, the merchant device 940, the payment server 140, the acquirer server 130, other computing systems of issuer and the payment network 145, and the like. The communication module 1125 is capable of

facilitating such operative communication with the remote devices and cloud servers using API (Application Program Interface) calls.
[00140] FIG. 12 is a simplified block diagram of an acquirer server 1200 used for processing digital payments to merchants using ATMs, in accordance with an example embodiment of the present disclosure.
[00141] The acquirer server 1200 is associated with the acquirer bank of a merchant where the merchant has established an account to accept payment from customers, such as payment using ATMs. It is noted that in some embodiments, the issuer server 945 and the acquirer server 1200 are the same server and referred to as the issuer server 945 or the acquirer server 1200 depending upon the financial transaction. For example, when the payment is processed from the customer payment account to the merchant payment account, then the bank associated with the merchant payment account is referred to as the acquirer bank and the server associated with the acquirer bank is referred to as the acquirer server. However, when the merchant is registering a merchant payment account using a payment card, then the merchant bank issuing the payment card serves as the issuer and a server associated with the merchant bank serves as the issuer server.
[00142] The acquirer server 1200 is an example of the acquirer server 130 of FIG. 1 or may be embodied in the acquirer server 130. Further, the acquirer server 1200 is configured to link the merchant payment account to one or more ATMs located in the vicinity of the merchant location. The acquirer server 1200 includes a processing module 1205 communicably coupled to a merchant database 1210 and a communication module 1215. The components of the acquirer server 1200 provided herein may not be exhaustive, and that the acquirer 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 acquirer server 1200 may be configured using hardware elements, software elements, firmware elements and/or a combination thereof.
[00143] The merchant database 1210 includes data related to merchant, such as, but not limited to, a merchant primary account number (PAN), a merchant name, a merchant

category code (MCC), a merchant city, a merchant postal code, a merchant brand name, a merchant ID and the like. The processing module 1205 is configured to use the merchant ID to identify the merchant during the normal processing of payment transactions, adjustments, chargebacks, end-of-month fees and so forth. The merchant ID is different than other merchant account numbers, particularly those that identify merchants to the equipment (e.g., the POS terminals or any other merchant electronic devices) they use for processing transactions. A merchant with a single merchant processing account number may use several terminals at one location, resulting in one merchant ID and several terminal identification numbers (TIDs). The processing module 1205 may be configured to store and update such merchant information in the merchant database 1210 for later retrieval.
[00144] In an embodiment, the communication module 1215 is capable of facilitating operative communication with a remote device 1220 (e.g., an ATM 1000, the merchant device 940 and/or the payment server 140) using API calls. The communication may be achieved over a communication network, such as the network 150. For example, the processing module 1205 may receive the transaction amount from the payment server 140 or the issuer server associated with an issuer of customer payment card, using the communication module 1215. Thereafter, the processing module 1205 may retrieve merchant PAN from the merchant database 1210 to credit the transaction amount in the acquirer account of the merchant. Further, the processing module 1205 may be configured to send the notification to the merchant device 940.
[00145] FIG. 13 is a simplified block diagram of a payment server 1300 used for processing digital payments to merchants using ATMs, in accordance with an example embodiment of the present disclosure. The payment server 1300 may correspond to payment server 140 of FIG. 1. As explained with reference to FIG. 1, the payment server 140 is associated with a payment network 145. The payment network 145 may be used by the issuer server 945 and the acquirer server 1200 as a payment interchange network. Examples of payment interchange network include, but not limited to, a payment interchange network operated by Mastercard. The payment server 1300 includes a processing system 1305 configured to extract programming instructions from a memory 1310 to provide various features of the present disclosure. The components of the payment

server 1300 provided herein may not be exhaustive, and that the payment server 1300 may include more or fewer components than that of depicted in FIG. 13. Further, two or more components may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the payment server 1300 may be configured using hardware elements, software elements, firmware elements and/or a combination thereof.
[00146] Via a communication interface 1320, the processing system 1305 receives the selection of the option to register a merchant payment account from an input provided by the merchant. The selection of the registration option is indicative of the merchant's intention to receive customer payments using the ATMs in the vicinity of the merchant location.
[00147] An ATM locator module 1330 is configured to communicate with location services in the merchant device to determine a merchant location and thereafter identify one or more ATMs in the vicinity of the merchant location.
[00148] A linking module 1335 is operatively coupled to the processing system 1305 and the ATM locator module 1330. The linking module 1335 is configured to link of the merchant payment account to the ATMs in vicinity of the merchant location. To that effect, the linking module 1335 may be in operable communication with the banks associated with the various ATMs via the communication interface 1320. The linking module 1335 may be configured to raise a request to link a merchant payment account to an ATM (identified using an ATM ID) and provide the request to the bank associated with the ATM to facilitate linking of the merchant payment account to the ATM.
[00149] The notification generator 1340 is configured to generate notification including an intimation related to the successful processing of the payment and provide the notification to the merchant via the communication interface 1320.
[00150] In an embodiment, a remote device 1345 may correspond to the ATM bank 935, the merchant device 940, or any other server on the payment network 145.
[00151] FIG. 14 shows simplified block diagram of an electronic device 1400 capable of implementing the various embodiments of the present disclosure. For example,

the electronic device 1400 may correspond to the automated teller machine or to a merchant device. The electronic device 1400 is depicted to include one or more applications 1406.
[00152] It should be understood that the electronic device 1400 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 electronic device 1400 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. 14.
[00153] The illustrated electronic device 1400 includes a controller or a processor 1402 (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 1404 controls the allocation and usage of the components of the electronic device 1400 and support for one or more payment application programs (see, applications 1406), that implements one or more of the innovative features, such as processing customer payments to merchants using ATMs, as described herein. In addition, the applications 1406 may include common mobile computing applications (e.g., telephony applications, email applications, calendars, contact managers, web browsers, messaging applications) or any other computing application.
[00154] The illustrated electronic device 1400 includes one or more memory components, for example, a non-removable memory 1408 and/or a removable memory 1410. The non-removable memory 1408 and/or the removable memory 1410 may be collectively known as database in an embodiment. The non-removable memory 1408 can include RAM, ROM, flash memory, a hard disk, or other well-known memory storage technologies. The removable memory 1410 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 1404 and the applications 1406. The electronic device 1400 may further include a user identity module (UTM) 1412. The UTM 1412 may be a memory device having a processor built in. The UTM 1412 may

include, for example, a subscriber identity module (SIM), a universal integrated circuit card (UICC), a universal subscriber identity module (USEVI), a removable user identity module (R-UEVI), or any other smart card. The UTM 1412 typically stores information elements related to a mobile subscriber. The UIM 1412 in form of the SEVI 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).
[00155] The electronic device 1400 can support one or more input devices 1420 and one or more output devices 1430. Examples of the input devices 1420 may include, but are not limited to, a touch screen / a display screen 1422 (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 1424 (e.g., capable of capturing voice input), a camera module 1426 (e.g., capable of capturing still picture images and/or video images) and a physical keyboard 1428. Examples of the output devices 1430 may include but are not limited to a speaker 1432 and a display 1434. 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 1422 and the display 1434 can be combined into a single input/output device.
[00156] A wireless modem 1440 can be coupled to one or more antennas (not shown in the FIG. 14) and can support two-way communications between the processor 1402 and external devices, as is well understood in the art. The wireless modem 1440 is shown generically and can include, for example, a cellular modem 1442 for communicating at long range with the mobile communication network, a Wi-Fi compatible modem 1444 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 1446. The wireless modem 1440 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 electronic device 1400 and a

public switched telephone network (PSTN).
[00157] The electronic device 1400 can further include one or more input/output ports 1450, a power supply 1452, one or more sensors 1454 for example, an accelerometer, a gyroscope, a compass, or an infrared proximity sensor for detecting the orientation or motion of the user device 1400 and biometric sensors for scanning biometric identity of an authorized user, a transceiver 1456 (for wirelessly transmitting analog or digital signals) and/or a physical connector 1460, 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.
[00158] The disclosed embodiments with reference to FIGS. 1 to 7, or one or more operations of the flow diagram 800 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.
[00159] Although the invention has been described with reference to specific

exemplary embodiments, it is noted that various modifications and changes may be made to these embodiments without departing from the broad spirit and scope of the invention. For example, the various operations, blocks, etc., described herein may be enabled and operated using hardware circuitry (for example, complementary metal oxide semiconductor (CMOS) based logic circuitry), firmware, software and/or any combination of hardware, firmware, and/or software (for example, embodied in a machine-readable medium). For example, the apparatuses and methods may be embodied using transistors, logic gates, and electrical circuits (for example, application specific integrated circuit (ASIC) circuitry and/or in Digital Signal Processor (DSP) circuitry).
[00160] Particularly, the server system 160 its various components such as the computer system 905 and the database 910 may be enabled using software and/or using transistors, logic gates, and electrical circuits (for example, integrated circuit circuitry such as ASIC circuitry). Various embodiments of the invention may include one or more computer programs stored or otherwise embodied on a computer-readable medium, wherein the computer programs are configured to cause a processor or computer to perform one or more operations. A computer-readable medium storing, embodying, or encoded with a computer program, or similar language, may be embodied as a tangible data storage device storing one or more software programs that are configured to cause a processor or computer to perform one or more operations. Such operations may be, for example, any of the steps or operations described herein. In some embodiments, the computer programs may be stored and provided to a computer using any type of non-transitory computer readable media. Non-transitory computer readable media include any type of tangible storage media. Examples of non-transitory computer readable media include magnetic storage media (such as floppy disks, magnetic tapes, hard disk drives, etc.), optical magnetic storage media (e.g. magneto-optical disks), CD-ROM (compact disc read only memory), CD-R (compact disc recordable), CD-R/W (compact disc rewritable), DVD (Digital Versatile Disc), BD (BLU-RAY® Disc), and semiconductor memories (such as mask ROM, PROM (programmable ROM), EPROM (erasable PROM), flash memory, RAM (random access memory), etc.). Additionally, a tangible data storage device may be embodied as one or more volatile memory devices, one or more non-volatile memory devices, and/or a combination of one or more volatile memory devices and non-volatile memory devices. In some embodiments, the computer programs may be provided to a

computer using any type of transitory computer readable media. Examples of transitory computer readable media include electric signals, optical signals, and electromagnetic waves. Transitory computer readable media can provide the program to a computer via a wired communication line (e.g. electric wires, and optical fibers) or a wireless communication line.
[00161] Various embodiments of the invention, as discussed above, may be practiced with steps and/or operations in a different order, and/or with hardware elements in configurations, which are different than those which, are disclosed. Therefore, although the invention has been described based upon these exemplary embodiments, it is noted that certain modifications, variations, and alternative constructions may be apparent and well within the spirit and scope of the invention.
[00162] Although various exemplary embodiments of the invention are described herein in a language specific to structural features and/or methodological acts, the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as exemplary forms of implementing the claims.

We Claim:

1.A method for processing digital payments to merchants using automated teller
machines, the method comprising:
providing an option to a merchant to register a merchant payment account for receiving payments from customers by using an automated teller machine (ATM), the ATM located in vicinity of a merchant location;
registering the merchant payment account in response to a selection of the option by the merchant, the registration linking the merchant payment account to the ATM;
receiving an input provided by a customer at the ATM, the input indicative of a customer intent to make a payment to the merchant for a purchase transaction; and
processing, in response to receiving the input, the payment to the merchant payment account based on the input and the linking of the merchant payment account to the ATM.
2. The method as claimed in claim 1, further comprising:
generating a machine-readable code comprising information representative of the purchase transaction, wherein the machine-readable code is provided to the customer by the merchant.
3. The method as claimed in claim 2, wherein the machine-readable code comprises at least one of a merchant identification information and an amount associated with the purchase transaction.
4. The method as claimed in claims 2 or 3, wherein the machine-readable code corresponds to a Quick Response (QR) code, and wherein the customer scans the QR code at the ATM for initiating the processing of the payment to the merchant for the purchase transaction.
5. The method as claimed in claims 1 or 4, further comprising:
generating a notification subsequent to the successful payment to the merchant payment account, wherein the notification is provided to the merchant and wherein the

merchant releases items related to the purchase transaction to the customer subsequent to a receipt of the notification.
6. The method as claimed in claim 5, wherein the notification corresponds to an ATM receipt and, wherein the customer provides the ATM receipt to the merchant.
7. The method as claimed in claim 5, wherein the notification provided to the merchant corresponds to one of a Short Message Service (SMS) notification, an Email notification and a chat message notification.
8. The method as claimed in claims 1 or 5, further comprising:
providing, by a server system associated with a payment network, an application capable of being installed on a merchant device, wherein the option to register the merchant payment account is displayed on a UI associated with the application.
9. The method as claimed in claims 1 or 5, wherein the ATM is configured to display the option to the merchant to register the merchant payment account in response to receiving a request from the merchant, the request indicating an intention of the merchant to use the ATM for receiving the payments from the customers.
10. The method as claimed in claims 1 or 5, wherein an interface associated with a bank related to the merchant payment account is configured to provide the option to the merchant to register the merchant payment account in response to receiving a request from the merchant, the request indicating an intention of the merchant to use the ATM for receiving the payments from the customers.
11. The method as claimed in claims 8 or 9 or 10, further comprising:
validating the merchant payment account prior to the registration of the merchant payment account.
12. A server system in a payment network for processing digital payments to merchants
using automated teller machines, the server system comprising:

a memory comprising stored instructions; and
a processor configured to execute the stored instructions to cause the server system to perform at least:
provide an option to a merchant to register a merchant payment account for receiving payments from customers by using one or more automated teller machines (ATMs), the one or more ATMs located in vicinity of a merchant location;
register the merchant payment account in response to a selection of the option by the merchant, the registration linking the merchant payment account to the one or more ATMs;
receive an input provided by a customer at a linked ATM, the input indicative of a customer intent to make a payment to the merchant for a purchase transaction; and
process, in response to receiving the input, the payment to the merchant payment account based on the input and the linking of the merchant payment account to the ATM.
13. The server system as claimed in claim 12, wherein the server system is further caused
to:
provide an application capable of being installed on a merchant device, wherein the option to register the merchant payment account is displayed on a UI associated with the application.
14. The server system as claimed in claim 13, wherein the application is further caused to:
identify the one or more ATMs in vicinity of the merchant location; and link the merchant payment account to each ATM from among the one or more ATMs.
15. The server system as claimed in claims 13 or 14, wherein the application is further
caused to:
generate a machine-readable code comprising information representative of the purchase transaction, wherein the machine-readable code comprises at least one of a

merchant identification information and an amount associated with the purchase transaction.
16. The server system as claimed in claim 15, wherein the machine-readable code corresponds to a Quick Response (QR) code and, wherein the customer scans the QR code at the linked ATM for initiating the processing of the payment to the merchant for the purchase transaction.
17. The server system as claimed in claims 12 or 16, wherein an ATM receipt is generated subsequent to the successful payment to the merchant payment account and, wherein the ATM receipt is provided to the merchant and, wherein the merchant releases items related to the purchase transaction to the customer subsequent to reception of the ATM receipt.
18. A method for processing digital payments to merchants using automated teller machines, the method comprising:
displaying a user interface (UI) to a merchant by an automated teller machine (ATM), the UI comprising an option to register a merchant payment account for receiving payments from customers by using the ATM;
registering the merchant payment account, by the ATM, in response to a selection of the option by the merchant, the registration linking the merchant payment account to the ATM;
receiving an input from a customer by the ATM, the input indicative of a customer intent to make a payment to the merchant for a purchase transaction; and
processing, in response to receiving the input, the payment to the merchant payment account based on the input and the linking of the merchant payment account to the ATM.
19. The method as claimed in claim 18, wherein the customer scans a quick response (QR)
code comprising information representative of the purchase transaction at the ATM for
initiating the processing of the payment to the merchant for the purchase transaction,
and wherein the QR code comprises at least one of a merchant identification
information and an amount associated with the purchase transaction.

20. The method as claimed in claims 18 or 19, further comprising:
generating, by the ATM, an ATM receipt subsequent to the successful payment to the merchant payment account, wherein the ATM receipt is provided to the merchant and, wherein the merchant releases items related to the purchase transaction to the customer subsequent to reception of the ATM receipt.