AU2017101144A4 - An electronic transaction system using long-lived proxy details for business transaction with a merchant - Google Patents

Abstract

Abstract The present invention there is provides an electronic transaction system for executing machine code for a proxy payment method comprising the steps of: receiving payment details from a user; issuing proxy details; receiving a first payment request from a merchant with the proxy details; verifying the first payment request with the proxy details; generating a second payment request to one or more financial institute; receiving payment confirmation from the financial institute; and wiring payment to the merchant. 1 0 2 \1 Payment Details 11. 112 11 0i--itCreate Proxy Details ~~rx Details II Setup PaymenA Proxy D)etails 100 " 116-- " Proxy Details 118" Figure 2 Paye*nt Request with Proxy Details 134 Lookup real details based on proxy details Validate that Merchant is Authorised Payment Request with ReaI Details d a tPayment142 Payment 144 Figure 3

Description

- 1 - - 1 - 2017101144 22 Aug 2017

AN ELECTRONIC TRANSACTION SYSTEM USING LONG-LIVED PROXY DETAILS FOR BUSINESS TRANSACTION WITH A MERCHANT TECHNICAL FIELD

[0001] The invention relates to a system, method, and computer program for intermediate transaction service. In particular, the present invention relates to a system, method or computer program for an intermediate transaction service to allow a user to create long-lived proxy credit card details to set up direct debits with a merchant. BACKGROUND.

[0002] Direct debit allows merchants to automatically deduct payments from a customer’s bank account / credit card. Unfortunately, these processes can be quite laborious for the customer (and merchant) to set up, and credit cards and bank accounts can expire, get stolen, or change, meaning that the customer has to set all of their direct debits up again, every time their details change. This also means that the merchant may attempt to charge unrequited payments against details that are no longer valid, and have to follow up with their customer to get the details updated.

[0003] Additionally, some customers may be concerned about setting up direct debits, citing concerns about sharing their details with all different merchants, and the possibility of their accounts still being charged after they have cancelled their service.

[0004] Generally, the prior art processes may involves providing the bank account (with an appropriate authorization) or credit card details to the payee, for them to store, and charge as needed. This system has the following draw backs: 1. It can be time-consuming (and potentially error - prone) for payers and payees to set up the Direct Debit; 2. There is very little visibility / monitoring of the payments that the payer has set up; 3. Payment details can and do change, and when they do, the payer has to update all of their direct debits, which is a very time-consuming process; 2017101144 22 Aug 2017 4. With the lack of monitoring (see point 2), it is easy for payers to forget to update their details with some of their payees, resulting in failed payments, and potentially additional charges for the payee and/or payer; and 5. With the lack of monitoring (see point 2), it is difficult for payees to ensure that payers are not charging them more, or for longer, than they are entitled to (e.g. if the payee continues charging the payer after the payer has discontinued use of the payee’s services) [0005] A known alternative to Direct Debits are “Standing Orders”, where the payer automatically sends the payee a set amount on a regular schedule. However, this set up is not especially useful for charges that vary in amount or frequency of charges.

[0006] US Patent No. 9,105,021 discloses an electronic device including an input/output interface operable to receive an input from a user and communicate an output to the user, a transceiver operable to electronically communicate with a computer network, a computer processor operable to execute instructions, and a memory storage operable to store the instructions. The memory storage further comprised a program module that is operable to: receive credentials for a proxy payment account. The proxy payment account was linked to a primary payment account but not linked directly to a method of payment underlying the primary payment account. Payment at a Point of Sale (POS) could be made using the received credentials.

[0007] US Published Patent Application No. 20140019352 discloses a method implemented on a proxy wallet transaction authentication processor. This method comprised the steps of: receiving a transaction authentication request associated with a proxy payment identifier; determining that the proxy payment identifier was associated with an electronic wallet; obtaining proxy payment preferences stored with the electronic wallet; determining a payment identifier associated with the electronic wallet based on the proxy payment preferences; and authenticating the transaction using the obtained payment identifier associated with the electronic wallet. 2017101144 22 Aug 2017 [0008] US Patent No. 8,418,918 discloses a system and method for securing a financial transaction using a proxy code, which is assigned a transaction account number. An account issuer permanently assigns the proxy code to a transaction account correlated to the transaction device. The proxy code is uploaded onto the transaction device for later use in completing a transaction request. During transaction completion, the proxy code is provided to a merchant system in lieu of any sensitive account information. Since the proxy code is permanently assigned, the number needs not be changed or updated on the merchant system once uploaded into a payment device or merchant database. The account issuer may manipulate the sensitive account information without the need to alter the information stored on the merchant database. Since the proxy code contains no sensitive information, the sensitive information related to the transaction account is secured from theft.

