WO2017081620A2 - Système de transaction, et procédé de commande associé - Google Patents

Système de transaction, et procédé de commande associé Download PDF

Info

Publication number
WO2017081620A2
WO2017081620A2 PCT/IB2016/056740 IB2016056740W WO2017081620A2 WO 2017081620 A2 WO2017081620 A2 WO 2017081620A2 IB 2016056740 W IB2016056740 W IB 2016056740W WO 2017081620 A2 WO2017081620 A2 WO 2017081620A2
Authority
WO
WIPO (PCT)
Prior art keywords
purchaser
transaction
merchant
security code
data
Prior art date
Application number
PCT/IB2016/056740
Other languages
English (en)
Other versions
WO2017081620A3 (fr
Inventor
Daniel Jacobus Buys
Original Assignee
Cloudone Technology Proprietary Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Cloudone Technology Proprietary Limited filed Critical Cloudone Technology Proprietary Limited
Priority to US15/774,571 priority Critical patent/US20180330366A1/en
Publication of WO2017081620A2 publication Critical patent/WO2017081620A2/fr
Publication of WO2017081620A3 publication Critical patent/WO2017081620A3/fr
Priority to ZA2018/03603A priority patent/ZA201803603B/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/385—Payment protocols; Details thereof using an alias or single-use codes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
    • G06F16/33—Querying
    • G06F16/335—Filtering based on additional data, e.g. user or group profiles
    • G06F16/337—Profile generation, learning or modification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions

Definitions

  • THIS INVENTION relates generally to commercial transaction systems and methods of operating same, and particularly to secure commercial transactions.
  • One way in which purchasers may provide a required deposit is to utilize online electronic banking facilities whereby the user would have to connect to the internet, log into their online banking profile, make payment, and then provide confirmation of such payment to the merchant before the latter proceeds with the booking.
  • a difficulty with this approach is that it involves a fair amount of time for a user to proceed with a transaction in this fashion, which is often impractical during a verbal transaction.
  • this method of transacting becomes inconvenient as these details will have to be obtained, and correctly entered into the required fields by the purchaser on their electronic banking platform.
  • Another way in which a required deposit or authorization may be processed is via an online platform which a purchaser is re-directed to, for example, via a merchant's website, wherein the purchaser inserts login credentials and facilitates the processing of the transaction with the merchant via the online platform.
  • the difficulty with this example methodology is that it does not lend itself well to certain types of interactive transacting between the purchaser and the merchant and is more suited to online transactions.
  • a required deposit or authorization may be processed, in the case where a transaction comprises a interactive verbal element between a purchaser and a merchant, would be for the purchaser to provide their bank card details to the merchant verbally in order for the merchant to drive the processing of the payment on the merchant's end.
  • the merchant on receipt of the bank card details, the merchant utilizes the same to take a deposit or authorize an amount for the booking on the bank card.
  • One particular difficulty associated with this approach is that the safety of a purchaser's bank card details is not guaranteed and thus any subsequent unauthorized use of the purchaser's bank card details in a fraudulent manner will only be determined after a fraudulent transaction occurs.
  • a financial transaction system comprising: a database configured to store data in a secure fashion; and one or more processors comprising: a purchaser receiver module configured to: receive transaction data associated with a transaction for one or both of payment and authorization of a financial amount from a purchaser to a merchant, wherein received transaction data comprises information selected from a group comprising identifier information associated with the purchaser, a financial amount associated with the transaction, financial currency associated with the transaction, and a transaction identifier identifying the transaction; a security code generating module configured to generate a timed security code, valid for a pre-determined period of time, in response to receiving transaction data, wherein the generated timed security code is linked to an associated transaction; a code transmission module operable to transmit a generated security code for use by a purchaser wherein, in use, the security code is presented to a merchant by the purchaser in order to process a transaction associated with the security code; and a merchant receiver module configured to: receive a security code transmitted by a merchant at a
  • the security code received by the merchant receiver module may be a human-readable code presented or provided verbally, particularly vocally/orally, by the purchaser and is input to the merchant endpoint device.
  • the security code may essentially be read out aloud orally/vocally by the purchaser to the merchant.
  • the merchant may typically hear the code audibly and inputs the same to the merchant endpoint device.
  • the merchant endpoint device may input the code presented verbally by the purchaser by recording the audible code read out by the purchaser.
  • the recorded code for example, in the form of a suitable sound file containing the security code read out by the purchaser may be received by the merchant receiver module and processed to determine if the security code read out matches the code transmitted to the purchaser as will be described below.
  • the secure database may be in the form of a Payment Card Industry Data Security Standard (PCI DSS) compliant database.
  • the security code may be selected from a group comprising a numeric code, an alphanumeric code, a character-based code, and an image which may be perceivable by a human purchaser.
  • the database may be configured to store data comprising a plurality of user profiles associated with one or both of purchasers and merchants, wherein the user profiles stores account data associated with one or more external financial accounts associated with the purchasers and users as well as personal data associated therewith.
  • the purchaser receiver module may be configured to: receive transaction data from a purchaser having a user profile stored in the database, wherein the received transaction data comprises information indicative of the financial account from which the purchaser desires to one or both of pay and authorize the financial amount; and associate the received transaction data with the user profile of the associated purchaser in the database.
  • the security code generating module may be configured to: generate a timed security code in response to receiving transaction data from a purchaser; and associate the generated timed security code with at least a user profile of the purchaser in the database. It will be noted that this generated code may be stored in the database and may be compared with the code received via the merchant receiver module, i.e., the code that is either input in an alpha-numeric format into the merchant endpoint device, for example, by the merchant or party associated therewith (typically a human operator associated therewith) or read out aloud by the purchaser, merchant, or third party and recorded by the merchant endpoint device, as the case may be in order to process a particular transaction.
  • the code transmission module may be configured to transmit a generated timed security code to an endpoint device associated with a purchaser; and the merchant receiver module may be configured to receive a security code from a merchant having a user profile stored in the database.
  • the merchant receiver module may be configured to: receive a security code from a merchant having a user profile stored in the database; determine whether or not the received security code is valid, identify a user profile of a purchaser associated with the received security code if the security code is valid; and retrieve at least some of the transaction data, and personal data associated with the identified user profile of the purchaser.
  • the financial transaction system may comprise: a payment processing module configured to: generate and transmit a merchant acceptance message, comprising all or some of the retrieved data associated with a user profile identified by the merchant retriever module including payment method detail stored securely in the database, to the endpoint device associated with the merchant, wherein the merchant acceptance message prompts the merchant for an acceptance response for the transaction; generate and transmit a purchaser acceptance message to the endpoint device associated with the purchaser, wherein the purchaser acceptance message prompts the purchaser for an acceptance response for the transaction; and in response to receiving acceptance responses from the merchant and the purchaser, processing the transaction.
  • a payment processing module configured to: generate and transmit a merchant acceptance message, comprising all or some of the retrieved data associated with a user profile identified by the merchant retriever module including payment method detail stored securely in the database, to the endpoint device associated with the merchant, wherein the merchant acceptance message prompts the merchant for an acceptance response for the transaction; generate and transmit a purchaser acceptance message to the endpoint device associated with the purchaser, wherein the purchaser acceptance message prompts the purchaser for an acceptance response for the transaction
  • the system may comprise a registration module operable to register a user to the system by generating and storing in the database a user profile associated therewith in response to receiving personal data and payment account data associated with the user, wherein the users are one or both of purchasers and merchants.
  • the merchant receiver module may be configured to receive a selection of merchant terms and conditions applicable to a transaction from a merchant, wherein the purchaser must accept the merchant terms and conditions for the transaction in order for the transaction to be processed.
  • the system may be configured to provide the purchaser access to terms and conditions selected by the merchant for a transaction.
  • the merchant terms and conditions may be selected from a group of terms and conditions on an ad hoc basis per transaction or are predetermined.
  • the system may comprise a purchaser interaction module operable on the endpoint device associated with the purchaser; and a merchant interaction module operable on the endpoint device associated with the merchant, wherein the purchaser interaction module is configured to receive and transmit data between the one or more processors and the endpoint device associated with the purchaser, and wherein the merchant interaction module is configured to receive and transmit data between the one or more processors and the endpoint device associated with the merchant.
  • the security code may be displayed via the purchaser interaction module for a predetermined period of time on the endpoint device associated with the purchaser. For example, the code may be displayed for 30 seconds such that the purchaser has enough time to vocalize the same.
  • the merchant acceptance message may comprise at least some transaction data and personal data associated with the purchaser, and wherein the purchaser acceptance message may comprise at least personal data associated with the purchaser.
  • the payment processing module may be operable to communicate with a financial institution associated with an account of the purchaser to facilitate one or both of a payment or an authorization to an account associated with the merchant.
  • the purchase receiver module may be configured to receive transaction data from a mobile wallet provider.
  • the security code generating module may be configured to generate a security code in response to receiving transaction data from a mobile wallet provider.
  • the code transmission module may be operable to transmit a generated security code to a mobile wallet provider for transmission to a purchaser.
  • the merchant receiver module may be operable, in response to determining that a received security code is valid, to transmit a suitable message to the mobile wallet provider to process the associated transaction.
  • a method of operating a financial transaction system comprising: maintaining a database storing data in a secure fashion; receiving, via a purchaser receiver module, transaction data associated with a transaction for one or both of payment and authorization of a financial amount from a purchaser to a merchant, wherein received transaction data comprises information selected from a group comprising identifier information associated with the purchaser, a financial amount associated with the transaction, financial currency associated with the transaction, and a transaction identifier identifying the transaction; generating, via a security code generating module, a timed security code, valid for a pre-determined period of time, in response to receiving the transaction data, wherein the generated timed security code is linked to the transaction; transmitting, via a code transmission module, the generated security code for use by the purchaser wherein, in use, the security code is provided by the purchaser to a merchant in order to process a transaction associated with the security code; receiving, via a merchant receiver module, the security code transmitted by the merchant at a merchant endpoint device, where
  • the security code may be as described above.
  • the method may comprise the step of recording the audible version of the security code, i.e., the security code read out aloud by the purchaser, merchant, or third party with the merchant endpoint device and transmitting the same to the merchant receiver module which receives the same so as to determine if the audible version matches that stored in the database.
  • the database may be configured to store data comprising a plurality of user profiles associated with one or both of purchasers and merchants, wherein the user profiles stores account data associated with one or more external financial accounts associated with the purchasers and merchants as well as personal data associated therewith, and wherein the method may further comprise: receiving transaction data from the purchaser having a user profile stored in the database, wherein the received transaction data comprises information indicative of the financial account from which the purchaser desires to one or both of pay and authorize the financial amount; associating the received transaction data with a user profile of the purchaser stored in the database; generating the timed security code in response to receiving transaction data from the purchaser; associating the generated timed security code with at least the user profile of the purchaser in the database; transmitting the generated timed security code to an endpoint device associated with the purchaser; and receiving a security code from a merchant having a user profile stored in the database; determining whether or not the received security code is valid, identifying a user profile of a purchaser associated with the received security code if the security code is valid; retriev
  • the method may comprise registering a user to the system by generating and storing in the database a user profile associated therewith in response to receiving personal data and payment account data associated with the user.
  • the method may comprise receiving a selection of merchant terms and conditions applicable to a transaction from a merchant, and wherein the method comprises receiving acceptance of the merchant terms and conditions from the purchaser for the transaction in order for the transaction to be processed.
  • the acceptance of the terms and conditions by the purchaser may be also a verbal acceptance which may be recorded by the merchant endpoint device and stored accordingly. Thus a verbal record is maintained of the transaction, or at least part thereof.
  • the method may comprise providing the purchaser with access to terms and conditions selected by the merchant for a transaction.
  • the merchant terms and conditions may be selected from a group of terms and conditions on one or both of an ad hoc basis per transaction and are predetermined per transaction.
  • the method may comprise displaying the security code for a predetermined period of time on the endpoint device associated with the purchaser.
  • the method may comprise: receiving transaction data from a mobile wallet provider; generating the security code in response to receiving transaction data from a mobile wallet provider; transmitting the generated security code to the mobile wallet provider for transmission to a purchaser; and in response to determining that a received security code is valid, transmitting a suitable message to the mobile wallet provider to process the associated transaction.
  • a non-transitory computer readable medium storing a set of computer executable instructions which when executed by one or more processors cause the same to: maintain a database storing data in a secure fashion; receive transaction data associated with a transaction for one or both of payment and authorization of a financial amount from a purchaser to a merchant, wherein received transaction data comprises information selected from a group comprising identifier information associated with the purchaser, a financial amount associated with the transaction, financial currency associated with the transaction, and a transaction identifier identifying the transaction; generate a timed security code, valid for a pre-determined period of time, in response to receiving the transaction data, wherein the generated timed security code is linked to the transaction; transmit the generated security code for use by the purchaser wherein, in use, the security code is provided by the purchaser to a merchant in order to process a transaction associated with the security code; receive the security code transmitted by the merchant at a merchant endpoint device, wherein the security code transmitted by the merchant is received thereby from the
  • a financial transaction system comprising: a secure database configured to store data including a plurality of user profiles associated with one or both of purchasers and merchants, wherein the user profiles stores account data associated with one or more external financial accounts associated with the users as well as personal data associated therewith; and one or more processors comprising: a purchaser receiver module configured to: receive transaction data associated with a transaction for the payment or authorization of a financial amount from a purchaser having a user profile to a merchant, wherein the transaction data comprises information indicative of one or more of the financial amount associated with the transaction, the financial account from which the purchaser desires to pay or authorize the financial amount, and a transaction identifier identifying the transaction; and associate the received transaction data with the user profile of the purchaser stored in the database; a security code generating module configured to: generate a timed security code in response to receiving the transaction data from the purchaser; and associate the generated timed security code with at least the user profile of the purchaser in the database, wherein the timed security code is valid for a
  • a payment processing module configured to: generate and transmit a merchant acceptance message, comprising all or some of the retrieved data associated with the identified user profile including payment method detail stored securely in the database, to the endpoint device associated with the merchant, wherein the merchant acceptance message prompts the merchant for an acceptance response for the transaction; generate and transmit a purchaser acceptance message to the endpoint device associated with the purchaser, wherein the purchaser acceptance message prompts the purchaser for an acceptance response for the transaction; and in response to receiving acceptance responses from the merchant and the purchaser, processing the transaction.
  • a method of operating a financial transaction system comprising: maintaining a secure database configured to store data including a plurality of user profiles associated with one or both of purchasers and merchants, wherein the user profiles stores account data associated with one or more external financial accounts associated with the users as well as personal data associated therewith; receiving transaction data associated with a transaction for the payment or authorization of a financial amount from a purchaser having a user profile to a merchant, wherein the transaction data comprises information indicative of one or more of the financial amount associated with the transaction, the financial account from which the purchaser desires to pay or authorize the financial amount, and a transaction identifier identifying the transaction; associating the received transaction data with the user profile of the purchaser stored in the database; generating a timed security code in response to receiving the transaction data from the purchaser; associate the generated timed security code with at least to the user profile of the purchaser in the database, wherein the timed security code is valid for a predetermined period of time; transmitting the generated timed security code to an
  • a financial transaction system comprising: a database configured to securely store data; and one or more processors comprising: a purchaser receiver module configured to: receive transaction data associated with a transaction for the payment or authorization of a financial amount from a purchaser to a merchant, wherein the transaction data is received from a mobile wallet provider and comprises information selected from a group comprising identifier information associated with the purchaser, the financial amount associated with the transaction, the currency associated with the transaction, and a transaction identifier identifying the transaction; a security code generating module configured to generate a timed security code in response to receiving the transaction data from the mobile wallet provider; and a code transmission module operable to transmit the generated timed security code to the mobile wallet provider for transmission to the purchaser.
  • the system may optionally comprise a merchant receiver module operable to: receive a timed security code from an endpoint device associated with a merchant, wherein the timed security code received by the merchant is associated with the purchaser; determine whether the timed security code received from the merchant is valid; in response to determining that the timed security code is valid, transmit a suitable message to the mobile wallet provider to process the transaction.
  • a merchant receiver module operable to: receive a timed security code from an endpoint device associated with a merchant, wherein the timed security code received by the merchant is associated with the purchaser; determine whether the timed security code received from the merchant is valid; in response to determining that the timed security code is valid, transmit a suitable message to the mobile wallet provider to process the transaction.
  • a method of operating a financial transaction system comprising: maintaining a database securely storing data; receiving transaction data associated with a transaction for the payment or authorization of a financial amount from a purchaser to a merchant, wherein the transaction data is received from a mobile wallet provider and comprises information selected from a group comprising identifier information associated with the purchaser, the financial amount associated with the transaction, and a transaction identifier identifying the transaction; generating a timed security code in response to receiving the transaction data from the mobile wallet provider; transmitting the generated timed security code to the mobile wallet provider for transmission to the associated purchaser.
  • the method may comprise: receiving a timed security code from an endpoint device associated with a merchant, wherein the timed security code received by the merchant is associated with the purchaser; determining whether the timed security code received from the merchant is valid; in response to determining that the timed security code is valid, transmitting a suitable message to the mobile wallet provider to process the transaction.
  • Figure 1 shows a schematic drawing of a transaction system in accordance with an example embodiment of the invention
  • Figure 2 shows a schematic drawing of a system in accordance with an example embodiment of the invention in more detail
  • Figure 3 shows a process flow diagram of a method of operating a transaction system in accordance with an example embodiment of the invention
  • Figure 4 shows a screen shot of an example user interface in accordance with an example embodiment of the invention
  • Figure 5 shows a screen shot of an example user interface in accordance with an example embodiment of the invention
  • Figure 6 shows a screen shot of an example user interface in accordance with an example embodiment of the invention
  • Figure 7 shows a screen shot of an example user interface in accordance with an example embodiment of the invention.
  • Figure 8 shows a screen shot of an example user interface in accordance with an example embodiment of the invention.
  • Figure 9 shows a screen shot of an example user interface in accordance with an example embodiment of the invention.
  • Figure 10 shows a screen shot of an example user interface in accordance with an example embodiment of the invention.
  • Figure 11 shows a screen shot of an example user interface in accordance with an example embodiment of the invention
  • Figure 12 shows a screen shot of an example user interface in accordance with an example embodiment of the invention
  • Figure 13 shows a screen shot of an example user interface in accordance with an example embodiment of the invention
  • Figure 14 shows a screen shot of an example user interface in accordance with an example embodiment of the invention
  • Figure 15 shows a screen shot of an example user interface in accordance with an example embodiment of the invention.
  • Figure 16 shows a schematic drawing of another transaction system in accordance with an example embodiment of the invention.
  • Figure 17 shows a schematic drawing of the system of Figure 16 in more detail.
  • Figure 18 shows a diagrammatic representation of a machine in the example form of a computer system in which a set of instructions for causing the machine to perform any one or more of the methodologies discussed herein, may be executed.
  • a network comprising a system 10 in accordance with an example embodiment of the invention is generally indicated by reference numeral 12.
  • the system 10 is an electronic transaction system comprising a transaction system server 14 connectable to users of the system 10, for example, a purchaser 16 and a merchant 18 via a communication network 20.
  • the system 10 facilitates transactions for the payment or authorization of payment between the purchaser 16 and the merchant 18, for example, for booking for a particular service such as a hotel or restaurant reservation.
  • the system 10 is configured to facilitate the said transaction whilst the purchaser 16 is conversing with the merchant 18, for example, telephonically, or in person.
  • the purchaser 16 and the merchant 18 may be able to facilitate the transaction via associated endpoint devices 22, 24, respectively, operatively connected to a communication network 20 as will be described below.
  • the communication network 20 may be a cellular or mobile telecommunication network. Instead, or in addition, the communication network 20 may be a packet-switched network and may form part of the Internet. Instead, the communication network 20 may be a circuit switched network, public switched data network, or the like.
  • the devices 22, 24 may be matched to the communication network 20. Instead, in addition, it will be noted that the devices 22, 24 may be operable to connect to other communication networks, not illustrated.
  • the endpoint devices 22, 24 may be in the form of mobile computing devices in the form of smart telephones, tablet computing devices, and the like comprising suitable hardware operable to connect to the communication network 20.
  • Figures 1 and 2 illustrate a single purchaser 16 and merchant 18, the network 12 may comprise a plurality of purchasers 16 and merchants 18.
  • the terms purchaser 16 and merchant 18 may be understood to include agents of the same, for example, if the merchant 18 is a retailer, then an agent thereof, for example, a teller of the retailer may be considered a merchant for the purposes of the description herein.
  • the purchaser 16 may additionally be merchants 18, and vice versa.
  • the server 14 may be communicatively coupled to one or more financial institutions or banks 26 associated with the purchasers 16 and merchants 18, particularly to payment gateways thereof in a conventional fashion.
  • the server 14 may be one or more networked servers or application servers operatively connectable to the communication network 20. In this way, the functionality provided by the server 14 may be a cloud-based computing functionality.
  • the system 10 comprises a database 28 configured to store data including a plurality of user profiles associated with purchasers 16 and merchants 18 associated with, or in particular, registered with the system 10 as registered users.
  • the user profiles stores account data associated with one or more external financial accounts associated with the users 16, 18 at the bank 26 as well as personal data associated therewith.
  • the account data may serve to identify one or more accounts associated with the users 16, 18 at the institution 26 or an external payment entity or platform.
  • the personal data may comprise one or more of the name, address, contact details, such as, email addresses, and telephone or mobile phone numbers, etc. associates with the users 16, 18.
  • the system 10 further comprises at least one processor 30 comprising a plurality of components and modules which correspond to at least some of the functional tasks to be performed by the system 10.
  • module in the context of the specification will be understood to include an identifiable portion of code, computational or executable instructions, data, or computational object to achieve a particular function, operation, processing, or procedure. It follows that a module need not be implemented in software; a module may be implemented in software, hardware, or a combination of software and hardware. Further, the modules need not necessarily be consolidated into one device but may be spread across a plurality of devices, for example, on a plurality of networked servers at the same location or at spaced apart geographic locations in the network 12.
  • the processor 30 may be programmed with software to control respective modules and components to achieve the desired functionality described herein.
  • the database 28 (or memory in the processor 30, main memory, and/or a hard disk drive) may carry a set of non-transitory computer executable instructions to direct the operation of the processor 30 in a fashion as described herein.
  • the processor 30 may be one or more microprocessors, controllers, or any other one or more suitable computing devices, resources, hardware, software, or embedded logic.
  • the system 10 further comprises a purchaser interaction module 32 and a merchant interaction module 34 operatively located in the endpoint device 22 and 24 of the purchaser 16 and merchant 18 respectively.
  • the modules 32, 34 may be in the form of software application modules downloadable to the purchaser and merchant endpoint devices 22, 24 and may facilitate receipt and transfer of data to and from the server 14. To this end the modules 32, 34 may be configured to receive data from the users 16, 18 and transmit the same to the server 14 and receive data from the server 14 and display the same to the users 16, 18.
  • some of the functionality of some of the modules as will be described with reference to the server 14, particularly the processor 30, may be carried out by the modules 32, 34 as the case may be.
  • the processor 30 comprises a purchaser receiver module 36 configured to receive transaction data associated with the transaction for the payment or authorization of a financial amount from the purchaser 16 to the merchant 18.
  • the transaction data typically comprises information indicative of the financial amount associated with the transaction, the financial account from which the purchaser 16 desires to pay or authorize the financial amount, and a transaction identifier identifying the transaction.
  • the transaction data may be input by the purchaser 16 via the module 32 on their endpoint device 22 and may be transmitted to the module 36 via the communication network 20.
  • the module 32 may prompt the purchaser 16 for the financial amount, and the account which the purchaser 16 desires to transact from.
  • the account may include a payment method, for example, if the account selection is a credit card, the module 32 may prompt the purchaser 16 for security code associated with said card.
  • the purchaser 14 may also select the current of the financial amount.
  • the transaction identifier may be system generated so as to identify the transaction from other transactions which the purchaser 16 may be involved in by way of the system 10.
  • the purchaser receiver module 36 may be further configured to associate the received transaction data with the user profile of the purchaser 16 stored in the database 28.
  • the processor 30 further conveniently comprises a security code generating module 38 configured to generate a unique timed security code in response to receiving the transaction data from the purchaser 16 via the device 22.
  • a security code generating module 38 configured to generate a unique timed security code in response to receiving the transaction data from the purchaser 16 via the device 22.
  • the timed security code is typically valid for a pre-determined period of time, for example, two minutes.
  • the module 38 may comprise a clock, and may allocate a time stamp to the code which is valid for the pre-determined period of time.
  • the timed security code may be one or a combination of a numeric and character code which may in one example embodiment be randomly generated by the module 38.
  • the module 38 may be configured to associate the generated timed security code with at least to the user profile of the purchaser 16 in the database 28.
  • the processor 30 further comprises a code transmission module 40 operable to transmit the generated timed security code to the endpoint device 22 associated with the purchaser 16.
  • the code may be pushed to a display screen associated with the endpoint device 22 associated with the purchaser 16 and may be displayed for a predetermined period of time.
  • the module 32 may be configured to display the code and may cease displayed the code after a pre-determined period of time has elapsed, for example, by utilizing a clock associated with the device 22 and a time stamp associated with the code.
  • the module 40 may be configured to control the display of the code for a pre-determined period of time.
  • the processor 30 may comprises a merchant receiver module 42 operable to receive the timed security code from the endpoint device 24 associated with the merchant 18, and determine whether the timed security code received from the merchant 18 is valid.
  • this may be done by interrogating the time in which the timed security code was received and the time in which the code was transmitted and/or generated, and wherein if the difference in time between when the timed security code was received and the time in which the code was transmitted and/or generated exceeds the pre-determined valid period of time, then the code is invalid.
  • the difference of time in which the code was transmitted and/or generated and was received by the module 42 is five minutes and the predetermined valid period is two minutes then the received code may be found to be invalid.
  • the said difference of time is less than the pre-determined valid period then the received code may be found to be valid.
  • determining the validity of the code may be done in a myriad of different, for example, this may be an operation undertaken by the module 34 utilizing a clock associated with the endpoint device 24 and a time stamp associated with the code. Instead, or in addition, to the code being received in a good time, the processor 30 may compare the received code to that stored in the database associated with a purchaser 16.
  • the code generated has a limited period of validity and thus use thereof outside the period of validity, which may be determined in a plurality of ways, would prove invalid.
  • the limited period of validity is part of the security mechanism deployed to prevent unauthorized and/or fraudulent access to payments.
  • the module 42 may be operable to identify the user profile of the purchaser 16 associated with the timed security code; and retrieve at least some of the transaction data, and personal data associated with the identified user profile of the purchaser, for example, at least the name of the purchaser 16 and the financial amount associated with the desired transaction.
  • a security code match of a code received within a pre-determined time against a particular code stored in the database and uniquely associated with a purchaser would locate the relevant user profile already, as the case may be.
  • the code may be verified and the purchaser user profile retrieved in many ways in order to process the transaction.
  • the processor 30 may further comprise a payment processing module 44 configure to generate and transmit, via a push operation, a merchant acceptance message, comprising all or some of the retrieved data associated with the identified user profile (i.e., the name of the purchaser 16 and financial amount), to the endpoint device 24 of the merchant 18.
  • the merchant acceptance message prompts the merchant 18 for an acceptance response for the transaction via the module 32 operating on the endpoint device 24.
  • the module 44 may also be configured to generate and transmit, also via a push operation, a purchaser acceptance message to the endpoint device 22 associated with the purchaser 16.
  • the purchaser acceptance message prompts the purchaser 16 for an acceptance response for the transaction.
  • the purchaser acceptance message identifies the merchant and the terms and conditions specified by the merchant for the intended transaction. This allows the opportunity for both the merchant 18 and the purchaser 16 to decline the transaction before the same is processed, thereby facilitating a more secure transaction.
  • the payment processing module 44 is configured to process the transaction in a conventional manner.
  • the module 44 may be communicatively coupled to a payment gateway or back-end financial system associated with the banks 26 so that, for example, a payment is made or an authorization is granted from the selected account of the purchaser 16 to the merchant 18 for the selected financial amount.
  • the system 10 may comprise a registration module 46 configured to facilitate a user registering a user profile in the database 28.
  • the registration module 46 may assign or may receive a selected unique user name and password so that the users 14, 16 may securely log in to the system 10 via the modules 32, 34 respectively.
  • account details such as card numbers stored in the database 28 may be stored in a PCI DSS (Payment Card Industry) compliant token vault (no security codes are stored).
  • PCI DSS Payment Card Industry
  • token vault no security codes are stored.
  • a user 16, 18 may vary or amend the information on their profile. For example, a purchaser 16 may select the personal details which they would like to share electronically with the merchant 18 in order to facilitate accurate processing of a transaction.
  • the merchant 18 as part of their registration may, by way of the module 46 create rules or in other words terms and conditions which the purchaser 16 must accept, for example, as part of the purchaser acceptance message in order for the module 44 to proceed with the transaction. Such terms and conditions would typically include refund conditions set by the merchant.
  • the processor 30 may also comprise a dashboard module 48 operable to retrieve and transmit to the purchaser 16 and the merchant 18 a listing of all transactions processed or in progress to be processed which are linked to their user profiles in the database 28. In this way, the purchaser 16 and merchant 18 are able to keep track of the transactions made and/or are being processed. Example embodiments will now be further described in use with reference to Figures 3 to
  • FIG. 15 The example method shown in Figures 3 is described with reference to Figures 1 & 2, although it is to be appreciated that the example methods may be applicable to other systems, not illustrated, as well.
  • the screen shot illustrations shown in Figures 4 to 15 may be exemplary screen shots of graphical user interfaces (GUIs) generated or provided by the modules 32, 34, as the case may be.
  • GUIs graphical user interfaces
  • further functionality of the system 10 as described above may be supplemented by the description which follows.
  • system 10 particularly the server 14 may comprise suitable security modules, firewalls, etc. so as to maintain the security and integrity of the data stored in the database 28.
  • FIG 3 a line/process flow diagram of a method in accordance with an example embodiment of the invention is generally indicated by reference numeral 50. The method 50 is described with reference to the Figures 4 to 15 so as to assist in facilitating the understanding of the invention.
  • the method 50 may be described with reference to a transaction which requires payment of a particular financial amount in order to secure a booking for a particular service, such as a spa treatment offered by the merchant 18, whilst the purchaser 16 is telephonically engaged with the merchant 18, particularly a human operator thereof.
  • the communication network 20 is typically a data network and the purchaser 16 is telephonically engaged with the merchant 18 via another communication channel such as a fixed line telephony network.
  • the method 50 may comprise the users 16, 18 downloading the software applications in the form of the module 32, 34 onto their respective devices 22, 24.
  • the users 16, 18 may access the system 10 particularly the server 14 via any device having the modules 32, 34 thereon using their user name and password.
  • the modules 32, 34 may be substantially similar, for example, wherein the purchaser 16 and merchant 18 are the same. Alternatively, the modules 32, 34 may be sufficiently different modules uniquely tailored for the purchaser 16 and merchant 18.
  • the method 50 typically comprises a prior step 52 of the merchant 18 registering via the module 34 to use the server 14 by setting up a user profile.
  • the module 34 downloaded onto their computing endpoint device 24.
  • the registration module 46 is configured to receive account data and personal data from the merchant 18 via the module 34 over the communication network 20 so as to register, at step 55, and create a user profile for the merchant 18 for storage and maintenance in the database 28.
  • the account data may be account details of bank accounts, cards (such as debit, credit, cheque cards, particularly their numbers, expiry date), etc. of financial institution 26 associated with the merchant 18 and the personal information may comprise the name, address, contact details of the merchant.
  • the merchant 18 may set, via the module 46 one or more terms and conditions to be accepted by the purchaser 16 before a transaction is processed.
  • the payment method details associated with the purchaser 16 may also be received and stored in the database 28.
  • the merchant 18 may have more than one user profile in the database 28, as the case may be.
  • the system 10 provides multiple access nodes to at least one user profile associated with the merchant 18, in which case certain account information associated with the merchant 18 may require additional permissions to access, edit, etc.
  • a merchant having a plurality of agents or operators may be able to access or use at least part of the system 10 from a plurality of endpoint devices 24.
  • account details are stored in a PCI DSS compliant token vault and no security codes associated with bank cards are stored. Bank cards may be added or deleted relatively easily.
  • the merchant 18 may typically log-on to the system 10 in a secure fashion by using their user names and passwords which have been pre-allocated and/or user selected.
  • the method 50 comprises a step 54 of the purchaser using the module 32 to register themselves to the system 10 via the module 46 by creating a user profile in a similar fashion as described above with reference to step 52 and 55.
  • the purchaser 16 having a user profile, or in other words a registered user of the system 10 when the purchaser 16 having a user profile, or in other words a registered user of the system 10, is engaged telephonically with the merchant 18 and wishes to facilitate a transaction for the payment of a deposit to the merchant 18, they access the system server 14 or in other words login to at least part of the system 10 by entering their username and password into the module 32.
  • the method 50 therefore comprises receiving, at step 57 via the module 32, the username and password of the purchaser 16, verifying the same, and allowing the verified purchaser 16 to access the associated user profile, at step 56. It follows that if the username and password are not verified, the purchaser 16 will not be able to use the module 32 or the functionality of at least part of the system 10.
  • the user 16, 18 When the user 16, 18 has access to their user profile, they may vary the data therein accordingly, for example, edit or change account details, etc. It will be noted that in some example embodiments, the username and password received by the module 32 is transmitted for verification to the server 14. It will be understood that once verified and the user 16 is logged in to the system 10, they may utilize the functionality of the system as described herein, for example, for facilitating the aforementioned transaction.
  • the purchaser 16 may use personal biometrics such as fingerprint authentication or a social media login via an OAuth application to gain access or login to the system 10.
  • the method 50 may comprise prompting, at step 58 via the module 32, the purchaser 16 for data as illustrated in Figure 5.
  • the method 50 may comprise prompting the purchaser 16, by way of the module 32, to input into the module 32, transaction data, comprising an indication of the nature of the transaction, for example, a payment authorization or payment, a selection of the financial account which the purchaser desires to transact from, a security code if the credit card is selected, payment method, as well as the currency of the transaction and financial amount of the transaction for the payment to the merchant 18.
  • the method 50 comprises the step 60 of receiving at the server 14, the transaction data transmitted by the module 32 by way of the purchaser receiver module 36 as described above. Also in step 60, the method 50 comprises operating the module 36 to associate the received transaction data with the relevant user profile of the purchaser 16 in a manner as described above.
  • the method 50 may comprise generating, at step 62 by way of the code generating module 38, a timed security code in the manner as described above.
  • the method 50 also at step 62, comprises operating the module 38 to associate the generated timed security code with the user profile of the purchaser 16.
  • the method 50 then comprises transmitting, also at step 62, the generated timed security code to the endpoint device 22, particularly the module 32 over the communication network 20 by way of the module 40.
  • the method 50 comprises receiving and displaying, at step 64, the security code for a predetermined period of time on the display screen of the endpoint device 22 by way of the module 32 on the device 22, as illustrated in Figure 6.
  • the code has a pre-determined time based period in which the same is valid as hereinbefore described.
  • the code may be displayed for a predetermined time period only and will cease to display once said period is over.
  • the module 40 may control the display of the code for the predetermined period of time or the module 32 may do so.
  • the purchaser 16 verbally provides the code to the merchant 18 over the telephone as opposed to giving the same their account data.
  • the method 50 therefore comprises receiving the verbally received code, at step 66, wherein the code is input into the module 34 by the merchant 18, as illustrated in Figure 7.
  • the code received audibly by the merchant 18 is input into the merchant point of sale terminal or business application integrated to the server 14.
  • this code may be spoken in an oral fashion by the purchaser 16 and may be recorded by the merchant 18 by the merchant endpoint device, particularly the software application running thereon.
  • the method 50 comprises receiving the code, at step 68, by the module 42 from the module 34 via the communication network 20 and in response thereto, the module 42 determines whether the timed security code received from the merchant is valid, at step 70, for example, in a manner described above.
  • the method 50 comprises, at step 70 via the module 42, identifying the user profile of the purchaser 16 associated with the timed security code, and retrieving at least some of the transaction data, and personal data associated with the identified user profile of the purchaser 16.
  • the method 50 may comprise communicating said invalidity to the user 16, 18.
  • the method 50 may comprise prompting the merchant 18 for the terms and conditions of the transaction.
  • the method 50 then comprises generating, at step 72, a merchant acceptance message as illustrated in Figure 8 via the module 44.
  • the method 50 also comprises transmitting, at step 72 by way of the module 44, the generated merchant acceptance message to the module 34 via the communication network 20.
  • the merchant acceptance message comprises at least some of the retrieves transaction data, and personal data, for example, the financial amount, the user name, and contact information.
  • the merchant acceptance message may comprise a field for merchant use as well as terms and/or conditions set, for example, by the purchaser, which the merchant 18 may accept.
  • the method 50 may comprise receiving the message at the module 34 and prompting merchant 18 for a reply, at step 74.
  • the method 50 comprises generating and transmitting, at step 78 via the module 44, a purchaser acceptance message, as illustrated in Figure 9, to the module 32 associated with the purchaser 16.
  • the purchaser acceptance message prompts the purchaser 16 for a final confirmation of the transaction, wherein the message comprises the details of the merchant 18, financial amount, as well as terms and/or conditions for the transaction set, for example, by the merchant 18.
  • the method 50 comprises receiving the acceptance message at the module 32 in step 80 and prompting the purchaser 16 for a response.
  • the method 50 also comprises prompting the purchaser 16 for acceptance of the terms and conditions of the transaction.
  • the method 50 comprises processing the transaction, at step 84, to effect the payment of the financial amount from the account at the bank 26 selected by the purchaser 16 to the bank account of the merchant 18 by way of the module 44.
  • the method 50 may comprise generating and transmitting, at step 86, for example, via the module 44 a confirmation message to the purchaser 16 and merchant 18 as illustrated in Figures 10 and 1 1 , particularly to the devices 22 and 24. Similarly, if there is a problem with the processing the transaction, the module 44 generates and transmits, at step 86, a declined message to the purchaser 16 and merchant 18 as illustrated in Figures 12 and 13.
  • dashboard module 48 it will be noted that the merchant 18 may view a list of transactions processed for a particular period as illustrated in Figures 14. As may be seen in Figure 15, the merchant 18 may drill down for more detail on any transaction.
  • FIG. 16 of the drawings another example embodiment of a network comprising a system 200 in accordance with an example embodiment is generally indicated by reference numeral 212.
  • the system 200 is substantially similar to the system 10 described above and thus similar components will be indicated by the same reference numerals.
  • the system 200 differs from the system 10 in that it instead of storing financial data such as bank account details, etc. associated with the purchaser 16 and processing payment and/or authorisations, the system 200, particularly a transaction system server 214 thereof, is configured to be in communicatively coupled with a mobile wallet provider 216 which facilitates the same.
  • the mobile wallet provider 216 may be a conventional mobile wallet service provider 216 which comprises a database which stores credit card payment data securely and has capacity to process payments for the purchase of goods and/or services and/or authorisations. Though only one provider 216 is illustrated, the server 214 may be configured to be communicatively coupled to a plurality of providers 216.
  • the mobile wallet provider 96 already has users in the form of users 16 and/or merchants 18 registered thereto and stores user profiles associated therewith in an associated database. If thus follows that the transaction system server 214 serves to extend the service offered by conventional mobile wallet providers 216 with the verbal payment methodology as aforementioned. In particular, the server 214 will thus provide a central, cloud based processing interface between a purchaser 16 and a merchant 18 and will leave the storage of the card information and processing of the payment to the mobile wallet provider 216.
  • the server 214 does not comprise a payment processing module of the type in the system of Figure 10 but comprises a suitable mobile wallet provider interaction module 244.
  • the mobile wallet provider interaction module 244 may be configured to allow the server 214 to interact with the mobile wallet providers 216.
  • the mobile wallet provider interaction module 244 may be configured to receive transaction data associated with transactions to be processed via the providers 216 and pass on acceptance of a transaction from a merchant to the mobile wallet provider 216 for processing in a conventional fashion as will be described below.
  • the server 214 may supply the providers 216 with two sets of interfaces, one for an associated software application provided by the providers 216 to the purchasers and one for interfaces with merchants.
  • the applications used by purchasers may be communicatively coupled directly to the server 214 or indirectly to the server via the providers 216 as described below.
  • the server 214 may be communicatively coupled directly or indirectly to the merchants.
  • the module 34 may be a ready to use software application which is operable to directly communicate with the server 214.
  • the providers 216 may have associated applications which enable the merchants to communicate with the server 214 via the software applications associated with the providers 216.
  • the purchaser receiver module 236 of the server 214 is substantially similar to the one described above albeit the transaction data is not received directly from the purchaser 16 but indirectly from a software application module associated with the provider 216 which the purchaser 16 interacts with. In particular, the transaction data is received from the provider application via module 244 which sends the same to the module 236.
  • the security code generating module 238 may be substantially similar to the module 38 as described above.
  • the code transmission module 240 differs from the module 40 in that it is configured to transmit the generated code to the mobile wallet provider 216, for example, via the module 244.
  • the provider 216 then provides the code to the purchaser by way of the associated software application module which the purchaser interacts with.
  • the registration module 246 may be substantially similar to the registration module 46 as described above, though it will be appreciated that in the present example embodiment there is no requirement for the purchaser 16 to register to the system 200. In some example embodiments, the merchant 18 may register.
  • the merchant receiver module 242 may, instead or in addition to the functionality of the similar module 42 as described above, be configured to transmit acceptance of a particular transaction through to the mobile wallet provider 216 which then would process payment accordingly.
  • the server 214 may be configured to transmit contact information associated with the purchaser as received from the transaction data securely to the merchant interaction module 34. The extent of the information sent may depend on the merchant's requirements.
  • the mobile wallet provider 216 particularly a purchaser application associated therewith may allow a purchaser to specify whether their contact information may be used for subsequent marketing purposes or not so as to protect the privacy of the purchaser, and to protect them from receiving unwanted spam.
  • the module 34 may be associated with the server 214 and/or may be associated with the provider 216.
  • acceptance of the merchant's terms and conditions, as described above, may also be receivable by the transaction system server 214 and may transmit the acceptance to the mobile wallet provider 216.
  • the system server 214 is also configured to, in response to the merchant 18 accepting payment, push a confirmation massage to the purchaser 16.
  • the purchaser 16 desiring to make a verbal payment in an associated software application of the mobile wallet provider 216 makes the appropriate selection.
  • the purchaser 16 selects payment method and selects any information required, a CVV code, currency, and an amount of the transaction.
  • the purchaser may make a selection of the information they wish to share with the merchant, for example, contact information.
  • the mobile wallet provider application will then establish a communication link with the transaction system server 214 and transmit transaction data comprising at least user identification, user name, the amount of the transaction, currency and any other information required.
  • the transaction server purchaser receiver module 236 receives this information via the module 244.
  • the module 236 may store the transaction data in the database 228, particularly, a PCI compliant data vault, only for a pre-determined period of time, for example, for the duration of the timed security code.
  • the transaction system server 214 may generate a security code and transmit the same to the mobile wallet provider 216 for presentation to the purchaser 16 via its associated application.
  • the modules 238 and 240 typically undertake this step. It will be appreciated that the security code transmitted to the mobile wallet provider is configured to be displayed for a predetermined period as described above with respect to system 10. The purchaser 16 then verbally provides this code to the merchant 18 in the fashion as described above.
  • the merchant 18 then enters a received security code, which they receive verbally, into their associated mobile wallet provider merchant application or merchant interaction module 34.
  • the code is received from the merchant 18 by the server 214, particularly, by module 242 in a similar fashion as described above in system 10.
  • the associated determination of the validity of the code is also substantially similar as hereinbefore described.
  • the mobile wallet provider merchant application or module 34 retrieves payment details including the user name and contact information from the server 214 or provider 216.
  • the merchant 18 is able to select applicable terms and conditions and accept the payment, wherein said acceptance of the payment is transmitted or received by the transaction system server 214 merchant receiver module 242.
  • the system server 214 is then configured to push a confirmation message to the purchaser 16.
  • the mobile wallet purchaser application will receive a push notification to identify the merchant 18 and await final confirmation from the purchaser 16. This may be done via the system server 214 or directly via the mobile wallet provider merchant application. It will be appreciated that the acceptance/rejection is preferably received by the server 214 which is operable to pass the same on to the provider 216. Once the purchaser 16 confirms the payment and accepts the merchant's terms and conditions, i.e., the final confirmation, the wallet provider 216 will proceed to execute payment in a conventional fashion.
  • the transaction is successful said confirmation of the successful transaction is transmitted to the system server 214 which notifies the purchaser 16 and merchant 18 accordingly. If the payment or authorisation has failed the mobile wallet provider application will notify the system server 214 which then will provide an associated reason for failure of the transaction to the merchant 18 and purchaser 16. Once the mobile wallet provider 216 has processed payment or authorisation, the, merchant 18 will receive a push notification or web-call back. It will be appreciated that if successful, the merchant 18 will receive authorisation information along with customer contact information. In addition, it will be appreciated that once payment is successful the system server 214 is configured to share the contact information of the purchaser 16 and merchant 18 with each other respectively.
  • the transaction data stored in the database 228 associated with the transaction is deleted, particularly purchaser contact information.
  • the data retained is comprised of one or more of merchant details, date and time of the transaction, a mobile wallet provider transaction identifier, the transaction amount, status of the transaction, Purchaser name, and any other transaction reference for billing purposes.
  • Figure 18 shows a diagrammatic representation of machine in the example of a computer system 100 within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed.
  • the machine operates as a standalone device or may be connected (e.g., networked) to other machines.
  • the machine may operate in the capacity of a server or a client machine in server-client network environment, or as a peer machine in a peer- to-peer (or distributed) network environment.
  • the machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine.
  • PC personal computer
  • PDA Personal Digital Assistant
  • STB set-top box
  • WPA Personal Digital Assistant
  • a cellular telephone a web appliance
  • network router switch or bridge
  • machine any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine.
  • machine shall also be taken to include any collection of machines, including virtual machines, that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.
  • the example computer system 100 includes a processor 102 (e.g., a central processing unit (CPU), a graphics processing unit (GPU) or both), a main memory 104 and a static memory 106, which communicate with each other via a bus 108.
  • the computer system 100 may further include a video display unit 1 10 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)).
  • the computer system 100 also includes an alphanumeric input device 1 12 (e.g., a keyboard), a user interface (Ul) navigation device 1 14 (e.g., a mouse, or touchpad), a disk drive unit 1 16, a signal generation device 1 18 (e.g., a speaker) and a network interface device 120.
  • an alphanumeric input device 1 12 e.g., a keyboard
  • a user interface (Ul) navigation device 1 14 e.g., a mouse, or touchpad
  • a disk drive unit 1 16 e.g., a speaker
  • signal generation device 1 18 e.g., a speaker
  • the disk drive unit 16 includes a machine-readable medium 122 storing one or more sets of instructions and data structures (e.g., software 124) embodying or utilised by any one or more of the methodologies or functions described herein.
  • the software 124 may also reside, completely or at least partially, within the main memory 104 and/or within the processor 102 during execution thereof by the computer system 100, the main memory 104 and the processor 102 also constituting machine-readable media.
  • the software 124 may further be transmitted or received over a network 126 via the network interface device 120 utilising any one of a number of well-known transfer protocols (e.g., HTTP).
  • HTTP transfer protocol
  • machine-readable medium 122 is shown in an example embodiment to be a single medium, the term “machine-readable medium” may refer to a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions.
  • the term “machine-readable medium” may also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present invention, or that is capable of storing, encoding or carrying data structures utilised by or associated with such a set of instructions.
  • the term “machine-readable medium” may accordingly be taken to include, but not be limited to, solid-state memories, optical and magnetic media, and carrier wave signals.
  • the invention as described herein provides a secure way of facilitating a financial transaction between a purchaser and a merchant, particularly a transaction which occurs in realtime and requires the payment of a deposit or authorization of an amount almost instantaneously, for example, during a telephonic booking process, etc.
  • account information need not be shared with a merchant, in particular, a purchaser may select the contact information which they would like to share with the merchant. It will be noted that as the code is transmitted verbally from purchaser to merchant, and that due to the verbal nature of transaction, the agreement regarding the terms and conditions provides an immutable recording thereof.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Marketing (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computational Linguistics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

L'invention concerne un système de transaction financière, et un procédé de commande associé. Le système comprend une base de données configurée pour stocker des données de manière sécurisée, et des processeurs comprenant un module récepteur acheteur, un module de génération de code de sécurité, un module de transmission de code, et un module récepteur marchand. Le module récepteur acheteur est configuré pour recevoir des données de transaction associées à une transaction. Le module de génération de code de sécurité est configuré pour générer un code de sécurité lié à une transaction temporisée, en réponse à la réception de données de transaction. Le module de transmission de code est utilisé pour transmettre le code de sécurité devant être utilisé par un acheteur. Le module récepteur marchand est configuré pour : recevoir un code de sécurité transmis par un commerçant à un dispositif point d'extrémité, ledit code étant reçu d'un acheteur en lien avec une transaction ; et déterminer si le code de sécurité reçu est valide, de sorte à traiter la transaction.
PCT/IB2016/056740 2015-11-09 2016-11-09 Système de transaction, et procédé de commande associé WO2017081620A2 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US15/774,571 US20180330366A1 (en) 2015-11-09 2016-11-09 A transaction system and method of operating same
ZA2018/03603A ZA201803603B (en) 2015-11-09 2018-05-30 A transaction system and method of operating same

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
ZA2015/08237 2015-11-09
ZA201508237 2015-11-09
ZA201600617 2016-01-28
ZA2016/00617 2016-01-28

Publications (2)

Publication Number Publication Date
WO2017081620A2 true WO2017081620A2 (fr) 2017-05-18
WO2017081620A3 WO2017081620A3 (fr) 2017-07-06

Family

ID=58695963

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2016/056740 WO2017081620A2 (fr) 2015-11-09 2016-11-09 Système de transaction, et procédé de commande associé

Country Status (3)

Country Link
US (1) US20180330366A1 (fr)
WO (1) WO2017081620A2 (fr)
ZA (1) ZA201803603B (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11551205B2 (en) * 2017-04-03 2023-01-10 Plc Group Ag Method for producing a cryptographical signed transaction

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
PL356106A1 (en) * 1999-11-30 2004-06-14 Citibank, N.A. System and method for performing an electronic transaction using a transaction proxy with an electronic wallet
US8820637B1 (en) * 2005-02-26 2014-09-02 James A. Roskind Time-varying security code for enabling authorizations and other uses of financial accounts
US20110119190A1 (en) * 2009-11-18 2011-05-19 Magid Joseph Mina Anonymous transaction payment systems and methods
US8831979B1 (en) * 2011-05-06 2014-09-09 Howard Jeffrey Gerson System and method for anonymous processing of financial transactions
US8430308B2 (en) * 2011-09-19 2013-04-30 Bank Of America Corporation Authorizing financial transactions

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11551205B2 (en) * 2017-04-03 2023-01-10 Plc Group Ag Method for producing a cryptographical signed transaction

Also Published As

Publication number Publication date
WO2017081620A3 (fr) 2017-07-06
US20180330366A1 (en) 2018-11-15
ZA201803603B (en) 2019-03-27

Similar Documents

Publication Publication Date Title
US11694200B2 (en) Secure account creation
US20230059316A1 (en) Systems and methods for performing financial transactions using active authentication
US20210390548A1 (en) Passwordless authentication through use of device tokens or web browser cookies
US20180211244A1 (en) Integrated security system
RU2438172C2 (ru) Способ и система для осуществления двухфакторной аутентификации при транзакциях, связанных с заказами по почте и телефону
US20180150830A1 (en) System, process and device for e-commerce transactions
US20140297538A1 (en) System and Method for Data and Identity Verification and Authentication
RU2597515C2 (ru) Осуществление доступа к счету в пункте продажи
US10949859B2 (en) Enhancing information security via the use of a dummy credit card number
US20170011400A1 (en) Friendly Funding Source
US20120028612A1 (en) Method and system for verifying an identification of a person
WO2015195176A1 (fr) Authentification à deux facteurs pour la facturation de paiements
US20170345003A1 (en) Enhancing electronic information security by conducting risk profile analysis to confirm user identity
EP3616111B1 (fr) Système et procédé permettant de générer des justificatifs d'accès
US20190164161A1 (en) System and method for Sharing account anonymously and using image coded account for easy transactions
US10997654B1 (en) Identity verification services through external entities via application programming interface
US20240135339A1 (en) Secure and compliant multi-cryptocurrency payment gateway
US20180330366A1 (en) A transaction system and method of operating same
CN112840337B (zh) 身份认证系统和方法
US20200387892A1 (en) Systems and methods for temporary account sharing via a mobile wallet

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16863763

Country of ref document: EP

Kind code of ref document: A2

DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
WWE Wipo information: entry into national phase

Ref document number: 15774571

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16863763

Country of ref document: EP

Kind code of ref document: A2