Processing

Please wait...

Settings

Settings

Goto Application

1. WO2020198764 - METHOD & SYSTEM FOR TERMINAL CODED MOBILE PAYMENTS

Note: Text based on automatic Optical Character Recognition processes. Please use the PDF version for legal matters

[ EN ]

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 3rd 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 3rd 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 3rd 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 3rd 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, 3rd Party Payment Interfaces 105, 3rd 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 3rd 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 3rd 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 3rd 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 3rd 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 3rd 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.