SUMMARY

[0009] PROBLEMS TO BE SOLVED

[0010] The present invention may generally relate to a proxy payment method for business transaction between the user and a merchant.

[0011] It is, therefore, an object of the present invention to provide a new and novel electronic transaction system.

[0012] Other objectives and advantages will become apparent when taken into consideration with the following specification and drawings.

[0013] It is also an object of the present invention to overcome or ameliorate at least one of the disadvantages of the prior art, or to provide a useful alternative.

[0014] It is a first aspect of the present invention to provide an electronic transaction system for executing machine code for a proxy payment method comprising the steps of: receiving payment details from a user; issuing proxy details; 2017101144 22 Aug 2017 receiving a first payment request from a merchant with the proxy details; verifying the first payment request with the proxy details; generating a second payment request to one or more financial institute; receiving payment confirmation from the financial institute; and wiring payment to the merchant.

[0015] Preferably, the payment details comprises a name of the merchant, at least one payment method, and an amount of payment.

[0016] Preferably, the proxy details is in the format of a credit card number or bank account number.

[0017] 4. Preferably, the payment method comprising credit card payment or electronic fund transfer.

[0018] Preferably, the verifying step comprises verifying the proxy details are issued by the electronic transaction system.

[0019] Preferably, the generating second payment request step comprises searching the payment method, generating one or more payment requests in accordance with the payment method, and forwarding the second payment request to the financial institute.

[0020] Preferably, the proxy payment method further comprises the step of sending one or more notification indicating the first payment request has been successfully proceeded or not.

[0021] Preferably, the proxy payment method further comprises the step of recording transactions processed. 2017101144 22 Aug 2017 [0022] 9. Preferably, the proxy payment method further comprises the step of filtering the transactions and displaying on a payment transaction interface.

[0023] Preferably, the proxy payment method further comprises the step of providing a merchant details interface, wherein the merchant details interface comprises a component for approving or rejecting a payment for a merchant.

[0024] Preferably, the proxy payment method further comprises the step of creating a list of merchants, wherein the electronic transaction system is adapted to reject transaction with merchant on the list.

[0025] Preferably, the proxy details have a long-lived expiry date.

BRIEF DESCRIPTION OF THE FIGURES

[0026] Figure 1 is schematic diagram of a system of an embodiment of the present invention; [0027] Figure 2 is a sequence diagram of a method for creating proxy details through the system of Figure 1; [0028] Figure 3 is a sequence diagram of a method for requesting a payment through the system of Figure 1; [0029] Figure 4 is an interface for creating a set of proxy payment details for use in the system of Figure 1; [0030] Figure 5 is a user interface for viewing proxy payment details for use in the system of Figure 1; [0031] Figure 6 is a user interface for updating proxy payment details for use in the system of Figure 1; [0032] Figure 7 is an interface for setting up a new “Direct Debit” for use in the system of Figure 1; [0033] Figure 8 is a user interface for viewing a user’s Direct Debits for use in the system of Figure 1; 2017101144 22 Aug 2017 [0034] Figure 9 is a user interface for viewing a user’s payments processed through the system of Figure 1; and [0035] Figure 10 is a user interface for viewing a user’s payments for a single merchant through the system of Figure 1.

DESCRIPTION OF THE INVENTION

[0036] In order to pay bills automatically, a customer or “payer” will set up an agreement with a service provider, or “payee”, whereby they provide their payment details (generally either bank account or credit card information) to the payee, and then allow the payee to draw the funds directly from the payer’s account. These arrangements or processes are commonly referred to as a “Direct Debit” (although, strictly speaking, Direct Debit may be considered to refer only to payments via Bank Account, it is commonly used to refer to arrangements with Credit Cards as well, and it is this terminology this specification uses). These Direct Debits are typically used for recurring charges, and especially ones that can vary from payment to payment (such as Electricity charges that can vary month to month). Customers will typically have many of these payments set up, for their various bills.

