Claims:
Claims

1. A computerized method implemented on a server for processing a payment transaction between a merchant and a customer, the server being operative within or communicatively linked to a payment network, the method comprising:
receiving, by the server, merchant identifier data, customer payment vehicle data, and transaction data from an electronic device of the merchant;
identifying, at the server, an issuer financial institution associated with the customer payment vehicle based on the customer payment vehicle data;
communicating the customer payment vehicle data and transaction data from the server to the issuer financial institution through the payment network for performing an authorization process on the customer payment vehicle;
receiving, by the server, a result of the authorization process from the issuer financial institution through the payment network upon completion of the authorization process; and
communicating a payment message based on the result of the authorization process from the server to the merchant electronic device,
wherein the payment message represents approval or rejection of the payment transaction if the result of the authorization process is positive or negative, respectively.

2. The method according to claim 1, wherein the customer payment vehicle data further comprises customer authentication data for the customer payment vehicle.

3. The method according to claim 2, wherein the customer authentication data comprises a passcode and/or biometric data.

4. The method according to any one of claims 1 to 3, wherein the authorization process comprises verifying the customer authentication data against a customer database of the issuer financial institution.

5. The method according to any one of claims 1 to 4, wherein the authorization process comprises retrieving the customer’s financial records from the customer database.

6. The method according to claim 5, wherein the authorization process further comprises assessing the customer’s financial status based on the customer’s financial records and the transaction data.

7. The method according to any one of claims 1 to 6, wherein the transaction data comprises data on value of the payment transaction.

8. The method according to claim 7, wherein if the payment transaction is approved, the method further comprises facilitating transfer of funds for the transaction value from the customer payment vehicle to a financial account of the merchant.

9. The method according to claim 8, wherein facilitating the transfer of funds comprises retrieving details of the merchant financial account.

10. The method according to claim 9, wherein the merchant financial account details are retrieved from a merchant user account based on the merchant identifier data.

11. The method according to claim 10, further comprising performing a merchant registration process to create the merchant user account.

12. The method according to claims 10 or 11, wherein the merchant user account is stored on an account database of the server.

13. The method according to any one of claims 8 to 12, wherein facilitating the transfer of funds comprises transferring funds from issuer financial institution to the merchant financial account through the payment network.

14. A system for processing a payment transaction between a merchant and a customer, the system comprising:
a server comprising a processor and a memory configured to store computer-readable instructions, wherein when the instructions are executed, the processor performs steps of the method of any one of claims 1 to 13.

15. A non-transitory computer-readable medium storing computer-readable instructions that, when executed, cause a processor to perform steps of the method according to any one of claims 1 to 13 for processing a payment transaction between a merchant and a customer.
, Description:Technical Field

The present disclosure generally relates to a method and system for payment transaction processing. More particularly, the present disclosure describes various embodiments of a method and system for processing a payment transaction between a merchant and a customer, e.g. for purchasing goods / products / services from the merchant.

Background

Payment transactions between merchants and customers are increasingly being performed using cashless payment modes in place of conventional cash. Cashless payment modes include payment cards such as credit / debit cards, or a digital wallet linked to a customer’s financial account. The customer may also link a mobile phone to his/her financial account, e.g. bank account or credit card, and use the mobile phone to pay for transactions at a merchant via wireless communications protocols such as Near Field Communication (NFC). The mobile phone has a hardware module or an NFC component, and the merchant has a corresponding NFC reader at the merchant billing machine / terminal. Transactions can be completed and paid for simply by waving the mobile phone in front of the NFC reader. Cashless payment transactions are quicker and more convenient, and arguably more secure compared to using cash.

However, several merchants still prefer to deal in cash and are not keen to do transactions with digital or cashless payments. Some merchants do not accept other forms of payment other than cash, e.g. payment / credit / debit cards. Or some merchants may only accept them for payment transactions that are valued above a certain threshold amount, such as for purchases of more expensive products. This could be due to the processing / transaction fees / surcharges imposed by the financial institution of the merchant and/or financial institution of the customer for transactions that are paid with payment / credit / debit cards, e.g. a credit card payment transaction. It may not be overall profitable for the merchants to accept credit card payments after consideration of the surcharge and their original profit margin.

In a simplified model of a credit card payment transaction between a merchant and a customer, there are essentially 4 parties involved in processing the transaction.
1. Issuer financial institution / bank – bank which issues the credit card to the customer.
2. Acquirer financial institution / bank – bank which contracts with the merchants to enable the merchant to accept payments via credit cards, such as by providing the merchant with a point-of-sale terminal or merchant billing machine.
3. Merchant – business entity that is contracted with an acquirer bank for accepting payments via credit cards.
4. Payment network – electronic communications network connecting all relevant parties involved in the processing of payment transactions.

Currently, when a customer makes a payment by presenting his/her credit card to the merchant, the merchant uses the point-of-sale (POS) terminal / merchant billing machine to process the credit card together with the transaction data. The POS terminal then requests an authorization from the acquirer bank. The request is communicated from the acquirer bank to the issuer bank via the payment network. The issuer bank then processes the request, e.g. to check whether the customer has sufficient credit balance, and either approves or rejects the payment transaction. The authorization result is communicated from the issuer bank to the acquirer bank via the payment network. The acquirer bank then communicates the authorization result to the merchant billing machine to complete the payment transaction.

