WO2020198764A2

WO2020198764A2 - Method & system for terminal coded mobile payments

Info

Publication number: WO2020198764A2
Application number: PCT/ZA2020/050017
Authority: WO
Inventors: Angus Pohl
Original assignee: Angus Pohl
Priority date: 2019-03-25
Filing date: 2020-03-25
Publication date: 2020-10-01
Also published as: WO2020198764A3

Abstract

A system and method for conducting a transaction are provided, in a method at a transaction terminal device (101), the total amount payable being manually or automatically entered into a suitable application for live transmission to a payment system platform, followed by the customer using a registered mobile phone to dial a USSD Code or Missed Call Number uniquely associated with said transaction terminal device, and receiving a PIN to Pay request on the customer mobile phone. Upon PIN entry the payment system platform (150) transmits the combined payload data including the merchant terminal id, amount due, customer mobile phone number, payment provider id and customer PIN to a relevant participating payment provider, which proceeds to settle the transaction on behalf of the customer with the merchant.

Description

METHOD & SYSTEM FOR TERMINAL CODED MOBILE PAYMENTS

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority from United States provisional patent application number US62/823.246 filed on 25 March 2019, which is incorporated by reference herein.

FIELD OF THE INVENTION

The present disclosure generally relates to financial transaction systems and methods and more particularly to a computerized system and method for processing customer/merchant financial transactions utilizing mobile phones.

BACKGROUND TO THE INVENTION

Several mobile payment initiatives have been implemented in different parts of the world using various mobile payment technologies and methods. Most require costly sophisticated mobile phones, mobile communication components (e.g. NFC) and SIM/chip technologies, the Internet and other mobile services to perform financial transactions. However, the globalization of these mobile payment solutions is still limited to certain markets, and more specifically entirely exclude more than 2 billion global underbanked people. The convergence of mobile and payment systems has proven to be complex, requiring the association and cooperation of multiple participants.

Additionally, multiple efforts to introduce USSD related payment solutions specifically serving the underbanked markets have failed to gain traction, mostly because they included costly hardware terminal devices, exclusive business models, and require too many user inputs, resulting in a bad (slow, error prone) user experience.

As such a simple, cost effective, straightforward system and method for utilizing existing phone technology and payment processing system capabilities are required to facilitate transactions directly at merchant point of sale location (offline and online).

SUMMARY OF THE INVENTION

The present disclosure utilizes existing Point-of-Sale (POS) terminals with internet connectivity, or mobile enabled devices or mobile phones capable of using a combination of GSM (Global System for Mobile Communications), USSD (Unstructured Supplementary Service Data), Voice, and SMS Text channels typically available to most mobile phones.

The present disclosure provides a simple and secure process solution that integrates standard, readily available mobile and internet technologies with business stakeholders (e.g., merchants, banks, etc) to enable customer payments in a low cost, simple, seamless and efficient manner through the use of a unique Mobile Payments System Platform and point of sale software interface.

One embodiment of a method of processing a payment for a transaction with a merchant by a customer via a customer's mobile phone includes the following operations: After provisioning and registering a fixed USSD Code uniquely associated with a specific point of sale (POS) terminal at a merchant location, the merchant enters a transaction amount into the POS terminal, which is transmitted as a transaction request to a payment system platform on standby for further processing.

The customer initiates the payment process by dialling the USSD POS Code from a pre-registered mobile phone, and receives a USSD pull message containing a list of payment options (if there is more than one to choose from) and selects one, and instantly followed by a Enter PIN to Pay request. Upon PIN entry the payment system platform transmits the payload data to the customer Payment Provider which directly settles the payment by transferring funds from the customer account to either a dedicated Platform Operator account (received on behalf of the merchant), or directly with a merchant account within the Payment Provider, or through a payment 3^rd party payment switch to the Merchant’s external Bank. The Payment Provider concludes the process by sending an approval message to both the customer's mobile phone and to the merchant via the POS terminal.

According to this embodiment the payer identifier is the customer Mobile Phone Number, Imei Number and Sim Card Numberwhich is in turn also associated with the customer’s list of Payment Providers (BIN). The POS terminal identifier is either the POS Terminal IP address, or the Mobile Device’s Phone Number, Imei Number and Sim Card Number which is in turn also associated with the merchant terminal, and unique USSD POS Code.

According to another embodiment a similar user experience and transaction flow can be achieved by way of a missed call methodology, where instead of USSD Codes issued to each POS Terminal, either real of virtualised Mobile Numbers can be used. In this instance the customer would initiate the payment process (after the merchant payment due is entered), by dialling a uniquely associated POS Mobile Number. Instead of a USSD menu, the customer would instantly receive a voice call from the Payment system platform, instructing the customer to enter the PIN to Pay on the mobile phone keyboard during the call. The selection of a payment provider will (in this case) be based on a default selection chosen in advance using a USSD dial-in number, mobile application, web interface, merchant kiosk or the promises of a participating payment provider.