[0037] In a first preferred embodiment of the present invention, there is provided a system whereby a user can create proxy payment details, linked to real details, to provide to merchants for the purposes of setting up a “Direct Debit”, being a mechanism to allow the merchant to draw funds from the payee’s account, via the system looking up the real details, and drawing the funds from the real details on behalf of the merchant. In a preferred embodiment, the proxy details resembling, as closely as possible, real credit card or bank account details, to work with merchant’s existing systems.

[0038] In one embodiment of the present invention, the system is adapted to provide a customer a set of virtual, proxy credit card / bank account details. In a preferred embodiment, these details will either never expire, (or at least expire far later than ordinary credit card details will). This is known to a person skilled in the art that 2017101144 22 Aug 2017 the proxy details have a long-lived expiry date. In another embodiment, these details will expire when it is used for one time only. The system may issue a new number for the next transaction.

[0039] Reference is now made to Figure 1 showing a system 10 of an embodiment of the present invention. The system 10 comprises a terminal 18 for accepting one or more payment methods such as credit or debit card 12, bitcoins 14, or bank transactions 16. The terminal 18 can request one or more proxy account details from a server 20 for payment of direct deposit payment or any other kind of transaction. The direct deposit payment may include, but not limited to utilities payment such as gas 22, electricity 24, and water 26. The system 10 may be to handle direct debit for foreign merchants, such as virtual private network service provider 28, cloud computing service providers, etc. The system 10 may issue proxy credit card / bank account details for online or offline shopping 30.

[0040] In one embodiment system 10 is adapted to work with the standard direct debit forms that merchants use and in another embodiment the merchant may use a simple interface instead.

[0041 ] In yet another embodiment, the system 10 may allow a user to set or change an expiry date and / or expiry conditions. For example, the credit card or bank details may expire after three used or after all the credit spent. In another embodiment, the condition involves an addition of a “whitelist” allowing a user to restrict which merchants are allowed to charge them on a particular proxy details.

[0042] The system of an embodiment of the present invention allows the use will link these proxy details to their actual credit card / bank account details. In one preferred embodiment, a user may link one or more payment method details to these proxy details. This will allow a user to link proxy details to multiple payment methods. The payment methods include, but not limited to, third party transaction services, such as Stripe, PayPal, BPay, etc, credit / debit cards, gift cards, vouchers, coupons, banking accounts, etc. These payment facilities may release or accept payment 2017101144 22 Aug 2017 [0043] In another embodiment, the system 10 allows the user set the percentage to charge each payment method, such as partitioning the payment methods for one transaction. For example, a client may use the proxy details to pay a water bill of $100. The system 10 may take $50 from a Visa credit card of the client, $25 from a Master credit card, and $20 from a gift card and $5 from a coupon. The client may set a goal for the system 10 which can optimise the partition of payment method for the client.

[0044] In another embodiment, each partition may have a different type of currencies. For example, a partition of the payment may come from an Australian dollars account, another partition of the payment may come from an US dollars account, and another partition of the payment may come from bitcoins.

[0045] Reference is now made to Figure 2 which provides a sequence diagram of a method 100 for creating Proxy Details through Indirect Debit of the system 10 of Figure 1. The Creating Proxy Details method 100 of the present invention will be implement in the system 10, which provides one or more interface for the customer 102 to carry out the step 110 of providing payment details to the system.

[0046] In the Providing Payment Details Step 110, the system 10 first provides the Add New Payment interface 38 as shown in Figure 4. The Add New Payment interface 30 provides a Name textbox 32 for a user to set the identity of the payment method. The user may then select the type of the payment method 34. In the example shown in Figure 4, there are two types of payment methods for the user to select - credit card 36, or bank account 38. In another embodiment, the Add New Payment interface 38 may provide other types of payment methods such as bitcoin, gift card, stripe, voucher, or coupons, etc.