After completion of the payment transaction, in order for the merchant to receive the funds for the value of the payment transaction, the merchant needs to submit the transaction receipt to the acquirer bank. This may be done in batches periodically together with other transaction receipts. The acquirer bank submits all the transaction receipts to the payment network for settlement. The payment network consolidates the transactions between the merchant and all of the merchant’s customers based on the transaction receipts. A final amount is credited to the merchant by the payment network. At the same time, the payment network communicates with the issuer banks and debits the respective issuer bank of each customer of the merchant. Each issuer bank then debits the customers in their monthly credit card statement, whereby the customer is expected to settle the outstanding debt on the statement by a stipulated deadline.

One problem with the existing model is that there are several parties involved in the processing of payment transactions, including at least the acquirer bank, issuer bank, and payment network. The merchant is required to pay a significant amount of processing / transaction fees / surcharges for the operational costs of accepting payments by payment / credit / debit cards. The processing fees may be calculated as a percentage of the payment transaction value, i.e. cost of the product purchased by the customer, a fixed fee, or a combination of both. The processing fees are incurred and paid by the merchant and are distributed to the acquirer bank, issuer bank, and payment network. Thus, if the payment transaction value is $100 and the customer pays $100 to the merchant, the merchant may only receive $95 eventually. $5 would be the processing fees distributed to the acquirer bank, issuer bank, and payment network.

Therefore, in order to address or alleviate at least one of the aforementioned problems and/or disadvantages, there is a need to provide a method and system for processing a payment transaction, in which there is at least one improved feature over the aforementioned prior art.

Summary

According to an aspect of the present disclosure, there is computerized method implemented on a server for processing a payment transaction between a merchant and a customer, the server being operative within or communicatively linked to a payment network; a system implementing the method; and a non-transitory computer-readable medium storing computer-readable instructions that, when executed, cause a processor to perform steps of the method. The method comprises: receiving, by the server, merchant identifier data, customer payment vehicle data, and transaction data from an electronic device of the merchant; identifying, at the server, an issuer financial institution associated with the customer payment vehicle based on the customer payment vehicle data; communicating the customer payment vehicle data and transaction data from the server to the issuer financial institution through the payment network for performing an authorization process on the customer payment vehicle; receiving, by the server, a result of the authorization process from the issuer financial institution through the payment network upon completion of the authorization process; and communicating a payment message based on the result of the authorization process from the server to the merchant electronic device. The payment message represents approval or rejection of the payment transaction if the result of the authorization process is positive or negative, respectively.

An advantage of the present disclosure is that the efficiency in the processing of payment transactions can be improved due to the exclusion of the acquirer bank from the process to reduce the number of parties involved. Another advantage of excluding the acquirer bank is that the need for processing fees to be paid to the acquirer bank is obviated, reducing the total processing fees incurred by the merchant and increasing the overall profit margin of the merchant. Reduction in the operating costs for merchants may attract more merchants to accept cashless payment modes for transactions, potentially increasing the overall efficiency of the payments industry.

A method and system for processing a payment transaction according to the present disclosure is thus disclosed herein. Various features, aspects, and advantages of the present disclosure will become more apparent from the following detailed description of the embodiments of the present disclosure, by way of non-limiting examples only, along with the accompanying drawings.

Brief Description of the Drawings

FIG. 1 is an illustration of a system for implementation of a method for processing a payment transaction, in accordance with an embodiment of the present disclosure.

FIG. 2 is a flowchart illustration of the method of FIG. 1 implemented on a server.

FIG. 3 is an illustration of the system of FIG. 1, illustrating the process flow of the method for processing a payment transaction.

FIG. 4 is a flowchart illustration of a method implemented on a server for processing a payment transaction, in accordance with an embodiment of the present disclosure.

FIG. 5 is a block diagram illustration of the technical architecture of a server, in accordance with an embodiment of the present disclosure.

FIG. 6 is a block diagram illustration of the technical architecture of a merchant electronic device, in accordance with an embodiment of the present disclosure.

Detailed Description

In the present disclosure, depiction of a given element or consideration or use of a particular element number in a particular figure or a reference thereto in corresponding descriptive material can encompass the same, an equivalent, or an analogous element or element number identified in another figure or descriptive material associated therewith. The use of “/” in a figure or associated text is understood to mean “and/or” unless otherwise indicated.

For purposes of brevity and clarity, descriptions of embodiments of the present disclosure are directed to a method and system for processing a payment transaction, in accordance with the drawings. While aspects of the present disclosure will be described in conjunction with the embodiments provided herein, it will be understood that they are not intended to limit the present disclosure to these embodiments. On the contrary, the present disclosure is intended to cover alternatives, modifications and equivalents to the embodiments described herein, which are included within the scope of the present disclosure as defined by the appended claims. Furthermore, in the following detailed description, specific details are set forth in order to provide a thorough understanding of the present disclosure. However, it will be recognized by an individual having ordinary skill in the art, i.e. a skilled person, that the present disclosure may be practiced without specific details, and/or with multiple details arising from combinations of aspects of particular embodiments. In a number of instances, well-known systems, methods, procedures, and components have not been described in detail so as to not unnecessarily obscure aspects of the embodiments of the present disclosure.

