WO2014124492A1 - Système et procédé de paiement - Google Patents

Système et procédé de paiement Download PDF

Info

Publication number
WO2014124492A1
WO2014124492A1 PCT/AU2014/000121 AU2014000121W WO2014124492A1 WO 2014124492 A1 WO2014124492 A1 WO 2014124492A1 AU 2014000121 W AU2014000121 W AU 2014000121W WO 2014124492 A1 WO2014124492 A1 WO 2014124492A1
Authority
WO
WIPO (PCT)
Prior art keywords
merchant
payment
transaction
customer
threshold
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/AU2014/000121
Other languages
English (en)
Inventor
Ross Mckinnon
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
MICHAEL HILL GROUP SERVICES Pty Ltd
Original Assignee
MICHAEL HILL GROUP SERVICES Pty Ltd
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
Priority claimed from AU2013900513A external-priority patent/AU2013900513A0/en
Application filed by MICHAEL HILL GROUP SERVICES Pty Ltd filed Critical MICHAEL HILL GROUP SERVICES Pty Ltd
Publication of WO2014124492A1 publication Critical patent/WO2014124492A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/42—Confirmation, e.g. check or permission by the legal debtor of payment
    • G06Q20/425—Confirmation, e.g. check or permission by the legal debtor of payment using two different networks, one for transaction and one for security confirmation
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network systems
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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