[0047] In the example as shown in Figure 4, the Credit Card option 36 is selected. The lower region of the Add New Payment interface 38 displays the corresponding text boxes for the user to input the Credit Card details including Card Number 40, Card Name 43, Expiry date 44, and the Verification Number 46. In another embodiment when the Bank Account option 38 is selected, the lower region of the Add New Payment interface will display the corresponding text boxes for the user to input the Bank Account details, including Bank State Branch Number, Account Number, Account 2017101144 22 Aug 2017

Name, Bank, Branch, and Bank Address, etc. In another embodiment where the user is allowed to select other payment methods such as Credit Card, the lower region of the Add Payment interface 38 will display the corresponding input text boxes for the user to input the relevant payment details.

[0048] System 10 of the present invention is adapted to display the payment details entered by the user in a Payment Details Interface 50 as shown in Figure 5. The Payment Details interface 50 displays a list of payment methods entered by the user. The user may view the list of payment methods 52 and their details through the Payment Details interface 50. The Payment Details Interface 50 also provide buttons for the user to add payment method, update payment method, or delete a payment method.

[0049] In one embodiment as shown in Figure 5, the Add Payment Method button 54 is placed at the top of the Payment Details Interface. When the Add Payment Method button 54 is clicked by a user, the system 10 will take the user back to the Add New Payment interface 30 as shown in Figure 5 for adding a new payment method.

[0050] In one embodiment of a preferred embodiment of the present invention, the system 10 provides an Update button on each of the payment method in the Payment Details interface 50 as shown in Figure 5. In this example, the Update button 54 is at the bottom of each payment method. In another embodiment, the system 10 provides a delete button on each payment method, so that a user may delete a payment method from the system 10 by clicking the delete button.

[0051] When a user clicks on the Update button 54 on the Payment Details Interface 50 as shown in Figure 5, system 10 will direct the user to the Update Payment Method Interface 60 as shown in Figure 6. The Update Payment Method Interface 60 shown in Figure 6 is very similar to the Add Payment Method Interface 30 shown in Figure 4. The Update Payment Method Interface 60 will have the data of the existing payment method populated in all the text boxes for the user to review and update. After the user finish updating the text boxes, the user may click on the Submit button 62 to submit the update to the system 10. System 10 will then update the corresponding record in the database, and display the updated information in the Payment Details Interface 50. 2017101144 22 Aug 2017 [0052] In one embodiment, the system 10 will keep a journal of all update action submitted to the system 10 such that a user may track all previous update information.

[0053] Alternatively, if the user would like to abandon the update, the system 10 provides a Cancel button 64 on the Update Payment Method Interface 60 shown in Figure 6. When a user clicks on the Cancel button, the system 10 will direct a user back to the Payment Details interface as shown in Figure 5 but will not update any record in the system 10.

[0054] After all the payment details are stored in the system 10 in Providing Payment Details Step 110, the system 10 will proceed to Create Proxy Details Step 112. In the Create Proxy Details Step 112, the system 10 will generate the proxy details such as credit card numbers, financial institute account details, digital wallet account number, or gift card / voucher number which a user may use to make payments. In one embodiment, the user may choose one or more proxy details for the system 10 create. In another embodiment, system 10 will only create one set proxy details per user.

[0055] Once the system 10 create the proxy details in Create Proxy Details Step 112, the system 10 will forward the proxy details to the user in Forward Proxy Step 114. In one embodiment, the proxy details will be displayed on the screen of the terminal where a user may view them. In other embodiments, the proxy details may also be forwarded to the user in other secured channels such as encrypted emails, SMS message, registered post, etc.

[0056] When the user obtained the proxy details from Forward Proxy Details Step 114, a user may proceed to setup payment in Setup Payment Step 116. In the Setup Step 116, the system 10 will direct the user to the Add New Merchant Interface 70 as shown in Figure 7. The Add New Merchant Interface 70 allows a user to add or associate a merchant to a payment method using the proxy details provided by the system 10. The Add New Merchant Interface 70 comprises a plurality of input components for user to input Merchant Name 72, the Customer Reference 74, and the proxy details 76. After a user inputs all the information for adding a new merchant, the user may click on the Save button 77 or the user may cancel the action by clicking on the Cancel button 78.