In representative or exemplary embodiments of the present disclosure, there is provided a system 10 as illustrated in FIG. 1. The system 10 comprises a host server or server 100 having a processor and a memory configured to store computer-readable instructions. The server 100 is operative for performing a method for processing a payment transaction between a merchant and a customer. The system 10 includes an electronic device 200 of the merchant which is communicable with the server 100. The merchant electronic device 200 may be a computing device, such as a POS terminal / merchant billing machine, that is located at a retail shop or store of the merchant. Alternatively, the merchant electronic device 200 may be a mobile device, such as mobile phones, smartphones, personal digital assistants (PDAs), tablets, laptops, and/or computers.

The system 10 further comprises a payment network 300 that may be operated by an organization such as a payment card or credit card association. The server 100 is communicatively linked to the payment network 300. It may alternatively be interpreted that the server 100 is communicatively linked such that it forms part of or is integrally connected within the payment network 300. The payment network 300 additionally connects or links together multiple financial institutions (e.g. banks and credit card institutions). These financial institutions may be associated with financial / bank accounts of the merchant and/or associated with payment cards (e.g. credit cards) or other payment vehicles / instruments of the customer.

The payment network 300 is communicatively linked to a group of issuer financial institutions, or issuer banks 320. Each issuer bank 320 is affiliated with the payment card association operating the payment network 300, and each payment card belonging to a customer is issued by an issuer bank 320. For each payment card of the customer, the respective issuer bank 320 is in contract with the customer for the terms of the repayment or clearing of the payment card. Details of customers of each issuer bank 320 are stored on a customer database 322 of the issuer bank 320. The customer database 322 may reside on a local server or computer of the issuer bank 320, or alternatively on a remote server or computer communicatively linked to the issuer bank 320.

The payment network 300 is further communicatively linked to a group of acquirer financial institutions or acquirer banks 340. Similar to the issuer banks 320, each acquirer bank 340 is also affiliated with the payment card association operating the payment network 300. Some financial institutions / banks may operate as both an acquirer bank 340 and an issuer bank 320. Conventionally, for a merchant to be able to accept cashless payments via payment cards, the merchant has to establish an account or contract with an acquirer bank 340. Some acquirer banks 340 may contract with a third party, e.g. a payment processor organization 360, to provide the merchant with payment card processing services on behalf of the acquirer banks 340. Details of merchants contracted with each acquirer bank 340 are stored on a merchant database 342 of the acquirer bank 340. The merchant database 342 may reside on a local server or computer of the acquirer bank 340, or alternatively on a remote server or computer communicatively linked to the acquirer bank 340.

The term “payment card” may refer to a credit card, debit card, prepaid card, or charge card which the customer may use to pay for transactions. More broadly, a payment card is a form of payment vehicle or instrument of the customer. The term “payment vehicle” of the customer may refer to any suitable cashless payment mechanism. In addition to payment cards, customer payment vehicles may include, but are not limited to, membership cards, promotional cards, frequent flyer cards, identification cards, gift cards, and/or any other payment cards that may hold payment card information and which may be stored electronically, such as on a mobile device or mobile phone of the customer.

With reference to FIG. 2, there is a computer-implemented or computerized method 20, e.g. implemented on the server 100, for processing a payment transaction between the merchant and the customer. When the customer goes to the merchant retail shop and intends to purchase a product, the customer presents his/her preferred payment vehicle (e.g. credit card) to the merchant to pay for the transaction. This may otherwise be known as a card-present payment transaction. Alternatively, the customer may make purchases from an online website or store of the merchant or by making a phone call to the merchant. The customer can pay for the purchases online using his/her credit card or by providing credit card details over the phone to the merchant. These may otherwise be known as card-absent or card-non-present transactions.

The merchant proceeds to initiate the method 20 comprising:
a. a step 22 of receiving, by the server 100, merchant identifier data, customer payment vehicle data, and transaction data from the merchant electronic device 200;
b. a step 24 of identifying, at the server 100, an issuer financial institution associated with the customer payment vehicle based on the customer payment vehicle data;
c. a step 26 of communicating the customer payment vehicle data and transaction data from the server 100 to the issuer financial institution through the payment network 300 for performing an authorization process on the customer payment vehicle;
d. a step 28 of receiving, by the server 100, a result of the authorization process from the issuer financial institution through the payment network 300 upon completion of the authorization process;
e. a step 30 of communicating a payment message based on the result of the authorization process from the server 100 to the merchant electronic device 200.

The payment message represents approval of the payment transaction if the result of the authorization process is positive. Conversely, the instruction message represents rejection of the payment transaction if the result of the authorization process is negative. Accordingly, the successful completion or failure of the transaction between the merchant and the customer is dependent on the payment message received by the merchant electronic device 200, and is specifically dependent on the result of the authorization process.

It can be seen from the method 20 that the acquirer bank 340 is not involved in the processing of the payment transaction. Accordingly, the payment transaction may be processed and settled by the payment network 300 and issuer bank 320, bypassing the acquirer bank 340 entirely. FIG. 3 illustrates the process flow of the method 20 implemented on a system 40 without the acquirer bank 340. The system 40 is also indicated in FIG. 1. A representative or exemplary embodiment of the method 20 implemented on the system 40 is described hereafter as a method 400 with reference to FIG. 4. In this embodiment, the customer payment vehicle may be a payment card such as a credit card. However, it would be appreciated various aspects of this embodiment may apply analogously to other forms of payment cards, payment vehicles or instruments.