Finally, records of transactions are stored in the Mobile Payments System Platform for reconciliation and settlement purposes or may optionally be stored in a centralized bank database.

The Mobile Payments System Platform in accordance with the present disclosure communicates with the customer mobile phone and the merchant's point of sale (POS) terminal via a mobile network operator or the internet. The Mobile Payments System Platform facilitates communication with participating payment provider API’s via secure VPN links.

One embodiment provides for the use of the invention for purposes of both offline (physical merchant) and online merchant points of sale. For example, in the case of online transactions either USSD POS Codes or POS Mobile Numbers can be actively generated or selected from an existing database, and allocated for every purchase during the checkout process.

One embodiment provides for the option of having either USSD POS Codes or POS Mobile Numbers automatically dialled when saved as a QR Code (or the like), and scanned by a smartphone QR Code (or the like) suitably configured application.

One embodiment provides customers with the option to use a smartphone application as transaction interface, instead of a default USSD Menu. For example, Opening the application, scanning the USSD POS Code associated QR Code, and choosing a payment provider + PIN entry within the application itself.

One embodiment provides for the option to either actively select a payment provider“on-the-fly” from a list of participating customer associated providers during a transaction, or choosing a default payment provider, which can be changed by either USSD, online or smartphone application channels prior to the transaction. One embodiment provides forthe routing of PIN data either directly through the Mobile Payments System Platform, or directly from the payment providers or a Universal Payment Interface, such as the NPCI UPI in India.

One embodiment provides for the real-time settlement of switchless payments amongst participating parties by way of distributed ledger / blockchain technology, such as the Ripple protocol for example.

One embodiment provides for a method and system where every participating payment provider receives an exact copy of a merchant account from every other payment provider by way of a distributed ledger system, making the settlement of transactions between payers and payees by way of a 3^rd party switch obsolete.

One embodiment provides for a method and system to accept and process all payments as“onus” transactions, where the payment system operator creates a bank account within each participating payment provider, which is used for purposes of receiving customer payments on a merchant’s behalf. The said payment being held for a period of time and then transferred to either a merchant internal account, external account by Electronic Funds Transfer (EFT).

One embodiment provides for the direct integration of the payment system platform with every payment provider API individually.

Another embodiment provides for the direct integration of the payment system platform with nationally or regionally controlled payment provider platform, such as the India NPCI Universal Payment Interface.

One embodiment provides for the direct integration of the payment system platform with a 3^rd party switch with direct real time push payment capabilities, such as the VISA Direct or Mastercard Send, as a means to eliminate the costs and complexity associated with traditional Issuer and Acquirer related interchange business models.

One embodiment provides for the use missed call numbers uniquely allocated to each point of sale, which when dialled, instantly replies with a One-time-PIN (OTP) which the merchant cashier can enter into the cash a register application as a means of validating a micro payment for processing and settlement using the same methodology expressed within. One embodiment provides for the cancelation of payments, where the merchant simply uses a cancelation button on a traditional cash register or USSD menu application, upon which the transaction is entirely cancelled.

One embodiment provides for the reversal of payments, where the merchant simply uses a payment reversal button on a traditional cash register or USSD menu application, upon which the transaction is reversed by entering the amount to be reversed into the application, and having the customer dial the USSD POS Code or POS Mobile Number, followed by entering the usual PIN number upon request.

One embodiment provides for a method and system where merchant point of sale is used as ATM to facilitate a cash-in and cash out functionality, where the merchant simply uses a cash-in or cash-out button on a traditional cash register or USSD menu application, upon which the transaction amount is entered into the application, followed by the customer dialling the USSD POS Code or POS Mobile Number, and entering the usual PIN number upon request.

One embodiment provides for the creation and management of virtual customer wallets, where customer wallets are connected to existing bank account, credit card or external 3rd party wallets such as cryptocurrency wallets, and configured by the customer to have funds either manually or automatically topped up, or alternatively topped up with cash at participating points of sale.

Another embodiment provides for the flexibility to integrate any suitable current or future instant payment solutions into the Mobile Payment System Platform, including Automated Instant EFT Platforms, Cryptocurrency Transfer / Remittance Solutions or the like. Thereby providing alternative 3^rd party service providers and their customers with a means to expand into previously inaccessible physical offline or online payment markets.

BRIEF DESCRIPTION OF THE DRAWINGS

The following represents a brief description of the non-limiting drawings of the invention:

Figure 1 Is a High-Level Diagram of the Payment System Architecture;

Figure 2 Is a schematic representation of the Mobile Payments System Platform at the centre of the Mobile Payments Ecosystem Participants, with the various communication interfaces and protocols used to interact with participating business partner applications; Figure 3 Illustrates the end-to-end Mobile Payments transaction flow from the time that the merchant enters (presents) the payment due, followed by the customer dialling a USSD POS CODE, receiving a USSD Menu to choose a Payment Provider and enter a PIN to Pay, followed by the Payment Provider directly receiving and processing the payment request, notifying the merchant of the transaction status, and the customer receiving a digital and / or printed receipt;

Figure 4 Illustrates the end-to-end Mobile Payments transaction flow from the time that the merchant enters (presents) the payment due, followed by the customer dialling a MISSED CALL POS NUMBER, receiving a Call Back to enter a PIN to Pay, followed by the Payment Provider directly receiving and processing the payment request, notifying the merchant of the transaction status, and the customer receiving a digital and / or printed receipt;

Figure 5 Illustrates the end-to-end Mobile Payments transaction flow from the time that the merchant enters (presents) the payment due, followed by the customer dialling a USSD POS CODE, receiving a USSD Menu to enter a PIN to Pay, followed by the Payment Provider receiving the payment request through the VISA API, processing the payment through the VISA Direct Network, notifying the merchant of the transaction status, and the customer a receiving digital and / or printed receipt;

Figure 6 Illustrates the end-to-end Mobile Payments transaction flow from the time that the merchant enters (presents) the payment due, followed by the customer dialling a USSD POS CODE, receiving a USSD Menu to enter a PIN to Pay, followed by the Payment Provider receiving the payment request through the UPI API, processing the payment through the UPI Platform, notifying the merchant of the transaction status, and the customer receiving a digital and / or printed receipt;

Figure 7 Illustrates the end-to-end Mobile Payments transaction flow from the time that the merchant enters (presents) the payment due, followed by the customer dialling a MISSED CALL POS NUMBER, receiving a Call Back to enter a PIN to Pay, followed by the Payment Provider receiving the payment request through the UPI API, processing the payment through the UPI Platform, notifying the merchant of the transaction status, and the customer receiving a digital and / or printed receipt;

Figure 8 Illustrates the end-to-end Mobile Payments transaction flow from the time that the merchant enters (presents) the payment due, followed by the customer dialling either a USSD POS Code or MISSED CALL POS NUMBER, receiving a USSD Menu to enter a PIN to Pay, followed by the Payment Provider receiving the payment request through the UPI API, processing the payment through the UPI Platform, notifying the merchant of the transaction status, and the customer receiving a digital and / or printed receipt;

Figure 9 Shows the sequence of a real-world transaction at a Traditional Merchant

POS using a Cash Register in accordance with the present disclosure;

Figure 10 Shows the sequence of a real-world transaction at a Street Merchant POS using Feature Phone in accordance with the present disclosure;

DETAILED DESCRIPTION WITH REFERENCE TO THE DRAWINGS

In the following detailed description of embodiments of the invention, reference is made to the accompanying drawings in which like references indicate similar elements, and in which is shown by way of illustration specific embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention, and it is to be understood that other embodiments may be utilized and that logical, mechanical, electrical, functional, and other changes may be made without departing from the scope of the present invention. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of the present invention is defined only by the appended claims.

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 disclosure. The appearances of the phrase“in one 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. The present disclosure provides a unique configurable process and method that enables mobile payment transactions to flow seamlessly between the Merchant POS 101 , the Customer Mobile phone 102, the Mobile Network Operator 103, 3^rd Party Payment Interfaces 105, 3^rd Party Payment Switches 106 and Payment Service Providers 104 which form an integral part of the Stakeholders Mobile Payments Ecosystem 100. The Stakeholders Mobile Payments Ecosystem 100 incorporates a system in accordance with the present disclosure as depicted in FIG. 1 and FIG. 2 with all feeding through the Mobile Payments System Platform.

In the present disclosure, each Merchant POS 101 is uniquely associated with its own USSD POS Code or Missed Call POS Number. In other words, the solution in accordance with the present disclosure provides the means to enable payments by linking every Merchant POS 101 to the Mobile Payments System Platform 150, thereby providing a Customer Mobile phone 102 with a simple digital payments channel to dial into for purposes of choosing a payment provider and confirming a POS initiated transaction request. This critical aspect makes it possible to acquire millions of Points of Sale at a fraction of the time and cost required for physical hardware terminals, including the benefit of working across mobile phones with the internet.