Definitions

  • the present invention relates to financial transactions.
  • the invention relates to a payment system and method.
  • Cashless payment methods have thus become more popular, including credit and debit card payments.
  • a bank will typically grant a customer a revolving line of credit, which is available to merchants when the customer makes purchases. The customer can then pay a credit card bill, long after the merchant has received money relating to the transaction.
  • Credit and debit card payment is popular among merchants, as the merchant does not take a risk associated with the customer not paying off a line of credit, or risk the delayed payment associated with maintaining a line of credit. Furthermore, a theft risk is reduced when lower volumes of cash are handled by the merchant.
  • a problem with such credit card payment systems is that payment involves multiple entities, and includes multiple steps, each of which is associated with a risk, and thus fees are in total generally high.
  • a payment is first authorized by a card issuer, and at a later time final transaction data is sent from an acquirer to the issuer for settlement, where an actual exchange of funds takes place.
  • steps are performed using a payment gateway or system, further complicating the transaction.
  • the invention resides in a payment method, the payment method including:
  • a request for payment including a transaction amount and customer details
  • the method further comprises retrieving details of the customer mobile phone from a data store.
  • approving the transaction further comprises obtaining authorisation of the transaction from an issuer associated with the customer details.
  • the method further comprises:
  • the further security information associated with the second security measure comprises an image of the customer captured by the merchant.
  • approving the transaction comprises automatically comparing the image of the customer with an image associated with the customer details.
  • the method further comprises:
  • the first merchant payment threshold storing, on the data store, the first merchant payment threshold; and associating, by a processor, the first merchant payment threshold with the merchant and the first security measure.
  • the one-time identifier is a character string code or a security question having a clearly defined answer.
  • the one-time identifier is a server-generated security token.
  • the invention resides in a payment system, accessible by a plurality of merchants and a plurality of customers, the payment system including:
  • a data store including a plurality of merchant managed rules, each merchant managed rule associated with a merchant and associated with a fraud risk;
  • a server including:
  • a data interface coupled to the processor; and a memory coupled to the processor, the memory including instruction code executable by the processor for:
  • a request for payment including a transaction amount and customer details
  • FIG. 1 illustrates a payment system, according to an embodiment of the present invention
  • FIG. 2 illustrates a payment system, similar to the payment system of FIG. 1 , but without a dedicated point-of-sale device, according to an embodiment of the present invention
  • FIG. 3 illustrates a payment system, similar to the payment systems of FIG. 1 and FIG. 2, adapted for e-commerce, according to an embodiment of the present invention
  • FIG. 4 illustrates a mobile transaction device, according to an embodiment of the present invention
  • FIG. 5 illustrates a screenshot of a primary purchase approval screen, according to an embodiment of the present invention
  • FIG. 6 illustrates a screenshot of a secondary purchase approval screen, according to an embodiment of the present invention
  • FIG. 7 illustrates a screenshot of a purchase approval screen, according to an embodiment of the present invention.
  • FIG. 8 illustrates a payment system, according to an embodiment of the present invention
  • FIG. 9 diagrammatically illustrates a computing device, according to an embodiment of the present invention.
  • FIG. 10 illustrates a payment method, according to an embodiment of the present invention.
  • Embodiments of the present invention comprise payment systems and methods. Elements of the invention are illustrated in concise outline form in the drawings, showing only those specific details that are necessary to the understanding of the embodiments of the present invention, but so as not to clutter the disclosure with excessive detail that will be obvious to those of ordinary skill in the art in light of the present description.
  • adjectives such as first and second, left and right, front and back, top and bottom, etc., are used solely to define one element or method step from another element or method step without necessarily requiring a specific relative position or sequence that is described by the adjectives.
  • Words such as “comprises” or “includes” are not used to define an exclusive set of elements or method steps. Rather, such words merely define a minimum set of elements or method steps included in a particular embodiment of the present invention.
  • the invention resides in a payment method, the payment method including: receiving, from a merchant, a request for payment, the request for payment including a transaction amount and customer details; retrieving, from a data store, a first merchant payment threshold, the first merchant payment threshold corresponding to a threshold transaction amount associated with the merchant and a first security measure; determining that the transaction amount is greater than the first merchant payment threshold; generating, by a processor, a first security measure in the form of a one-time identifier associated with the transaction; sending the one-time identifier to a customer mobile phone, for entry by a customer into a merchant device; receiving, on the data interface, security information associated with the one-time identifier; and approving the transaction based upon at least the security information and the customer details.
  • Advantages of some embodiments of the present invention include an ability to provide improved payment security, which can in turn reduce cost relating to managing payments.
  • Fraud management is merchant based, and each merchant can manage a risk they are willing to take in a transaction, thus preventing excessive fees by third parties having to cover these risks without specific knowledge of the industry in which the merchant operates, or the merchant's fraud management practices.
  • certain embodiments involve 'bidding' among issuers, thus ensuring that consumers receive low interest rates and/or better conditions associated with a transaction.
  • FIG. 1 illustrates a payment system 100, according to an embodiment of the present invention.
  • the payment system 100 is accessible by a plurality of merchants and for a plurality of customers, and enables fast and secure transactions.
  • the payment system 100 includes a point-of-sale device 105, and a mobile transaction device 110, which are typically located at a shop of a merchant.
  • the point-of-sale device 105 and the mobile transaction device 110 are used by the merchant to initiate, authenticate and complete payment transactions.
  • the payment system 100 further includes a clearing house server 115 and an issuer gateway 120.
  • the clearing house server 115 is in communication with the point-of-sale device 105 and the mobile transaction device 110 by a data communication network 125, such as the Internet.
  • the clearing house server 115 manages funds transfers.
  • the issuer gateway 120 is connected to the clearing house server 115 by a data communication network 130, which can be similar or identical to the data communication network 125.
  • the issuer gateway 120 corresponds to a card issuer of the customers, and includes details of the customers' accounts.
  • the payment system 100 is in communication with a customer mobile phone 135 by a mobile network 140, such as a Global System for Mobile Communications (GSM) telecommunication network.
  • a mobile network 140 such as a Global System for Mobile Communications (GSM) telecommunication network.
  • GSM Global System for Mobile Communications
  • the customer mobile phone 135 is used for added security, as it is unlikely that a fraudster will obtain access to both a customer's credit card, and their mobile phone.
  • a transaction is initiated at the point-of-sale device 105.
  • Details of the transaction are sent from the point-of-sale device 105 to the clearing house server 1 15, as illustrated by message 'a'.
  • the clearing house server 115 then sends transaction details to the mobile transaction device 110, as illustrated by message 'b', which are then presented on the mobile transaction device 110, for approval by the customer.
  • the customer then taps a customer card against the mobile transaction device 110 to approve the purchase, upon which details of the customer card are captured and sent to the clearing house server 115, as illustrated by message 'c'.
  • the customer card and the mobile transaction device 1 10 can, for example, transfer data by near field communication (NFC) and radio- frequency identification (RFID), by scanning an image or barcode on the card, or by reading a magnetic strip of the card.
  • NFC near field communication
  • RFID radio- frequency identification
  • the clearing house server 115 processes the details of the transaction to determine if further authentication is required.
  • the further authentication is achieved using security information in the form of a one-time identifier.
  • a one-time identifier can be a character string code, a security question having a clearly defined answer, or another form of server-generated security token.
  • the clearing house server 115 processes the details of the customer card, and retrieves details of the customer mobile phone 135. This can be achieved using a database including details of customer cards and customer mobile phone numbers.
  • the one-time identifier is generated and sent to the customer mobile phone 135, as illustrated by message 'd'.
  • the customer upon receipt of the one-time identifier on the customer mobile phone 135, enters the one-time identifier or data associated with the one-time identifier, such as an answer to a security question, onto the mobile transaction device 1 10.
  • the one-time identifier is then sent from the mobile transaction device 110 to the clearing house server 115, as illustrated by message 'e'.
  • the one-time identifier is then verified by the clearing house server 115. After verification of the one-time identifier, transaction details are sent from the clearing house server 115 to the issuer gateway 120, as illustrated by message 'f.
  • the issuer gateway 120 processes the transaction details and sends a transaction approval to the clearing house server 115, as illustrated by message 'g'.
  • the clearing house server 15 then finalises the transaction, and sends approval confirmations to the point-of-sale device 105 and the mobile transaction device 1 10.
  • FIG. 1 illustrates a valid transaction where all approval, authentication and verification has been successful. If, for example, an authentication, verification or approval step is not successful, the transaction is stopped, and error messages are sent to the point-of-sale device 105 and the mobile transaction device 110 respectively.
  • FIG. 2 illustrates a payment system 200, similar to the payment system 100, but without a dedicated point-of-sale device.
  • the payment system 200 is particularly suited for on-site services, such as home electrical services, where portability is desirable. Similarly, the payment system 200 is suited to new shops, where there is not a need to integrate with existing point-of-sale equipment.
  • the payment system 200 includes a mobile point-of-sale device 210, which is similar to a combination of the point-of-sale device 105 and mobile transaction device 110 of FIG. 1.
  • the mobile point-of-sale device 210 is connected to a clearing house server 215, which is similar to the clearing house server 115 of FIG. 1.
  • a transaction is initiated at the mobile point-of-sale device 210.
  • the customer taps a customer card against the mobile point-of-sale device 210, upon which details of the customer card are read.
  • the clearing house server 215 processes the details of the transaction to determine if further authentication, in the form of a one-time identifier, is required. The clearing house server 215 then sends details of the further authentication required to the mobile point-of-sale device 210, as illustrated by message 'b1'. At approximately the same time, the clearing house server 215 automatically generates the one-time identifier, processes the details of the customer card, retrieves details of the customer mobile phone 135, and sends the one-time identifier to the customer mobile phone 135, as illustrated by message 'c1'.
  • the mobile point-of-sale device 210 displays a graphical user interface enabling the customer to enter the one-time-pin into the mobile point-of-sale device 210.
  • the customer Upon receipt of the one-time identifier, the customer enters the one-time identifier onto the mobile point-of-sale device 210 using, for example, a virtual keypad.
  • the one-time identifier is then sent from the mobile point-of-sale device 210 to the clearing house server 215, as illustrated by message 'd1'.
  • the one-time identifier is then verified by the clearing house server 215, after which transaction details are sent from the clearing house server 215 to the issuer gateway 120, as illustrated by message 'e1'.
  • the issuer gateway 120 processes the transaction details returns a transaction approval to the clearing house server 215, as illustrated by message 'f1'.
  • the clearing house server 215 then finalises the transaction, and sends approval confirmation to the mobile point-of-sale device 210, as illustrated by message 'g1'.
  • the approval confirmation can include an image of the customer, for verification by the merchant.
  • FIG. 3 illustrates a payment system 300, similar to the payment systems 100, 200 of FIG. 1 and FIG. 2, adapted for e-commerce.
  • the payment system 300 is particularly suited for online sales and bookings, and/or when payment is made online.
  • the payment system 300 includes an e-commerce server 305, which provides an e-commerce web page to a plurality of customer computers 310.
  • the e-commerce web page can, for example, comprise a traditional e-commerce store, including goods available for purchase using a shopping cart, or an online auction site.
  • the payment system 300 also includes a clearing house server 315, similar to the clearing house server 115 of FIG. 1.
  • a transaction is initiated at the customer computer 310, by entering details of a customer card into a website provided by the e- commerce server 305.
  • the details of the customer card can include, for example, a card number, and an expiry date.
  • Details of the transaction are sent from the customer computer 310 to the e-commerce server 305, as illustrated by message 'a2'.
  • the e-commerce server 305 then sends details of the transaction, including the details of the customer card and a transaction amount, to the clearing house server 315, as illustrated by message 'b2'.
  • the clearing house server 315 processes the details of the transaction to determine the details of the customer mobile phone 135, automatically generates a one-time identifier, and sends the one-time identifier to the customer mobile phone 135, as illustrated by message 'c2'. As there is no direct contact between a merchant and the customer when a transaction is performed online, the one-time identifier form of verification is used for all such transactions.
  • the customer computer 310 displays a graphical user interface enabling the customer to enter the one-time-pin into the device.
  • the customer Upon receipt of the one-time identifier, the customer enters the one-time identifier into the customer computer 310, upon which the one-time identifier is sent to the e-commerce server 305, as illustrated by message 'd2'.
  • the e-commerce server 305 then sends the one-time identifier to the clearing house server 315, as illustrated by message 'e2'.
  • the one-time identifier is then verified by the clearing house server 315, after which transaction details are sent from the clearing house server 315 to the issuer gateway 120, as illustrated by message 'f2'.
  • the issuer gateway 120 processes the transaction details returns a transaction approval to the clearing house server 315, as illustrated by message 'g2'.
  • the clearing house server 315 then finalises the transaction, and sends approval confirmation to the e-commerce server 305, as illustrated by message 'h2'.
  • the e-commerce server 305 can then finalise the transaction, and can, for example, send an email confirmation to the customer.
  • FIG. 4 illustrates a mobile transaction device 400, according to an embodiment of the present invention.
  • the mobile transaction device 400 can be similar or identical to the mobile transaction device 105 of FIG. 1.
  • the mobile transaction device 400 can be similar or identical to the mobile point-of-sale device 210 of FIG. 2
  • the mobile transaction device 400 includes a capacitive touch screen 405, a user interaction button 410, and a camera 415, all attached to a body 420.
  • the body 420 is substantially rectangular in shape, and is sized to enable portable operation.
  • the merchant and customer interact with the mobile transaction device 400 primarily through the capacitive touch screen 405, where icons, buttons and other selectable elements are displayed, as discussed further below.
  • the user interaction button 410 can, however, be user for certain interaction in the system, such as navigating between applications ('apps') on the mobile transaction device 400.
  • the mobile transaction device 400 has a processor and memory (not shown), the memory including program code executable by the processor.
  • the program code can comprise operating system code, such as Android operating system code, by Google Inc. of Mountain View, California.
  • the mobile transaction device 400 further includes a wireless network adapter (not shown), which enables the mobile transaction device 400 to communicate with other devices and entities.
  • the wireless adapter can communicate with a local base, such as a particular wireless hotspot, or more advantageously connect to a cellular network.
  • the camera 415 enables the mobile transaction device 400 to capture images of the user, for example the customer. As discussed above, this enables a user to capture an image of a card of the customer, such as a barcode, Quick Response (QR) code printed on the card, or to capture an image of the customer for security reasons.
  • a card of the customer such as a barcode, Quick Response (QR) code printed on the card
  • FIG. 5 illustrates a screenshot 500 of a primary purchase approval screen, according to an embodiment of the present invention.
  • the primary purchase screen is typically the first screen that a customer will see after choosing to purchase an item.
  • the primary purchase screen includes a merchant logo 505, which is customisable by the merchant. This will typically comprise a general trade mark of the merchant, but can comprise any image.
  • the primary purchase screen further includes a purchase total 510, which corresponds to an amount that the merchant is requesting from the customer in payment.
  • the purchase total 510 does not need to correspond directly to a purchase amount of an item or service, as vouchers, cash or other payment forms can be used for part payment.
  • the primary purchase screen includes purchase approval instructions 515, which indicate that the customer should tap their card against the device.
  • purchase approval instructions 515 are configured specifically for NFC based card communications, however, the purchase approval instructions
  • 515 can be modified to suit any purchase approval method, including scanning a card using other means, and entering card details manually.
  • a server such as a clearing house server
  • FIG. 6 illustrates a screenshot 600 of a secondary purchase approval screen, according to an embodiment of the present invention.
  • the secondary purchase approval screen can be used when, for example, a threshold purchase amount is reached, in order to provide extra security.
  • the secondary purchase approval screen includes a merchant logo
  • the secondary purchase screen also includes a purchase total 610, similar to the purchase total 510 of FIG. 5.
  • the secondary purchase approval screen further includes secondary purchase approval instructions 615, a one-time-pin entry field
  • the secondary purchase approval instructions 615 indicate to the customer that the customer should enter their one-time-pin into the device.
  • the one-time-pin can be sent to the customers mobile phone by text messaging.
  • the customer can, for example, enter the one-time-pin into the onetime-pin entry field 620 using a data entry apparatus, such as a keyboard, associated with the device, or by using a virtual keyboard and a touch screen.
  • the confirmation button 625 the one-time-pin is sent to the server for verification and approval of the purchase, as discussed above.
  • FIG. 7 illustrates a screenshot 700 of a purchase approval screen, according to an embodiment of the present invention.
  • the purchase approval screen is displayed to the merchant upon approval of the purchase.
  • the purchase approval screen includes a merchant logo 705, similar to the merchant logo 505 of FIG. 5, and a purchase approval indication 710.
  • a purchase denial message (not shown) can be displayed in place of the purchase approval indication 710 if the purchase is not approved.
  • the purchase approval screen includes purchase approval instructions 715, an accountholder photo 720, an approve transaction button 725 and a cancel transaction button 730.
  • the accountholder photo 720 has been retrieved from a database, and corresponds to an official image of the accountholder.
  • the merchant compares the customer with the accountholder photo 720, for security purposes. This prevents use of a lost or stolen card, even if access to the accountholders telephone is available.
  • the merchant selects the approve transaction button 725. The transaction is then finalised. Alternatively, a cancel transaction button 730 is selected, upon which the transaction is cancelled.
  • FIG. 8 illustrates a payment system 800, according to an embodiment of the present invention.
  • the payment system 800 is similar to the payment system 200 of FIG. 2, but with the addition of several issuer gateways 820.
  • the payment system 800 includes the mobile point-of-sale device 210, which is connected to a clearing house server 815, which is similar to the clearing house server 215 of FIG. 2.
  • a transaction is initiated at the mobile point-of-sale device 210, as discussed earlier, and the mobile point-of-sale device 210 interacts with the clearing house server 815 in the same way as illustrated with reference to FIG. 2 and in particular as illustrated by messages 'a1 ⁇ • b1 ⁇ 'gr and 'dr.
  • authorisation requests are sent from the clearing house server 815 to the issuer gateways 820, as illustrated by messages ' ⁇ '-' ⁇ '.
  • the issuer gateways 820 process the authorisation requests and return transaction approval information, as illustrated by messages 'yl'-'yn'.
  • the transaction approval information includes, in addition to information regarding whether or not the transaction has been approved, details of conditions associated with the transaction, such as interest rates, payment terms and/or other conditions.
  • the clearing house server 815 selects an issuer based upon the transaction approval information provided by each of the issuer gateways 820. According to certain embodiments, the issuer is selected based upon a lowest interest rate offered, a highest reward, or most favourable conditions otherwise.
  • the approval confirmation which is sent to the mobile point-of-sale device 210, can include details of the selected issuer as well as an image of the customer.
  • a settlement request can later be initiated with the selected issuer, in order to initiate settlement with the merchant.
  • FIG. 9 diagrammatically illustrates a computing device 900, according to an embodiment of the present invention.
  • the mobile transaction device 110, the clearing house server 115, 215, 315, 815, the mobile point-of-sale device 210, the e-commerce server 305, and the mobile transaction device 400 can be similar or identical to the computing device 900.
  • the computing device 900 includes a central processor 902, a system memory 904 and a system bus 906 that couples various system components, including coupling the system memory 904 to the central processor 902.
  • the system bus 906 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures.
  • the structure of system memory 904 is well known to those skilled in the art and may include a basic input/output system (BIOS) stored in a read only memory (ROM) and one or more program modules such as operating systems, application programs and program data stored in random access memory (RAM).
  • BIOS basic input/output system
  • ROM read only memory
  • RAM random access memory
  • the computing device 900 may also include a variety of interface units and drives for reading and writing data.
  • the computing device 900 includes a hard disk interface 908 and a removable memory interface 910, respectively coupling a hard disk drive 912 and a removable memory drive 914 to the system bus 906.
  • removable memory drives 914 include magnetic disk drives and optical disk drives.
  • the drives and their associated computer-readable media, such as a Digital Versatile Disc (DVD) 916 provide non-volatile storage of computer readable instructions, data structures, program modules and other data for the computer system 900.
  • a single hard disk drive 912 and a single removable memory drive 914 are shown for illustration purposes only and with the understanding that the computing device 900 may include several similar drives.
  • the computing device 900 may include drives for interfacing with other types of computer readable media.
  • the computing device 900 may include additional interfaces for connecting devices to the system bus 906.
  • FIG. 9 shows a universal serial bus (USB) interface 918 which may be used to couple a device to the system bus 906.
  • USB universal serial bus
  • an IEEE 1394 interface 920 may be used to couple additional devices to the computing device 900.
  • the computing device 900 can operate in a networked environment using logical connections to one or more remote computers or other devices, such as a server, a router, a network personal computer, a peer device or other common network node, a wireless telephone or wireless personal digital assistant.
  • the computing device 900 includes a network interface 922 that couples the system bus 906 to a local area network (LAN) 924.
  • LAN local area network
  • a wide area network such as the Internet
  • network connections shown and described are exemplary and other ways of establishing a communications link between computers can be used.
  • the existence of any of various well-known protocols, such as TCP/IP, Frame Relay, Ethernet, FTP, HTTP and the like, is presumed, and the computing device 900 can be operated in a client-server configuration to permit a user to retrieve web pages from a web-based server.
  • any of various conventional web browsers can be used to display and manipulate data on web pages.
  • the operation of the computing device 900 can be controlled by a variety of different program modules.
  • program modules are routines, programs, objects, components, and data structures that perform particular tasks or implement particular abstract data types.
  • the present invention may also be practiced with other computer system configurations, including hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, personal digital assistants and the like.
  • the invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network.
  • program modules may be located in both local and remote memory storage devices.
  • FIG. 10 illustrates a payment method, according to an embodiment of the present invention.
  • a request for payment is received from a merchant.
  • the request for payment includes a transaction amount and customer details.
  • the customer details can include, for example, details of a customer card.
  • a first merchant payment threshold is retrieved from a data store.
  • the first merchant payment threshold corresponds to a threshold transaction amount associated with the merchant and a first additional security measure.
  • Each merchant is able to set different payment thresholds for security measures, based upon the nature of the business the merchant operates, or the level of risk the merchant is willing to take.
  • an address based subscription service may have a high payment threshold for security measures, as it can both be easily determined who (i.e. which address) is receiving the service, and the subscription can be cancelled if needed.
  • Foreign exchange services may have low payment thresholds, as the cash provided in such a service is often at a relatively low profit, and is virtually untraceable after a transaction is made.
  • step 1015 it is determined that the transaction amount is greater than the first merchant payment threshold. Therefore, as an added security measure, a one-time identifier is sent to a customer's mobile phone.
  • step 1020 security information associated with the additional security measure and the request for payment is received on the data interface. This can, for example, comprise receiving data on a web form, or receiving a message including security information associated with the one-time identifier that was sent to the customer's mobile phone.
  • step 1025 the transaction is approved based upon at least the security information and the customer details. According to certain embodiments, the transaction is approved based upon a credit authorisation.
  • advantages of some embodiments of the present invention include an ability to provide improved payment security, which can in turn reduce cost relating to managing the payments.
  • Fraud management is merchant based, and each merchant can manage a risk they are willing to take in a transaction, thus preventing excessive fees by third parties having to cover these risks without specific knowledge of the industry in which the merchant operates, or the merchant's fraud management practices.
  • Certain embodiments involve 'bidding' among issuers, thus ensuring that consumers receive low interest rates and/or better conditions associated with a transaction.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