The method 400 comprises a step 402 of performing, at the server 100, a merchant registration process for the merchant to create a user account of the merchant. Particularly, in order to use the method 20, the merchant may be first required to create or register the merchant user account through the merchant registration process. The merchant may register the merchant user account using a software application executable on the merchant electronic device 200, or on another computing device. During the merchant registration process, the merchant may be required to provide identification details of the merchant, e.g. name, address, identification number, phone number, etc.

The merchant may further be required to input details of a financial account or payment vehicle / instrument of the merchant for receiving funds after the customer pays for the transaction with his/her payment card. For example, the financial account may be a bank account of the merchant and funds are credited directly to the bank account. Alternatively, the merchant may prefer to use a payment vehicle such as a payment / credit / debit card or a digital wallet into which the merchant wants the funds to be credited.

The merchant user account is stored on an account database, along with other user accounts of other merchants. The merchant may be required to create a unique username, or alternatively the username may be generated by the server 100. Accordingly, the username functions as an identifier data of the merchant such that each merchant user account can uniquely identifiable on the account database based on the username. The account database may reside on the server 100, or alternatively on a remote server or computer communicatively linked to the server 100.

When the customer goes to the merchant’s retail shop to purchase a product, the customer can present his/her credit card to the merchant to pay for the transaction, specifically a card-present transaction. The merchant electronic device 200 may be a POS terminal that comprises a reader for physically inserting the credit card inside. Alternatively, such a reader may be separate and connectable to the merchant electronic device 200 which may be a mobile phone. The reader would then be able to read the magnetic stripe or EMV chip on the credit card and retrieve embedded customer payment vehicle data or credit card details.

If the merchant electronic device 200 does not have such a reader, the merchant may use an image capture device, which may be part of or connected to the merchant electronic device 200, to capture an image of the credit card. Specifically, the front side of the credit card is captured as image data, which would show the credit card details. The credit card details may comprise the Primary Account Number (PAN) of the credit card which, for most credit cards, is a 16-digit number. The credit card details may further comprise the customer’s name on the credit card and the expiry date of the credit card. The merchant electronic device 200 then generates customer payment vehicle data based on the credit card details. It would be appreciated that the merchant electronic device 200 may comprise optical character recognition (OCR) functionality, e.g. as part of the software application executable thereon, to convert the image data to textual form before generating the customer payment vehicle data.

Alternatively, at the retail shop, the customer may manually key in or input the credit card details on the merchant electronic device 200. The merchant electronic device 200 then generates the customer payment vehicle data based on the customer’s input. Yet alternatively, each of the merchant electronic device 200 and the credit card may be NFC-enabled or comprises an NFC component. The credit card details may already be in a standby or communicative mode, e.g. embedded in the NFC component of the credit card. NFC data comprising the credit card details is thus communicable from the credit card to the merchant electronic device 200 via NFC protocol. The merchant electronic device 200 then generates the customer payment vehicle data based on the received NFC data. It would be appreciated that the NFC data may be tokenized during communication from the credit card to the merchant electronic device 200.

If the customer is not at the retail shop but is instead making purchases from the merchant through the phone or online website, the payment transaction would be a card-absent transaction. The customer may provide his/her credit card details through the phone and the merchant may manually input the credit card details on the merchant electronic device 200. Alternatively, the merchant electronic device 200 may be configured to automatically receive the credit card details after the customer completes the purchase process on the online website.

In some payment transactions, the credit card may require additional authentication. The customer payment vehicle data of the credit card may additionally comprise customer authentication data for the credit card, which includes security code(s), passcode(s), signature(s), and/or biometric data.

In one example, the customer authentication data may comprise a security code of the credit card. The security code may also be known as card verification value (CVV) or card verification code (CVC). The security code is normally indicated on the back side of the credit card as a 3-digit number. Such security codes are normally used in card-absent transactions to verify that the customers are in physical possession of their credit cards during the payment transactions, which may occur through phone or online website.

In another example, the customer authentication data may comprise biometric data such as a photo of the customer’s face, fingerprint, or the customer’s retinal information. The biometric data would be verified against the customer database 322 / biometric database of the issuer bank 320 of the credit card during the authorization process mentioned in the step 26. The customer database 322 / biometric database may comprise reference biometric data of the customer. Alternatively, the reference biometric data of customers may be stored on a separate biometric database of the issuer bank 320. The reference biometric data may comprise image data, such as a captured photo of the customer’s face, i.e. a still image of the customer’s face. Alternatively, the image data may comprise a set of images, such as a series of images or a video sequence. Reference biometric data may alternatively or additionally comprise one or more fingerprints. Prints from multiple digits or fingers of the customer may be scanned and recorded as reference biometric data so that the customer may still rely on fingerprint recognition if one of his/her scanned fingers is injured and a legible print or scan cannot be obtained. Reference biometric data may alternatively or additionally include retinal information of the customer. The retinal information may be captured with an Intelligent Retinal Imaging System (IRIS) together with a high-definition camera on or connectable to the merchant electronic device 200 to scan or screen retinal information from the customer’s eye(s).

The customer authentication data may be obtained by the merchant electronic device 200, usually by the customer’s manual input. Accordingly, the merchant electronic device 200 may comprise or may be connectable to an image capture device to capture a photo of the customer’s face, and/or a fingerprint scanner for reading the customer’s fingerprints. Upon receiving the customer authentication data for the credit card, the merchant electronic device 200 proceeds to generate the customer payment vehicle data for communication to the server 100.