[0057] After a user adds the merchant details to the system 10, the system will display the merchant details to the user through a Merchant Details Interface 80 as shown in Figure 8. The Merchant Details Interface 80 list all the merchant details in one or more of the merchant details boxes 82. On top of the Merchant Details Interface 80, there is provide an Add New Merchant button 84. When a user clicks on the Add New Merchant button 84, the system 10 will take the user to the Add New Merchant Interface 70. 2017101144 22 Aug 2017 [0058] In each of the merchant details box 82, there is displayed the Merchant Name 85. The Merchant Name 85 is an active element, such as a hyperlink or button. When a user clicks on the Merchant Name 85, the system 10 will direct the he to the Merchant Transaction Interface 92 as shown in Figure 10 which lists all the transactions carried out with that particular merchant.

[0059] The merchant details box 82 further provides the transaction details set up with the merchant, including the status of the transaction, the customer reference number, payment method, total payment, etc. The merchant details box 82 also provide an iconic symbol representing the current status 86 of the transaction such that the user may easy recognise the current status. If the current status 86 is “Waiting” for the user’s decision, there will be a question mark icon on top of the merchant details box 82, an Approve button 87 and Decline button 88 displayed at the bottom of the merchant details box. If the current status 86 is “Approved”, there will be a tick icon displayed at the top of the merchant details box 82 and a Decline button 88 displayed at the bottom of the merchant details box. If the current status 86 is “Declined”, there will be a cross icon at the top of the merchant details box 82, and an Approve button at the bottom of the merchant details box. In another embodiment, there will be provided an Update Merchant button on the merchant details box for the user to update the merchant details. In another embodiment, there will be provide a Delete button on the merchant details box for the user to remove the user from the merchant list.

[0060] In a further preferred embodiment, the system 10 is adapted to allow users view all of their transactions processed through the system. The system 10 provides a Transaction List Interface 90 as shown in Figure 9 for a user to view the overall transactions processed or pending in the system. A user may search or filter these 2017101144 22 Aug 2017 transactions by the date, status, merchant name, reference number, description, payment amount, payment method, etc.

[0061] Preferably, system 10 is adapted to allow users to view all of their transactions for a single merchant. Figure 10 shows a Merchant Transaction Interface 92. The Merchant Transaction Interface 92 is an example of a filtered results from the Transaction list Interface 90, in which the overall transactions are filtered by merchant name.

[0062] Once the user input the merchant details through the Setup Payment Step 116, the user may send the proxy details for the merchant in Step 118. When a merchant charges a user on the proxy details whether it be a credit card details or bank account details, the system 10 will check whether the merchant has been setup or not. This process will now describe in more details with reference to the sequence diagram 130 of a method for a merchant requests a payment through the system 10 of an embodiment of the present invention as shown in Figure 3.

[0063] When setting up the direct debit, the customer can use the proxy details instead of their actual payment method details.

[0064] These proxy details will be stored by the merchant for future use. When the merchant attempts to charge against the proxy details, the system will look up the linked, real details, and charge the payment against those details.

[0065] When the customer’s real details change, they need only update the details in the system, so that it points to their new details. Subsequent payment requests from merchants to the system, using the same proxy details, will now be charged against the updated details.

[0066] A customer is able to set up a whitelist of authorised merchants. If the customer has a whitelist, only merchants authorised included in the whitelist will have their payments processed. Any customers not in the whitelist will be declined. 2017101144 22 Aug 2017 [0067] A customer is able to setup a blacklist of unauthorised merchants. Any payment request from a merchant in the customer’s blacklist will be declined.

[0068] Reference is now made to Figure 3 showing the sequence diagram 130 of a method for a merchant requests a payment through the system 10 after the user passed the proxy details to a merchant. When a merchant receives proxy details from a user, the merchant may make a payment request with proxy details to the system 10 through Request Payment Step 134.

[0069] When the system 10 receives a payment request with the proxy details, it will look up the records stored in the system based on the proxy details. If the system 10 cannot locate a matching record, the system will send a payment decline signal to the merchant indicating that the payment request is declined.