L'invention concerne un procédé de paiement permettant d'améliorer la sécurité des paiements. Le procédé de paiement consiste à recevoir, en provenance d'un commerçant, une demande de paiement, la demande de paiement incluant un montant de transaction et des coordonnées du client. En réponse, un premier seuil de paiement de commerçant est récupéré à partir d'un magasin de données, le premier seuil de paiement de commerçant correspondant à un montant de transaction seuil associé au commerçant et à une première mesure de sécurité. Si le montant de la transaction est alors déterminé comme étant supérieur au premier seuil de paiement de commerçant, une première mesure de sécurité sous la forme d'un identifiant unique associé à la transaction est générée par un processeur. L'identifiant unique est ensuite envoyé à un téléphone mobile du client. Sur l'interface de données, des informations de sécurité associées à l'identifiant unique sont ensuite reçues, et la transaction est approuvée sur la base au moins des informations de sécurité et des coordonnées du client.
PCT/AU2014/000121 2013-02-14 2014-02-13 Système et procédé de paiement Ceased WO2014124492A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
AU2013900513A AU2013900513A0 (en) 2013-02-14 Payment system and method
AU2013900513 2013-02-14

Publications (1)

Publication Number Publication Date
WO2014124492A1 true WO2014124492A1 (fr) 2014-08-21