The method 400 comprises a step 404 of receiving, by the server 100, the merchant identifier data, customer payment vehicle data, and transaction data from the merchant electronic device 200. It would be appreciated that the merchant identifier data, customer payment vehicle data, and transaction data are simultaneously communicated from the merchant electronic device 200 to the server 100.

The merchant identifier data may refer to or comprise the username of the merchant user account that was created during the merchant registration process described above. The merchant identifier data enables the server 100 to identify the merchant that is party to the instant payment transaction from the multiple merchants in the account database. In order for the merchant electronic device 200 to receive or accept the credit card details of the customer, the merchant may be required to login to his/her merchant user account on the merchant electronic device 200. During data transmission from the merchant electronic device 200 to the server 100, the merchant identifier data may be communicated together with the customer payment vehicle data and transaction data. Alternatively, the merchant identifier data may be embedded as metadata in the data transmission.

The customer payment vehicle data is obtained by the merchant electronic device 200 as described above. It would be appreciated that the customer data may be communicated from the merchant electronic device 200 to the server 100 in the form of image data, and that the server 100 may comprise OCR functionality to convert the image data to textual form. The customer payment vehicle data comprises the credit card details and may further comprise the customer authentication data.

The transaction data refers to data associated with the payment transaction, and may comprise data on value of the transaction. For example, if the customer is purchasing a product from the merchant, the transaction data may include the transaction value of the payment transaction and the transaction value refers to the cost or price of the product. The transaction data may be generated by the merchant electronic device 200 through manual input by the merchant. For example, the merchant may manually enter the product’s identification number and price on the merchant electronic device 200. Alternatively, the product may comprise a barcode for retrieving the product’s price, and optionally together with the product’s identification number, from a merchant inventory system. The merchant electronic device 200 may comprise or may be connectable to a barcode reader / scanner for reading / scanning the barcode and retrieving the product’s price. Accordingly, the transaction data comprising data on the transaction value can be generated based on the product’s price and optionally the product’s identification number. Yet alternatively, if the purchase process is occurring online, the merchant electronic device 200 may be configured to automatically generate the transaction data after the customer completes the online purchase process.

The method 400 comprises a step 406 of identifying, at the server 100, the issuer bank 320 associated with the credit card based on the customer payment vehicle data. The customer payment vehicle data comprises credit card details which includes the 16-digit credit card number. The number group of consisting of the first 6 digits of the credit card number represents the issuer identification number or bank identification number. This number group uniquely identifies the financial institution, i.e. the issuer bank 320, which issued the credit card to the customer.

The method 400 comprises a step 408 of communicating the customer payment vehicle data and transaction data from the server 100 to the issuer bank 320 through the payment network 300 for performing an authorization process on the customer payment vehicle, i.e. credit card. Specifically, in the step 408, the server 100 communicates the customer payment vehicle data to the issuer bank 320 that was identified in the step 406. The customer payment vehicle data comprises the credit card details and optionally the customer authentication data. Upon receiving the customer payment vehicle data, the issuer bank 320 proceeds to perform the authorization process on credit card.

During the authorization process, the issuer bank 320 may verify the customer payment vehicle data or credit card details against the customer database 322. This may include verifying whether the 16-digit credit card number is valid and not associated with fraudulent activities, whether the customer’s name on the credit card matches the 16-digit credit card number, and/or whether the expiry date of the credit card is correct. Accordingly, the authorization process seeks to verify the authenticity / validity of the credit card.

Additionally, during the authorization process, the issuer bank 320 may determine the identity of the customer from the customer database 322 based on the credit card details. With the customer’s identity determined, the issuer bank 320 would be able to retrieve his/her financial records from the customer database 322 or a separate financial database of the issuer bank 320. From the financial records, the issuer bank 320 would be able to assess the customer’s credit information, e.g. credit balance, credit limit, outstanding debt, spending history, long-term loans, and/or other financial liabilities. The customer’s financial status and ability to purchase the product from the merchant can thus be determined based on the credit information. For example, if the customer’s outstanding debt exceeds his/her available credit limit, or if there is insufficient credit balance, then the issuer bank 320 would not allow the customer to purchase the product from the merchant. The result of the authorization process would be negative.

Further additionally, during the authorization process, the issuer bank 320 may verify the customer’s identity based on the customer authentication data. In one example of a card-absent transaction, the merchant electronic device 200 does not process the physical credit card and is unable to read the EMV chip or magnetic stripe on the credit card. The issuer bank may instead require the security code (e.g. CVV or CVC) of the credit card. This is a security feature for credit card payment transactions wherein the physical credit card is not inserted into and read by a POS terminal. The security feature is intended to verify that the customer is in physical possession of his/her credit card during the payment transaction, so as to mitigate risk of credit card fraud.

In another example of a card-present transaction, the issuer bank 320 may need to verify that the customer is the true owner of the credit card that was presented to the merchant to pay for the transaction. This verification may be done by a passcode, signature, and/or biometric data. Credit cards with EMV chips usually have embedded customer authentication data in the form of a passcode (e.g. personal identification number or PIN) or a signature. Alternatively or additionally, the issuer bank 320 may require the customer to also provide his/her biometric data. This may be done via the merchant electronic machine 200. The issuer bank 320 would then proceed to verify the customer’s biometric data against the reference biometric data in the customer database 322 / biometric database of the issuer bank 320.