[0070] After the record is retrieved, the system 10 will validate that the merchant is authorised in the Validation Step 138. In the Validation Step 138, the system 10 will match the merchant name, payment method, payment amount. The system 10 will also check whether the user has approved the payment as well. If there is any discrepancy, the system 10 will send a payment decline signal to the merchant indicating that the payment request is declined.

[0071 ] On the system 10 successfully validates the payment request with the proxy details, the system will look up the payment method provided by the user. The payment method may refer to bank card or account from a financial institute such as a bank 132. The system 10 then send a payment request with the bank card or account details to the financial institute to pay the account of the owner of the system 10 in Payment Request Step 140. The financial institute will then approve or decline the request. If the financial institute declines the payment request, the system 10 will then decline the payment request made by the merchant 106. If the bank successfully approves the payment in the Payment Step 142, the system 10 will approve the payment to the merchant 106 in Payment Step 144 to complete the transaction.

[0072] Regardless of whether the payment has been declined or accepted, the system 10 will store the transaction in its record. The user may set up a preference to 2017101144 22 Aug 2017 have a notification send to him or her regarding to the payment or decline of a transaction. The notification may be sent out to different communication channel such as SMS, emails, etc.

[0073] In another embodiment of the present invention, the payment method may comprise a number of different form of payment, such as bank card, bank account, gift card, voucher, bitcoin, etc. The user may also set multiple forms of payment in a payment method. For example, a user may set up to pay an electricity bill with a visa card and a master card, where the visa card is limit to $500 while the master card is limited to $1000.

[0074] In one embodiment, the system 10 will not receive any payment from the bank. System 10 will prepare a new payment request form to forward to the bank requesting the bank directly pay the requested amount to the merchant 106. Further, when the system 10 receives a payment request from the merchant 106, the system may break the total request amount into smaller portions. Based on the payment method set up by the user, the system 10 may prepare a payment request for each of the smaller portions of payments and direct the financial institutes to pay directly to the merchant 106.

[0075] Although the invention has been described with reference to specific examples, it will be appreciated by those skilled in the art that the invention may be embodied in many other forms, in keeping with the broad principles and the spirit of the invention described herein.

[0076] The present invention and the described preferred embodiments specifically include at least one feature that is industrial applicable.

Claims (12)

1. An electronic transaction system for executing machine code for a proxy payment method comprising the steps of: receiving payment details from a user; issuing proxy details; receiving a first payment request from a merchant with the proxy details; verifying the first payment request with the proxy details; generating a second payment request to one or more financial institute; receiving payment confirmation from the financial institute; and wiring payment to the merchant.

2. An electronic transaction system of Claim 1, wherein the payment details comprises a name of the merchant, at least one payment method, and an amount of payment.

3. An electronic transaction system of Claim 1 or Claim 2, wherein the proxy details is in the format of a credit card number or bank account number.

4. An electronic transaction system of Claim 2, wherein the payment method comprising credit card payment or electronic fund transfer.

5. An electronic transaction system of any one of Claim 1 to 4, wherein the verifying step comprises verifying the proxy details are issued by the electronic transaction system.

6. An electronic transaction system of any one of Claims 2 to 5, wherein the generating second payment request step comprises searching the payment method, generating one or more payment requests in accordance with the payment method, and forwarding the second payment request to the financial institute.

7. An electronic transaction system of any one of Claims 1 to 6, wherein the proxy payment method further comprises the step of sending one or more notification indicating the first payment request has been successfully proceeded or not.

8. An electronic transaction system of any one of Claims 1 to 7, wherein the proxy payment method further comprises the step of recording transactions processed.

9. An electronic transaction system of Claim 8, wherein the proxy payment method further comprises the step of filtering the transactions and displaying one payment transaction interface.

10. An electronic transaction system of any one of Claims 1 to 9, wherein the proxy payment method further comprises the step of providing a merchant details interface, wherein the merchant details interface comprises a component for approving or rejecting a payment for a merchant.

11. An electronic transaction system of any one of Claims 1 to 10, wherein the proxy payment method further comprises the step of creating a list of merchants, wherein the electronic transaction system is adapted to reject transaction with merchant on the list.

12. An electronic transaction system of any one of Claims 1 to 11, wherein the proxy details have a long-lived expiry date.