Family

ID=51353426

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/AU2014/000121 Ceased WO2014124492A1 (fr) 2013-02-14 2014-02-13 Système et procédé de paiement

Country Status (1)

Country Link
WO (1) WO2014124492A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050224573A1 (en) * 2004-04-09 2005-10-13 Oki Electric Industry Co., Ltd. Identification system using face authentication and consumer transaction facility
GB2463299A (en) * 2008-08-29 2010-03-10 Etranzact Global Ltd Authenticating a transaction using a one-time pass code generated on a mobile device

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050224573A1 (en) * 2004-04-09 2005-10-13 Oki Electric Industry Co., Ltd. Identification system using face authentication and consumer transaction facility
GB2463299A (en) * 2008-08-29 2010-03-10 Etranzact Global Ltd Authenticating a transaction using a one-time pass code generated on a mobile device

Similar Documents

Publication Publication Date Title
US10482465B2 (en) Method and system for hosted order page/silent order post plus fraud detection
US8635157B2 (en) Mobile system and method for payments and non-financial transactions
US9390412B2 (en) Dynamic point of sale system integrated with reader device
US9898719B2 (en) Systems, methods, and computer program products providing push payments
US20180068293A1 (en) Method and system for allowing offline peer-2-peer transactions using exchangeable provisioned tokens
US20120203666A1 (en) Contactless wireless transaction processing system
US20190066089A1 (en) Secure transactions using digital barcodes
US20140032410A1 (en) Method and system for linking and controling of payment cards with a mobile
US20160232527A1 (en) Token processing utilizing multiple authorizations
AU2019283784A1 (en) Methods and systems for providing 3-D secure service on-behalf-of merchants
US11030589B2 (en) Hosted disbursement system
US20180114224A1 (en) Authenticating transactions using risk scores derived from detailed device information
US20160048822A1 (en) Method and System for Delivering Funding Options to a User
US20150100486A1 (en) System and method for automatically enrollng an item in a virtual wallet
US20130290178A1 (en) System and method for effecting payment to a beneficiary including a real-time authorization of the payment
US10242354B2 (en) Selectively providing cash-based e-commerce transactions
US20210287217A1 (en) Method and system for secure real-time processing of an invoice pertaining to a transaction
US20190057383A1 (en) Method and system for chargeback prevention
KR20120100283A (ko) 전자결제 시스템 및 방법
KR20160010042A (ko) 실시간 계좌 이체, 계좌 추심을 통한 결제 방법, 서버 및 컴퓨터 판독 가능한 기록 매체
KR101692234B1 (ko) 신용한도를 포함한 정보를 제공받아 ict를 활용한 간편결제를 수행하는 방법
KR100897498B1 (ko) 유비쿼터스 환경에서의 통합형 금융 서비스 시스템
WO2014124492A1 (fr) Système et procédé de paiement
US12499442B2 (en) Online systems using currency at access device

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: 14751798

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 04.12.2015)

122 Ep: pct application non-entry in european phase

Ref document number: 14751798

Country of ref document: EP

Kind code of ref document: A1