Verification of the customer’s authentication data against the customer database 322 by the issuer bank 320 may also occur if the customer is using a digital wallet as the payment vehicle to the merchant. Further, the issuer bank 320 may only require verification by the customer authentication data if the transaction value is above a predetermined threshold amount, which may be determined and adjusted by the customer or the issuer bank 320.

Therefore, after the step 408, the issuer bank 320 performs the authorization process on the credit card, assessing the customer payment vehicle data which comprises the credit card details and optionally the customer authentication data. If the credit card details are assessed to be invalid and/or if the customer authentication data cannot be verified, the authorization process would yield a negative or rejection result. Conversely, if the credit card details are assessed to be valid and the customer authentication data is verified, the authorization process would yield a positive or approval result.

According to a step 410 of the method 400, the result from the authorization process may be positive or negative upon completion of the authorization process. A positive authorization process result may mean, for example, that the issuer bank 320 has successfully assessed all of the following conditions:
a. The credit card is valid.
b. The customer authentication data is verified.
c. The customer’s identity is verified.
d. The customer has sufficient credit balance to complete the purchase.
A negative authorization process result may mean that if one or more of the above conditions cannot be successfully assessed in the authorization process. It would be appreciated that the decision of a positive or negative result from the authorization process may be dependent on various conditions or criteria assessed by the issuer bank 320, some of which are listed above.

If the authorization process result is negative, the method 400 comprises a step 412 of receiving, by the server 100, the negative authorization process result from the issuer bank 320 communicated through the payment network 300. The method 400 further comprises a step 414 of communicating, from the server 100 to the merchant electronic device 200 through the payment network 300, a payment message based on the negative authorization process result. This “negative” payment message may be displayed on the merchant electronic device 200 to inform the merchant that the payment transaction is rejected. The method 400 thus proceeds to a step 416 of terminating the payment transaction.

If the authorization process result is positive, the method 400 comprises a step 418 of receiving, by the server 100, the positive authorization process result from the issuer bank 320 communicated through the payment network 300. The method 400 further comprises a step 420 of communicating, from the server 100 to the merchant electronic device 200 through the payment network 300, a payment message based on the positive authorization process result. This “positive” payment message may be displayed on the merchant electronic device 200 to inform the merchant that the payment transaction is approved. The method 400 thus proceeds to a step 422 of completing the payment transaction, wherein the merchant may allow the customer to leave with the purchased product.

From the method 400, it is evident that the major parties involved in processing of the payment transaction are the payment network 300 and issuer bank 320. Conventionally, processing of payment transactions also included the acquirer bank 340 as one of the major parties involved. However, as seen in the method 400 and more broadly the method 20, while still communicatively linked to the payment network 300, acquirer banks 340 are not involved in any aspect of processing of payment transactions described in the method 400 / 20.

The customer payment vehicle data can be communicated from the merchant electronic device 200 to the issuer bank 320 via the payment network 300, or more particularly the server 100 of the payment network 300. This communication path essentially bypasses the acquirer bank 340 of the merchant. The merchant electronic device 200 may thus operate as the acquirer bank 340 and communicate with the issuer bank 320 via the payment network 300 for approval of the payment transaction.

By excluding the acquirer bank 340, the number of parties involved in the processing of payment transactions is reduced, potentially increasing the efficiency in the processing of payment transactions. The exclusion of the acquirer bank 340 also obviates the need for processing fees to be paid to the acquirer bank 340. While processing fees may still be imposed by and payable to the payment network 300 and issuer bank 320, the total amount incurred by the merchant is lower, thereby increasing the overall profit margin of the merchant.

In addition, without the acquirer bank 340, it is not necessary for the merchant to use complex POS terminals that are communicable with the acquirer bank 340. While POS terminals and other forms of merchant billing machines may still be used as the merchant electronic device 200 described herein, the merchant electronic device 200 may more preferably be a portable or mobile device such as a mobile phone or tablet. The mobile device is capable of obtaining and communicating the merchant identifier data, customer payment vehicle data, and transaction data. The mobile device is configured for communication directly with the payment network 300 or the server 100 of the payment network 300, bypassing the acquirer bank 340 Approval of the payment transaction is performed by the issuer bank 320 and communicated to the mobile device, also bypassing the acquirer bank 340. Accordingly, the need of an acquirer bank 340 in the processing of payment transactions described in the method 400 / 20 is obviated.

After completion of the payment transaction in the step 422 of the method 400, funds from the value of the payment transaction, i.e. revenue from the sale of the product to the customer, are paid to the merchant subsequently. It may be appreciated that the actual amount or revenue received by the merchant may not be equivalent to the transaction value, in consideration of processing fees imposed by and payable to the payment network 300 and issuer bank 320. The method 400 comprises a step 424 of facilitating transfer of funds for the transaction value from the customer payment vehicle (credit card) to the merchant financial account. Particularly, facilitating the transfer of funds may comprise transferring funds from issuer bank 320 to the merchant financial account through the payment network 300. In the step 424, details of the merchant financial account may be retrieved, by the server 100 or payment network 300, from the merchant user account based on the merchant identifier data received in the step 404.

In one example of the step 424, funds are firstly transferred from the payment network 300 to the merchant financial account. The payment network 300 credits the merchant financial account and debits the issuer bank 320. A settlement is then obtained from the issuer bank 320 and funds are transferred from the issuer bank 320 to the payment network 300. The issuer bank 320 then debits the customer in his/her monthly / periodic credit card statement, whereby the customer is expected to settle the outstanding debt on the statement by a stipulated deadline.