Additionally, the present disclosure also provides for a Customer Mobile phone 102 be used as the Customer identifying credential capable of being associated with multiple accounts from multiple participating institutions, such as banks and mobile money / wallet providers. In other words, the solution in accordance with the present disclosure provides the means to link the mobile phone number or Payer ID (unique payment identifier) to customer accounts from various funding sources (demand deposit account (DDA), savings, debit/credit card, pre-paid accounts) via a Transaction Authorisation Service 107. This structure is external to the mobile phone mobile phone 106, and avoids the need to store, handle and transmit sensitive data outside of the Payment Provider environment.

An important enabler of the system and method of this disclosure is the existing technology behind the Customer Mobile phone 102 and Mobile Network Operator 103 gateway infrastructure. This is the USSD protocol (Unstructured Supplementary Service Data protocol). The USSD protocol is a session-based communication channel exclusive to the GSM standard that is leveraged as the primary channel for the Customer Mobile phone 102 to interact with the Mobile Payments System Platform 150 to facilitate financial transaction requests. Moreover, within the USSD capabilities, the present disclosure uses USSD Pull (when the customer dials the POS code), and USSD Push when the Payment Service Provider 104 sends a PIN to Pay menu to the Customer Mobile phone 102 for approval in a real-time session. Additionally, the present disclosure provides for an alternative Missed Call mechanism, where customers can dial a Missed Call POS Number instead of a USSD POS Code. Missed Calls work by either triggering an automated instant voice channel Call Back used for PIN entry on the mobile phone keyboard (as 1234# for example), or for passing on the customer mobile number + transaction request data to the PSP, who in turn pushes a USSD PIN request directly to the customer from their side.

The Mobile Payments System Platform 150 (application engine), is the focal point for messages, exchanges and translations between the Mobile Payments System Platform 150 and the Stakeholders Mobile Payments Ecosystem 100, with various API related messaging standards used to communicate with the stakeholders on the back-end.

The XML (extensible Markup Language) based-format is used for banks and mobile network operator exchanges, and the HTTPS (Hypertext Transfer Protocol Secure) format is used for message exchanges with Stakeholders by Web Service Interface. Mobile Payments System Platform 150 transactions, in accordance with the present disclosure, combines all relevant messaging standards as end-to-end transactions.

The methods disclosed herein uses (1) USSD POS Codes or Missed Call POS Numbers, (2) Customer Mobile phone 102 data (e.g. customer's mobile phone number), (3) Merchant POS Applications 1 18 to relay transaction request data (POS ID and payment due) directly to the Mobile Payments System Platform 150, (4) a Transaction Request Service 123, (5) a User Account Service (relationship lookup using merchant POS ID, Customer mobile phone number / account ID, PSP accounts list etc) 130, (6) a Transaction Authorisation Service (referencing white / black listed users, user registration status, etc) 107, and (7) a Transaction Response Service 1 19 communication transaction status between participants.

The customer's 10-digit mobile phone number forms the basis of their account within the Mobile Payments System Platform 150, as well as a reference to the accounts they hold with participating Payment Service Providers 104. As such the Mobile ID number (mobile phone number), becomes a singular mechanism that facilitates mobile payment transactions across the entire network, either directly or indirectly to and from participating payment providers in accordance with the present disclosure.

The end-to-end process in accordance with the present disclosure preferably takes advantage of key mobile and network technologies such as USSD Pull / Push, Voice Channels (Missed Call) and SMS Text to provide a special customer experience for exchanging information to facilitate real-time offline or online payments.

The Merchant USSD POS Code or Missed Call POS Number and Customer Mobile ID (mobile phone number) serves as the major linking mechanism between the Merchant POS 101 , Customer Mobile phone 102, and Customer Payment Service Provider. This key element of the present disclosure along with the User Account Service 130 provides the means to access multiple funding sources and other related functionalities and services such as micro payments, micro loans, micro insurance, direct marketing etc.

At the centre of the Stakeholders Mobile Payments Ecosystem 100 is the Mobile Payments System Platform 150 which has been architected to integrate all the required message formats and protocols (USSD, Voice, SMS, XML, HTTPS) in a single end-to-end payment transaction to successfully communicate with the different stakeholder application systems. In addition, the Mobile Payments System Platform 150 will perform (manage) all necessary daily processes to record, reconcile & settle transactions with participating business partners.

The USSD POS Code and Missed Call POS Number Merchant Payment Methods, in accordance with the present disclosure is designed to enable merchant payment transactions at POS locations using the customer's mobile phone capabilities as a monetary instrument, without requiring dedicated hardware payment processing terminals. The major operational steps are: (1) Merchant enters (automatically or manually) the payment amount due on a POS terminal, (2) Customer initiates the payment transaction by dialling either a USSD POS Code and Missed Call POS Number, (3) Payment provider receives the transaction request from the Mobile Payments System Platform 150, and sends a PIN request directly to the customer by USSD Push menu, (4) Customer confirms payment by entering the PIN on the mobile phone, (5) Payment provider settles the payment and notifies the Merchant (by internet) and Customer (by SMS Text), (6) Merchant issues a receipt to the Customer.

A detailed description of 6 closely related alternative transaction flow scenarios follows, each illustrating the various elements of the present disclosure that comprise the overall end-to-end process. These elements are: the Merchant POS (A), the Customer Mobile phone 102 (B), the Payment Service Provider/s 104 (with or without associated Unified Payment Interfaces 105 or 3^rd Party Payment Switches) (C), the Mobile Payments System Platform 150 that synchronizes all exchanges, and validations with stakeholder applications (D), the Mobile Network Operator 103 that handles the mobile device USSD / Missed Call sessions and SMS communications (E): SCENARIO 1 : FIG. 3. This process begins when the customer opts to pay by mobile phone at the POS using the Mobile Payments System Platform 150.

Step 1 a. Cashier enters the total due into the Merchant POS Application 1 18, which is installed on a traditional Cash Register, a Smart Device, or accessed as a Web Interface or USSD Menu.

Step 1 b. The amount due including the POS ID (associated with the USSD POS Code or Missed Call POS Number) is forwarded to the Mobile Payments System Platform 150 in real time using the internet or USSD channel, where it awaits the next step.

Step 2. Customer dials the USSD POS Code displayed as a Sticker at the Merchant POS 101 . For online points of sale USSD Codes will be randomly selected and allocated (by software) to every transaction during checkout. USSD POS Codes are uniquely allocated and registered with each point of sale by a registration (button) feature within the Merchant POS Application 1 18. Smartphone users will have the option of dialling POS associated codes and numbers by scanning a QR Code with a service associated application, instead of dialling the number by hand.

Step 3. Customer mobile phone receives a USSD Menu with Payment Providers to choose from (if there is more than one), otherwise this and Step 5 step is skipped. The list of Payment Providers is collected from the User Database 121 , where the Customer mobile phone number (collected from the USSD call) is used to cross reference Customer accounts data received from the customer’s participating Payment Service Provider/s 104 through the Payment Service Provider API 1 1 1 .

Step 4. Customer chooses a Payment Provider from the USSD Menu if there is more than one, otherwise this step is skipped. Note that this step and Step 3 can be experience using Smartphone Applications regardless of the channel type for example, if Internet is not available it will default to using a USSD channel. Communication between the mobile phone and the platform in this step and Step 3 is configured to use end to end encryption when available.

Step 5. The Platform 150 forwards the transaction request data (Customer ID, Customer Account ID, Merchant ID, Payment Due) to the correct Payment Provider through the PSP API 1 1 1 . This is enabled by using the Customer ID (mobile phone number) as reference to lookup the Customer associated Payment Provider Data with the User Account Service 130 connected to the User Database 120, and authorising the transaction with the Authorisation Service 107. Step 6. The Payment Service Provider 104 pushes a USSD menu-based PIN to Pay request directly to the Customer mobile phone or Smartphone application for transaction approval.

Step 7. Customer approves the payment request by entering his/her account related PIN on the USSD menu or Smartphone application.

Step 8. The Payment Service Provider 104 settles the transaction internally with the Merchant on behalf of the Customer. Internal settlement is made possible by establishing a Mobile Payments System Platform 150 account within each participating PSP 104 that receive payments on behalf of participating Merchants, and transferring these payments to the Merchants by EFT at a later point in time (typically within 24 hours).

Step 9a. The Payment Service Provider 104 transmits the transaction status back to the Mobile Payments System Platform 150 through the Payment Service Provider API 11 1.

Step 9b. The Mobile Payments System Platform 150 forwards the transaction status to the Merchant POS 101.

Step 10a. The Merchant provides the Customer with a printed or digital receipt.

Step 10b. The Payment Service Provider 104 sends the Customer a transaction related SMS text notification.

SCENARIO 2: FIG. 4. This process is the same or different to other scenarios as follows.

Step 1 a. The same as Scenario 1 FIG. 3.

Step 1 b. The same as Scenario 1 FIG. 3.

Step 2. Customer dials a Missed Call POS Number instead of a USSD POS Code.

Step 3. Customer mobile phone gets an instant automated Call back for PIN to Pay entry, instead of a USSD Menu with Payment Provider options. In this scenario customers (with more than one payment provider) will pre-select a Payment Provider by way of a USSD or Smartphone application before dialling the Missed Call POS Number, or a default Payment Provider will be used. Step 4. The PIN is entered on the mobile phone keyboard for transmission over a voice channel instead of a USSD or Internet channel.

Step 5. The Platform 150 forwards the transaction request data (Customer ID, Customer Account ID, Merchant ID, Payment Due & Customer PIN) to the correct Payment Provider through the PSP API 1 1 1 . This is enabled by using the Customer ID (mobile phone number) as reference to lookup the Customer associated Payment Provider Data with the User Account Service 130 connected to the User Database 120, and authorising the transaction with the Authorisation Service 107.

Step 6. The Payment Service Provider 104 settles the transaction internally with the Merchant on behalf of the Customer. Internal settlement is made possible by establishing a Mobile Payments System Platform 150 account within each participating PSP 104 that receive payments on behalf of participating Merchants, and transferring these payments to the Merchants by EFT at a later point in time (typically within 24 hours).

Step 7a. The Payment Service Provider 104 transmits the transaction status back to the Mobile Payments System Platform 150 through the Payment Service Provider API 1 1 1 .

Step 7b. The Mobile Payments System Platform 150 forwards the transaction status to the Merchant POS 101 .

Step 8a. The Merchant provides the Customer with a printed or digital receipt.

Step 8b. The Payment Service Provider 104 sends the Customer a transaction related SMS text notification.

SCENARIO 3: FIG. 5. This process is the same or different to other scenarios in the following ways.

Step 1 a. The same as Scenario 1 FIG. 3.

Step 1 b. The same as Scenario 1 FIG. 3.

Step 2. The same as Scenario 1 FIG. 3. Step 3. Customer mobile phone gets an instant USSD PIN to Pay menu, instead of a Missed Call. In this scenario customers (with more than one payment provider) will pre-select a Payment Provider by way of a USSD or Smartphone application before dialling the USSD POS Code, or a default Payment Provider will be used.

Step 4. Customer approves the payment request by entering his/her account related PIN on the USSD menu or Smartphone application.

Step 5. The Platform 150 forwards the transaction request data (Customer ID, Customer Account ID, Merchant ID, Payment Due & Customer PIN) to the correct Payment Provider through the VISA API 134. This is enabled by using the Customer ID (mobile phone number) as reference to lookup the Customer associated Payment Provider Data with the User Account Service 130 connected to the User Database 120, and authorising the transaction with the Authorisation Service 107.

Step 6. The Payment Service Provider 104 settles the transaction with the Merchant on behalf of the Customer by way of the VISA Direct (or the like) Switch. External instant low cost settlement (where the Merchant account is with a different Payment Provider than the Customer), is made possible through a VISA Direct Push Payment type functionality instead of using traditional card- based pull type switches. In this scenario the Mobile Payments System Platform 150 is able to establish an external account (outside the Customer account Payment Provider), for purposes of receiving customer payments on behalf of participating Merchants, and transferring these payments to the Merchants by EFT at a later point in time (typically within 24 hours).

Step 7a. The Payment Service Provider 104 transmits the transaction status back to the Mobile Payments System Platform 150 through the VISA API 134.

Step 7b. The same as Scenario 2 FIG. 4.

Step 8a. The same as Scenario 2 FIG. 4.

Step 8b. The same as Scenario 2 FIG. 4.

SCENARIO 4: FIG. 6. This process is the same or different to other scenarios in the following ways.

Step 1 a. The same as Scenario 1 FIG. 3. Step 1 b. The same as Scenario 1 FIG. 3.

Step 2. The same as Scenario 1 FIG. 3.

Step 3. The same as Scenario 3 FIG. 5.

Step 4. The same as Scenario 3 FIG. 5.

Step 5. The Platform 150 forwards the transaction request data (Customer ID, Customer Account ID, Merchant ID, Payment Due & Customer PIN) to the correct Payment Provider through a 3^rd Party Payment Interface 105 API 133, such as the India NPCI UPI for example. This is enabled by using the Customer ID (mobile phone number) as reference to lookup the Customer associated Payment Provider Data with the User Account Service 130 connected to the User Database 120, and authorising the transaction with the Authorisation Service 107.

Step 6. The Payment Service Provider 104 settles the transaction with the Merchant on behalf of the Customer by way of the 3^rd Party Payment Interface 105 (or the like) Switch. External instant low cost settlement (where the Merchant account is with a different Payment Provider than the Customer), is made possible through the 3^rd Party Payment Interface 105 Switch instead of using traditional card-based pull type switches. In this scenario the Mobile Payments System Platform 150 is able to establish an external account (outside the Customer account Payment Provider), for purposes of receiving customer payments on behalf of participating Merchants, and transferring these payments to the Merchants by EFT at a later point in time (typically within 24 hours).

Step 7a. The Payment Service Provider 104 transmits the transaction status back to the Mobile Payments System Platform 150 through the 3rd Party Payment Interface API 133.

Step 7b. The same as Scenario 2 FIG. 4.

Step 8a. The same as Scenario 2 FIG. 4.

Step 8b. The same as Scenario 2 FIG. 4.

SCENARIO 5: FIG. 7. This process is the same or different to other scenarios in the following ways. Step 1 a. The same as Scenario 1 FIG. 3.

Step 1 b. The same as Scenario 1 FIG. 3.

Step 2. The same as Scenario 2 FIG. 4.

Step 3. The same as Scenario 2 FIG. 4.

Step 4. The same as Scenario 2 FIG. 4.

Step 5. The same as Scenario 4 FIG. 6.

Step 6. The same as Scenario 4 FIG. 6.

Step 7a. The same as Scenario 4 FIG. 6.

Step 7b. The same as Scenario 2 FIG. 4.

Step 8a. The same as Scenario 2 FIG. 4.

Step 8b. The same as Scenario 2 FIG. 4.

SCENARIO 6: FIG. 8. This process is the same or different to other scenarios in the following ways.

Step 1 a. The same as Scenario 1 FIG. 3.

Step 1 b. The same as Scenario 1 FIG. 3.

Step 2. Customer dials a USSD POS Code or Missed Call POS Number.

Step 3. The Platform 150 forwards the transaction request data (Customer ID, Customer Account ID, Merchant ID, Payment Due) to the correct Payment Provider through a 3^rd Party Payment Interface 105 API 133, such as the India NPCI UPI for example. This is enabled by using the Customer ID (mobile phone number) as reference to lookup the Customer associated Payment Provider Data with the User Account Service 130 connected to the User Database 120, and authorising the transaction with the Authorisation Service 107.

Step 4. The Payment Service Provider 104 pushes a USSD menu-based PIN to Pay request directly to the Customer mobile phone or Smartphone application for transaction approval.

Step 5. Customer approves the payment request by entering his/her account related PIN on the USSD menu or Smartphone application.

Step 6. The same as Scenario 4 FIG. 6.

Step 7a. The same as Scenario 4 FIG. 6.

Step 7b. The same as Scenario 2 FIG. 4.

Step 8a. The same as Scenario 2 FIG. 4.

Step 8b. The same as Scenario 2 FIG. 4.

Beyond the above variations of this embodiment, multiple additional transaction related functional use cases can flow, including a method for reversing payments where the Cashier clicks a Reverse Payment button, followed by entering the amount to be reversed on the POS Application, and having the Customer initiate a transaction as usual for payment transactions.

Additionally, the embodiment makes it possible for physical points of sale be used as ATM’s for purposes of withdrawing or depositing hard currency, simply by having the Cashier enterthe cash amount to be withdrawn or deposited on the POS Application, followed by the same transaction steps when making payment type transactions.

It is clear that many modifications and variations of this embodiment may be made by one skilled in the art without departing from the spirit of the novel art of this disclosure. These modifications and variations do not depart from the broader spirit and scope of the invention, and the examples cited here are to be regarded in an illustrative rather than a restrictive sense.

Claims

CLAIMS:

1 . A method for a merchant to accept and process a payment for a transaction from a customer mobile phone, the method comprising:

Allocating a unique mobile phone point of sale (POS) number such as a USSD Code or Missed Call number, to a point of sale (POS) terminal at a merchant location that is displayed, registered and directly associated with the particular point of sale (POS) terminal;

providing a point of sale (POS) terminal at a merchant location having stored and registered the unique mobile point of sale number therein as a terminal identifier unique to the terminal and the merchant;

entering a transaction amount into the POS terminal;

generating and sending the transaction request from the POS terminal to the payment system platform;

generating a USSD pull live session from the payment system platform on the customer mobile phone when the customer dials the point of sale (POS) USSD Code;

selecting a payment provider (financial account) on the customer's mobile phone;

transmitting via the mobile phone the customer mobile phone number, financial account selection, and personal identification number (PIN) to the payment system platform;

transmitting the customer mobile phone number, financial account number, personal identification number (PIN), merchant identification number and transaction amount from the payment system platform to the payment provider to authorize the transaction;

upon verification of account and sufficient account balance, the institution debiting the financial account; and

sending an approval message to the customer's mobile phone and the merchant POS terminal via the payment system platform.

2. The method of processing according to claim 1 wherein the customer dials either a physical point of sale number (offline), or a digital point of sale number (online).

3. The method of processing according to claim 1 wherein the customer scans a QR Code or the like type code, enabling customers with smart devices to automate the dialling process.

4. The method of processing according to claim 1 wherein customer dials a point of sale (POS) Missed Call Number instead of a point of sale (POS) USSD Code.

5. The method of processing according to claim 4 wherein the dialled Missed Call Number triggers an automated Call-back response, providing the customer with the means to enter a personal identification number (PIN) on the mobile phone transmitted through a voice channel.

6. The method of processing according to claim 1 wherein the POS terminal comprises either a traditional cash register, a smart device or a feature phone.

7. The method of processing according to claim 1 wherein the merchant can reverse a payment by entering the amount on the terminal, and having the customer dial the point of sale (POS) number, selecting a payment provider and entering a personal identification number (PIN).

8. The method of processing according to claim 1 wherein the merchant point of sale (POS) can be used as an ATM by entering the amount to deposit or withdraw on the terminal, and having the customer dial the point of sale (POS) number, selecting a payment provider and entering a personal identification number (PIN).

9. A system for processing a payment for a transaction with a merchant by a customer via a customer's mobile phone, the system comprising:

means for providing a point of sale (POS) terminal at a merchant location, displaying and having stored therein an associated USSD Code or Missed Call Number as identifier unique to that terminal;

means for entering a transaction amount into the POS terminal;

means for sending the transaction request to the payment system platform;

means for generating a USSD pull live session from the payment system platform on the customer mobile phone when the customer dials the point of sale (POS) USSD Code;

means for selecting a financial account in the USSD menu on the customer's mobile phone for transmission to the payment system platform;

means for entering a personal identification number (PIN) in a USSD menu on the customer’s mobile phone for transmission to either the payment system platform or directly to the payment provider.

means for entering a personal identification number (PIN) on the customer mobile phone during a Call-back session for transmission to either the payment system platform or directly to the payment provider.

means for transmitting the customer mobile phone number, financial account number, personal identification number (PIN), merchant identification number and transaction amount from the payment system platform to the payment provider to authorize the transaction;

means for debiting the customer financial account upon verification of account balance; means for sending an approval message to the customer's mobile phone and to the merchant via the POS terminal.

10. The system according to claim 9 wherein the customer dials either a physical point of sale number (offline), or a digital point of sale number (online).

1 1. The system according to claim 9 wherein the customer dials a point of sale (POS) Missed Call Number instead of a point of sale (POS) USSD Code.

12. The system according to claim 1 1 wherein the dialled Missed Call Number triggers an automated Call-back response, providing the customer with the means to enter a personal identification number (PIN) on the mobile phone transmitted through a voice channel.

13. The system according to claim 9 wherein the merchant can reverse a payment by entering the amount on the terminal, and having the customer dial the point of sale (POS) number, selecting a payment provider and entering a personal identification number (PIN).

14. The system according to claim 9 wherein the merchant point of sale (POS) can be used as an ATM by entering the amount to deposit or withdraw on the terminal, and having the customer dial the point of sale (POS) number, selecting a payment provider and entering a personal identification number (PIN).

15. A machine-readable tangible medium having stored thereon a set of instructions which when executed perform a method comprising:

providing a point of sale (POS) terminal at a merchant location, displaying and having stored therein an associated USSD Code or Missed Call Number as identifier unique to that terminal;

entering a transaction amount into the POS terminal;

sending the transaction request to the payment system platform;

selecting a financial account in the USSD menu on the customer's mobile phone for transmission to the payment system platform;

entering a personal identification number (PIN) in a USSD menu on the customer’s mobile phone for transmission to either the payment system platform or directly to the payment provider. entering a personal identification number (PIN) on the customer mobile phone during a Call-back session for transmission to either the payment system platform or directly to the payment provider.

16. The machine readable medium according to claim 15 wherein the customer dials either a physical point of sale number (offline), or a digital point of sale number (online).

17. The machine readable medium according to claim 15 wherein the customer dials a point of sale (POS) Missed Call Number instead of a point of sale (POS) USSD Code.

18. The machine readable medium according to claim 17 wherein the dialled Missed Call Number triggers an automated Call-back response, providing the customer with the means to enter a personal identification number (PIN) on the mobile phone transmitted through a voice channel.

19. The machine readable medium according to claim 15 wherein the merchant can reverse a payment by entering the amount on the terminal, and having the customer dial the point of sale (POS) number, selecting a payment provider and entering a personal identification number (PIN).

20. The machine readable medium according to claim 15 wherein the merchant point of sale (POS) can be used as an ATM by entering the amount to deposit or withdraw on the terminal, and having the customer dial the point of sale (POS) number, selecting a payment provider and entering a personal identification number (PIN).