In another example of the step 424, funds are firstly transferred from the issuer bank 320 to the payment network 300. The issuer bank 320 credits the payment network 300 and debits the customer. Similar to the above example, the issuer bank 320 debits the customer in his/her monthly / periodic credit card statement, whereby the customer is expected to settle the outstanding debt on the statement by a stipulated deadline. With the credit on the payment network 300, funds are then transferred from the payment network 300 to the merchant financial account, crediting the merchant financial account.

It would be appreciated that the transfer of funds (i) from the payment network 300 to the merchant financial account, and (ii) from the issuer bank 320 to the payment network 300, may occur simultaneously or sequentially in no specific order. It would also be appreciated that the actual amount of funds in (i) and (ii) may not be equivalent to each other, in consideration that each of the payment network 300 and issuer bank 320 may levy some processing fees prior to the respective funds transfer.

Therefore, in the step 424, the payment transaction can be settled, i.e. settlement of funds, between the merchant and the issuer bank 320 via the payment network 300. The acquirer 340 is not involved in the settlement process, or more specifically, does not play a major role in the settlement process. It may be understood that the merchant financial account or bank account may be maintained by a financial institution such as an acquirer bank 340. However, the role of the acquirer bank 340 is purely for maintaining the financial account for the merchant, and the acquirer bank 340 does not participate in the processing of payment transactions described in the method 400 / 20.

The software application executable on the merchant electronic device 200 may be additionally configured with various functionalities to assist or complement the processing of payment transactions. For example, the software application may be configured for monitoring and tracking of past payment transactions and transaction history. This could enable the merchant to track and follow up on disputed transactions, particularly those that are refundable to customers. The software application may also be configured for compiling consolidating the merchant’s financial statements, so that the merchant can be informed on the revenue, costs, losses, profits, and other financial aspects of his/her business. The software application may also be configured for automatically providing benefits to the customer for certain purchases, if the customer is a frequent patron, and/or if the customer is using a particular credit card that the merchant is in contract with for providing benefits. These benefits may include reward points, loyalty points, discounts, rebates, etc. Moreover, it may be advantageous for merchants to provide benefits to customers in consideration of their cost savings due to lower processing fees for payment transactions paid for by credit cards.

The following is a description of the technical architectures of the server 100 and the merchant electronic device 200.

FIG. 5 illustrates a block diagram showing a technical architecture of the server 100. The technical architecture includes a processor 102 (which may be referred to as a central processor unit or CPU) that is in communication with memory devices including secondary storage 104 (such as disk drives or memory cards), read only memory (ROM) 106, and random access memory (RAM) 108. The processor 102 may be implemented as one or more CPU chips. The technical architecture further comprises input/output (I/O) devices 110, and network connectivity devices 112.

The secondary storage 104 is typically comprised of a memory card or other storage device and is used for non-volatile storage of data and as an over-flow data storage device if RAM 108 is not large enough to hold all working data. Secondary storage 104 may be used to store programs which are loaded into RAM 108 when such programs are selected for execution.

The secondary storage 104 has a processing component 114, comprising non-transitory instructions operative by the processor 102 to perform various operations of the method 20 / 400 according to various embodiments of the present disclosure. The ROM 106 is used to store instructions and perhaps data which are read during program execution. The secondary storage 104, the ROM 106, and/or the RAM 108 may be referred to in some contexts as computer-readable storage media and/or non-transitory computer-readable media. Non-transitory computer-readable media include all computer-readable media, with the sole exception being a transitory propagating signal per se.

The I/O devices 110 may include printers, video monitors, liquid crystal displays (LCDs), plasma displays, touch screen displays, keyboards, keypads, switches, dials, mice, track balls, voice recognizers, card readers, paper tape readers, and/or other well-known input devices.

The network connectivity devices 112 may take the form of modems, modem banks, Ethernet cards, universal serial bus (USB) interface cards, serial interfaces, token ring cards, fibre distributed data interface (FDDI) cards, wireless local area network (WLAN) cards, radio transceiver cards that promote radio communications using protocols such as code division multiple access (CDMA), global system for mobile communications (GSM), long-term evolution (LTE), worldwide interoperability for microwave access (WiMAX), near field communications (NFC), radio frequency identity (RFID), and/or other air interface protocol radio transceiver cards, and other well-known network devices. These network connectivity devices 112 may enable the processor 102 to communicate with the Internet or one or more intranets. With such a network connection, it is contemplated that the processor 102 might receive information from the network, or might output information to the network in the course of performing the operations or steps of the method 20 / 400. Such information, which is often represented as a sequence of instructions to be executed using processor 102, may be received from and outputted to the network, for example, in the form of a computer data signal embodied in a carrier wave.

The processor 102 executes instructions, codes, computer programs, scripts which it accesses from hard disk, floppy disk, optical disk (these various disk based systems may all be considered secondary storage 104), flash drive, ROM 106, RAM 108, or the network connectivity devices 112. While only one processor 102 is shown, multiple processors may be present. Thus, while instructions may be discussed as executed by a processor, the instructions may be executed simultaneously, serially, or otherwise executed by one or multiple processors.

It should be appreciated that the technical architecture of the server 100 may be formed by one computer, or multiple computers in communication with each other that collaborate to perform a task. For example, but not by way of limitation, an application may be partitioned in such a way as to permit concurrent and/or parallel processing of the instructions of the application. Alternatively, the data processed by the application may be partitioned in such a way as to permit concurrent and/or parallel processing of different portions of a data set by the multiple computers. In an embodiment, virtualization software may be employed by the technical architecture to provide the functionality of a number of servers that is not directly bound to the number of computers in the technical architecture. In an embodiment, the functionality disclosed above may be provided by executing the application and/or applications in a cloud computing environment. Cloud computing may comprise providing computing services via a network connection using dynamically scalable computing resources. A cloud computing environment may be established by an enterprise and/or may be hired on an as-needed basis from a third party provider.

FIG. 6 illustrates a block diagram showing a technical architecture of the merchant electronic device 200 which may be a mobile device such as a mobile phone. The technical architecture includes a processor 202 (which may be referred to as a central processor unit or CPU) that is in communication with memory devices including secondary storage 204 (such as disk drives or memory cards), read only memory (ROM) 206, and random access memory (RAM) 208. The processor 202 may be implemented as one or more CPU chips. The technical architecture further comprises input/output (I/O) devices 210, and network connectivity devices 212.

The I/O devices 210 comprise a user interface (UI) 214 and an image capture device or camera 216. The merchant electronic device 200 may further include a geolocation module 218. The UI 214 may comprise a touch screen, keyboard, keypad or other known input devices, e.g. fingerprint sensor 220 and barcode scanner 222. The camera 216 allows the merchant to capture image data and save the captured image data in electronic form on the merchant electronic device 200, e.g. on the secondary storage 204. The fingerprint sensor 220 allows the merchant to read and capture the customer’s fingerprint as authentication data. The geolocation module 218 is operable to determine the geolocation of the mobile device 200 using signals from, for example global positioning system (GPS) satellites. The barcode scanner 222 allows the merchant to scan barcodes from products to obtain transaction data including the prices of products.

The secondary storage 204 is typically comprised of a memory card or other storage device and is used for non-volatile storage of data and as an over-flow data storage device if RAM 208 is not large enough to hold all working data. Secondary storage 204 may be used to store programs which are loaded into RAM 208 when such programs are selected for execution.

The secondary storage 204 has a processing component 224, comprising non-transitory instructions operative by the processor 202 to perform various operations of the method 20 / 400 according to various embodiments of the present disclosure. The ROM 206 is used to store instructions and perhaps data which are read during program execution. The secondary storage 204, the ROM 206, and/or the RAM 208 may be referred to in some contexts as computer-readable storage media and/or non-transitory computer-readable media. Non-transitory computer-readable media include all computer-readable media, with the sole exception being a transitory propagating signal per se.

The network connectivity devices 212 may take the form of modems, modem banks, Ethernet cards, universal serial bus (USB) interface cards, serial interfaces, token ring cards, fibre distributed data interface (FDDI) cards, wireless local area network (WLAN) cards, radio transceiver cards that promote radio communications using protocols such as code division multiple access (CDMA), global system for mobile communications (GSM), long-term evolution (LTE), worldwide interoperability for microwave access (WiMAX), near field communications (NFC), radio frequency identity (RFID), and/or other air interface protocol radio transceiver cards, and other well-known network devices. For example, the network connectivity devices 212 include an NFC component 226 of the merchant electronic device 200. These network connectivity devices 212 may enable the processor 202 to communicate with the Internet or one or more intranets. With such a network connection, it is contemplated that the processor 202 might receive information from the network, or might output information to the network in the course of performing the operations or steps of the method 20 / 400. Such information, which is often represented as a sequence of instructions to be executed using processor 202, may be received from and outputted to the network, for example, in the form of a computer data signal embodied in a carrier wave.

The processor 202 executes instructions, codes, computer programs, scripts which it accesses from hard disk, floppy disk, optical disk (these various disk based systems may all be considered secondary storage 204), flash drive, ROM 206, RAM 208, or the network connectivity devices 212. While only one processor 202 is shown, multiple processors may be present. Thus, while instructions may be discussed as executed by a processor 202, the instructions may be executed simultaneously, serially, or otherwise executed by one or multiple processors 202.

It is understood that by programming and/or loading executable instructions onto the technical architecture of the server 100 and/or merchant electronic device 200, at least one of the CPU 102 / 202, the ROM 106 / 206, and the RAM 108 / 208 are changed, transforming the technical architecture in part into a specific purpose machine or apparatus having the functionality as taught by various embodiments of the present disclosure. It is fundamental to the electrical engineering and software engineering arts that functionality that can be implemented by loading executable software into a computer can be converted to a hardware implementation by well-known design rules.

In the foregoing detailed description, embodiments of the present disclosure in relation to a method and system for processing a payment transaction between a merchant and a customer are described with reference to the provided figures. The description of the various embodiments herein is not intended to call out or be limited only to specific or particular representations of the present disclosure, but merely to illustrate non-limiting examples of the present disclosure. The present disclosure serves to address at least some of the mentioned problems and issues associated with the prior art. Although only some embodiments of the present disclosure are disclosed herein, it will be apparent to a person having ordinary skill in the art in view of this disclosure that a variety of changes and/or modifications can be made to the disclosed embodiments without departing from the scope of the present disclosure. Therefore, the scope of the disclosure as well as the scope of the following claims is not limited to embodiments described herein.