US20170091775A1 - Secure authentication and payment system - Google Patents
Secure authentication and payment system Download PDFInfo
- Publication number
- US20170091775A1 US20170091775A1 US15/296,759 US201615296759A US2017091775A1 US 20170091775 A1 US20170091775 A1 US 20170091775A1 US 201615296759 A US201615296759 A US 201615296759A US 2017091775 A1 US2017091775 A1 US 2017091775A1
- Authority
- US
- United States
- Prior art keywords
- transaction
- consumer
- merchant
- user
- authentication
- 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.)
- Abandoned
Links
Images
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/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
- G06Q20/4014—Identity check for transactions
- G06Q20/40145—Biometric identity checks
-
- 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/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
- G06Q20/102—Bill distribution or payments
-
- 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/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/325—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks
-
- 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/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/325—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks
- G06Q20/3255—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks using mobile network messaging services for payment, e.g. SMS
-
- 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/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/327—Short range or proximity payments by means of M-devices
-
- 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
-
- 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
- G06Q20/4012—Verifying personal identification numbers [PIN]
-
- 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
- G06Q20/4014—Identity check for transactions
-
- 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/405—Establishing or using transaction specific rules
-
- 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/409—Device specific authentication in transaction processing
-
- 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
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- Strategic Management (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Finance (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Economics (AREA)
- Development Economics (AREA)
- Marketing (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
The present invention provides a service for allowing secure financial transactions to be carried out, the service involving authenticating a user's identity and/or status as part of a financial transaction with another party and in the event that the user is authenticated arranging for the transaction to be completed without revealing the user's financial details and/or other personal details to that other party. Authentication data and transaction data may be communicated over any suitable communications channel(s). The invention provides a trusted authentication and payment environment that protects a user's financial details, but allows them to be securely authenticated and arranges for transactions to be fulfilled, whilst providing other parties with reassurance that transactions will be completed. In this way, fraud and theft due to misappropriation of financial details can be minimized.
Description
- This application is a continuation of U.S. application Ser. No. 14/716,519, filed May 19, 2015, which is a continuation of U.S. application Ser. No. 13/838,764, filed on Mar. 15, 2013, which is a continuation of U.S. application Ser. No. 11/692,656, filed Mar. 28, 2007, which is based on, and claims priority to GB Application No. 0621189.0, filed Oct. 25, 2006, the entire contents of each of which are incorporated fully herein by reference.
- The present invention relates to a system, method and apparatus for identity authentication and/or secure payment.
- Technology has revolutionized the way that consumers make purchases and expanded the range of retail channels. Goods may be purchased in a range of ways including traditional face-to-face purchases, mail order and telephone order as well as more recent retail formats such as Internet shopping, purchase by mobile phone and other contactless purchase methods. The number of payment options has also expanded to suit and include credit cards, debit cards, charge cards, contactless wallet payment systems such as Oyster, Speedpass and vending cards, direct debit from bank accounts and payment using mobile phone accounts. This proliferation of payment and retail systems, whose transactions are often conducted remotely or between consumers and merchants who have little or no prior relationship, has led to a change in the security challenges faced by consumers, merchants and financial institutions.
- Using existing payment card systems in transactions such as mail order, Internet shopping and purchases over the telephone, a consumer gives their complete payment and identity details up front and has to trust that the goods and services will be delivered and that the merchant is legitimate and uses the details given only for processing that order. This exposes the consumer to identity theft, theft of payment details and payment fraud via, for example, phishing, swiping cards through non-authorized card readers and simple misuse or copying of card details. These theft and fraud threats are not presently secured by existing payment security methods such as those typically employed by credit card processors. Similarly, merchants must trust that the consumer has given the correct identity, is an authorized user of the payment method and that the payment details are correct. In addition, merchants are exposed to identity fraud or deception where payment or account details have been stolen.
- To meet these challenges, credit card companies and financial institutions are putting security measures into place. The introduction of chip and PIN (EMV authentication) in the UK for card transactions has reduced fraud in the face-to-face market. Whilst this is undoubtedly a significant improvement in security, face-to-face fraud does still occur, exemplified by some major merchants withdrawing their chip and PIN payment terminals after their compromise. Indeed, a direct consequence of chip and PIN at point of sale is that consumers are now open to greater risk of shoulder surfing. Further threats to security may arise from the use of electronic “bugging” equipment in point of sale terminals.
- Card detail theft is also an issue, with fraudsters using legitimate card details to perpetrate non-face-to-face and face-to-face payment theft. This is because existing terminals and PIN pads are designed to accept many cards from consumers without requiring specific validation by the merchant or staff members before use. In addition, terminals that are not validated by the registered merchant can give rise to high fraud levels if compromised. This is due to the lack of accountability over their security, and the nature, size and technical needs of existing terminals and PIN pads, making it difficult to keep them secure when not being used. Furthermore, card details taken from the face and back of payment cards can be fraudulently used across non-chip and PIN channels.
- According to the present invention, there is provided a service for allowing secure financial transactions to be carried out, the service involving authenticating a user's identity and/or status as part of a financial transaction with another party and in the event that the user is authenticated arranging for the transaction to be completed without revealing the user's financial details and/or other personal details to that other party.
- Authentication data and transaction data may be communicated over any suitable communications channel, and in some circumstances are preferably communicated over different communications channels.
- The invention provides a trusted authentication and payment environment that protects a user's financial details, but allows them to be securely authenticated and arranges for transactions to be fulfilled, whilst providing other parties with reassurance that transactions will be completed. In this way, fraud and theft due to misappropriation of financial details can be minimized.
- Authenticating the user may involve receiving authentication data input by the user via a communications channel. Multiple communications channels may be available. For example, user data may be received via a wireless telecommunications network and/or the Internet and/or e-mail and/or any other suitable communications channel. Preferably, the method involves allowing the user to select a preferred communications channel. Different communications channels may be selected for different transaction types. For example, the user may prefer to communicate authentication data via a mobile telephone network, when transacting via the Internet.
- Communications to the user may be sent via any suitable communications channel, for example a wireless telecommunications network and/or the Internet and/or e-mail. Preferably, communications to the user are sent via a different channel to those from the user. For example, messages may be sent to the user via e-mail but received from the user via a mobile telephone network. Events of which the user may be notified include authentication failures and/or mismatch of order details supplied by differing users and/or the order is available for dispatch and/or the order is only partially fulfilled and/or a payment is refused and/or a transaction has been referred and/or the consumer has, or is close to, breach of their operating parameters. A confirmation may be sent and payment may be withheld until the confirmation is received. The user being notified may have to provide identification information before access is given to the notification.
- The authentication may be two-stage, but preferably is three-stage. Each authentication stage may involve input of personal identification numbers and/or code words and/or personal details and/or answers to challenge questions and/or matching of a user with a list of authorized users for a transaction device and/or cross referencing two or more sets of input authentication data. Authentication may involve comparing the input data with user related data stored by the system. Authentication may involve online and/or offline authentication stages.
- The service may allow a user to register one or more payment means. The user may assign a particular payment means for use in specified transactions. For example, the user may specify that a credit card is to be used for Internet transactions, but a debit card is to be used with person to person transactions. Additionally or alternatively, the user may specify that a particular card or account may be used for transactions only with a particular organization, such as a merchant or retailer. Payment may be made when the paying user's authentication/identification code is provided rather than details of the payment means to be used.
- One of the user's payment means may be used in the step of authenticating the user. The payment means used for authentication is preferably different from the payment means used to complete the transaction. This provides an added level of security for the user.
- The service may further include storing authentication data associated with at least one user and authentication is by comparing data supplied by the user with stored authentication data. The authentication may be associated with a transaction. The transaction may be a purchase or a cash withdrawal or money transfer.
- The service may further include defining operating parameters for a user and checking that transactions do not breach those operating parameters before making payment.
- The service may further involve allocating a user identification code to a first user, providing the first user's identification code to a second user and comparing the first user's identification code with data stored in user records to confirm that the first user is a registered user of the system.
- Payment may be held in escrow until goods have been dispatched. This provides an added level of security for users, especially when the transaction is via Internet or mail order.
- According to another aspect of the invention, there is provided a transaction system that is configured to authenticate a user and arrange a financial transaction with another party based on the user's authentication and without disclosing the user's financial details and/or personal identity to that other party.
- Preferably, the transaction is payment for goods and/or services. Preferably, the system includes authentication means for authenticating the user and payment means that are functionally and/or physically separate from authentication means, the payment means being adapted to arrange for payments.
- By separating authentication from the transaction, users can be authenticated and transactions authorized without providing the user's financial details to other users. This provides protection against misuse of, for example a user's debit or credit card, should it become compromised. In this way, fraud and theft due to misappropriation of financial details can be minimized.
- All users that are party to a transaction may be authenticated in the same way, regardless of whether they are retailers or consumers. This minimizes fraud on both sides of a transaction.
- The system may be adapted to receive order details from at least two users, for example a consumer and a merchant, and to compare the order details received from each user to ensure that both sets of orders are identical. The system may be adapted to arrange payment only if the order details match. In this way the system can minimize errors in the order process and also fraudulent altering of transactions.
- The system may be adapted to arrange payment directly from a user account, for example a credit or debit card account or any other financial vehicle provided to allow the user to make payments. Alternatively, before forwarding arranging for payment from a user account, the system may be adapted to receive payment and hold it in escrow until goods are dispatched or services provided and/or the user acknowledges the payment is valid.
- The payment may be a cash withdrawal or cash advance. The system may be adapted to be used with transactions over one or multiple transaction channels. This may be achieved by provision of a communications system for allowing users to interact with the system via for example the Internet (and other networks using an IP protocol), telephone or mobile data communications services.
- The transaction channels may include face-to-face, mail order, telephone order, Internet shopping, user-to-user transfers, purchase by mobile phone and other contactless purchase methods. In this way, the system provides a unitary authentication and payment management system that can be used in many retail formats, allowing the user to use one account and authentication method to centrally control many payment means and authenticate and arrange payment in many transaction channels.
- The system may be adapted to apply the same authentication regardless of transaction channel, so that a consistent level of security is applied in all transactions. Alternatively, differing authentication may be applied to differing transaction channels. This allows the degree of authentication to be tailored to suit factors related to the transaction channel such as the inherent security of the transaction channel.
- The system may be adapted to store authentication data associated with at least one user on the system. The system may authenticate the user's identity and/or status by comparing data supplied by the user with stored authentication data. The system may be adapted to carry out authentication associated with a transaction.
- The system may be adapted to receive data from a transaction device, the transaction device having means for inputting data and means for communicating data to the system. The means for inputting data may be a keypad and/or a trackball and/or a joystick and/or a biometric feature reader and/or a reader. The biometric feature reader may include a fingerprint reader and/or a retinal scanner and/or a voice analyzer. The card reader may be a chip card reader and/or a magnetic strip card reader and/or a radio frequency identification (RFID) card reader.
- The means for communicating data may include any wireless or mobile telecommunications apparatus and/or bluetooth communications apparatus and/or WiFi communications apparatus, such as WiFi 802.11 a/b/g communications apparatus and/or infrared communications apparatus and/or RFID communications apparatus and/or NFC communications apparatus and/or a USB port and/or a firewire port. The mobile telecommunications apparatus may be adapted to operate over GPRS or 3G or GSM or CDMA networks.
- The means for communicating data may be adapted to allow the transaction device to communicate with payment systems, for example RFID or NFC based payment systems, to allow the transaction device to operate in place of the payment means, e.g. a RFID card such as an Oyster card, associated with the payment system.
- Authentication may involve at least two-stages, and preferably three. Each authentication stage may require input of personal identification numbers and/or code words and/or personal details and/or answers to challenge questions and/or biometric data and/or matching of a user with a list of authorized users for a transaction device and/or valid reading of an EMV compliant card or other registered identity card and/or cross referencing two or more sets of provided authentication data. Authentication may involve comparing the input data with user related data stored by the system. Authentication may involve online and/or offline authentication stages.
- The system may be adapted to store user names and/or user identification codes and/or user addresses and/or user address codes and/or user payment account details and/or user operating parameters and/or user transaction histories and/or audit trails.
- The system may be adapted to process orders using a user identification code and a delivery address code uniquely associated with a user. The system may be adapted to receive the delivery address code of a first user, determine the address corresponding to the delivery address code and to provide the address to at least a second user only when the at least second user confirms that it is in a position to fulfill the transaction. By only revealing a user's address once all the users have been authenticated and only at a stage in the transaction when the information is necessary, the disclosure of user information is minimized, helping to prevent identity fraud.
- The system may be adapted to have more than one payment means associated with each user. Each payment means may be assigned for use in specified transactions. The system may be adapted to use a payment means to carry out a payment after authenticating both users and when provided with the paying user's identification code rather than details of the payment means (e.g. PayPal, credit card, etc.) to be used. This again minimizes the information disclosed by a user during a transaction and helps prevent identity fraud and misuse of payment details.
- The system may be adapted to send a notification to users to confirm events. The notification may be a short message service (SMS) message, e-mail, telephone call or message sent to a transaction device. Preferably, the notification is via a different notification method to the placing of the order. In this way, if a communications means is compromised and used to place a fraudulent transaction, then the user will receive notification of the transaction by a different communications channel, allowing them to detect and stop the fraudulent transaction.
- Events of which the user may be notified may include authentication failures and/or mismatch of order details supplied by differing users and/or the order is available for dispatch and/or the order is only partially fulfilled and/or a payment is to be made and/or a payment is refused and/or a transaction has been referred and/or the consumer has, or is close to, breach of their operating parameters.
- The system may be adapted to require a confirmation to the notification before processing a payment. The system may be adapted to obtain identification information from the user before providing access to the notification so as to prevent erroneous notification of someone other than the user.
- The system may be adapted to assign at least one user identity code to at least a first user, whereby the authentication means are adapted to validate the identity and/or status of the first user to a second user upon provision of the first user's identity code to the system by the second user.
- The user data used for validation may be whether or not a user is a registered user of the system and/or the user is transacting within specified criteria and/or the user account has permission for carrying out that transaction. The specified criteria may include that transactions values and/or transaction velocities are within a set limit or that the transaction is of a specified type. This allows the users to have increased confidence in transacting with other users.
- Each user may be associated with at least one sub user. The system may be adapted to register users or sub-users and to only allow access to the system by registered users or sub-users. For example, pre-registered and designated staff (sub-users) may transact on behalf of a retailer (user). This allows for individual traceability and accountability. Authentication of a user may include authentication of at least one associated sub-user.
- The system may require re-authentication by at least one user if a transaction has not been completed within a specified time-scale. The system may require at least one user to review and/or accept a transaction if the transaction has not been completed within a specified time-scale.
- The system may be adapted to allow each user to make or receive payments in a currency of choice. The system may be adapted to convert the currency of a payment such that the currency in which a payment is made is different to the currency in which the payment is received.
- According to yet another aspect of the invention, there is provided a transaction device for collecting and communicating authentication data having data input means and communications means for use with the method and system of the other aspects.
- According to a fourth aspect of the present invention, there is provided a computer program, or a storage means containing a computer program or a server programmed with a computer program for implementing any of the other aspects of the invention.
- According to yet another aspect of the invention, there is provided a method involving using an authentication means associated with a consumer to authenticate a merchant. Preferably, the authentication means is an authentication device, for example a mobile wireless authentication device. Preferably the consumer device comprises a card reader and/or a keypad and/or biometric feature reader and/or an RFID detector. Preferably the method further involves arranging payment from the consumer to the authenticated merchant using the consumer's authentication means.
- Various aspects of the invention will now be described by way of example only and with reference to the accompanying drawings of which:
-
FIG. 1 is an overview of the interaction between an authentication and payment system, users of the system, payment account issuers and merchant and payment acquiring banks and processors; -
FIG. 2 is a schematic representation of how the authentication and payment system interacts with a user and the user's accounts; -
FIG. 3 is a schematic of the authentication and payment system ofFIG. 1 ; -
FIG. 4 is a further schematic of the components of the authentication and payment system ofFIG. 1 and its interaction with users; -
FIG. 5 shows how users can interact with the system ofFIG. 1 ; -
FIG. 6a is a front view of an authentication device for use with thetransaction system 1 ofFIG. 1 ; -
FIG. 6b is an internal view of an authentication device for use with thetransaction system 1 ofFIG. 1 ; -
FIG. 6c is first side view of an authentication device for use with thetransaction system 1 ofFIG. 1 ; -
FIG. 6d is another side view of an authentication device for use with thetransaction system 1 ofFIG. 1 ; -
FIG. 6e is yet another side view of an authentication device for use with thetransaction system 1 ofFIG. 1 ; -
FIG. 7 is a flow diagram of an authentication and payment method; -
FIG. 8 is a flow diagram of a user registration method; -
FIG. 9 is a flow diagram of a user maintenance method; -
FIG. 10 is a flow diagram of a notification method; -
FIG. 11 is a flow diagram of a user service review method; -
FIG. 12 is a flow diagram of a method for authenticating a user; -
FIG. 13 is a flow diagram of a method for triple authenticating a merchant; -
FIG. 14 is a flow diagram of a method for validating a merchant's identity; -
FIG. 15 is a flow diagram of a method for validating a consumer's identity; -
FIG. 16 is a flow diagram of a method for validating a consumer's payment ability; -
FIG. 17 is a flow diagram of a method for validating that goods are ready for dispatch; -
FIG. 18 is a flow diagram of a method for consumer acceptance/rejection of a payment; -
FIG. 19 is a flow diagram of a method for fulfilling an order; -
FIG. 20 is a flow diagram of a method for processing referred consumer transactions; -
FIG. 21 is a flow diagram of a consumer rejection process; -
FIG. 22 is a flow diagram of a method for processing chargebacks, and -
FIG. 23 is a flow diagram of a method for processing credits. -
FIG. 1 shows asecure transaction system 1 that is run by a system operator for identity authentication and authorizing payment. Thetransaction system 1 is able to communicate with users that are transacting with one another, for example a consumer and a merchant. It is also able to communicate with the systems ofinstitutions 2 a-c, 4 that provide users with financial services, for example banks, credit card companies etc. Thetransaction system 1 acts as a gateway for authenticating the identities of users who are parties to transactions and for arranging for payments to be made without disclosure of a user's financial details. To do this, thesystem 1 implements security procedures at various stages in a transaction and controls and arranges payment from one user to another user only when one and preferably both users have been fully authenticated and without the paying user's financial details, for example credit or debit card details, being revealed to the other user. - The transaction system or
system operator 1 is not a bank or payment provider but sits between these providers and the user, and acts as a secure, trusted system for arranging payment from one user to another once a transaction has been fulfilled and only once the identities of both users have been authenticated and appropriate security checks have been completed. Thesystem 1 is not designed to replace a merchant's ordering system and transactions are still conducted between a consumer and the merchant over conventional commercial channels, such as face-to faceinteraction 6, mail order 8, telephone order 10,Internet shopping 12, contactless 14, mobile 16 and person-to-person 18 payment. Instead, thesystem 1 allows a user to transact with merchants over numerous different channels, using a single authentication means 20 to interact with thesystem 1, thereby to be authenticated and arrange for payment, without having to reveal financial details to the merchant. Thesystem 1 provides multi-channel, consistent anti-fraud measures and validation services to users to ensure that the other users involved in the transaction are who they claim and are transacting within allowed limits. Transactions can be recorded with thesystem 1, but only to allow checks that the transaction is as expected and to release user information or arrange payment at appropriate stages in the transaction. - By having the authentication and security aspects of a transaction handled separately from the users, banks or other facilities that can arrange payment and ordering systems, the
system 1 can be implemented to operate consistently with a wide range of payment means and use a range of transaction channels 6-18. Use of the system brings the same level of security and protection across multiple commercial channels 6-18. In addition, authentication is carried out on a transaction level, not on a payment level. These aspects allow the user to interact with a single, unitary authentication andsecurity system 1 thereby to authorize payment from any of their nominated accounts, rather than having to deal with a multitude of specific authentication and payment systems tied to certain payment facilities, for example banks or credit card providers, merchants or transaction channels. - As shown in
FIG. 2 , the single user authentication means 20 can be used for authentication, whilst providing access to at least some and optionally all payment channels nominated by that user, for example acontactless tag account 22, a firstcredit card account 24 a, a secondcredit card account 24 b, amobile telephone account 26, aloyalty scheme 28, afirst bank account 30 a,asecond bank account 30 b, and agift voucher scheme 32. The authentication means could be for example a dedicatedconsumer ID card 34/merchant card 36 and/orconsumer authentication device 38/merchant authentication device 40 or could be a credit or debit card that the user has nominated for use in the authentication process. Since the authentication and payment processes are decoupled, even where a credit or debit card is used for authentication, this does not necessarily have to be used for payment. Indeed by using one card for authentication and another for payment, security can be increased. For example in the arrangement ofFIG. 2 , a credit card could be used for authentication, but the user could arrange for payment via any one or more of thecontactless tag account 22, the first and second credit card accounts 24 a,b, themobile telephone account 26, theloyalty scheme 28, etc. -
FIG. 3 shows thetransaction system 1 in more detail. This includes atransaction server 42 for applying security procedures to transactions; anauthentication server 44 for authenticating user identities; apayment server 46 for liaising with the consumer's payment means 47 and arranging actions, such as payments or bank transfers, on behalf of users;storage media 48 for storing data relating to users, transactions and operating parameters; and acommunications system 50 for communicating with users, other parties such as issuing institutions, and operators of the system. Thetransaction server 42,authentication server 44,payment server 46 and any server required by thecommunications system 50 may be physically separate. Alternatively, one or more of the transaction system server functions 42-50 may be incorporated within the same physical server. - The
transaction system 1 acts as a gateway so that users can control what information is provided to other users and at which point in the transaction that information is provided. As all users are part of a trust network, they can have confidence that certain information is held on thesystem 1 and can be used, or appropriately accessed, to complete the transaction. This negates the need for a user to supply that information, which prevents it being used fraudulently by another user. This gateway function is facilitated by thetransaction server 42, which is adapted to carry out security operations at various stages of the transaction. The security operations may include storing details of a user and arranging actions using the user's details rather than revealing the details to the other users, for example by arranging payments from one user to another without revealing details of thepayment channel 47. The security operation may only reveal certain details of the user at an appropriate stage in a transaction, for example, for non-face-to-face transaction where goods are not provided at the point of sale, by revealing address details only when goods are ready for dispatch. - Further security operations carried out by the
transaction server 42 include allowing users to record expected transactions with thetransaction system 1, thetransaction server 42 being adapted to compare the transactions to ensure that they match. The transaction server is further adapted to record in thememory 48, at least in an aggregated or generalized manner, each user's transaction history and monitor user transactions against a series of operating parameters to allow further control of the user's account and to limit exposure to fraud. Thetransaction server 42 is also adapted to notify the user at various stages in a transaction using thecommunications system 50 such that users are aware of details of the transaction and can detect and stop fraudulent transactions. - The
transaction system 1 is adapted to register users of the system only on completion of a series of registration checks. To ensure that a user wishing to take part in a transaction is the registered user, theauthentication server 44 authenticates their identity using at least two-stage (double) and typically three-stage (triple) authentication as will be described in more detail later. In this way, other users of thesystem 1 can have confidence that they are transacting with another member of a trusted network, upon whom certain checks have been made and whose identity has been authenticated. The authentication server is also adapted to allow users to check that other users are registered with thesystem 1 by submitting a user identification code, amongst other details, to theauthentication server 44 which is adapted to compare the supplied consumer identification code and details with those stored within user records to provide an indication that the user is a registered user. - The memory/
storage media 48 includes a fast access, high capacity storage system, such as a hard disk bank, although any suitable storage means may be used. User records, for example consumer records 54 andmerchant records 56, are stored in thestorage medium 48. These include user data such as name, identity code, delivery and billing addresses and associated address codes, details of payment means such ascredit card 24 a,b,debit card 30 a,b orbank account 30 a,b details, authentication data such as passwords, PIN codes and challenge questions such as the user's mother's maiden name, school, place of birth, etc, data required to comply with regulating authority regulations, service settings such as preferred payment methods and operating parameters, such as maximum transaction volume, value and type settings, transaction data, audit trails and user/transaction status such as “active”, “on hold”, etc. - The
authentication server 44 is able to access thestorage media 48 for recording and accessinguser records 54, 56, transaction histories and audit trails and thecommunications system 50 for communicating with users,authentication devices communications system 50. Theauthentication server 44 is adapted to process the requests and data via a triple authentication method for requests received from anauthentication device authentication device payment server 46,transaction server 42 or requesting user via thecommunications system 50. - The
payment server 46 is operable to process payment requests and communicates these to the user's payment meansissuer 2 a-c. Thepayment server 46 is arranged to process payment requests only when certain criteria have been met, such as authentication of both users by theauthentication server 44, the transaction leading to the payment request does not breach operating parameters of either user or that the transaction expected by each user matches the transaction expected by other users that are party to that transaction. As thepayment server 46 handles any payment request and arranges payment, when a consumer and a merchant are transacting, the consumer's financial details are not available to the merchant. - The
payment server 46 is able to access the storage means 20 to retrieve user details, such as the user's payment means 22-32, required to carry out the action. Thepayment server 46 also has access via thecommunications system 50 to the servers of other parties involved, e.g. issuers of payment means 2 a-c, such as a credit card company or bank. The payment means 22-32 may be acredit card account 24 a,b, adebit card account 30 a,b, a bank account such as a current account, acontactless account 22 such as an Oyster card, a customerloyalty scheme account 28, agift card scheme 32 or a mobilephone service account 26. The payment means 22-32 is operated, and any payment made, by apayment issuer 2 a-c such as a bank or credit card company separate from thetransaction system 1. Thepayment server 46 is adapted to act as an intermediary to process payment requests and arrange payment upon completion of orders, obtain validations of consumer payment means 22-32 fromissuers 2 a-c upon request from a merchant, or other authenticated user (for example for user-to-user transactions such as via PayPal or Western Union transfers), and arrange chargebacks and credits. -
FIG. 4 shows thecommunications system 50, which links thetransaction system 1 with various parties involved in the placing and processing of transactions such as consumers, merchants and financial institutions/payment issuers 2 a-c, 4. Various servers and associated hardware are provided, such as an Extranet/Internet server 86 andmobile communications server 88. Also provided are appropriate firewall routers for fixedline communication 90,mobile data communication 92 andInternet communication 94. Thecommunications system 50 is adapted to provide communications by a range of methods such as Internet communications, e-mail, GPRS, SMS, RFID, telephone, Interactive Voice Response (IVR) as will be described in greater detail later. Thecommunications system 50 also provides link toterminals 96 for allowing system operator staff to access thetransaction system 1, for example in response to telephone enquiries. Users can communicate with thetransaction system 1 by one communications method, and thesystem 1 can notify the user of transactions by another communications method. These communications methods can be pre-defined by the user. For example, the user may opt to send instructions and/or information to thesystem 1 via mobile telephone, but receive information via the Internet. This helps prevent fraudulent or unauthorized intervention through unauthorized access to a single communications medium. In addition, it allows thetransaction system 1 to be used with a variety of transaction types and negates the necessity for every user to have expensive processing terminals. -
FIG. 5 shows the transaction types supported by thesystem 1. These include mail order 8, face-to-face 6, Internet ordering 12, telephone ordering 10, Internet 102 and telephone banking andtransactions 16 using mobile communications technology such as various technologies employing WAP, i-mode, 3G and GPRS. As shown inFIG. 4 , merchants'servers 104 can access thetransaction system 1 directly via fixed line communications or over the Internet or Extranet.Authentication devices authentication device modem 108 to another communications system such as atelephone line 110. Users may also access the system viavoice telecommunications 110 to anoperator 96 or to an IVR service. Access via a usermobile telephone 110 may additionally include use of messaging services such as short messaging service (SMS) messages or access via a mobile browser such as WAP or via a direct network link such as those available over 3G networks. These communications are intercepted and decoded by themobile communications server 88. Users, whether merchants or consumers, may access the system fromterminals 106 such as PC's over the Internet, which are via an interactive Extranet or Internet service and controlled by theInternet server 86. -
FIGS. 6a-e show anauthentication device transaction system 1 and display of instructions from thetransaction system 1 to the user. Theauthentication device display 112; data input devices as appropriate such as a keypad 114,trackball 116,microphone 118, touch pad (not shown), and/orbuttons 120; abiometric information reader 122 such as fingerprint scanner or a retinal scanner; acard reader 124 such as a chip card reader, preferably Europay MasterCard Visa (EMV) compliant, and/or magnetic strip card reader and/or an RFID card reader; cable and/or wireless communications means such as aBluetooth port 126, anIR port 128,RFID port 130,USB port 132, Firewire port , 802.11a/b/g wireless (“Wi-Fi”)communications apparatus 136 and/ormobile telecommunications apparatus 138 including a SIM card and SIM card reader; and arechargeable battery 140; along with the associated hardware required to run each of these components, as would be understood by a person skilled in the art. Theauthentication device memory 142 and processing means 144 for storing data, processing operations and controlling the components. The authentication device may comprise separate logical and/or physical memory configurations for payment and other functions. - The
authentication device authentication device device memory 142 of theauthentication device transaction system 1 via thecommunications system 50. Thedevice transaction system 1 once a user has validated their identity, for example by using an identity card and/or PIN and/or ID code. Data can be input to thedevice display 112. Activation of individual input devices 114-124 or operation of thedisplay 112 may be in response to software stored on theauthentication device transaction system 1 via at least one of the communications means 126-138. - The communications means 126-138 of the
authentication device authentication device transaction system 1 and may be used to send update data, user data or instructions to theauthentication device transaction system 1. The preferred communications route is via encrypted mobile communications over networks such as GPRS or 3G. In an optional embodiment, thecard reader 124 may be adapted to receive contactless payment cards, including RFID cards such as Oyster, Speedpass or vending system cards. TheRFID port 130 of the authentication device can then be used to communicate between theauthentication device transaction system 1. In this, case the contactless card could be preloaded with funds and used as a user's payment account for transactions via thetransaction system 1. Conversely, other payment accounts, e.g. credit 24 ordebit cards 30, could be used to make contactless payments. -
FIG. 7 shows the steps for authenticating users using thetransaction system 1 to facilitate a secure transaction, including authenticating the identities of users who are parties to a transaction and controlling delivery and payment. All parties to a transaction must be registered users of thetransaction system 1 before being allowed access to thesystem 1. A potential user must first complete aregistration procedure 146 to obtain details necessary for operation of thetransaction system 1 and to ensure that all the details are correct and that all regulatory requirements are met. The users can be specified as being consumers, who only use thetransaction system 1 to make purchases from a merchant, or merchants, who use thetransaction system 1 to make sales to a consumer or another merchant acting as a consumer. A merchant may also make purchases and any reference to a consumer includes merchants when making a purchase. For transactions such as person-to-person or Western Union type transfers, both users may be consumers, with one user acting as a ‘merchant’ in so much as they receive a payment. As an optional feature, thetransaction system 1 may act as a directory or database of merchants offering services or products through which consumers may browse to locate a suitable supplier with whom they can transact in a safe and secure fashion. At the end of the registration procedure, each consumer is given a consumer identity code and each merchant is given a merchant identity code. - Once registered, a consumer wishing to make a transaction with a merchant must first access the
transaction system 1 and authenticate 148 their identity to prove that they are who they claim to be and that they are registered on thetransaction system 1. After the consumer has been authenticated 148, they requestvalidation 150 of the identity of the merchant with whom they wish to transact by sending to the transaction server a merchant identity code. This would be supplied to them by the merchant by normal commercial means, e.g. via a website or advert. Theauthentication server 44 is then operable to compare the supplied merchant identity code with those stored on thetransaction system 1. A positive match allows the consumer to have confidence that the merchant has passed the transaction system registration checks and is operating within its operational parameters. The consumer then transmits an expectedorder 152 to thetransaction system 1. Thetransaction system 1 stores the expected order for comparison with the order placed on thetransaction system 1 by the merchant to ensure that the details of the actual order matches the expected order details. This procedure is consumer driven and so is ideal for mail order 8, transactions over theInternet 12, and telephone shopping 10. - The merchant accesses the
transaction system 1 and goes throughauthentication 154. This ensures that they are an authorized user and the intended party to the transaction. The merchant may seek to validate 156 the identity of the consumer by supplying the consumer's identity code to thetransaction system 1. Theauthentication server 44 of thetransaction system 1 is operable to compare the user identification code with those stored by thetransaction system 1. This can be used to check that the identity provided by the consumer is correct and that the consumer has passed the registration conditions of thesystem 1 and is operating within their operational parameters. The merchant may also access thetransaction system 1 to validate 158 that the consumer's selected payment means 22-32 are valid for use and not showing as stolen or suspended. Thetransaction system 1 can process these requests by checking for appropriate status flags stored in the consumer's record and by using thepayment server 46 to communicate with theissuing institutions 2 a-c of the consumer's payment means to carry out funds available and other standard security checks, as would be known in the art. - The
transaction system 1 notifies the consumer of the transaction details recorded on the system by the merchant and gives the consumer an option to reject the transaction or flag up anyfraudulent transactions 160. Thetransaction system 1 also makesreferral checks 162 to ensure that the consumer's payment means 22-32 is valid and within the limits set by the consumer'sissuer 2 a-c and that both consumer and also the merchant are within their operating parameters. Only once the goods or services are ready fordispatch 164 to the consumer is any consumer personal address information 54 released to the merchant by thetransaction system 1. Afterdispatch 164 of the goods or services, thetransaction system 1 processes 166 the payment for the goods or services from the consumer'spayment issuer 2 a-c to the merchant through the merchant's acquiringbank 4. The details of the consumer's payment means 22-32 is never revealed to the merchant, thus ensuring a separation of authentication and payment. Thetransaction system 1 also provides facilities for control of post sales transactions such aschargebacks 168 andcredits 170 utilizing its advantageous authentication facilities. -
FIG. 8 shows theregistration process 146 in detail. This requires potential users to provide their identities (including name, address and certain payment and banking information) and verify those identities using reliable, independent source documents, data or information. Where the potential user is a business or corporate body, the beneficial owner must be identified and steps taken to verify the identity of the beneficial owner. Details are also required on the purpose and intended nature of the business relationship with the potential user. These may be used to determine the risks associated with each user and to conduct ongoing due diligence on the business relationship and scrutiny of transactions undertaken throughout the course of that relationship to ensure that the transactions being conducted are consistent with the activities of the user, their business and risk profile, including, where necessary, the source of funds. To this end, thetransaction system 1 may distinguish between merchants and consumers at all times to help determine the expected activities and incorporate these into risk analysis by determining whether actual usage matches this expected profile. - The preferred method of ensuring the details supplied in the user validation are correct is to obtain a
reference 172 from a bank or other sponsoring institution. A potential user may request registration by completing an application form (which may be electronic, such as an Internet form). If the potential user has an existing relationship and is referred by a bank or other institution (retail or otherwise) that requires to follow the same regulatory requirements as thetransaction system 1 operator, the prospective user may provide details of the bank as a referee to confirm that the prospective user has undergone the required regulatory checks by that bank or institution. The prospective user must also provide appropriate permission for thetransaction system 1 operator to contact the prospective user's clearing bank and to give the bank or institution authorization to release the information required. The bank or sponsoring institution is then contacted 174 to confirm that the prospective user has undergone a consumer validation process that meets regulatory requirements and to confirm that the details supplied by the prospective user are correct. This approach may be enhanced by credit reference agency checks as appropriate. - Where the reference is positive, full application details for the prospective user are assessed 176 to determine whether a service agreement should be granted.
Assessment 176 is preferably carried out using underwriting analyses/scorecards as is known in the art. If the reference or subsequent risk analysis is negative, account-opening procedures are not initiated 178 and the outcome is referred back to the prospective user and the sponsoring institution as appropriate. A record of this event is also sent to audit trail logs. If the potential user does not elect to provide a bank reference, then optionallyother checks 180 may be employed that depend on local regulatory requirements and system operator policy as would be known in the art. If the other checks are unsuccessful, the audit logs are updated and the account is not opened 182. Where the checks (either via a bank reference or other procedure) are successful 184, the prospective user is notified of the successful application, and a user record is set up 186 as either a consumer record 54 or amerchant record 56. Users are issued with a service agreement setting out their conditions of operating and agreeing initial operating parameters for their account. - Once accepted, the new user provides user and preference details. This can be achieved by: (a) secure access to the system via an Extranet; (b) communication with the service centre staff; (c) via an IVR system; or (d) via written documentation provided through registered postal means. The user and preference details to be provided will vary depending on whether the user is a consumer or a merchant. If the user is a consumer, the details required 188 are: (a) name, address, employment and identity details; (b) details of further consumers who may use the account (e.g. in the case of a household or group account); (c) the method of communication based on specific notifications; and (d) multi-currency transaction base currency. In addition, the consumer has to indicate preferred consumer communication methods, for example, telephone, mobile phone, text message, email address; specific criteria for each communication method preferred, based upon predefined criteria, i.e. which communication formats to use to communicate which events (e.g. account or transaction queries); details of the payment means 22-32 to be used, including card and non-card payment means; unique consumer preferences and operating parameter 60 checks for: specific identity authentication and transaction payment combinations; for each identity / payment combination, preferences for the payment channel 22-32, with identification of default accounts for each channel for faster processing; transaction and gross values over specified periods; payment velocities; and merchant type exclusions or limitations. The system imposes transaction volume, value and velocity limits based on each consumer's application details.
- The consumer also has to indicate any preference for trusting transactions if the transaction value in transaction or base currency matches an order that has been pre-loaded by the consumer. Even where this option is selected, the consumer will still be notified of any payment transaction using the consumer's account. The user also has to provide the address details 54 for goods delivery and invoice dispatch to which address codes 76 will be assigned. In addition, the user has to select alphanumeric passwords 78 for Extranet,
authentication device 38 and IVR use. Multiple passwords may be selected for different users of an account. An answerback PIN for SMS messages and alphanumeric answerback password for email notifications may also be selected at registration. Where appropriate, an initial password to facilitateauthentication device 38 registration of consumer biometric identity means (e.g. fingerprint) will also be registered or generated automatically during registration. Preference over the time delay after which an order is deemed to be an “aged order” and requires to be revalidated and accepted by the consumer may be set and optionally may depend on the payment channel. - At registration, the consumer may also select the level of service. This is principally a choice between an
authentication device 38 andidentity card 34, which allows triple authentication, or an identity card only 34, which allows dual authentication. For those selecting anauthentication device 38, its use can be limited to purchasing items only or for both purchase and sale of items. This feature is advantageous for example for PayPal power sellers or small traders trading under a trusted network. In addition, the user may specify whether or not they wish to transact cash withdrawals in a virtual ATM arrangement. For accounts where more than one user is authorized to use anauthentication device 38, each authorized user will select his/her own password, and register his/her unique payment methods, and have his/herown identity card 34. A maximum number of users andidentity cards 34 perauthentication device 38 is imposed, with payment cards being uniquely linked to specific authentication devices for consumer identity verification and security purposes. - Where an
authentication device 38 is selected, the user can select preferred components, e.g. one or more of: GPRS/mobile communications 138;Bluetooth communications 126; 802.11a/b/g Wi-Fi communications 136;USB communications 132;Firewire communications 134; Contactless (RFiD) orNFC communications 130; Wallet capability for contactless payments (where the contactless close proximity channel is selected by the principal consumer); PayPal or small merchant seller functionality. Person-person money transfer capability will be set automatically in accordance with the principal consumer payment type preferences. - At registration, default fulfillment choices should be made regarding the period over which the consumer is prepared to wait during delays in goods dispatch from the merchant, either overall or by transaction channel and merchant type. Mail order will be extended by a default number of days to facilitate postal order timescales but not facsimile or email orders. This will be defaulted to a preset limit based on service arrangements with merchant users. This facilitates notifications from the
transaction system 1 to remind the consumer that the default delay period is close to being met. Where no delay is selected, the system will automatically prompt the consumer to acknowledge that goods have been received before allowing transactions to complete. - For registration of a merchant, the details required 190 are name, address, merchant classification and identity details; details of all merchant staff who are to be issued with identity cards 36 (
identity cards 36 will be capable of being reallocated to new members of staff as changes occur); and member(s) of merchant staff to be granted authority to change or reset the PIN onidentity cards 36. Where more than one member of staff is to use anauthentication device 40, the merchant can select the functions to which each member of staff will have access. In this way the merchant can ensure segregation of duties between different parts of the payment process, for example, order input and fulfillment. A maximum number of merchant staff and thereforeidentity cards 36 perauthentication device 40 will be imposed. Preferred merchant communication methods have to be chosen, for example telephone, mobile phone, text message, email address, as do rules for each communication method, based upon predefined criteria (e.g. to use a certain communications route for account notifications or a different communications route for transaction queries or to select which events are to result in notifications). - Details of which payment acceptance methods are to be used, such as card and non-card payment, also have to be defined. Unique merchant preferences can be selected for: payment types, e.g. credit and debit card, accepted across each payment channel, for example face-to-
face 6,Internet 12, mail order 8. For each payment channel selected, the merchant can define the estimated values for the numbers of transactions; the gross value of transactions over specified periods; the volume of transactions over specified periods; and exclusions or limitations on specific payment types. Thesystem 1 will impose operational parameters such as transaction volume, value and velocity limits based on each merchant's application details, and will limit specific transaction levels based upon levels of credits, complaints, referrals and other service characteristics. Where delays in dispatch of goods are typical in the merchant's business, the time periods that are typical before dispatch of goods takes place can be specified. These delays will be built into the service agreement with merchants, and monitored by the system. - Other preferences that have to be defined include the method of communication to the merchant in response to specified notification triggers; multi-currency transaction base currency and acceptance of specific currencies elected by consumers using the system. This may be part of a dynamic currency conversion (DCC)/consumer preferred currency (CPC) service provided by the system, as do any preferences for trusting transactions if the transaction value or base currency matches an order that has been pre-loaded by a consumer. Where this option is selected, the merchant will still be notified of payment transactions impacting the merchant account. Alphanumeric passwords for use with Extranet, authentication devices and interactive voice response (IVR) may also be defined, and multiple passwords may be selected for different merchant members of staff. In addition, an answerback PIN for SMS notifications, and an alphanumeric answerback password for email notifications, may be selected. Where appropriate, an initial password to facilitate registration of merchant biometric identity means, e.g. fingerprint, for use with an
authentication device 40 is also be registered or generated automatically. - As for the consumer, the merchant can also select the level of service by choosing between authentication using an
authentication device 40 and identity card oridentity card 36 only. A limited number of identity cards will be provided to merchants, which may or may not be linked to specific authentication devices. For those selecting theauthentication device 40, the merchant may elect to use it only for selling items or for both sale of items and providing consumers with cash withdrawal facilities. Also, where anauthentication device 40 is selected, the merchant has to indicate whether a Bluetooth enabled base station is required for connection to a fixed telephone line or mobile telecommunications device for communication between theauthentication device 40 and thesystem 1.Authentication device 40 component preferences also have to be included for example: GPRS/mobile communications; Bluetooth communications; 802.11a/b/g Wi-Fi communications; USB communications; Firewire communications, and Contactless (RFiD) or NFC communications (receiver). - The
transaction system 1 will determine chargeback reserves according to methods known in the art and provide details of chargeback reserves to be applied as part of the merchant application process. - Once the user's details and preferences are entered, the
transaction system 1 determines operational parameters, e.g. according to value, quantity or velocity for each user and records these in the user'srecord 54, 56. Thenauthentication devices identity validation cards authentication device Authentication devices identity cards identity cards transaction system 1 must be by telephone, IVR or Extranet. Once the user account is enabled, the user is then free to use thetransaction system 1 within the terms of their service agreement. - The registration details and operational parameters may be modified using account maintenance as shown in
FIG. 9 . Each user's record can be accessed 200 for maintenance purposes via any of the communications methods supported by the system such as using anauthentication device merchant 202. The user then has to be authenticated 204, 206. Access to the account maintenance system is by triple authentication if the user is using anauthentication device system 1 allows the user to alter. - The system maintains a transaction activity logs for recording all transactions made by a user and an audit log for recording any instances where a transaction, registration or access attempt fails or is rejected, orders are rejected by a consumer along with an appropriate reason code, or payment is declined or referred. An expected user behavioral pattern based on information gathered at registration is created. This behavioral pattern is used to determine operational parameters that are agreed with the user. As each user account is used, the transaction data is recorded in the transaction log and audit trail as appropriate in addition to other data as supplied by the
issuers 2 a-c of payment cards or other payment means to monitor the behavior of the users. The user's credit and fraud risk is calculated periodically and/or upon transactions being made by methods known in the art to provide a constant assessment of risk to thetransaction system 1 operator. As shown inFIG. 10 , a notification system is provided with trigger events set to provide user information or communication, or provide a warning when operational parameters are breached or the system determines that the credit or fraud risk is too high. - The form of notification may be specified by the user at registration or during account maintenance. It may be any notification type known in the art, but is preferably an SMS message, a message sent to and displayed on an
authentication device user 210. To ensure that the user receives the notification and not a third party, the user will be required either (a) to respond to an SMS message with a predefined password set at registration before the notification is sent; or (b) will be referred to a link by email which will transfer the consumer to a secure Extranet facility which will require validation by password orauthentication device 140 set atregistration 212. Once the user has been verified, the notification is accessed 214. - Each user account is assigned notification triggers in response to operational parameter breaches that are used to control risk and to flag up any operations that are out with the service agreed during the registration, maintenance or review processes. Grace limits above transaction limits are set to create shadow limits, which act as a buffer against any minor breach of the transaction limits. Consumer accounts are reviewed periodically and/or when a transaction is made. If a consumer is: (a) in breach of its transaction limits (over and above any shadow limit); or (b) where the system has detected an unusual or suspicious transaction, the system will lock the user account by recording a “hold” flag on the user's account such that the user will be unable to use the system for any purpose, including validation of the consumer identity to third parties, until it has undertaken a service review, as shown in
FIG. 11 . - A service review involves a user contacting an operator to discuss the
problem 216. Before discussing the problem, the user supplies their identity code from which it can be determined if the user is a consumer ormerchant 218. The user then validates theiridentity authentication device authentication device consumer 226, for example an increase in transaction limits if appropriate, the user's account is updated accordingly and the “hold” flag is removed from the user's account such that the user may use the system again. Where appropriate arrangements are not reached 228 with an operator, the operator may, according to predefined criteria, keep the “hold” flag on the consumer's account until settlement and satisfaction of the service agreement; or permanently disable the consumer's account. Details of the limit breach and subsequent interaction are recorded in the audit logs 230. - The authentication procedure depends on whether the user is using an authentication device or not and whether or not the user is a consumer or a merchant. If an authentication device is used, then the user must triple authenticate their identity. If authentication is carried out without an authentication device, then the user must double authenticate their identity. Alternately, the method for authentication without use of an authentication device can be used as a backup only when the authentication device(s) are unavailable or incapacitated. Regardless of the authentication method used, personal details of the consumer, such as payment details, are not communicated to the merchant, thereby significantly reducing the possibility of identity theft, theft of payment details and/or payment fraud. Only after both parties are authenticated as being recognized and trusted users can payment processing proceed.
- As shown in
FIG. 12 , the first step is to identify whether the user is aconsumer 232, and if yes, whether an authentication device is to be used 234. If the user is a consumer and authentication is to be carried out using an authentication device, the consumer firstly validates his/her permission to use theauthentication device 236. This primary validation takes place locally (offline), between the consumer and the authentication device, representing the first authentication of a multi-stage authentication approach to validating the right of the consumer to use the authentication device in their possession. For those markets or regulatory environments that require online verification, the service will connect the relevant issuing institution through thesystem 1 to the authentication device. The primary validation is by entry of a relevant multi-digit PIN and/or alphanumeric security code and/or biometric authentication, employing a combination of encryption/authentication standards, biometric recognition and 128-bit encryption methods, such as secure socket layers (SSL). Where a PIN is used, the PIN is mutually exclusive to any PIN associated with the consumer's credit, debit, charge or prepaid cards, or other payment means. The consumer may change the PIN, alphanumeric security code, or biometric authentication method at any time through use of the maintenance process described above with reference toFIG. 9 , which is accessed via the authentication device or through secure access to the consumer's account maintenance facilities via an Extranet. Both offline and online security codes and, where utilized, biometrics can be maintained using this facility. - If the consumer fails 238 to validate his/her permission to use the authentication device after three successive entry failures of a PIN, alphanumeric entry code or biometric parameter, the authentication device will be automatically disabled for entry of further details. The consumer will be required to contact a system operator to have his/her authentication device unlocked and reset, and may be required to reregister his/her security details on the authentication device and with the system operator or
system 1, via, e.g. Extranet or IVR. Where the consumer wishes to use thesystem 1 before his/her authentication device is unlocked and reset, the consumer will “fallback” to using theauthentication system 1 without an authentication device as described below. -
Secondary authentication 240 is performed either on-line by using the authentication device to connect with the authentication server 10 or off-line. For authentication in response to Internet or on-line transactions, links to this step of the validation may be provided within a merchant's web page. On-line authentication is the preferred approach, as this provides the most secure approach by allowing access to the most recently available data. On-line authentication can be achieved by firstly using the authentication device to connect to the authentication server 10 by Internet Protocol (IP) using one of (a) USB; (b) Firewire; (c) 802.11a/b/g wireless (“Wi-Fi”); or (d) Bluetooth connectivity, and employing secure encryption techniques such as key encryption or secure socket layers (SSL). Alternatively, connection can be achieved by using mobile telephony services such as GPRS and 3G to communicate securely with the authentication server 10. These approaches combat anti-phishing and anti-fraud screen capture measures, providing increased security. The authentication device can also be dynamically set to require regular on-line authentication, which further enhances identity and payment security. The mobile telephony service can also be used contemporaneously with Internet access, providing a further security benefit. - The
secondary authentication 240 of the consumer involves verifying consumer identity or payment card(s) employing chip and PIN and compliant with the Europay MasterCard Visa (EMV) validation standards using the EMVcompliant chip reader 124 within theauthentication device 38. Any card used must be registered with thesystem 1 during registration of the account or using the account maintenance procedure. The card details are then compared with the details held within the consumer's user record 54. User identity cards may be any card satisfying EMV chip and PIN standards such as specific user identity cards issued by thetransaction system 1 operator or debit, credit, charge or prepaid cards. Where a card is not used to verify a consumer identity, the consumer may elect to use a secondary on-line PIN and/or alphanumeric security code and/or password and/or biometric, which will be encrypted and matched against a PIN and/or alphanumeric security code and/or password and/or biometric identity which is pre-registered during registration or account maintenance. If the user fails the secondary authentication, contact with the service operator is required 242. - In the event that the secondary authentication step is successful, the third and final authentication step is commenced 244. This is facilitated by matching the authentication device identity tag, unique to the authentication device, with the cards, security codes, password and/or biometric combination linked specifically to named consumers and held securely online on the
central transaction system 1. The users allowed to use an authentication device are specified during registration or account maintenance. Individual consumers are validated against a unique authentication device tag if the authentication device is assigned to a sole user. If multi-user accounts are operated using one or more authentication devices, validation is achieved by checking for a matching authentication device tag/account holder user identity card combination as well as the multi-user identification/authentication device tag combinations. - Where the consumer details are matched to the
correct authentication device 246, a check is done to see whether the consumer is in breach of any operatingparameters 248. If yes, the transaction is halted and the audit files up-dated 250. If no, the consumer is fully authenticated and the transaction continues 252. In contrast, where failure to match the consumer's details occurs 256, for example, due to incorrect entry or non-match of password, code, chip and PIN card details, biometric or authentication device identity tag, the consumer is halted from further transacting using the authentication device. The consumer will then have to use the account maintenance service or contact an operator to restore use of the authentication device, or to transact by using the non-authentication device procedure described below. In all cases, the transaction history of the user associated with the authentication device is updated with details of invalid consumer transactions. - Optionally, for face-to-face transactions, the consumer may be authenticated using a merchant's authentication device. This process involves the merchant triple authenticating themselves as described below. Once the merchant has successfully authenticated its identity, the merchant will pass the authentication device to the consumer for the consumer to authenticate their identity online. The consumer will be prompted to enter their identification code and PIN code and/or security code and/or biometric identifier. If these are valid, this will be confirmed by an acknowledgement message being sent to the authentication device from the authentication server 10, facilitating the next step in the transaction process. If the consumer fails this first step in authenticating their identity by three successive entry failures of a PIN, alphanumeric entry code or biometric, processing of further order details will be halted. The consumer will be required to contact the operator, and may be required to reregister their security details. The invalid user identity code is transferred to the audit trail logs by the authentication server 10, and the transaction history of the merchant account associated with the authentication device is updated with details of invalid consumer transactions.
- Where the first authentication step is concluded successfully, the consumer dual authenticates their identity using a registered EMV certified card (whether credit, debit, charge, prepaid or user identification card) and PIN. In addition, the authentication server 10 sends an on line challenge for third stage authentication by the consumer, based either on a further EMV certified payment card if one is registered to the consumer's account (e.g. where a user identification card was first used) or on the basis of pre-registered personal details or transaction histories. In this way, the consumer needs at least to dual authenticate himself using the merchant's authentication device before proceeding with a transaction. Where a consumer fails identity validation after three failed attempts at dual or tertiary identification, the authentication server 10 sends an appropriate referral message to the authentication device, requesting the consumer either to use another registered EMV card/PIN combination or to contact an operator. Where the consumer has no further registered cards or after a failure of three attempted EMV card/PIN combination entries, processing will be halted as a security measure. No further activity will be allowed for that consumer using the card/PIN combinations used against that authentication device. Transaction processing will be halted, and the appropriate merchant and consumer event and anti-fraud audit logs will be updated.
- Where an authentication device is not used, a
dual authentication procedure 258 can be used by (a) interacting with an operator by telephone after security validation is attained; (b) logging into the Extranet which will require at least dual authentication secure access, and validation and navigation capabilities as generally used for financial web sites, employing secure encryption techniques for transaction processing; or (c) interacting with the IVR service. Primary authentication is achieved by providing a user specific password and/or security details and/or PIN. Where there are multiple users of a consumer account, the password and/or security details and/or PIN is specific to the member of staff or individual user to enable accountability. Secondary authentication is carried out using various authentication checks. These may include questions based on registration details or transaction histories. The authentication checks used are dynamically varied, for example, according to an analytical algorithm to achieve best selection of questions to provide maximum security. If the consumer fails authentication, re-validation of their identity is required through interaction with anoperator 260. The consumer cannot then process transactions until their registered identity details have been re-validated by the operator. The consumer account and audit logs are updated with the details of the failed authentication attempt. Where a consumer passes identity validation, the process proceeds as before 248-256. - Where the user is a merchant, the merchant registers staff members as authorized users and assigns EMV compliant user identity cards, user accounts and user PINs, passwords and/or biometric identifiers to the members of staff. The permissions on each member of staff's user account may be selected upon registration or maintenance such that each staff member has access rights and ability to use only the features of the system necessary to do their job. In this way, the merchant can control and segregate duties between staff members and control exposure to erroneous transactions, mistakes, staff acting out with their authorized area and fraud. The merchant may also specify that authentication is carried out with an authentication device using triple authentication or without an authentication device requiring double authentication.
-
FIG. 13 shows the process for authenticating amerchant 262. If the merchant staff member is authenticating using anauthentication device 264, the staff member firstly authenticates their identity offline by entry into thedevice 266 of a relevant multi-digit PIN, alphanumeric security code or biometric authentication, employing a combination of EMV authentication technology (e.g. chip and PIN), biometric recognition and 128-bit encryption methods as generally available. Where a PIN is used, the PIN is mutually exclusive to any PIN associated with any merchant's or staff member's identity or merchant personal EMV compliant cards. One or more authentication devices may be uniquely linked to one or more authorized members of merchant staff - The list of staff members authorized to use an authentication device may be updated using the account maintenance facilities. Updated user lists are communicated to the
authentication device 40 from theauthentication server 44 via an appropriate communications channel such as an Extranet, GPRS, Wi-Fi, 3G mobile communications, etc. Authentication is achieved by comparing the identity as indicated by the identity card and associated PIN, security code, etc. with the list of valid users stored on the authentication device. The merchant may change the PIN, alphanumeric security code, or biometric authentication method at any time through use of the maintenance facility using the authentication device directly or through secure access to the merchant account maintenance facilities via the Extranet. Both offline and online security codes and, where utilized, biometrics can be maintained using this facility. Validation of the merchant identity with the authentication device is a prerequisite to transacting using the authentication device. - If the merchant member of staff fails to validate their
identity 268 after three successive entry failures of a PIN, alphanumeric entry code or biometric, the authentication device will be automatically disabled for entry of further details as a security measure. The merchant will be required to call an operator to have its authentication device unlocked and reset, and may be required to reregister its security details on the authentication device and on theauthentication server 44. No further transactions can be processed using theauthentication device 40 until it is unlocked, and potentially re-registration has taken place. Similar restrictions apply whether or not a merchant has a single or multiple users of anauthentication device 40. Where the merchant wishes to use the service in the event that an authentication device is locked, the merchant may fallback to using the authentication service without anauthentication device 40 as described below. - If the merchant member of staff successfully completes the first authentication step, the staff member must then carry out two
more stages authentication server 44. Both approaches include anti-phishing and anti-fraud screen capture measures as are known in the art. The mobile telephony service can also be used contemporaneously for Internet (IP) access, providing a further security benefit for merchants in countering identity theft and payment fraud. -
Secondary authentication 270 of the merchant staff member is thereafter facilitated by verifying merchant staff member identity card(s) employing EMV compliant chip and PIN validation techniques against the EMV compliant chip reader within the authentication device. Any identity cards used must be registered and match details held within the merchant's account. Other cards that satisfy EMV chip and PIN standards and common criteria could be used (e.g. specific to merchant) but would require to be registered and validated to maintain security levels. In the event that the merchant fails this stage, they are required to contact theservice operator 273. In the event that the merchant passes this stage, they move onto to third authentication stage, 272. This is facilitated by matching the identity tag unique to the authentication device with the cards, security codes, password and/or biometric combination used by the merchant member of staff and held securely online on thetransaction system 1. This is a further unique security aspect, requiring merchant PINs, security codes, passwords, card identity details, and authentication devices identity tags to be linked specifically to named merchants and pre-registered staff held and registered on thetransaction system 1. As before, if the merchant fails this stage, they are required to contact theservice operator 273. Otherwise, they move onto the next stage 274. This involves a check of whether the merchant is in breach of its operating parameters and/or agreed service limits. If yes, the transaction is halted and the transaction and audit files up-dated 276. If no, then the transaction proceeds 278. - In an optional embodiment, for face-to-face transactions the merchant or merchant staff member may be authenticated using a consumer's authentication device. All parties must be registered users of the service. In this process, the consumer is firstly authenticated as described above. Once successfully authenticated, the consumer is instructed via instructions displayed on the authentication device to pass the device to the merchant member of staff. The merchant member of staff then inserts their identity card into the consumer's authentication device. Primary authentication is achieved utilizing EMV authentication standards such as chip and pin. Secondary authentication is via the input of a pass code or 2nd PIN and optionally answering of appropriate dynamically selected challenge questions selected according to an analytical algorithm. Authentication is carried out online, thereby increasing the security of the authentication process. Individual merchant staff are separately identified by specific identity cards and pass codes or PINs that are unique to the member of staff.
- If a merchant fails authentication during secondary or tertiary authentication (e.g. invalid identity, invalid pass code or security details), merchant re-registration will be required, through merchant interaction with an operator. The merchant member of staff involved cannot process transactions until their registered identity details have been revalidated. In instances where validation fails, requiring re-registration, two further merchant staff with appropriate access capabilities may attempt validation, in which case the process is repeated with a different merchant member of staff using a different identity card and pass code. If other members of staff do not have appropriate access permissions, processing will halt, and the audit logs will be updated with the details of the transaction. Communication of the authentication failure to the consumer is the responsibility of the merchant, as the operator will not be aware of the consumer's order being received by the merchant. If consumers contact the operator with details of the merchant, the operator can investigate the rejection.
- Where an authentication device is not used, a dual authentication procedure is used 280 by (a) interacting with an operator by telephone after security validation is attained; (b) logging into the Extranet which will require at least dual authentication secure access, and validation and navigation capabilities as generally used for financial web sites, employing secure encryption techniques for transaction processing; or (c) interacting with the IVR service. Primary authentication is achieved by providing a user specific password and/or security details and/or PIN. Where the user is a merchant staff member or where there are multiple users of a consumer account, the password and/or security details and/or PIN is specific to the member of staff or individual user to enable accountability. Secondary authentication is carried out using various authentication checks. These may include questions based on registration details or transaction histories. The authentication checks used are dynamically varied, for example, according to an analytical algorithm to achieve best selection of questions to provide maximum security. If the merchant fails authentication 282 (e.g. invalid user identity, invalid password or security details), they are required to re-validate their identity through interaction with an operator. The staff member cannot then process transactions until their registered identity details have been re-validated by the operator. The merchant account and audit logs are updated with the details of the failed authentication attempt. If the merchant passes authentication, then the procedure is as before 274-278.
-
FIG. 14 shows a process for pre-order validation of a merchant's identity. This allows the consumer to establish if a merchant is a valid, trusted user that is currently transacting within its authorized service agreement. This affords the consumer a significantly increased level of confidence and security in transacting with merchants of whom the consumer has previously had no experience. In some transaction types, for example face-to-face purchases, it is less likely that the user will want to pre-validate the merchant's identity, as purchases are generally made on impulse. However, this feature may still be useful when purchasing high value items such as jewellery, high value electrical goods, cars or furniture, or the goods are purchased face-to-face but delivered later. - To facilitate validation of a merchant's
identity 284, the merchant supplies the consumer with the merchant'sidentity code 286, which may be displayed on, for example, the merchant's web page, in a shop, in a catalogue, promotional literature or communicated by sales staff over a phone line or face-to-face. To pre-validate the merchant, the consumer transmits the merchant's identity code to the authentication server 10. The merchant identity code is then checked against valid, active merchant user records held on thetransaction system 288. Where the merchant identity is found to be invalid or suspended, the consumer will be informed/alerted 290. The consumer and, where appropriate, merchant accounts will be updated accordingly, as will the appropriate audit trail log files. Until a valid merchant identity is authenticated and acknowledged, the consumer takes no further action. Interaction between the consumer and an operator may take place to investigate the invalid merchant details. Where the merchant identity is found to be valid, the consumer will be informed/alerted 292 and the transaction can proceed. - Once the merchant has been validated as genuine and operating within its service agreement, the order may be logged with the
transaction system 1. Logging details of an expected order with thetransaction system 1 before placing the order with the merchant allows the expected order to be crosschecked against the order the merchant actually processes. The consumer firstly selects which payment means they wish to use in the transaction. Once thetransaction server 1 matches the transactions supplied by the consumer and the merchant, the payment server of thetransaction system 1 uses the specified payment means to effect payment to the merchant. No details of the payment means are ever communicated to the merchant. Thus, not only is the method of payment distinct and mutually exclusive from the method of achieving identity verification but unlike existing payment methods, no source payment account details are ultimately available to the merchant, enhancing identity and payment security for consumers. As an extra security feature, each payment account can be stipulated for use only with certain transaction types, e.g. mail, telephone, face to face or Internet order and for other transaction parameters such as use only with certain merchants and/or transactions up to a certain limit and/or for certain types of goods, etc. - During registration certain accounts may be selected as default accounts for certain transactions. For example, the consumer may specify that a particular credit card be used for all Internet based transactions, and a particular debit card be used for all person-to-person transactions. Alternatively, a single account may be specified for all transactions. In any case, default accounts, where registered, may be confirmed or overridden only with other previously registered accounts, providing further security. Where the consumer wishes to override pre-selected default accounts, a secondary password/security code is required if an authentication device is not used, such as when using telephone, IVR or Extranet. Where an authentication device is used, non-default over-ride accounts, whether card or non-card, can only be selected after online verification of an override PIN, alphanumeric code or biometric. The authorization server will prompt for confirmation of selected non-default over-ride accounts. Only previously registered accounts may be selected in favor of default accounts. Where an over-ride account selection fails verification, the consumer is notified in accordance with their preferences, and the system falls back to the default account choices previously registered.
- Where no default accounts have been previously registered, the consumer may register a new account through the maintenance facilities, which will result in processing of the order being halted until this is done. Where a valid, pre-registered default or over-ride account is selected and confirmed, the transaction value, an address code selected from those updated during consumer registration or maintenance, and an optional narrative description of the goods are supplied to complete the order pre-validation. At this point, both consumer and merchant accounts are updated for the order, within an “awaiting order” status.
- The order data stored against a consumer record is compared to any subsequent order lodged by the merchant upon order fulfillment. Unless any subsequent order logged by a merchant matches the order details provided by the consumer, the transaction will be placed on hold and both consumer and merchant notified. It is then up to the consumer and merchant to rectify the discrepancy as appropriate. The transaction will remain on hold until released by the consumer. This provides extra confidence to the consumer that any orders match the requirements of the consumer before any payment is made and lowers the cost of returns and minimizes complaints rates for merchants. This procedure may be waived in certain retail situations such as face-to-face purchases where the goods are generally provided instantly to the consumer. However, even in these cases, this procedure may still be used in appropriate situations, for example, if the goods are ordered face-to-face but delivered or supplied later.
- As noted previously, the placement of orders by consumers can be made using a range of transaction types, e.g. mail order, telephone order, face-to-face or Internet order. Regardless of the transaction type, the consumer generally orders goods by validating the merchant's identity, and authenticating themselves as described above. Then details of an expected order are logged and the order is placed. Communication with the transaction system 10 may be via any of the communications routes described previously, for example by using an authentication device, Extranet, via telephone to an operator or IVR, mobile communications such as WAP, 3G or i-mode or by Wi-Fi. However, regardless of the transaction type or communication channel used, because of the basic principle of separation of authentication and payment, the same security levels can be applied across all payment channels.
- Once the merchant receives the consumer's order, the merchant may process the order by accessing the
transaction system 1 using one of the communications methods such as using an authentication device, Extranet, by telephone to an operator or IVR or mobile communications. Thereafter, the merchant is required to authenticate their identity using triple authentication if an authentication device is being used or by double authentication otherwise, as described above. After the merchant identity is authenticated, to access the system, the merchant must then validate the consumer's identity and address codes, as shown inFIG. 15 . This feature serves to reduce the levels of consumer identity theft and gives the merchant an increased level of confidence in transacting with consumers of whom the merchant has no previous experience. The merchant carries out consumer identity and address validation by interacting with (a) the operator by telephone; (b) the Extranet secure processing service (utilizing SSL 128-bit security encryption or better as generally available); (c) the IVR (Integrated Voice Response) service, to provide details by voice or by using the telephone keypad; or (d) avalid authentication device 40 to enter details. Merchants using the Extranet system will require to use a selection of mouse selection, alphanumeric character recognition and different web pages to improve security. The merchant may use theauthentication device 40 as an input device to send encrypted data using generally available mobile telephony services to thetransaction system 1 and gain acknowledgement in return. -
FIG. 15 shows part of the order process, which serves to validate theconsumer 294. The merchant obtains an identity code and an address code from the consumer. The merchant communicates the consumer identity code to theauthentication server 296. The authentication server checks the consumer identity code against the user records on the storage media and returns an indication of whether or not the consumer identity is valid. If the consumer identity code entered by the merchant is invalid and fails a pre-specified number of repeated attempts at entry validation, the order entry transaction halts and the merchant is referred back to the consumer with the option of receiving further details by contacting anoperator 298. The transaction logs of both the consumer and merchant are updated along with the consumer and merchant audit logs 299. Progress to the next stage of input of the address code is dependent upon successful validation of the consumer identity code. - Where the consumer identity is valid, the address code can then be communicated to the
authentication server 300. The authentication server checks that the supplied address code matches an address code stored in the consumer's user record. If the address code is invalid (i.e. does not match a stored address code) and remains invalid after failing a pre-specified number of repeated attempts at entry validation, the authentication server will refer the transaction back to the merchant and additionally alerts the consumer using the preferred notification route recorded on the consumer'suser record 302. If either the consumer identity code or the address code is invalid, the invalid consumer details are transferred to the anti-fraud audit trail logs 303. The merchant account transaction history is updated with details of the invalid consumer transactions with appropriate status codes. The consumer account transaction history is also updated. If the merchant is processing multiple consumer orders, processing will flow to the next consumer identity transaction. - Optionally, in some circumstances, the consumer can upload their order details onto the
transaction system 1. If the consumer does this, thetransaction system 1 matches the consumer identity code, address code and merchant identity code to those supplied in the preloaded details in order to further validate the order and merchant identity during initial order processing. The matching of consumer and merchant transactions is an improved counter-fraud security validation check. Where the matches are valid, processing moves to the validation of the consumer payment details. -
FIG. 16 shows a process for validating consumer payments. This allows the merchant to pre-check the consumer's ability to pay and is transacting normally. Validation of consumer payments prior to dispatch or handing over of goods minimizes the risk of non-payment to the merchant and provides an increased level of confidence in transacting with new customers. Checks performed by issuers of payment cards for availability of funds do not, where identity is breached, provide further identity security. The validation process described herein provides, in addition to its triple authentication approach, additional checks against pre-registered payment preferences for consumer-preferred channels, types or values of payment, as well as volume and transaction velocity checks. These checks differ from the authentication means used, providing separation of authentication and payment. - To validate consumer payments, the merchant provides the
transaction system 1 with further details of the consumer order/transaction 306. Thesystem 1 matches the transaction details with those uploaded by the consumer and determines which consumer payment means 47 is to be used. If the consumer did not elect to upload order details (including specifying which payment means to use) prior to contacting the merchant, the payment account selected will default to the payment means nominated by the consumer during registration/maintenance. Once the payment means is identified, checks can be performed by liaising with the consumer account/service providers 2 a-c during transaction entry, for example to establish funds availability and status of the consumer payment account to be used 308. Thetransaction system 1 may facilitate these services by acting as a third party trusted processor, merchant aggregator, reseller or independent sales organization (ISO) as appropriate, in line with the appropriate payment association classifications. If the consumer issuer payment validation is successful, then a service payment validation is carried out 310. - Transactions that fail any specific issuer validation check will be notified to the consumer and a referral/service review initiated 312. Processing is halted on the consumer transaction. If the merchant is bulk processing multiple consumer orders, processing will flow to the next consumer identity transaction. Where transactions are not referred by payment issuers, additional checks are made by the
transaction system 1 to compare and validate the payment against the consumer's operational parameters such as for payment type, value, transaction frequency/velocity and bulk spend in a consumer-predefined period that are stored against the consumer's account during registration or account maintenance. Thetransaction system 1 may compare the transaction details, along with transactions from the consumer transaction log where appropriate, with the preferences and limits stored on the consumer's account. If a transaction would result in a breach of operational parameters, the transaction is referred back to the consumer using the referredtransactions procedure 314. This may include a review of the consumer's status and activity. Processing is halted on the consumer transaction. If the merchant is bulk-processing orders for multiple consumers, processing will flow to the next consumer identity transaction. - For valid transactions that are not stopped by issuer or consumer referrals, additional
merchant validation checks 316 are applied by thetransaction system 1, irrespective of the method utilized by the merchant for communicating with thetransaction system 1. These merchant validation checks are necessary to ensure that the merchant keeps within its operational parameters, such as value, transaction volume, frequency/velocity and level of complaints, agreed and authorized during the merchant registration or subsequent merchant account review or account maintenance. Where breaches of merchant operational parameters occur, thetransaction system 1 may either restrict merchant transactions or allow the merchant to fulfill the transactions processed with appropriate retention of settlement for payments until the merchant's transaction activity is brought back within the operational parameters or new operational parameters are agreed and authorized. The merchant will be referred to an operator to review 318 its service agreement, for example to negotiate different agreement limits, regardless of whether transactions are allowed or halted. Whether a transaction is halted or allowed will depend upon, respectively, whether or not shadow limits have been breached. - Where merchant processing is halted, the merchant is notified and further transacting with the merchant suspended until the merchant rectifies the reason for the breach of operational parameters, or agrees a change to, its service agreement terms and/or
operational parameters 320. The merchant is then responsible for communicating the delay in processing to the relevant consumer, as the rationale for restricting transactions is linked to the merchant commercial terms with the service operator. Thetransaction system 1 will additionally send a notification to the consumer that transactions are halted, in accordance with consumer notification preferences. Updates to the merchant and consumer transaction logs are made, together with updates to the audit trail logs, tagged with appropriate status codes, which indicate the status of the transaction, for example “transaction halted: merchant limit breach”. Every transaction has a status code until it is completed. No further activity on the consumer transaction causing the merchant breach takes place. A new transaction will require to be processed where the merchant breach of operational parameters is not rectified. - If the merchant validation checks are satisfactorily completed, acknowledgement is provided in real-time by the
transaction system 1 to the merchant as appropriate 322. A unique transaction identifier is assigned to the validated transaction. Additional acknowledgement can be provided in the form of automated SMS text message, either per transaction or at end of day for consolidated transaction details. The merchant will be required to respond to an SMS message with a predefined password set at registration before the acknowledgement is transmitted. Historic merchant acknowledgements are stored on the merchant's transaction log and can be reviewed by the merchant by interaction with thetransaction system 1. The consumer is also notified of the completed merchant transaction using the notification procedure. - Finally, merchant and consumer transaction histories, and relevant audit trail logs are updated. Subsequent transactions are processed until all consumer orders are processed. If the merchant is processing bulk orders for multiple consumers, processing will flow to the next consumer identity transaction. Processing of valid merchant transactions is next directed to the consumer acceptance/rejection process, which allows the consumer to confirm that they did place the original order and that they accept the dispatch of goods/services from, and payment to, the merchant. This extra check at this advanced stage in the order process provides increased end-to-end security against payment fraud and consumer and merchant identity theft. In order for fraud to occur, multiple security breaches and checks would require to be compromised.
- Within the notice of the completed merchant transaction, the consumer is prompted to respond to accept or reject the merchant processed transaction by providing details of the order via the notification system, and then to confirm their choice, to ensure single-attempt transaction entry errors are minimized 324. The consumer may, alternatively, elect to trust validated order transactions, in which case a transaction acknowledgement will be sent. Specification of which transactions to trust is set during consumer registration or account maintenance. In the event of discrepancies, the consumer may contact an operator to obtain more details of the transaction.
- Where the consumer elects to reject a merchant order transaction, the specific order transaction concerned will be halted and the transaction status will be changed to “consumer rejected”. No further activity is taken to settle the transaction between consumer and merchant. Where the consumer accepts the payment transaction, the transaction status will be set to “awaiting fulfillment”. Relevant merchant and consumer transaction and value limits will be updated for “awaiting fulfillment” transactions, to ensure that early warning is registered of potential breaches. The merchant is then notified by the
transaction system 1 to proceed with order fulfillment. Thus, before the merchant can dispatch goods/services to a consumer the following security steps must be completed: Successful authentication of the merchant identity; successful authentication of the consumer identity; successful validation checks that the merchant and consumer are operating within their service preferences and limits; validation of the consumer payment means; and confirmation from the consumer that they accept the transaction as valid and wish to proceed. This combination of security measures provides a safeguard for both the merchant and consumer beyond levels provided by prior art payment systems, and can advantageously be applied over multiple transaction channels. - Once the merchant has goods ready to ship to the consumer, the shipping process can be engaged. This may occur contemporaneously with order processing and validation, or take place some time after, depending on the availability of goods and with predefined segregation of duties of merchant staff for added security. Validated order transactions will be held on the
transaction system 1 with “awaiting fulfillment” status codes. Before starting the order fulfillment process, the merchant or staff member must authenticate their identity using the triple authentication process if an authentication device is used or the double authentication process without an authentication device. During account registration, merchants can elect to segregate each merchant staff member's ability to process and fulfill the same orders. This can be done by individual registration of merchant staff users, their authentication devices if applicable, their user identity cards and the functions to which they have access. - As shown in
FIG. 17 , once both merchant and/or relevant merchant staff are authenticated (notwithstanding they may already be on line and not subject to predefined segregation of duties for added security), the merchant (or merchant staff) may access those order transactions flagged with a status of “awaiting fulfillment”, from thetransaction system 1. The merchant identifies the transaction(s) to be processed for payment by their account details and order transaction reference(s), which additionally identifies the channel of origin, for example mail, Internet, telephone. Only transactions with an “awaiting fulfillment” status are made available to the merchant by thetransaction system 1. Referred transactions will be held in an appropriate queue tagged with a “referred transaction” status. - The merchant will be prompted by IVR, operator, Extranet or authentication device prompt, to acknowledge the merchant is ready to dispatch the goods concerned. This facilitates card scheme requirements to take payment only on dispatch of goods, providing an additional compliance check. The merchant then accesses the orders that are awaiting
fulfillment 330 and determines whether the orders can be wholly or partially fulfilled 332. Where goods are partially available for dispatch, the merchant contacts the consumer to determine whether the consumer wishes to accept delivery of the partial order or whether they would prefer to wait 334. The request is made via the notification system. The consumer can then respond accordingly via thetransaction system 1. The consumer may also default to await fulfillment of complete orders or accept partial fulfillment at registration or through account maintenance. Where (i) the merchant does not have the goods to fulfill the order; or (ii) the consumer declines partial fulfillment, or (iii) the consumer accepts partial fulfillment, for those goods that cannot be fulfilled, the transaction status of the order remains at “awaiting fulfillment” 336 and no further action is taken on that order until the goods are ready for dispatch to fulfill the consumer order. Where the merchant has one or more further transactions to process, thesystem 1 will direct the merchant to the next order with transaction status “awaiting fulfillment”. - Once the merchant has acknowledged readiness to dispatch goods (whether full or partial orders), and the consumer order is wholly fulfilled, or partially fulfilled with consumer acceptance, a check is performed to assess whether the initial processing of the order is over a specified number of days old, defaulted to five days at registration (and specified further in the merchant service agreement) 338. Where the order has been unfulfilled for at least this period, the
transaction system 1 re-validates theconsumer identity 340 and payment details to ensure the payment can proceed before goods are dispatched 342. This security check ensures that merchants are not overtly exposed to fraud that may have occurred during the delay between the payment transaction and completion. Thetransaction system 1 firstly re-validates the consumer's identity and address code as described above, to ensure it remains active and does not have a “lost/stolen” or other security status recorded. If the consumer identity and address code are revalidated, thetransaction system 1 next revalidates the relevant payment means for funds availability and notification statuses. - The consumer can select to automatically trust transactions in their operating parameters. If transactions are automatically trusted then the aged transaction status is then updated to “awaiting address confirmation” and the merchant is notified. Where a consumer has not previously elected to automatically trust a transaction, the
transaction system 1 reconfirms that they want the order to be fulfilled or rejected 344. Once this is done, the merchant dispatches the goods and the order is fulfilled 346. The merchant cannot fulfill orders prior to acceptance by the consumer, as the consumer address has not been passed by thetransaction system 1 to the merchant. In this way, additional security protection is provided to both consumer and merchant. -
FIG. 18 shows the steps for accepting and/or rejecting an aged payment in more detail. Firstly it is determined whether the consumer has elected to trust the transaction withoutvalidation 350. Where the consumer has not previously elected to trust transactions and accept fulfillment of orders processed without further validation at the order fulfillment stage, the consumer is prompted to respond to a notification requesting the user to accept or reject the delayed transaction and then to confirm his/her choice, to ensure single-attempt transaction entry errors are minimized 352. Where the consumer does not trust transactions and subsequently rejects theorder 354, the merchant will receive a “consumer rejection” transaction notification from an operator, IVR, authentication device or Extranet communication. The transaction will halt and the merchant and consumer account transaction logs will be updated. No further transaction processing will take place on the rejected transaction. Audit-trail and rejected transaction records, and the merchant transaction volume and value limits will be updated. Where the consumer accepts the revalidated order, the merchant will receive acknowledgement 356 by service agent, IVR, authentication device or Extranet communication that the transaction has been successfully completed. The transaction status will be updated to “awaiting address confirmation”. Thetransaction system 1 updates the consumer and merchant accounts for the status of the transaction (whether completed successfully or rejected) and tracks transaction stages and transaction status accordingly 358. Transactions will have a “awaiting address confirmation” or “consumer rejected” status. - Once all checks are successfully completed, the merchant can fulfill the
order 360, as shown inFIG. 19 . For those transactions with a status of “awaiting address confirmation” only, the consumer's delivery address details are passed to the merchant fororder fulfillment 362. Thus, the consumer address is withheld from the merchant until the order is on the point of dispatch and all authentication steps have been completed. In addition, the delivery address may be different from the billing address. This is beneficial in reducing the accessibility of consumer details and thereby reducing the risk of identity theft. The consumer is notified of the dispatch of goods by anotification message 364. In this way, the consumer has a final notification of the transaction before dispatch of the goods, which allows the consumer a further chance to report any unexpected orders and thereby reducing fraud. Thetransaction system 1 updates the consumer and merchant accounts to “completed” transaction status. Relevant merchant transaction and value limits will be updated for completed transactions, to ensure that early warning is registered ofpotential breaches 366. - The
transaction system 1 communicates with the issuer of the consumer payment means selected for that transaction and facilitates the transfer of funds to the merchant directly into itspredefined bank account 368. In an alternate embodiment, thetransaction system 1 can arrange for the transaction funds to be obtained and held in escrow by thesystem 1 before the goods are dispatched by the merchant. Once the funds are in escrow by thesystem 1, the system notifies the merchant. The merchant may then dispatch the goods, with the funds being transferred by thesystem 1 to the merchant's predefined bank account when the goods are received by the consumer. This gives the retailer a guarantee of payment and the consumer a guarantee that they will receive the goods before payment is received by the retailer. Any chargeback reserve or retention fund assessed prudent by the system operator or in accordance with the merchant service agreement will be withheld until the merchant meets specific contractual terms. -
FIG. 20 shows the process for handling referred consumer transactions. Each user account has certain operational parameters within which the account must be operated. The operational parameters are either set by the service operator when issuing accounts or during a user review, based on an assessment of the risk of the user in order to minimize exposure of the service operator to fraud and bad debts, and/or selected by the user themselves on registration or account maintenance to limit their own exposure to fraudulent use or to help control their own transaction patterns. As shown inFIG. 18 , referred transactions are transactions that fail to meet these operational parameters or are referred by a user's payment issuer is response to a breach of limits set by the issuer. Since changing of the operational parameters is via account maintenance, which requires the user to dual or triple authenticate themselves, it is considerably more difficult for fraudsters to alter user account settings and thereby reduce the possibility that fraudulent transactions can be approved. The greater the use of these criteria, the more effective the referral processes will be. Consumer security and convenience are therefore emphasized. - Consumer transactions may be referred either by the transaction system or by the institution providing the consumer with a card or account for a number of reasons. When a referral is made, it is firstly determined whether it was by the
system 1 or theissuer 372. Where it is the issuer, referral can be for a number of reasons, e.g. insufficient funds, temporary hold on account, lost or stolen card, type of merchant, value of transaction. Payment card and non-card payment means transaction validation checks are performed during transaction entry, in line with existing payment provider checks, to establish funds availability and status of the registered consumer payment account being used. Thetransaction system 1 may facilitate these validation checks directly or through access to payment provider services by acting as a third party trusted processor, merchant aggregator, reseller or independent sales organization (ISO) as appropriate, in line with Cards and non-Cards payment association classifications. When a card or non-card payment account breaches a predefined referral check, a formal card, or non-card issuer referral is activated, in line with card scheme or non-card payment means provider regulations. In addition, consumer operational parameters may be breached that trigger a referral by thetransaction system 1 that halts or delays a consumer's ability to pursue a transaction further. The operational parameters include, for example, checking for breach of limits on payment type, value, transaction frequency/velocity and bulk spend in a consumer-predefined period. - Where a consumer's payment means issuer (e.g. Visa, MasterCard) refers 374 a transaction to the
transaction system 1, thetransaction system 1 will notify the merchant automatically 376. The merchant will be notified of the referral status of transactions by the interaction route being used to process the consumer payment transactions, e.g. by IVR, service agent by telephone, Extranet or authentication device. The merchant will notify transaction referral to the consumer during the ordinary course of the transactions, as referrals necessarily hold uppayment completion progress 378. For consumer order transactions, notification is also made using the notification system. This approach should ensure appropriate notification to the consumer is effected, alerting the consumer to any transaction issues of which they should be aware. Where a referral has occurred due to the consumer breaching one or more predefined operating parameters, the consumer is requested to contact an operator for a service review. Assessment of the referred transaction against shadow limits will determine whether a transaction can be processed to conclusion. Shadow limits will be set at registration and will be applied by thetransaction system 1 to allow orderly management of consumer use of the service. This enables the consumer to have control over the value and velocity of their transactions. - Where a transaction is allowed within the shadow limits, the referred transaction is processed to conclusion. The relevant user is notified by a notification and the consumer may be requested to seek a service review. Where the
transaction system 1 does not allow a transaction to proceed to conclusion, for example, where a shadow limit is breached or an issuer referral has occurred, both the merchant involved and the consumer are notified by the notification system. The payment transaction will be halted, and its status set to “halted” 380. Thetransaction system 1 will take no further action on the transaction until the merchant and consumer have placed a further transaction that is not referred. Additionally, the merchant and consumer transaction records will be updated to reflect the transaction status. The audit trail logs are updated with details of the transaction. - As shown in
FIG. 21 , in particular instances, a consumer may reject atransaction 384. This may take place where the consumer is unaware the transaction has been made, for example fraud or misuse, but the existing card or bank account systems used by the consumer have not been alerted to the activity. It may also be due to “cooling off” legislation, which allows consumers to repudiate transactions in particular circumstances and hand back goods. Where the consumer rejects the transaction, and selects an appropriate reason code for transmission, the transaction will be halted 386. The consumer may also reject a pending transaction that has yet to be fulfilled, due to merchant delay, before the merchant acknowledges readiness to dispatch the order. The consumer will do this by processing a rejection transaction through a valid, secure authentication device, Extranet or by direct telephone call. SMS or email will not be valid formats for processing consumer initiated rejection transactions as since these transactions are consumer initiated, the options to provide authentication using these channels are limited. No further activity on the transaction will take place. No goods will at this stage have passed from the merchant to the consumer, and the status of the transaction should remain at “awaiting fulfillment”. The consumer may reject the transaction even after acceptance during initial transaction validation if a valid reason code is entered. On receipt of a valid consumer rejection transaction, the merchant concerned will be notified by thenotification system 388. - The merchant and consumer transaction logs will be updated accordingly 390 and the audit trail logs will be updated 392. System operators can then investigate the transaction and engage transaction monitoring systems to identify whether fraudulent or abnormal activity is taking place with the consumer and merchant concerned.
- In view of the unique additional security aspects offered by the
transaction system 1, the probability of chargebacks due to fraudulent transactions will be significantly reduced, enhancing convenience and security for consumers, and reducing fraud risk, costs and administration for merchants. Nevertheless, provisions are made for doing this as shown inFIG. 22 . Chargeback transactions originate from issuers of credit and charge card products who have been legitimately instructed by consumers who wish, for varying reasons, to reverse a payment transaction previously made, generally due to dispute. Thetransaction system 1 will processchargebacks 394 against registered merchants in line with credit card association rules for credit cards, for example, where a consumer claims goods purchased were not received or where the item purchased is “not as described” by the merchant. Other payment provider chargeback rules will also be honored. The authentication, notification service and other security aspects result in reduced probability of chargebacks due to fraudulent transactions, enhancing convenience and security for consumers, and reducing fraud risk, costs and administration for merchants. - A consumer requiring a chargeback to be made sends a chargeback request to the
transaction system 1 directly for service transactions, or through the consumer's issuing institution for other transactions, where the system acts as a merchant aggregator or ISO. The system is checked to see whether the chargeback is recorded 396. Details of the transaction to be charged back are matched against the consumer and merchant transaction records and validated against legitimatechargeback reason codes 398. This prevents consumers mistakenly or fraudulently obtaining chargebacks on transactions that have not actually occurred or for invalid reasons. Where the chargeback request is unsupported, no further action is taken, and the consumer and merchant transaction logs and audit and chargeback logs are updated accordingly 400. Thesystem 1 will transfer the relevant transaction details onto the audit logs to filter against future chargeback attempts involving the same consumer or merchant. - Where a chargeback request is valid, both the merchant and consumer accounts are updated with the chargeback details and reason codes in accordance with
general industry practice 402. The chargeback log will also be updated. The transaction concerned will be charged back against the merchant's account or chargeback reserve as necessary whilst chargeback dispute resolution takes place. Thetransaction system 1 will pass details to the merchant's bank or payment institution concerned, and thereafter liaise 404 with the merchant's bank/institution and the consumer's bank/institution as necessary. For non-card transactions, the operator liaises with the banks/institutions representing the consumer and the merchant as necessary. - In instances in which resolution to a chargeback dispute is required, merchant and consumer service terms and conditions will dictate which party bears the liability for the value in dispute 406. This will be facilitated through service agreement reviews. This review may result in suspension of particular merchants or consumers from use of the service due to excessive chargeback histories, velocities or value parameters being breached. During “suspended” periods, merchants or consumers may only access registration and maintenance facilities. No payment transactions can be processed. Chargeback dispute resolution may result in merchant funds being withheld whilst a chargeback dispute is investigated to conclusion. Dispute resolution may result in a refund to the consumer from the merchant, or validation of the disputed transaction in favor of the merchant 408. The relevant consumer and merchant accounts will be updated on completion of the chargeback dispute. Dispute resolution will be communicated to the users concerned via the
notification system 410. - In some instances, for example, where an error is made and accepted by a merchant, e.g. processing error, or goods are legitimately returned or exchanged, a credit transaction may be required to reimburse, in full or in part, the consumer. In such cases, the merchant can process a credit using the
transaction system 1.FIG. 23 shows the steps for processing credits. Credits may be issued to consumers mistakenly or fraudulently by members of the merchant's staff. In order to minimize this, the service matches credits to underlying transactions and if they are not matched, presents additional security levels to validate the credits. In addition, merchant check criteria may be set and permissions only given to certain members of merchant staff, for example to authorize large value credits, as defined on registration or account maintenance, or credits that do not match underlying transactions. - Where a credit transaction is initiated 414, the merchant may only process the credit against a completed transaction. In order to process a credit the merchant and merchant member of staff must undergo the double or triple authentication process. As described previously, merchants can elect to improve security over potential fraud by segregating the ability to process order transactions and subsequent credit transactions against those orders amongst different merchant staff by registering different merchant staff as users, their authentication devices if applicable and their identity cards and assigning their access only to
certain transaction system 1 functions. Once the merchant staff member identity details are validated 416, details of the transaction to be credited back are matched against the consumer and merchant account records 418. - Where the credit cannot be matched partially or fully against a previously completed transaction, no further action is taken unless the merchant further authorizes the
credit 420. This further authorization may be done where merchants possess two or more identity cards, the merchant will be required to have a secondary authorization for processing of credits in excess of a value set up on merchant registration or where matching does not occur. This uniquely provides security against fraudulent processing of credits by individual members of merchant staff colluding with third party consumers (who may be themselves). Parameters such as specific value and velocity and volume of credit transactions are specified in the merchant's operating parameters upon registration or account maintenance and will be monitored against both merchant and consumer accounts, and the audit trail and anti-fraud logs updated, providing a unique monitoring check against multiple merchant-consumer combinations 422. - Where a merchant has two or more identity cards, the merchant may elect during registration or account maintenance to have a secondary authorization for processing of credits where a predefined credit limit is breached (for single or multiple transactions across specific and general time periods). Where a particular merchant and/or consumer has breached its operating parameters across particular timescales of credit transactions, the user service agreement terms may restrict further processing of credits. Where a credit transaction breaches the operating parameters, the transaction is halted, the merchant and consumer accounts are updated, and relevant audit trail logs are updated 424. A service review is then instigated to investigate matters further.
- Where a credit transaction is matched, or is further authorized and does not breach any operating parameters, the credit processing proceeds 426. Merchant settlement proceeds may be withheld to set-off/cover credit transactions for a specified period thereby providing protection against increasing, undetected fraud by otherwise authorized members of merchant staff. Once processed, the consumer and merchant transaction accounts are updated accordingly 428 and a notification sent to the consumer by the notification process. Funds are settled back to the consumer from the merchant account in accordance with the user service agreement. Consumer and merchant accounts will be updated, and credit transaction and audit log files updated 430. The status of the credit transaction is set to “completed.” The credit transaction log is monitored for velocity, volume and value checks against merchant and consumer accounts, to facilitate anti-fraud checks.
- As noted previously the present invention can be used for many different transaction types. The same basic principles apply to all of these. However, as will be appreciated, the specifics will vary. For example, for face-to-face transactions where the consumer will take the goods away with them, once both parties are authenticated, the transaction can be concluded as normal, although without the consumer's financial details being made available to the merchant. Hence, for face-to-face transactions there is generally no need to check whether the goods have been dispatched etc. In contrast, these considerations are clearly important for all orders for which the consumer will be unable to access or take goods physically away at the time of transaction, for example for Internet or telephone or mail order transactions. In this case, the consumer's identity code and address code are needed to help identify where goods are to be sent when dispatched. Only where prior order lodgement and merchant validation has been recorded will details of the order be stored within the consumer's and/or merchant's user accounts on the
transaction system 1. - A skilled person will appreciate that variations of the disclosed arrangements are possible without departing from the invention. For example, although the transaction server, authentication server, payment server and any server required by the communications system are shown as physically separate, or one or more of the
transaction system 1 server functions may be incorporated within the same physical server. In addition, whilst the description refers generally to the use of servers, it will be appreciated that any computer processor or computer based system could be used. Accordingly the above description of the specific embodiment is made by way of example only and not for the purposes of limitation. It is clear that minor modifications may be made without significant changes to the operation described.
Claims (20)
1. A computer-implemented method for facilitating electronic transactions between a first party and one or more second parties, comprising:
establishing a first relationship with the first party, the first relationship defining a dynamically controllable and selectable selection of at least one user-specified and user-specific authentication method selected from a plurality of stored authentication methods of different types operating on an authentication device over a plurality of different communication channels and useable to authenticate the identity of the first party in a non-predictable and anonymous manner;
establishing a second relationship with at least one of said one or more second parties;
storing one or more associations between payment methods and transactions, the one or more associations specified by the first party; and
upon receiving an authentication request related to a transaction with one or more of the second parties:
controlling the authentication device to validate the identity of the first party by presenting the first party with at least one of the previously selected user-specified and user-specific stored authentication methods on the authentication device; and
upon successful authentication using the at least one of the previously selected user-specified and user-specific stored authentication methods on the authentication device, initiating the transaction with said one or more second parties using one or more payment methods associated with the transaction.
2. The computer-implemented method of claim 1 , wherein the associations associate payment methods with types of transactions.
3. The computer-implemented method of claim 2 , wherein the associations associate payment methods with a particular second party.
4. The computer-implemented method of claim 1 , further comprising:
upon receiving an authentication request related to the transaction and prior to the initiating step, validating the transaction against one or more parameters.
5. The computer-implemented method of claim 4 , wherein the one or more parameters include one or more selected from the group consisting of: payment type, payment value, transaction frequency, transaction velocity, bulk spend within a period, credit risk, and fraud risk.
6. The computer-implemented method of claim 1 , wherein said transaction comprises a purchase of goods or services.
7. The computer-implemented method of claim 1 , wherein said transaction comprises a disbursement of cash from a cash disbursement mechanism.
8. The computer-implemented method of claim 1 , wherein said transaction comprises a money transfer.
9. The computer-implemented method of claim 1 , wherein the transaction includes executing a first financing method for the transaction.
10. The computer-implemented method of claim 1 , wherein the entire transaction is completed without identifying any financial information of the consumer to the first of said one or more second parties.
11. The computer-implemented method of claim 1 , wherein the plurality of stored authentication methods of different types include interactive voice recognition via a voice telecommunications channel.
12. The computer-implemented method of claim 11 , wherein the interactive voice recognition is directed to a predetermined telecommunications device.
13. The computer-implemented method of claim 1 , wherein the plurality of stored authentication methods of different types include a fingerprint-based authentication method implemented on a device including both a fingerprint reader and a mobile telecommunications apparatus.
14. The computer-implemented method of claim 1 , wherein the plurality of stored authentication methods of different types include providing an answerback PIN via an SMS message.
15. The computer-implemented method of claim 1 , wherein the plurality of stored authentication methods are not associated with the transaction.
16. The computer-implemented method of claim 1 , wherein the plurality of stored authentication methods are not prescribed by the second party involved in the transaction.
17. The computer-implemented method of claim 1 , wherein information about the first party is not transmitted until the second party is ready to transfer possession of a subject of the transaction to the first party.
18. The computer-implemented method of claim 17 , wherein the information about the first party includes a ship-to address.
19. The computer-implemented method of claim 1 , wherein the plurality of stored authentication methods of different types operate on different communication channels from the transaction.
20. The computer-implemented method of claim 1 , wherein at least one of the plurality of stored authentication methods utilize one or more selected from the group consisting of: IP protocol data and device identity data.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US15/296,759 US20170091775A1 (en) | 2006-10-25 | 2016-10-18 | Secure authentication and payment system |
Applications Claiming Priority (6)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
GB0621189.0 | 2006-10-25 | ||
GBGB0621189.0A GB0621189D0 (en) | 2006-10-25 | 2006-10-25 | Secure authentication and payment system |
US11/692,656 US8423466B2 (en) | 2006-10-25 | 2007-03-28 | Secure authentication and payment system |
US13/838,764 US20130212022A1 (en) | 2006-10-25 | 2013-03-15 | Secure authentication and payment system |
US14/716,519 US9530129B2 (en) | 2006-10-25 | 2015-05-19 | Secure authentication and payment system |
US15/296,759 US20170091775A1 (en) | 2006-10-25 | 2016-10-18 | Secure authentication and payment system |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/716,519 Continuation US9530129B2 (en) | 2006-10-25 | 2015-05-19 | Secure authentication and payment system |
Publications (1)
Publication Number | Publication Date |
---|---|
US20170091775A1 true US20170091775A1 (en) | 2017-03-30 |
Family
ID=37545927
Family Applications (6)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/692,656 Active 2028-10-05 US8423466B2 (en) | 2006-10-25 | 2007-03-28 | Secure authentication and payment system |
US13/838,764 Abandoned US20130212022A1 (en) | 2006-10-25 | 2013-03-15 | Secure authentication and payment system |
US14/716,519 Active US9530129B2 (en) | 2006-10-25 | 2015-05-19 | Secure authentication and payment system |
US15/296,759 Abandoned US20170091775A1 (en) | 2006-10-25 | 2016-10-18 | Secure authentication and payment system |
US15/296,778 Abandoned US20170039564A1 (en) | 2006-10-25 | 2016-10-18 | Secure authentication and payment system |
US15/296,743 Abandoned US20170039563A1 (en) | 2006-10-25 | 2016-10-18 | Secure authentication and payment system |
Family Applications Before (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/692,656 Active 2028-10-05 US8423466B2 (en) | 2006-10-25 | 2007-03-28 | Secure authentication and payment system |
US13/838,764 Abandoned US20130212022A1 (en) | 2006-10-25 | 2013-03-15 | Secure authentication and payment system |
US14/716,519 Active US9530129B2 (en) | 2006-10-25 | 2015-05-19 | Secure authentication and payment system |
Family Applications After (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/296,778 Abandoned US20170039564A1 (en) | 2006-10-25 | 2016-10-18 | Secure authentication and payment system |
US15/296,743 Abandoned US20170039563A1 (en) | 2006-10-25 | 2016-10-18 | Secure authentication and payment system |
Country Status (2)
Country | Link |
---|---|
US (6) | US8423466B2 (en) |
GB (1) | GB0621189D0 (en) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20150081462A1 (en) * | 2012-07-31 | 2015-03-19 | Matthew D. Ozvat | Systems and methods for secure normative intermediation of payments processing peripherals |
US20200111094A1 (en) * | 2018-10-05 | 2020-04-09 | Mastercard International Incorporated | Systems and methods for facilitating network transactions based on user authentication |
WO2020205035A3 (en) * | 2019-01-22 | 2021-07-22 | Shtar Llc | Securing transactions via multi-device authentication |
Families Citing this family (450)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8396811B1 (en) | 1999-02-26 | 2013-03-12 | Syncada Llc | Validation approach for auditing a vendor-based transaction |
US20070055582A1 (en) | 1996-11-12 | 2007-03-08 | Hahn-Carlson Dean W | Transaction processing with core and distributor processor implementations |
US8392285B2 (en) | 1996-11-12 | 2013-03-05 | Syncada Llc | Multi-supplier transaction and payment programmed processing approach with at least one supplier |
US20080172314A1 (en) | 1996-11-12 | 2008-07-17 | Hahn-Carlson Dean W | Financial institution-based transaction processing system and approach |
US8706630B2 (en) | 1999-08-19 | 2014-04-22 | E2Interactive, Inc. | System and method for securely authorizing and distributing stored-value card data |
US7237117B2 (en) | 2001-03-16 | 2007-06-26 | Kenneth P. Weiss | Universal secure registry |
US8548927B2 (en) * | 2001-07-10 | 2013-10-01 | Xatra Fund Mx, Llc | Biometric registration for facilitating an RF transaction |
US8235287B2 (en) | 2010-10-13 | 2012-08-07 | Square, Inc. | Read head device with slot configured to reduce torque |
US9286635B2 (en) | 2002-02-05 | 2016-03-15 | Square, Inc. | Method of transmitting information from efficient communication protocol card readers to mobile devices |
US9305314B2 (en) | 2002-02-05 | 2016-04-05 | Square, Inc. | Methods of transmitting information to mobile devices using cost effective card readers |
US9324100B2 (en) | 2002-02-05 | 2016-04-26 | Square, Inc. | Card reader with asymmetric spring |
US8302860B2 (en) | 2010-10-13 | 2012-11-06 | Square, Inc. | Read head device with narrow card reading slot |
US8500018B2 (en) | 2010-10-13 | 2013-08-06 | Square, Inc. | Systems and methods for financial transaction through miniaturized card reader with decoding on a seller's mobile device |
US8870070B2 (en) | 2010-10-13 | 2014-10-28 | Square, Inc. | Card reader device |
US9495676B2 (en) | 2002-02-05 | 2016-11-15 | Square, Inc. | Method of transmitting information from a power efficient card to a mobile device |
US8876003B2 (en) | 2010-10-13 | 2014-11-04 | Square, Inc. | Read head device with selected output jack characteristics |
US8573487B2 (en) | 2010-10-13 | 2013-11-05 | Square, Inc. | Integrated read head device |
US9582795B2 (en) | 2002-02-05 | 2017-02-28 | Square, Inc. | Methods of transmitting information from efficient encryption card readers to mobile devices |
US9916581B2 (en) | 2002-02-05 | 2018-03-13 | Square, Inc. | Back end of payment system associated with financial transactions using card readers coupled to mobile devices |
US8870071B2 (en) | 2010-10-13 | 2014-10-28 | Square, Inc. | Read head device with selected sampling rate |
US9262777B2 (en) | 2002-02-05 | 2016-02-16 | Square, Inc. | Card reader with power efficient architecture that includes a wake-up circuit |
US8573486B2 (en) | 2010-10-13 | 2013-11-05 | Square, Inc. | Systems and methods for financial transaction through miniaturized card reader with confirmation of payment sent to buyer |
US20120005039A1 (en) | 2002-02-05 | 2012-01-05 | Jack Dorsey | Method of conducting financial transactions |
US9016572B2 (en) | 2010-10-13 | 2015-04-28 | Square, Inc. | Systems and methods for financial transaction through miniaturized card with ASIC |
US9262757B2 (en) | 2002-02-05 | 2016-02-16 | Square, Inc. | Method of transmitting information from a card reader with a power supply and wake-up circuit to a mobile device |
US9224142B2 (en) | 2002-02-05 | 2015-12-29 | Square, Inc. | Card reader with power efficient architecture that includes a power supply and a wake up circuit |
US9495675B2 (en) | 2002-02-05 | 2016-11-15 | Square, Inc. | Small card reader configured to be coupled to a mobile device |
US20030187778A1 (en) * | 2002-03-27 | 2003-10-02 | First Data Corporation | Merchant application and underwriting systems and methods |
US9710852B1 (en) | 2002-05-30 | 2017-07-18 | Consumerinfo.Com, Inc. | Credit report timeline user interface |
US9400589B1 (en) | 2002-05-30 | 2016-07-26 | Consumerinfo.Com, Inc. | Circular rotational interface for display of consumer credit information |
US7792715B1 (en) | 2002-09-21 | 2010-09-07 | Mighty Net, Incorporated | Method of on-line credit information monitoring and control |
US7451113B1 (en) | 2003-03-21 | 2008-11-11 | Mighty Net, Inc. | Card management system and method |
US8762238B2 (en) | 2004-06-09 | 2014-06-24 | Syncada Llc | Recurring transaction processing system and approach |
AU2005255456B2 (en) | 2004-06-09 | 2007-09-13 | Syncada Llc | Order-resource fulfillment and management system and approach |
AU2005255453B2 (en) | 2004-06-09 | 2007-11-08 | Syncada Llc | Financial institution-based transaction processing system and approach |
US8732004B1 (en) | 2004-09-22 | 2014-05-20 | Experian Information Solutions, Inc. | Automated analysis of data to generate prospect notifications based on trigger events |
US8175889B1 (en) | 2005-04-06 | 2012-05-08 | Experian Information Solutions, Inc. | Systems and methods for tracking changes of address based on service disconnect/connect data |
US20070043577A1 (en) * | 2005-08-16 | 2007-02-22 | Sheldon Kasower | Apparatus and method of enabling a victim of identity theft to resolve and prevent fraud |
US20080033852A1 (en) * | 2005-10-24 | 2008-02-07 | Megdal Myles G | Computer-based modeling of spending behaviors of entities |
US8290433B2 (en) * | 2007-11-14 | 2012-10-16 | Blaze Mobile, Inc. | Method and system for securing transactions made through a mobile communication device |
WO2007145687A1 (en) * | 2006-02-21 | 2007-12-21 | Weiss Kenneth P | Method and apparatus for secure access payment and identification |
US11227676B2 (en) | 2006-02-21 | 2022-01-18 | Universal Secure Registry, Llc | Universal secure registry |
US8234220B2 (en) | 2007-02-21 | 2012-07-31 | Weiss Kenneth P | Universal secure registry |
US8117459B2 (en) * | 2006-02-24 | 2012-02-14 | Microsoft Corporation | Personal identification information schemas |
US8104074B2 (en) * | 2006-02-24 | 2012-01-24 | Microsoft Corporation | Identity providers in digital identity system |
US7711636B2 (en) | 2006-03-10 | 2010-05-04 | Experian Information Solutions, Inc. | Systems and methods for analyzing data |
US7818264B2 (en) | 2006-06-19 | 2010-10-19 | Visa U.S.A. Inc. | Track data encryption |
US8078880B2 (en) | 2006-07-28 | 2011-12-13 | Microsoft Corporation | Portable personal identity information |
US8510223B2 (en) | 2006-08-03 | 2013-08-13 | The Western Union Company | Money transfer transactions via pre-paid wireless communication devices |
US8036979B1 (en) | 2006-10-05 | 2011-10-11 | Experian Information Solutions, Inc. | System and method for generating a finance attribute from tradeline data |
US8712884B2 (en) | 2006-10-06 | 2014-04-29 | Syncada Llc | Transaction finance processing system and approach |
US8359278B2 (en) | 2006-10-25 | 2013-01-22 | IndentityTruth, Inc. | Identity protection |
US20080126258A1 (en) * | 2006-11-27 | 2008-05-29 | Qualcomm Incorporated | Authentication of e-commerce transactions using a wireless telecommunications device |
US7657569B1 (en) | 2006-11-28 | 2010-02-02 | Lower My Bills, Inc. | System and method of removing duplicate leads |
US7778885B1 (en) | 2006-12-04 | 2010-08-17 | Lower My Bills, Inc. | System and method of enhancing leads |
US8087072B2 (en) * | 2007-01-18 | 2011-12-27 | Microsoft Corporation | Provisioning of digital identity representations |
US8407767B2 (en) * | 2007-01-18 | 2013-03-26 | Microsoft Corporation | Provisioning of digital identity representations |
US8689296B2 (en) * | 2007-01-26 | 2014-04-01 | Microsoft Corporation | Remote access of digital identities |
US8606626B1 (en) | 2007-01-31 | 2013-12-10 | Experian Information Solutions, Inc. | Systems and methods for providing a direct marketing campaign planning environment |
US8606666B1 (en) | 2007-01-31 | 2013-12-10 | Experian Information Solutions, Inc. | System and method for providing an aggregation tool |
BRPI0810369B8 (en) | 2007-04-17 | 2019-05-28 | Visa Usa Inc | method, computer readable medium, directory server, and telephone |
US8078515B2 (en) * | 2007-05-04 | 2011-12-13 | Michael Sasha John | Systems and methods for facilitating electronic transactions and deterring fraud |
US11257080B2 (en) | 2007-05-04 | 2022-02-22 | Michael Sasha John | Fraud deterrence for secure transactions |
US20080289020A1 (en) * | 2007-05-15 | 2008-11-20 | Microsoft Corporation | Identity Tokens Using Biometric Representations |
WO2008147918A2 (en) * | 2007-05-25 | 2008-12-04 | Experian Information Solutions, Inc. | System and method for automated detection of never-pay data sets |
US7739169B2 (en) * | 2007-06-25 | 2010-06-15 | Visa U.S.A. Inc. | Restricting access to compromised account information |
US8121956B2 (en) * | 2007-06-25 | 2012-02-21 | Visa U.S.A. Inc. | Cardless challenge systems and methods |
US10163092B2 (en) | 2007-08-18 | 2018-12-25 | Expensify, Inc. | System and method for establishing a payment mechanism with a plurality of merchants |
US10068225B2 (en) | 2007-08-18 | 2018-09-04 | Espensify, Inc. | System and method for utilizing a universal prepaid card |
US10185947B2 (en) | 2007-08-18 | 2019-01-22 | Expensify, Inc. | Computer system implementing a network transaction service |
US9830582B1 (en) * | 2007-08-18 | 2017-11-28 | Expensify, Inc. | System, computer readable medium, and method for authorizing purchase using on-demand prepaid card |
US10423896B2 (en) | 2007-08-18 | 2019-09-24 | Expensify, Inc. | Computer system implementing a network transaction service |
WO2009026460A1 (en) | 2007-08-23 | 2009-02-26 | Giftango Corporation | Systems and methods for electronic delivery of stored value |
EP2203865A2 (en) | 2007-09-24 | 2010-07-07 | Apple Inc. | Embedded authentication systems in an electronic device |
US20090089190A1 (en) * | 2007-09-27 | 2009-04-02 | Girulat Jr Rollin M | Systems and methods for monitoring financial activities of consumers |
US9690820B1 (en) | 2007-09-27 | 2017-06-27 | Experian Information Solutions, Inc. | Database system for triggering event notifications based on updates to database records |
US20090131089A1 (en) * | 2007-11-16 | 2009-05-21 | Anthony Micali | Personal text trainer system for sound diets and fitness regimens |
US9098844B2 (en) | 2007-11-20 | 2015-08-04 | Wells Fargo Bank, N.A. | Mobile electronic wallet |
SE532268C2 (en) * | 2007-12-04 | 2009-11-24 | Accumulate Ab | Procedure for secure transactions |
US8359268B2 (en) * | 2007-12-11 | 2013-01-22 | Mastercard International Incorporated | System and method for processing financial transactions |
US9990674B1 (en) | 2007-12-14 | 2018-06-05 | Consumerinfo.Com, Inc. | Card registry systems and methods |
US8127986B1 (en) | 2007-12-14 | 2012-03-06 | Consumerinfo.Com, Inc. | Card registry systems and methods |
US8794532B2 (en) * | 2008-12-29 | 2014-08-05 | Mastercard International Incorporated | Methods and apparatus for use in association with identification token |
US20090171852A1 (en) * | 2007-12-28 | 2009-07-02 | Scott Taylor | Method and System for Providing Secure Processing of Electronic Transactions |
US8600120B2 (en) | 2008-01-03 | 2013-12-03 | Apple Inc. | Personal computing device control using face detection and recognition |
US20090192944A1 (en) * | 2008-01-24 | 2009-07-30 | George Sidman | Symmetric verification of web sites and client devices |
US8751337B2 (en) | 2008-01-25 | 2014-06-10 | Syncada Llc | Inventory-based payment processing system and approach |
US20090216651A1 (en) * | 2008-02-22 | 2009-08-27 | Ncr Corporation | Dispensing valuable media |
US7913902B2 (en) * | 2008-04-15 | 2011-03-29 | Novell, Inc. | System and method for implementing a virtual automated teller machine |
US8024238B2 (en) * | 2008-04-24 | 2011-09-20 | Visa U.S.A. Inc. | Negative balance management |
US9715709B2 (en) | 2008-05-09 | 2017-07-25 | Visa International Services Association | Communication device including multi-part alias identifier |
US8516562B2 (en) * | 2008-05-13 | 2013-08-20 | Veritrix, Inc. | Multi-channel multi-factor authentication |
US20090307140A1 (en) | 2008-06-06 | 2009-12-10 | Upendra Mardikar | Mobile device over-the-air (ota) registration and point-of-sale (pos) payment |
US10373198B1 (en) | 2008-06-13 | 2019-08-06 | Lmb Mortgage Services, Inc. | System and method of generating existing customer leads |
US8145565B1 (en) * | 2008-06-20 | 2012-03-27 | United Services Automobile Association (Usaa) | Credit card account shadowing |
US8312033B1 (en) | 2008-06-26 | 2012-11-13 | Experian Marketing Solutions, Inc. | Systems and methods for providing an integrated identifier |
US8187972B2 (en) * | 2008-07-01 | 2012-05-29 | Teledyne Scientific & Imaging, Llc | Through-substrate vias with polymer fill and method of fabricating same |
US7991689B1 (en) | 2008-07-23 | 2011-08-02 | Experian Information Solutions, Inc. | Systems and methods for detecting bust out fraud using credit data |
US8090650B2 (en) * | 2008-07-24 | 2012-01-03 | At&T Intellectual Property I, L.P. | Secure payment service and system for interactive voice response (IVR) systems |
US9256904B1 (en) | 2008-08-14 | 2016-02-09 | Experian Information Solutions, Inc. | Multi-bureau credit file freeze and unfreeze |
US8275097B2 (en) | 2008-08-28 | 2012-09-25 | Ebay Inc. | Voice phone-based method and system to authenticate users |
WO2010028302A2 (en) * | 2008-09-05 | 2010-03-11 | Giftango Corporation | Systems and methods for authentication of a virtual stored value card |
SK288747B6 (en) * | 2009-04-24 | 2020-04-02 | Smk Kk | Method and system for cashless payment transactions, particularly with contactless payment device using |
US9098845B2 (en) * | 2008-09-19 | 2015-08-04 | Logomotion, S.R.O. | Process of selling in electronic shop accessible from the mobile communication device |
SK50862008A3 (en) * | 2008-09-19 | 2010-06-07 | Logomotion, S. R. O. | System for electronic payment applications and method for payment authorization |
US20100076833A1 (en) * | 2008-09-19 | 2010-03-25 | Giftango Corporation | Systems and methods for managing and using a virtual card |
SK288757B6 (en) * | 2008-09-19 | 2020-05-04 | Smk Kk | System and method for contactless payment authorization |
WO2010036737A2 (en) * | 2008-09-26 | 2010-04-01 | Giftango Corporation | System and methods for managing a virtual card based on geographical information |
US9215331B2 (en) * | 2008-10-02 | 2015-12-15 | International Business Machines Corporation | Dual layer authentication for electronic payment request in online transactions |
US8082448B2 (en) * | 2008-10-28 | 2011-12-20 | Xerox Corporation | System and method for user authentication using non-language words |
US8060424B2 (en) | 2008-11-05 | 2011-11-15 | Consumerinfo.Com, Inc. | On-line method and system for monitoring and reporting unused available credit |
AU2009311303B2 (en) * | 2008-11-06 | 2015-09-10 | Visa International Service Association | Online challenge-response |
US11797953B2 (en) * | 2008-11-24 | 2023-10-24 | Malikie Innovations Limited | Electronic payment system including merchant server and associated methods |
WO2010062974A1 (en) * | 2008-11-26 | 2010-06-03 | Syncada Llc | Methods and arrangements involving adaptive auditing and rating for disparate data processing |
US8095519B2 (en) * | 2008-12-16 | 2012-01-10 | International Business Machines Corporation | Multifactor authentication with changing unique values |
GB2466676A (en) * | 2009-01-06 | 2010-07-07 | Visa Europe Ltd | A method of processing payment authorisation requests |
GB2466810A (en) | 2009-01-08 | 2010-07-14 | Visa Europe Ltd | Processing payment authorisation requests |
SG163446A1 (en) * | 2009-01-19 | 2010-08-30 | Creative Tech Ltd | Method & system for managing electronic messages in a closed network |
US8301684B2 (en) * | 2009-02-26 | 2012-10-30 | Google Inc. | User challenge using information based on geography or user identity |
US8613047B2 (en) * | 2009-04-21 | 2013-12-17 | Yahoo! Inc. | Interacting with internet servers without keyboard |
US8762288B2 (en) | 2009-04-22 | 2014-06-24 | The Western Union Company | Methods and systems for establishing an identity confidence database |
RU2543935C2 (en) * | 2009-05-03 | 2015-03-10 | Логомотион, С.Р.О. | Payment terminal using mobile communication device such as mobile telephone and non-cash payment method |
US8639920B2 (en) | 2009-05-11 | 2014-01-28 | Experian Marketing Solutions, Inc. | Systems and methods for providing anonymized user profile data |
US20100287061A1 (en) * | 2009-05-11 | 2010-11-11 | Jeroen Paul Terheggen | Method and system for payment of a network-based marketplace transaction |
BRPI1010801A2 (en) * | 2009-05-15 | 2016-04-05 | Setcom Pty Ltd | security system and method |
US9135424B2 (en) * | 2009-05-29 | 2015-09-15 | Paypal, Inc. | Secure identity binding (SIB) |
US9734496B2 (en) | 2009-05-29 | 2017-08-15 | Paypal, Inc. | Trusted remote attestation agent (TRAA) |
AU2010256394A1 (en) * | 2009-06-04 | 2012-01-19 | Mobile Messenger Global, Inc. | Method and system for providing real-time access to mobile commerce purchase confirmation evidence |
US20100312702A1 (en) * | 2009-06-06 | 2010-12-09 | Bullock Roddy M | System and method for making money by facilitating easy online payment |
US20100332337A1 (en) * | 2009-06-25 | 2010-12-30 | Bullock Roddy Mckee | Universal one-click online payment method and system |
US8612352B2 (en) | 2010-10-13 | 2013-12-17 | Square, Inc. | Decoding systems with a decoding engine running on a mobile device and coupled to a payment system that includes identifying information of second parties qualified to conduct business with the payment system |
US9436955B2 (en) | 2009-06-10 | 2016-09-06 | Square, Inc. | Methods for transferring funds using a payment service where financial account information is only entered once with a payment service and need not be re-entered for future transfers |
US8701997B2 (en) | 2010-10-13 | 2014-04-22 | Square, Inc. | Decoding systems with a decoding engine running on a mobile device and using financial transaction card information to create a send funds application on the mobile device |
US8364593B2 (en) * | 2009-06-30 | 2013-01-29 | Visa International Service Association | Intelligent authentication |
US8825548B2 (en) * | 2009-06-30 | 2014-09-02 | Ebay Inc. | Secure authentication between multiple parties |
WO2011047028A2 (en) * | 2009-10-13 | 2011-04-21 | Square, Inc. | Systems and methods for financial transaction through miniaturized card reader |
US20110087611A1 (en) * | 2009-10-14 | 2011-04-14 | Shyam Chetal | Biometric identification and authentication system for financial accounts |
US20110131132A1 (en) * | 2009-11-27 | 2011-06-02 | Eazybreak Oy | System and method for managing subscriber account |
US20110131130A1 (en) * | 2009-12-01 | 2011-06-02 | Bank Of America Corporation | Integrated risk assessment and management system |
US11928696B2 (en) | 2009-12-16 | 2024-03-12 | E2Interactive, Inc. | Systems and methods for generating a virtual value item for a promotional campaign |
RU2563163C2 (en) * | 2010-01-19 | 2015-09-20 | Виза Интернэшнл Сервис Ассосиэйшн | Remote variable authentication processing |
US20110195748A1 (en) * | 2010-02-09 | 2011-08-11 | Jonathan Main | Enhanced security feature for payment-enabled mobile telephone |
US9799070B1 (en) | 2010-02-14 | 2017-10-24 | Expensify, Inc. | System and method for aggregating and presenting financial information |
US9407689B1 (en) * | 2010-02-18 | 2016-08-02 | Lemon, Inc. | Physical verification for online check-in |
US9652802B1 (en) | 2010-03-24 | 2017-05-16 | Consumerinfo.Com, Inc. | Indirect monitoring and reporting of a user's credit data |
US9171306B1 (en) * | 2010-03-29 | 2015-10-27 | Bank Of America Corporation | Risk-based transaction authentication |
US9152960B2 (en) | 2010-04-01 | 2015-10-06 | Shyam Chetal | Biometric identification and authentication system |
US10453093B1 (en) | 2010-04-30 | 2019-10-22 | Lmb Mortgage Services, Inc. | System and method of optimizing matching of leads |
JP2011248768A (en) * | 2010-05-28 | 2011-12-08 | Sony Corp | Information processor, information processing system and program |
US10068287B2 (en) | 2010-06-11 | 2018-09-04 | David A. Nelsen | Systems and methods to manage and control use of a virtual card |
US11348150B2 (en) | 2010-06-21 | 2022-05-31 | Paypal, Inc. | Systems and methods for facilitating card verification over a network |
US20110313898A1 (en) * | 2010-06-21 | 2011-12-22 | Ebay Inc. | Systems and methods for facitiating card verification over a network |
US8527417B2 (en) * | 2010-07-12 | 2013-09-03 | Mastercard International Incorporated | Methods and systems for authenticating an identity of a payer in a financial transaction |
FR2963975A1 (en) * | 2010-08-20 | 2012-02-24 | In Webo Tech | ONLINE PAYMENT SYSTEM |
WO2012037479A1 (en) | 2010-09-17 | 2012-03-22 | Universal Secure Registry, Llc | Apparatus, system and method employing a wireless user-device |
US10043180B2 (en) | 2010-09-30 | 2018-08-07 | The Western Union Company | System and method for secure transactions at a mobile device |
US8589288B1 (en) * | 2010-10-01 | 2013-11-19 | Jpmorgan Chase Bank, N.A. | System and method for electronic remittance of funds |
US8571989B2 (en) | 2010-10-13 | 2013-10-29 | Square, Inc. | Decoding systems with a decoding engine running on a mobile device and coupled to a social network |
US9454866B2 (en) | 2010-10-13 | 2016-09-27 | Square, Inc. | Method of conducting financial transactions where a payer's financial account information is entered only once with a payment system |
US9031869B2 (en) | 2010-10-13 | 2015-05-12 | Gift Card Impressions, LLC | Method and system for generating a teaser video associated with a personalized gift |
US8701996B2 (en) | 2010-10-13 | 2014-04-22 | Square, Inc. | Cost effective card reader and methods to be configured to be coupled to a mobile device |
US9619797B2 (en) | 2010-10-13 | 2017-04-11 | Square, Inc. | Payment methods with a payment service and tabs selected by a first party and opened by a second party at an geographic location of the first party's mobile device |
US8640953B2 (en) | 2010-10-13 | 2014-02-04 | Square, Inc. | Decoding system running on a mobile device and coupled to a payment system that includes at least one of, a user database, a product database and a transaction database |
US9483786B2 (en) | 2011-10-13 | 2016-11-01 | Gift Card Impressions, LLC | Gift card ordering system and method |
CA2812611C (en) * | 2010-10-13 | 2016-06-14 | Square, Inc. | Payment methods with a payment service and tabs selected by a first party and opened by a second party at any geographic location of the first party's mobile device |
US8573489B2 (en) | 2010-10-13 | 2013-11-05 | Square, Inc. | Decoding systems with a decoding engine running on a mobile device with a touch screen |
US8678277B2 (en) | 2010-10-13 | 2014-03-25 | Square, Inc. | Decoding system coupled to a payment system that includes a cryptographic key |
US8602305B2 (en) | 2010-10-13 | 2013-12-10 | Square, Inc. | Decoding systems with a decoding engine running on a mobile device configured to be coupled and decoupled to a card reader with wake-up electronics |
US8930262B1 (en) | 2010-11-02 | 2015-01-06 | Experian Technology Ltd. | Systems and methods of assisted strategy design |
US8782217B1 (en) | 2010-11-10 | 2014-07-15 | Safetyweb, Inc. | Online identity management |
US8484186B1 (en) | 2010-11-12 | 2013-07-09 | Consumerinfo.Com, Inc. | Personalized people finder |
US10825013B2 (en) | 2010-11-17 | 2020-11-03 | International Business Machines Corporation | Systems and methods for face-to-face mobile phone mercantile transactions |
US9147042B1 (en) | 2010-11-22 | 2015-09-29 | Experian Information Solutions, Inc. | Systems and methods for data verification |
US9042281B2 (en) * | 2010-12-08 | 2015-05-26 | At&T Intellectual Property I, L.P. | Method and apparatus for initializing an RFID tag via an optical display |
US9489669B2 (en) | 2010-12-27 | 2016-11-08 | The Western Union Company | Secure contactless payment systems and methods |
US9576159B1 (en) | 2011-01-24 | 2017-02-21 | Square, Inc. | Multiple payment card reader system |
CA2827478C (en) | 2011-02-18 | 2020-07-28 | Csidentity Corporation | System and methods for identifying compromised personally identifiable information on the internet |
US20120284187A1 (en) * | 2011-03-15 | 2012-11-08 | Ayman Hammad | System and method for processing payment transactions |
US20120239578A1 (en) * | 2011-03-17 | 2012-09-20 | Allegro Systems Llc | Mobile Secure Transactions Using Human Intelligible Handshake Key |
US9288836B1 (en) * | 2011-03-18 | 2016-03-15 | Marvell International Ltd. | Electronic bracelet |
US8489504B1 (en) | 2011-04-05 | 2013-07-16 | Google Inc. | Transferring money using a mobile electronic device |
NL2006609C2 (en) * | 2011-04-14 | 2012-10-16 | Sepasoft B V | COMPOSITION AND METHOD FOR HANDLING TRANSACTIONS. |
US9558519B1 (en) | 2011-04-29 | 2017-01-31 | Consumerinfo.Com, Inc. | Exposing reporting cycle information |
US20120284135A1 (en) * | 2011-05-03 | 2012-11-08 | Zaarly, Inc. | Proximity based online marketplace |
US8861861B2 (en) | 2011-05-10 | 2014-10-14 | Expensify, Inc. | System and method for processing receipts and other records of users |
US20180268175A1 (en) * | 2011-05-31 | 2018-09-20 | Smartrac Investment B.V. | Method and arrangement for providing and managing information linked to rfid data storage media in a network |
US9607336B1 (en) | 2011-06-16 | 2017-03-28 | Consumerinfo.Com, Inc. | Providing credit inquiry alerts |
US9483606B1 (en) | 2011-07-08 | 2016-11-01 | Consumerinfo.Com, Inc. | Lifescore |
US20130018789A1 (en) * | 2011-07-14 | 2013-01-17 | Payment 21 LLC | Systems and methods for estimating the risk that a real-time promissory payment will default |
US8782761B1 (en) * | 2011-08-08 | 2014-07-15 | Google Inc. | Generating authentication challenges based on preferences of a user's contacts |
US8862767B2 (en) | 2011-09-02 | 2014-10-14 | Ebay Inc. | Secure elements broker (SEB) for application communication channel selector optimization |
US9106691B1 (en) | 2011-09-16 | 2015-08-11 | Consumerinfo.Com, Inc. | Systems and methods of identity protection and management |
US8498939B1 (en) * | 2011-09-16 | 2013-07-30 | Google Inc. | Post-paid, single click payments |
US8819793B2 (en) | 2011-09-20 | 2014-08-26 | Csidentity Corporation | Systems and methods for secure and efficient enrollment into a federation which utilizes a biometric repository |
US8997240B1 (en) | 2011-09-21 | 2015-03-31 | Google Inc. | Generating user authentication challenges based on social network activity information |
US8806603B2 (en) | 2012-04-11 | 2014-08-12 | Jerome Svigals | Dual device system for secure transactions |
US8997188B2 (en) | 2012-04-11 | 2015-03-31 | Jerome Svigals | System for enabling a smart device to securely accept unsolicited transactions |
US9344437B2 (en) | 2011-09-23 | 2016-05-17 | Jerome Svigals | Internet of things security |
US9319404B2 (en) | 2011-09-23 | 2016-04-19 | Jerome Svigals | Security for the internet of things |
US9432378B1 (en) | 2011-09-23 | 2016-08-30 | Jerome Svigals | Internet of things security |
US9313215B2 (en) | 2011-09-26 | 2016-04-12 | Visa International Service Association | Monitoring and limiting requests to access system resources |
US8769624B2 (en) | 2011-09-29 | 2014-07-01 | Apple Inc. | Access control utilizing indirect authentication |
US9002322B2 (en) | 2011-09-29 | 2015-04-07 | Apple Inc. | Authentication with secondary approver |
US20130085927A1 (en) * | 2011-10-04 | 2013-04-04 | Research In Motion Limited | Providing Increased Ability To Perform A Transaction Based On Locale |
US8738516B1 (en) | 2011-10-13 | 2014-05-27 | Consumerinfo.Com, Inc. | Debt services candidate locator |
US11409971B1 (en) * | 2011-10-23 | 2022-08-09 | Dynamics Inc. | Programming and test modes for powered cards and devices |
US11030562B1 (en) | 2011-10-31 | 2021-06-08 | Consumerinfo.Com, Inc. | Pre-data breach monitoring |
CH705774B1 (en) * | 2011-11-16 | 2016-12-15 | Swisscom Ag | Method, system, and card to authenticate a user through an application. |
US20140006123A1 (en) * | 2011-12-09 | 2014-01-02 | Weyenot, Inc. | Microgift System and Method of Operation |
CN103177388B (en) * | 2011-12-22 | 2016-12-07 | 中国银联股份有限公司 | For authoring system and for authorization method |
US10417677B2 (en) | 2012-01-30 | 2019-09-17 | Gift Card Impressions, LLC | Group video generating system |
US9009807B2 (en) | 2012-04-11 | 2015-04-14 | Jerome Svigals | Smart device lockout |
US8984607B1 (en) * | 2012-04-20 | 2015-03-17 | Wells Fargo Bank, N.A. | Authentication system and method |
US9853959B1 (en) | 2012-05-07 | 2017-12-26 | Consumerinfo.Com, Inc. | Storage and maintenance of personal data |
GB2502263A (en) * | 2012-05-16 | 2013-11-27 | Ibm | Authentication using near field communication with varied signal strength |
US8639619B1 (en) | 2012-07-13 | 2014-01-28 | Scvngr, Inc. | Secure payment method and system |
JP6363503B2 (en) * | 2012-07-31 | 2018-07-25 | フェリカネットワークス株式会社 | Information processing system and information processing method |
US20140046830A1 (en) * | 2012-08-08 | 2014-02-13 | Swipe Alert, Llc | Mobile Application For Monitoring and Managing Transactions Associated with Accounts Maintained at Financial Institutions |
AU2013312784A1 (en) | 2012-09-04 | 2015-03-19 | Linq3 Technologies Llc | Systems and methods for integrated game play through the use of barcodes on smart phones and hand held devices |
US10943432B2 (en) | 2012-09-04 | 2021-03-09 | E2Interactive, Inc. | Processing of a game-playing transaction based on location |
US10229561B2 (en) | 2012-09-04 | 2019-03-12 | Linq3 Technologies Llc | Processing of a user device game-playing transaction based on location |
US9756022B2 (en) * | 2014-08-29 | 2017-09-05 | Box, Inc. | Enhanced remote key management for an enterprise in a cloud-based environment |
EP2725756A1 (en) * | 2012-10-24 | 2014-04-30 | OpenLimit SignCubes AG | Security-device and secure data transmission method |
US9654541B1 (en) | 2012-11-12 | 2017-05-16 | Consumerinfo.Com, Inc. | Aggregating user web browsing data |
US8856894B1 (en) | 2012-11-28 | 2014-10-07 | Consumerinfo.Com, Inc. | Always on authentication |
KR101721852B1 (en) * | 2012-11-29 | 2017-03-31 | 알까뗄 루슨트 | Status tracking system |
US9916621B1 (en) | 2012-11-30 | 2018-03-13 | Consumerinfo.Com, Inc. | Presentation of credit score factors |
US10255598B1 (en) | 2012-12-06 | 2019-04-09 | Consumerinfo.Com, Inc. | Credit card account data extraction |
US20140201065A1 (en) * | 2013-01-11 | 2014-07-17 | Mastercard International Incorporated | System for and method of mobile fleet data capture with real-time authorization data |
US9565911B2 (en) | 2013-02-15 | 2017-02-14 | Gift Card Impressions, LLC | Gift card presentation devices |
US11219288B2 (en) | 2013-02-15 | 2022-01-11 | E2Interactive, Inc. | Gift card box with slanted tray and slit |
US9697263B1 (en) | 2013-03-04 | 2017-07-04 | Experian Information Solutions, Inc. | Consumer data request fulfillment system |
US8972400B1 (en) | 2013-03-11 | 2015-03-03 | Consumerinfo.Com, Inc. | Profile data management |
US9406085B1 (en) | 2013-03-14 | 2016-08-02 | Consumerinfo.Com, Inc. | System and methods for credit dispute processing, resolution, and reporting |
US10102570B1 (en) | 2013-03-14 | 2018-10-16 | Consumerinfo.Com, Inc. | Account vulnerability alerts |
US10380591B2 (en) * | 2013-03-14 | 2019-08-13 | Nuance Communications, Inc. | Pro-active identity verification for authentication of transaction initiated via non-voice channel |
US9870589B1 (en) | 2013-03-14 | 2018-01-16 | Consumerinfo.Com, Inc. | Credit utilization tracking and reporting |
US8812387B1 (en) | 2013-03-14 | 2014-08-19 | Csidentity Corporation | System and method for identifying related credit inquiries |
WO2014143776A2 (en) | 2013-03-15 | 2014-09-18 | Bodhi Technology Ventures Llc | Providing remote interactions with host device using a wireless device |
US10664936B2 (en) | 2013-03-15 | 2020-05-26 | Csidentity Corporation | Authentication systems and methods for on-demand products |
US20140279426A1 (en) * | 2013-03-15 | 2014-09-18 | Elwha Llc | Devices, methods, and systems for technologically shifting options and modalities |
US9633322B1 (en) | 2013-03-15 | 2017-04-25 | Consumerinfo.Com, Inc. | Adjustment of knowledge-based authentication |
US10115268B2 (en) | 2013-03-15 | 2018-10-30 | Linq3 Technologies Llc | Systems and methods for integrated game play at payment-enabled terminals |
US10685398B1 (en) | 2013-04-23 | 2020-06-16 | Consumerinfo.Com, Inc. | Presenting credit score information |
US10217107B2 (en) | 2013-05-02 | 2019-02-26 | Gift Card Impressions, LLC | Stored value card kiosk system and method |
US20140351126A1 (en) * | 2013-05-22 | 2014-11-27 | Seth Priebatsch | Secure synchronization of payment accounts to third-party applications or websites |
US9721147B1 (en) | 2013-05-23 | 2017-08-01 | Consumerinfo.Com, Inc. | Digital identity |
JP6098400B2 (en) * | 2013-07-01 | 2017-03-22 | 富士ゼロックス株式会社 | Information processing apparatus and program |
US8770478B2 (en) | 2013-07-11 | 2014-07-08 | Scvngr, Inc. | Payment processing with automatic no-touch mode selection |
US9384478B2 (en) | 2013-07-19 | 2016-07-05 | Bank Of America Corporation | Offline mobile banking system |
US20150026082A1 (en) * | 2013-07-19 | 2015-01-22 | On Deck Capital, Inc. | Process for Automating Compliance with Know Your Customer Requirements |
RU2583710C2 (en) * | 2013-07-23 | 2016-05-10 | Закрытое акционерное общество "Лаборатория Касперского" | System and method for providing privacy of information used during authentication and authorisation operations using trusted device |
US20150039502A1 (en) * | 2013-08-05 | 2015-02-05 | Bank Of America Corporation | Misappropriation protection based on shipping address or store info from e-receipt |
US9443268B1 (en) | 2013-08-16 | 2016-09-13 | Consumerinfo.Com, Inc. | Bill payment and reporting |
US9880926B1 (en) * | 2013-08-20 | 2018-01-30 | Seagate Technology Llc | Log structured reserved zone for a data storage device |
US20160071104A1 (en) * | 2013-09-04 | 2016-03-10 | George Gregory Stamatis | Securebuy merchant information analytics decision engine |
US9898642B2 (en) | 2013-09-09 | 2018-02-20 | Apple Inc. | Device, method, and graphical user interface for manipulating user interfaces based on fingerprint sensor inputs |
US9160742B1 (en) * | 2013-09-27 | 2015-10-13 | Emc Corporation | Localized risk analytics for user authentication |
US10102536B1 (en) | 2013-11-15 | 2018-10-16 | Experian Information Solutions, Inc. | Micro-geographic aggregation system |
US10325314B1 (en) | 2013-11-15 | 2019-06-18 | Consumerinfo.Com, Inc. | Payment reporting systems |
US9477737B1 (en) | 2013-11-20 | 2016-10-25 | Consumerinfo.Com, Inc. | Systems and user interfaces for dynamic access of multiple remote databases and synchronization of data based on user rules |
US8910868B1 (en) | 2013-11-27 | 2014-12-16 | Square, Inc. | Firmware management |
US9424410B2 (en) | 2013-12-09 | 2016-08-23 | Mastercard International Incorporated | Methods and systems for leveraging transaction data to dynamically authenticate a user |
US9928358B2 (en) * | 2013-12-09 | 2018-03-27 | Mastercard International Incorporated | Methods and systems for using transaction data to authenticate a user of a computing device |
US11823190B2 (en) * | 2013-12-09 | 2023-11-21 | Mastercard International Incorporated | Systems, apparatus and methods for improved authentication |
US9633236B1 (en) | 2013-12-11 | 2017-04-25 | Square, Inc. | Power harvesting in reader devices |
US8931699B1 (en) | 2013-12-11 | 2015-01-13 | Square, Inc. | Bidirectional audio communication in reader devices |
US10049409B1 (en) * | 2013-12-19 | 2018-08-14 | Jpmorgan Chase Bank, N.A. | Linking data from multiple market participants to generate a consolidated audit trail |
US9916620B2 (en) * | 2014-01-03 | 2018-03-13 | The Toronto-Dominion Bank | Systems and methods for providing balance notifications in an augmented reality environment |
US9928547B2 (en) | 2014-01-03 | 2018-03-27 | The Toronto-Dominion Bank | Systems and methods for providing balance notifications to connected devices |
US9953367B2 (en) | 2014-01-03 | 2018-04-24 | The Toronto-Dominion Bank | Systems and methods for providing balance and event notifications |
US10296972B2 (en) * | 2014-01-03 | 2019-05-21 | The Toronto-Dominion Bank | Systems and methods for providing balance notifications |
US9313190B2 (en) | 2014-02-07 | 2016-04-12 | Bank Of America Corporation | Shutting down access to all user accounts |
US9185117B2 (en) | 2014-02-07 | 2015-11-10 | Bank Of America Corporation | User authentication by geo-location and proximity to user's close network |
US9223951B2 (en) | 2014-02-07 | 2015-12-29 | Bank Of America Corporation | User authentication based on other applications |
US9305149B2 (en) | 2014-02-07 | 2016-04-05 | Bank Of America Corporation | Sorting mobile banking functions into authentication buckets |
US9331994B2 (en) | 2014-02-07 | 2016-05-03 | Bank Of America Corporation | User authentication based on historical transaction data |
US9965606B2 (en) | 2014-02-07 | 2018-05-08 | Bank Of America Corporation | Determining user authentication based on user/device interaction |
US9213974B2 (en) | 2014-02-07 | 2015-12-15 | Bank Of America Corporation | Remote revocation of application access based on non-co-location of a transaction vehicle and a mobile device |
US9286450B2 (en) | 2014-02-07 | 2016-03-15 | Bank Of America Corporation | Self-selected user access based on specific authentication types |
US9647999B2 (en) | 2014-02-07 | 2017-05-09 | Bank Of America Corporation | Authentication level of function bucket based on circumstances |
US9317673B2 (en) | 2014-02-07 | 2016-04-19 | Bank Of America Corporation | Providing authentication using previously-validated authentication credentials |
US9208301B2 (en) | 2014-02-07 | 2015-12-08 | Bank Of America Corporation | Determining user authentication requirements based on the current location of the user in comparison to the users's normal boundary of location |
US9185101B2 (en) | 2014-02-07 | 2015-11-10 | Bank Of America Corporation | User authentication based on historical user behavior |
US9317674B2 (en) | 2014-02-07 | 2016-04-19 | Bank Of America Corporation | User authentication based on fob/indicia scan |
US10262362B1 (en) | 2014-02-14 | 2019-04-16 | Experian Information Solutions, Inc. | Automatic generation of code for attributes |
US20150235220A1 (en) * | 2014-02-19 | 2015-08-20 | Bank Of America Corporation | Location based risk mitigating transaction authorization |
US20150235219A1 (en) * | 2014-02-19 | 2015-08-20 | Bank Of America Corporation | Item/value based risk mitigating transaction authorization |
US9256769B1 (en) | 2014-02-25 | 2016-02-09 | Square, Inc. | Mobile reader device |
US20150242840A1 (en) * | 2014-02-25 | 2015-08-27 | Jpmorgan Chase Bank, N.A. | Systems and methods for dynamic biometric configuration compliance control |
US9830597B2 (en) | 2014-03-04 | 2017-11-28 | Bank Of America Corporation | Formation and funding of a shared token |
US9424572B2 (en) | 2014-03-04 | 2016-08-23 | Bank Of America Corporation | Online banking digital wallet management |
US9721248B2 (en) | 2014-03-04 | 2017-08-01 | Bank Of America Corporation | ATM token cash withdrawal |
US10002352B2 (en) | 2014-03-04 | 2018-06-19 | Bank Of America Corporation | Digital wallet exposure reduction |
US9721268B2 (en) | 2014-03-04 | 2017-08-01 | Bank Of America Corporation | Providing offers associated with payment credentials authenticated in a specific digital wallet |
US9600817B2 (en) | 2014-03-04 | 2017-03-21 | Bank Of America Corporation | Foreign exchange token |
US9600844B2 (en) | 2014-03-04 | 2017-03-21 | Bank Of America Corporation | Foreign cross-issued token |
US9406065B2 (en) | 2014-03-04 | 2016-08-02 | Bank Of America Corporation | Customer token preferences interface |
US10176542B2 (en) * | 2014-03-24 | 2019-01-08 | Mastercard International Incorporated | Systems and methods for identity validation and verification |
USD759689S1 (en) | 2014-03-25 | 2016-06-21 | Consumerinfo.Com, Inc. | Display screen or portion thereof with graphical user interface |
USD759690S1 (en) | 2014-03-25 | 2016-06-21 | Consumerinfo.Com, Inc. | Display screen or portion thereof with graphical user interface |
USD760256S1 (en) | 2014-03-25 | 2016-06-28 | Consumerinfo.Com, Inc. | Display screen or portion thereof with graphical user interface |
US20160012216A1 (en) * | 2014-04-10 | 2016-01-14 | Sequitur Labs Inc. | System for policy-managed secure authentication and secure authorization |
US9892457B1 (en) | 2014-04-16 | 2018-02-13 | Consumerinfo.Com, Inc. | Providing credit data in search results |
US10373240B1 (en) | 2014-04-25 | 2019-08-06 | Csidentity Corporation | Systems, methods and computer-program products for eligibility verification |
US10262346B2 (en) | 2014-04-30 | 2019-04-16 | Gift Card Impressions, Inc. | System and method for a merchant onsite personalization gifting platform |
US9576030B1 (en) | 2014-05-07 | 2017-02-21 | Consumerinfo.Com, Inc. | Keeping up with the joneses |
US10242351B1 (en) | 2014-05-07 | 2019-03-26 | Square, Inc. | Digital wallet for groups |
US9959529B1 (en) | 2014-05-11 | 2018-05-01 | Square, Inc. | Open tab transactions |
US10438204B2 (en) * | 2014-05-19 | 2019-10-08 | American Express Travel Related Services Copmany, Inc. | Authentication via biometric passphrase |
US10304043B1 (en) | 2014-05-21 | 2019-05-28 | Square, Inc. | Multi-peripheral host device |
US9483763B2 (en) | 2014-05-29 | 2016-11-01 | Apple Inc. | User interface for payments |
US9967401B2 (en) | 2014-05-30 | 2018-05-08 | Apple Inc. | User interface for phone call routing among devices |
KR102201095B1 (en) | 2014-05-30 | 2021-01-08 | 애플 인크. | Transition from use of one device to another |
USD762651S1 (en) | 2014-06-06 | 2016-08-02 | Square, Inc. | Mobile device case |
US20150363762A1 (en) * | 2014-06-14 | 2015-12-17 | Mastercard International Incorporated | Apparatus, method, and computer program product for mobile open payment network |
US9311504B2 (en) | 2014-06-23 | 2016-04-12 | Ivo Welch | Anti-identity-theft method and hardware database device |
US9760740B1 (en) | 2014-06-23 | 2017-09-12 | Square, Inc. | Terminal case with integrated dual reader stack |
US9256770B1 (en) | 2014-07-02 | 2016-02-09 | Square, Inc. | Terminal case with integrated reader and shortened base |
WO2016018721A1 (en) * | 2014-07-30 | 2016-02-04 | Wal-Mart Stores, Inc. | Systems and methods for roll-up payments |
US9736040B2 (en) * | 2014-08-07 | 2017-08-15 | International Business Machines Corporation | Monitoring SMS messages related to server/customer interactions |
US10339293B2 (en) | 2014-08-15 | 2019-07-02 | Apple Inc. | Authenticated device used to unlock another device |
US9799025B2 (en) | 2014-08-19 | 2017-10-24 | Square, Inc. | Energy harvesting bidirectional audio interface |
US10462185B2 (en) | 2014-09-05 | 2019-10-29 | Sequitur Labs, Inc. | Policy-managed secure code execution and messaging for computing devices and computing device security |
US9977881B2 (en) * | 2014-10-15 | 2018-05-22 | Mastercard International Incorporated | Methods, apparatus and systems for securely authenticating a person depending on context |
US10339527B1 (en) | 2014-10-31 | 2019-07-02 | Experian Information Solutions, Inc. | System and architecture for electronic fraud detection |
US9558493B2 (en) | 2014-11-12 | 2017-01-31 | BenedorTSE LLC | Secure authorizations using independent communications and different one-time-use encryption keys for each party to a transaction |
US10614457B2 (en) | 2014-11-12 | 2020-04-07 | BenedorTSE LLC | Secure authorizations using independent communications and different one-time-use encryption keys for each party to a transaction |
US9558492B2 (en) | 2014-11-12 | 2017-01-31 | Benedoretse Llc | Secure authorizations using independent communications and different one-time-use encryption keys for each party to a transaction |
US9569776B2 (en) | 2014-11-12 | 2017-02-14 | BenedorTSE LLC | Secure authorizations using independent communications and different one-time-use encryption keys for each party to a transaction |
US9875468B2 (en) | 2014-11-26 | 2018-01-23 | Buy It Mobility Networks Inc. | Intelligent authentication process |
US10242019B1 (en) | 2014-12-19 | 2019-03-26 | Experian Information Solutions, Inc. | User behavior segmentation using latent topic detection |
US9317845B1 (en) * | 2014-12-23 | 2016-04-19 | Mastercard International Incorporated | Flexible electronic payment transaction process |
US9355285B1 (en) | 2015-02-12 | 2016-05-31 | Square, Inc. | Tone-based wake up circuit for card reader |
US11049090B2 (en) * | 2015-03-11 | 2021-06-29 | Paypal, Inc. | NFC application registry for enhanced mobile transactions and payments |
US20160300236A1 (en) * | 2015-04-09 | 2016-10-13 | Mastercard International Incorporated | Systems and Methods for Confirming Identities of Verified Individuals, in Connection With Establishing New Accounts for the Individuals |
US10685130B2 (en) | 2015-04-21 | 2020-06-16 | Sequitur Labs Inc. | System and methods for context-aware and situation-aware secure, policy-based access control for computing devices |
US11847237B1 (en) | 2015-04-28 | 2023-12-19 | Sequitur Labs, Inc. | Secure data protection and encryption techniques for computing devices and information storage |
WO2016183504A1 (en) | 2015-05-14 | 2016-11-17 | Sequitur Labs, Inc. | System and methods for facilitating secure computing device control and operation |
US11151468B1 (en) | 2015-07-02 | 2021-10-19 | Experian Information Solutions, Inc. | Behavior analysis using distributed representations of event data |
WO2017001870A1 (en) | 2015-07-02 | 2017-01-05 | Payfont Limited | Resilient secret sharing cloud based architecture for data vault |
US10021565B2 (en) | 2015-10-30 | 2018-07-10 | Bank Of America Corporation | Integrated full and partial shutdown application programming interface |
US9820148B2 (en) | 2015-10-30 | 2017-11-14 | Bank Of America Corporation | Permanently affixed un-decryptable identifier associated with mobile device |
US9641539B1 (en) | 2015-10-30 | 2017-05-02 | Bank Of America Corporation | Passive based security escalation to shut off of application based on rules event triggering |
US9729536B2 (en) | 2015-10-30 | 2017-08-08 | Bank Of America Corporation | Tiered identification federated authentication network system |
US10757154B1 (en) | 2015-11-24 | 2020-08-25 | Experian Information Solutions, Inc. | Real-time event-based notification system |
US20170180360A1 (en) * | 2015-12-22 | 2017-06-22 | Centre For Development Of Advanced Computing (Cdac) | System for securing user identity information and a device thereof |
US20170186003A1 (en) * | 2015-12-28 | 2017-06-29 | Ncr Corporation | Secondary authentication of network transactions |
US10437880B2 (en) | 2016-02-08 | 2019-10-08 | Bank Of America Corporation | Archive validation system with data purge triggering |
US10437778B2 (en) | 2016-02-08 | 2019-10-08 | Bank Of America Corporation | Archive validation system with data purge triggering |
US9823958B2 (en) | 2016-02-08 | 2017-11-21 | Bank Of America Corporation | System for processing data using different processing channels based on source error probability |
US10460296B2 (en) | 2016-02-08 | 2019-10-29 | Bank Of America Corporation | System for processing data using parameters associated with the data for auto-processing |
US20170228737A1 (en) * | 2016-02-09 | 2017-08-10 | American Express Travel Related Services Company, Inc. | Systems and Methods for Payment using Biometric Information |
US9952942B2 (en) | 2016-02-12 | 2018-04-24 | Bank Of America Corporation | System for distributed data processing with auto-recovery |
US10067869B2 (en) | 2016-02-12 | 2018-09-04 | Bank Of America Corporation | System for distributed data processing with automatic caching at various system levels |
US10628811B2 (en) | 2016-03-15 | 2020-04-21 | Square, Inc. | System-based detection of card sharing and fraud |
US10410200B2 (en) | 2016-03-15 | 2019-09-10 | Square, Inc. | Cloud-based generation of receipts using transaction information |
US10636019B1 (en) | 2016-03-31 | 2020-04-28 | Square, Inc. | Interactive gratuity platform |
US10157078B2 (en) | 2016-04-10 | 2018-12-18 | Bank Of America Corporation | System for transforming large scale electronic processing using application block chain |
CN105847270A (en) * | 2016-04-18 | 2016-08-10 | 贵州安易和信科技有限公司 | Loan authentication system |
CN107306183B (en) * | 2016-04-22 | 2021-12-21 | 索尼公司 | Client, server, method and identity verification system |
US10460367B2 (en) | 2016-04-29 | 2019-10-29 | Bank Of America Corporation | System for user authentication based on linking a randomly generated number to the user and a physical item |
DK179186B1 (en) | 2016-05-19 | 2018-01-15 | Apple Inc | REMOTE AUTHORIZATION TO CONTINUE WITH AN ACTION |
US10621581B2 (en) | 2016-06-11 | 2020-04-14 | Apple Inc. | User interface for transactions |
DK201670622A1 (en) | 2016-06-12 | 2018-02-12 | Apple Inc | User interfaces for transactions |
US10268635B2 (en) | 2016-06-17 | 2019-04-23 | Bank Of America Corporation | System for data rotation through tokenization |
US11070703B2 (en) * | 2016-07-29 | 2021-07-20 | Robert Bosch Tool Corporation | 3D printer touchscreen interface lockout |
US10678894B2 (en) | 2016-08-24 | 2020-06-09 | Experian Information Solutions, Inc. | Disambiguation and authentication of device users |
US20180068313A1 (en) | 2016-09-06 | 2018-03-08 | Apple Inc. | User interfaces for stored-value accounts |
US20180089688A1 (en) * | 2016-09-27 | 2018-03-29 | Mastercard International Incorporated | System and methods for authenticating a user using biometric data |
US10069672B2 (en) | 2016-10-07 | 2018-09-04 | Bank Of America Corporation | Real time event capture, analysis and reporting system |
US10067994B2 (en) | 2016-10-07 | 2018-09-04 | Bank Of America Corporation | Real time event capture and transformation of transient data for an information network |
US10158737B2 (en) | 2016-10-07 | 2018-12-18 | Bank Of America Corporation | Real time event capture and analysis of transient data for an information network |
US10700865B1 (en) | 2016-10-21 | 2020-06-30 | Sequitur Labs Inc. | System and method for granting secure access to computing services hidden in trusted computing environments to an unsecure requestor |
US10496808B2 (en) | 2016-10-25 | 2019-12-03 | Apple Inc. | User interface for managing access to credentials for use in an operation |
CA3050139A1 (en) | 2017-01-31 | 2018-08-09 | Experian Information Solutions, Inc. | Massive scale heterogeneous data ingestion and user resolution |
US10685131B1 (en) * | 2017-02-03 | 2020-06-16 | Rockloans Marketplace Llc | User authentication |
TR201703371A2 (en) * | 2017-03-06 | 2018-04-24 | Turkcell Teknoloji Arastirma Ve Gelistirme Anonim Sirketi | A PAYMENT SYSTEM AND METHOD |
US11431836B2 (en) | 2017-05-02 | 2022-08-30 | Apple Inc. | Methods and interfaces for initiating media playback |
US10992795B2 (en) | 2017-05-16 | 2021-04-27 | Apple Inc. | Methods and interfaces for home media control |
US10740760B2 (en) * | 2017-05-10 | 2020-08-11 | Sap Se | Framework for managing online transactions in internet of things (IoT) |
CN111343060B (en) | 2017-05-16 | 2022-02-11 | 苹果公司 | Method and interface for home media control |
US20220279063A1 (en) | 2017-05-16 | 2022-09-01 | Apple Inc. | Methods and interfaces for home media control |
US11068567B2 (en) * | 2017-06-04 | 2021-07-20 | Harsha Ramalingam | Self-owned authentication and identity framework |
US10524165B2 (en) | 2017-06-22 | 2019-12-31 | Bank Of America Corporation | Dynamic utilization of alternative resources based on token association |
US10313480B2 (en) | 2017-06-22 | 2019-06-04 | Bank Of America Corporation | Data transmission between networked resources |
US10511692B2 (en) | 2017-06-22 | 2019-12-17 | Bank Of America Corporation | Data transmission to a networked resource based on contextual information |
US10735183B1 (en) | 2017-06-30 | 2020-08-04 | Experian Information Solutions, Inc. | Symmetric encryption for private smart contracts among multiple parties in a private peer-to-peer network |
US10397209B2 (en) * | 2017-07-06 | 2019-08-27 | International Business Machines Corporation | Risk-aware multiple factor authentication based on pattern recognition and calendar |
WO2019028366A1 (en) * | 2017-08-03 | 2019-02-07 | Yombu Inc. | Fingerprint-based authentication system |
US11768934B2 (en) | 2017-08-22 | 2023-09-26 | Sontiq, Inc. | Data breach system and method |
KR102185854B1 (en) | 2017-09-09 | 2020-12-02 | 애플 인크. | Implementation of biometric authentication |
JP6736686B1 (en) | 2017-09-09 | 2020-08-05 | アップル インコーポレイテッドApple Inc. | Implementation of biometrics |
US10699028B1 (en) | 2017-09-28 | 2020-06-30 | Csidentity Corporation | Identity security architecture systems and methods |
US10616280B2 (en) | 2017-10-25 | 2020-04-07 | Bank Of America Corporation | Network security system with cognitive engine for dynamic automation |
US10437984B2 (en) | 2017-10-26 | 2019-10-08 | Bank Of America Corporation | Authentication protocol elevation triggering system |
US10686684B2 (en) | 2017-11-02 | 2020-06-16 | Bank Of America Corporation | Individual application flow isotope tagging within a network infrastructure |
US10896472B1 (en) | 2017-11-14 | 2021-01-19 | Csidentity Corporation | Security and identity verification system and architecture |
US10410021B1 (en) | 2017-12-08 | 2019-09-10 | Square, Inc. | Transaction object reader with digital signal input/output and internal audio-based communication |
US10954049B2 (en) | 2017-12-12 | 2021-03-23 | E2Interactive, Inc. | Viscous liquid vessel for gifting |
US11087301B1 (en) | 2017-12-19 | 2021-08-10 | Square, Inc. | Tamper resistant device |
US10812460B2 (en) * | 2018-01-02 | 2020-10-20 | Bank Of America Corporation | Validation system utilizing dynamic authentication |
US11366884B2 (en) * | 2018-02-14 | 2022-06-21 | American Express Travel Related Services Company, Inc. | Authentication challenges based on fraud initiation requests |
CN108564366A (en) | 2018-03-15 | 2018-09-21 | 阿里巴巴集团控股有限公司 | Payment cipher remapping method, device and electronic equipment |
CN110348653B (en) | 2018-04-04 | 2020-07-07 | 阿里巴巴集团控股有限公司 | Service data processing method and device and electronic equipment |
US11170085B2 (en) | 2018-06-03 | 2021-11-09 | Apple Inc. | Implementation of biometric authentication |
US11842407B2 (en) * | 2018-06-04 | 2023-12-12 | Machine Cover, Inc. | Parametric instruments and methods relating to geographical area business interruption |
US20190392450A1 (en) | 2018-06-22 | 2019-12-26 | Mastercard International Incorporated | Systems and methods for authenticating online users in regulated environments |
US10911234B2 (en) | 2018-06-22 | 2021-02-02 | Experian Information Solutions, Inc. | System and method for a token gateway environment |
US11593793B2 (en) * | 2018-06-29 | 2023-02-28 | Ncr Corporation | Cryptocurrency payment and refund processing on a transaction terminal |
US10748132B2 (en) * | 2018-07-17 | 2020-08-18 | Bank Of America Corporation | Security tool |
USD905059S1 (en) | 2018-07-25 | 2020-12-15 | Square, Inc. | Card reader device |
US11265324B2 (en) | 2018-09-05 | 2022-03-01 | Consumerinfo.Com, Inc. | User permissions for access to secure data at third-party |
US11100349B2 (en) | 2018-09-28 | 2021-08-24 | Apple Inc. | Audio assisted enrollment |
US10860096B2 (en) | 2018-09-28 | 2020-12-08 | Apple Inc. | Device control using gaze information |
JP2022501861A (en) | 2018-10-02 | 2022-01-06 | キャピタル・ワン・サービシーズ・リミテッド・ライアビリティ・カンパニーCapital One Services, LLC | Systems and methods for cryptographic authentication of non-contact cards |
US11315179B1 (en) | 2018-11-16 | 2022-04-26 | Consumerinfo.Com, Inc. | Methods and apparatuses for customized card recommendations |
WO2020106229A1 (en) * | 2018-11-21 | 2020-05-28 | Moneymo Onli̇ne Bi̇li̇şi̇m Hi̇zmetleri̇ Anoni̇m Şi̇rketi̇ | An account management system and method |
US10944745B2 (en) | 2018-12-06 | 2021-03-09 | Bank Of America Corporation | System and method for device and transaction authentication |
US10986079B2 (en) | 2018-12-06 | 2021-04-20 | Bank Of America Corporation | System and method for hierarchical decisioning within a hybrid blockchain |
US11403387B2 (en) * | 2019-01-04 | 2022-08-02 | Bank Of Montreal | Systems and methods for authenticating user information |
WO2020146667A1 (en) | 2019-01-11 | 2020-07-16 | Experian Information Solutions, Inc. | Systems and methods for secure data aggregation and computation |
US11238656B1 (en) | 2019-02-22 | 2022-02-01 | Consumerinfo.Com, Inc. | System and method for an augmented reality experience via an artificial intelligence bot |
CN110060035A (en) | 2019-02-26 | 2019-07-26 | 阿里巴巴集团控股有限公司 | Processing method, device and the equipment of risk payment |
US20200311732A1 (en) * | 2019-03-25 | 2020-10-01 | Yuh-Shen Song | Consumer protection system |
US11250429B1 (en) * | 2019-03-29 | 2022-02-15 | Square, Inc. | Identity verification (IDV) using a payment processing platform |
US11126601B2 (en) | 2019-04-10 | 2021-09-21 | Paypal, Inc. | Ensuring data quality through deployment automation in data streaming applications |
US11196737B2 (en) | 2019-04-30 | 2021-12-07 | Bank Of America Corporation | System for secondary authentication via contactless distribution of dynamic resources |
US11234235B2 (en) | 2019-04-30 | 2022-01-25 | Bank Of America Corporation | Resource distribution hub generation on a mobile device |
US10998937B2 (en) | 2019-04-30 | 2021-05-04 | Bank Of America Corporation | Embedded tag for resource distribution |
US20200349620A1 (en) * | 2019-04-30 | 2020-11-05 | Shopify Inc. | Email address verification |
US11151542B2 (en) * | 2019-05-07 | 2021-10-19 | Paypal, Inc. | Wearable payment device |
US11010121B2 (en) | 2019-05-31 | 2021-05-18 | Apple Inc. | User interfaces for audio media control |
WO2020243691A1 (en) | 2019-05-31 | 2020-12-03 | Apple Inc. | User interfaces for audio media control |
US11941065B1 (en) | 2019-09-13 | 2024-03-26 | Experian Information Solutions, Inc. | Single identifier platform for storing entity data |
US11238429B2 (en) * | 2019-11-25 | 2022-02-01 | Capital One Services, Llc | Automatic optimal payment type determination systems |
US11615395B2 (en) * | 2019-12-23 | 2023-03-28 | Capital One Services, Llc | Authentication for third party digital wallet provisioning |
US11238459B2 (en) | 2020-01-07 | 2022-02-01 | Bank Of America Corporation | Intelligent systems for identifying transactions associated with an institution impacted by an event |
US11443320B2 (en) | 2020-01-07 | 2022-09-13 | Bank Of America Corporation | Intelligent systems for identifying transactions associated with an institution impacted by an event using a dashboard |
US11244314B2 (en) * | 2020-04-13 | 2022-02-08 | Paypal, Inc. | Dual controls for processing electronic transactions |
US11836740B2 (en) * | 2020-05-31 | 2023-12-05 | Bank Of America Corporation | Countless system for pre-staging and executing transactions |
US11816194B2 (en) | 2020-06-21 | 2023-11-14 | Apple Inc. | User interfaces for managing secure operations |
US11392291B2 (en) | 2020-09-25 | 2022-07-19 | Apple Inc. | Methods and interfaces for media control with dynamic feedback |
US11847378B2 (en) | 2021-06-06 | 2023-12-19 | Apple Inc. | User interfaces for audio routing |
US11888854B2 (en) | 2021-08-23 | 2024-01-30 | The Toronto-Dominion Bank | Systems and methods for authenticating end users of a web service |
US11784956B2 (en) | 2021-09-20 | 2023-10-10 | Apple Inc. | Requests to add assets to an asset account |
US20230196371A1 (en) * | 2021-12-22 | 2023-06-22 | Brex Inc. | Canary card identifiers for real-time usage alerts |
WO2023200612A1 (en) * | 2022-04-14 | 2023-10-19 | Visa International Service Association | System, method, and computer program product for flexible transaction message routing |
US11887103B2 (en) | 2022-05-10 | 2024-01-30 | Capital One Services, Llc | System and method for facilitating transaction account provisioning |
US20240127201A1 (en) * | 2022-10-18 | 2024-04-18 | Vivid Seats Llc | Ticketing validation and fulfillment system and method |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020112170A1 (en) * | 2001-01-03 | 2002-08-15 | Foley James M. | Method and apparatus for using one financial instrument to authenticate a user for accessing a second financial instrument |
US20020111916A1 (en) * | 2001-02-12 | 2002-08-15 | Coronna Mark S. | Payment management |
US20050193198A1 (en) * | 2004-01-27 | 2005-09-01 | Jean-Michel Livowsky | System, method and apparatus for electronic authentication |
US20070033643A1 (en) * | 2005-07-19 | 2007-02-08 | Ssh Communications Security Corp. | User authentication in connection with a security protocol |
US7540408B2 (en) * | 2006-06-22 | 2009-06-02 | Hip Consult Inc. | Apparatus and method for facilitating money or value transfer |
Family Cites Families (61)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5511121A (en) * | 1994-02-23 | 1996-04-23 | Bell Communications Research, Inc. | Efficient electronic money |
US6029150A (en) * | 1996-10-04 | 2000-02-22 | Certco, Llc | Payment and transactions in electronic commerce system |
US6047268A (en) * | 1997-11-04 | 2000-04-04 | A.T.&T. Corporation | Method and apparatus for billing for transactions conducted over the internet |
US6023688A (en) | 1997-11-28 | 2000-02-08 | Diebold, Incorporated | Transaction apparatus and method that identifies an authorized user by appearance and voice |
US8538801B2 (en) * | 1999-02-19 | 2013-09-17 | Exxonmobile Research & Engineering Company | System and method for processing financial transactions |
US20040083184A1 (en) * | 1999-04-19 | 2004-04-29 | First Data Corporation | Anonymous card transactions |
US7617157B2 (en) * | 2002-01-03 | 2009-11-10 | The Western Union Company | Method for receiving electronically transferred funds using an automated teller machine |
US6695207B1 (en) * | 2000-02-04 | 2004-02-24 | Carroll Boyd Norris, Jr. | System for secure, identity authenticated, and immediate financial transactions as well as activation of varied instrumentalities |
US7280984B2 (en) * | 2000-05-08 | 2007-10-09 | Phelan Iii Frank | Money card system, method and apparatus |
US7565326B2 (en) * | 2000-05-25 | 2009-07-21 | Randle William M | Dialect independent multi-dimensional integrator using a normalized language platform and secure controlled access |
US20020002545A1 (en) * | 2000-06-29 | 2002-01-03 | Resneck James D. | Electronic money transaction device and method |
EP1180751A1 (en) * | 2000-08-18 | 2002-02-20 | Siemens Aktiengesellschaft | Method and system for transmitting an amount of electronic money from a credit memory |
AU2000270486A1 (en) * | 2000-08-22 | 2002-03-04 | Payperfect Pte Ltd | Electronic payment methods |
US7941669B2 (en) * | 2001-01-03 | 2011-05-10 | American Express Travel Related Services Company, Inc. | Method and apparatus for enabling a user to select an authentication method |
US20020112177A1 (en) * | 2001-02-12 | 2002-08-15 | Voltmer William H. | Anonymous biometric authentication |
US7003497B2 (en) * | 2001-05-23 | 2006-02-21 | International Business Machines Corporation | System and method for confirming electronic transactions |
WO2003015043A1 (en) | 2001-08-03 | 2003-02-20 | Haltfern Limited | A credit card security system |
US20030115142A1 (en) * | 2001-12-12 | 2003-06-19 | Intel Corporation | Identity authentication portfolio system |
US20030187784A1 (en) * | 2002-03-27 | 2003-10-02 | Michael Maritzen | System and method for mid-stream purchase of products and services |
US8751391B2 (en) * | 2002-03-29 | 2014-06-10 | Jpmorgan Chase Bank, N.A. | System and process for performing purchase transactions using tokens |
US20040019564A1 (en) * | 2002-07-26 | 2004-01-29 | Scott Goldthwaite | System and method for payment transaction authentication |
US20040230489A1 (en) * | 2002-07-26 | 2004-11-18 | Scott Goldthwaite | System and method for mobile payment and fulfillment of digital goods |
US7801826B2 (en) * | 2002-08-08 | 2010-09-21 | Fujitsu Limited | Framework and system for purchasing of goods and services |
US6954862B2 (en) * | 2002-08-27 | 2005-10-11 | Michael Lawrence Serpa | System and method for user authentication with enhanced passwords |
CA2406880A1 (en) * | 2002-10-04 | 2004-04-04 | Ibm Canada Limited-Ibm Canada Limitee | Method and apparatus for an ecommerce message using sms |
US6676017B1 (en) * | 2002-11-06 | 2004-01-13 | Smith, Iii Emmitt J. | Personal interface device and method |
FR2847401A1 (en) * | 2002-11-14 | 2004-05-21 | France Telecom | Access to a network service with rapid, revokable anonymous authentication and session creation and maintenance for online auctions, uses anonymous certificate of authority to produce anonymous signature which can be checked if needed |
US7421738B2 (en) * | 2002-11-25 | 2008-09-02 | Honeywell International Inc. | Skeptical system |
US7003493B2 (en) * | 2003-01-22 | 2006-02-21 | First Data Corporation | Direct payment with token |
JP2004258897A (en) * | 2003-02-25 | 2004-09-16 | Fujitsu Ltd | Anonymous electronic settlement system and method, and anonymous delivery system and method |
GB0308629D0 (en) * | 2003-04-14 | 2003-05-21 | Tagboard Ltd | Payment apparatus and method |
US20040230843A1 (en) * | 2003-08-20 | 2004-11-18 | Wayne Jansen | System and method for authenticating users using image selection |
DE10343566A1 (en) | 2003-09-19 | 2005-05-04 | Brunet Holding Ag | Process for processing an electronic transaction |
US7788715B2 (en) * | 2003-12-10 | 2010-08-31 | Cisco Technology, Inc. | Authentication for transmission control protocol |
US20050165684A1 (en) * | 2004-01-28 | 2005-07-28 | Saflink Corporation | Electronic transaction verification system |
US20060041507A1 (en) | 2004-08-13 | 2006-02-23 | Sbc Knowledge Ventures L.P. | Pluggable authentication for transaction tool management services |
WO2006018709A1 (en) | 2004-08-20 | 2006-02-23 | Gary John Kamp | Improved security for bank card payments |
WO2006034284A1 (en) * | 2004-09-20 | 2006-03-30 | Claude Charles Buchert | System and method for control of air time of communication devices |
US20060218226A1 (en) * | 2005-03-23 | 2006-09-28 | Matsushita Electric Industrial Co., Ltd. | Automatic recording based on preferences |
US8756099B2 (en) * | 2005-04-11 | 2014-06-17 | Bill Me Later, Inc. | Consumer processing system and method |
US8996423B2 (en) * | 2005-04-19 | 2015-03-31 | Microsoft Corporation | Authentication for a commercial transaction using a mobile module |
US7810143B2 (en) * | 2005-04-22 | 2010-10-05 | Microsoft Corporation | Credential interface |
US8041646B2 (en) * | 2005-06-15 | 2011-10-18 | E. E. System Corporation | Method and system for real time online debit transactions |
GB2434472A (en) * | 2005-12-01 | 2007-07-25 | Jonathan Geoffrey Milt Craymer | Verification using one-time transaction codes |
US8135642B1 (en) * | 2006-02-07 | 2012-03-13 | Sprint Communications Company L.P. | Resilient messaging system and method |
US20080028453A1 (en) * | 2006-03-30 | 2008-01-31 | Thinh Nguyen | Identity and access management framework |
US9336543B2 (en) * | 2006-03-30 | 2016-05-10 | Datascape, Inc. | System and method for facilitating transactions through a network portal |
KR100847532B1 (en) * | 2006-04-06 | 2008-07-21 | 재단법인서울대학교산학협력재단 | User terminal and authenticating apparatus used for user authentication using information of user's behavior pattern |
US20070280509A1 (en) * | 2006-04-24 | 2007-12-06 | Encryptakey, Inc. | Systems and methods for storing data to a handheld device |
US20070277224A1 (en) * | 2006-05-24 | 2007-11-29 | Osborn Steven L | Methods and Systems for Graphical Image Authentication |
US8793490B1 (en) * | 2006-07-14 | 2014-07-29 | Jpmorgan Chase Bank, N.A. | Systems and methods for multifactor authentication |
US20080028205A1 (en) * | 2006-07-31 | 2008-01-31 | Cui Qing Yang | Method and apparatus for authenticating a user |
US8978117B2 (en) * | 2007-11-19 | 2015-03-10 | Avaya Inc. | Authentication frequency and challenge type based on environmental and physiological properties |
US8024775B2 (en) * | 2008-02-20 | 2011-09-20 | Microsoft Corporation | Sketch-based password authentication |
US20100031200A1 (en) * | 2008-07-30 | 2010-02-04 | Arima Communications Corp. | Method of inputting a hand-drawn pattern password |
US20100082445A1 (en) * | 2008-09-30 | 2010-04-01 | Apple Inc. | Smart menu options |
US8543415B2 (en) * | 2008-11-26 | 2013-09-24 | General Electric Company | Mobile medical device image and series navigation |
US8941466B2 (en) * | 2009-01-05 | 2015-01-27 | Polytechnic Institute Of New York University | User authentication for devices with touch sensitive elements, such as touch sensitive display screens |
US8924858B2 (en) * | 2010-11-01 | 2014-12-30 | Massachusetts Institute Of Technology | Touch-based system for transferring data |
AU2012201745B2 (en) * | 2011-03-24 | 2014-11-13 | Visa International Service Association | Authentication using application authentication element |
US8831585B2 (en) * | 2012-08-31 | 2014-09-09 | Nuance Communications, Inc. | Systems, methods and articles for a communications device providing communications and services involving automobile head units |
-
2006
- 2006-10-25 GB GBGB0621189.0A patent/GB0621189D0/en not_active Ceased
-
2007
- 2007-03-28 US US11/692,656 patent/US8423466B2/en active Active
-
2013
- 2013-03-15 US US13/838,764 patent/US20130212022A1/en not_active Abandoned
-
2015
- 2015-05-19 US US14/716,519 patent/US9530129B2/en active Active
-
2016
- 2016-10-18 US US15/296,759 patent/US20170091775A1/en not_active Abandoned
- 2016-10-18 US US15/296,778 patent/US20170039564A1/en not_active Abandoned
- 2016-10-18 US US15/296,743 patent/US20170039563A1/en not_active Abandoned
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020112170A1 (en) * | 2001-01-03 | 2002-08-15 | Foley James M. | Method and apparatus for using one financial instrument to authenticate a user for accessing a second financial instrument |
US20020111916A1 (en) * | 2001-02-12 | 2002-08-15 | Coronna Mark S. | Payment management |
US20050193198A1 (en) * | 2004-01-27 | 2005-09-01 | Jean-Michel Livowsky | System, method and apparatus for electronic authentication |
US20070033643A1 (en) * | 2005-07-19 | 2007-02-08 | Ssh Communications Security Corp. | User authentication in connection with a security protocol |
US7540408B2 (en) * | 2006-06-22 | 2009-06-02 | Hip Consult Inc. | Apparatus and method for facilitating money or value transfer |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20150081462A1 (en) * | 2012-07-31 | 2015-03-19 | Matthew D. Ozvat | Systems and methods for secure normative intermediation of payments processing peripherals |
US11507950B2 (en) * | 2012-07-31 | 2022-11-22 | Worldpay, Llc | Systems and methods for secure normative intermediation of payments processing peripherals |
US20200111094A1 (en) * | 2018-10-05 | 2020-04-09 | Mastercard International Incorporated | Systems and methods for facilitating network transactions based on user authentication |
US11455628B2 (en) * | 2018-10-05 | 2022-09-27 | Mastercard International Incorporated | Systems and methods for facilitating network transactions based on user authentication |
WO2020205035A3 (en) * | 2019-01-22 | 2021-07-22 | Shtar Llc | Securing transactions via multi-device authentication |
Also Published As
Publication number | Publication date |
---|---|
US20170039563A1 (en) | 2017-02-09 |
US20170039564A1 (en) | 2017-02-09 |
US8423466B2 (en) | 2013-04-16 |
US20080103972A1 (en) | 2008-05-01 |
US20150254661A1 (en) | 2015-09-10 |
GB0621189D0 (en) | 2006-12-06 |
US20130212022A1 (en) | 2013-08-15 |
US9530129B2 (en) | 2016-12-27 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9530129B2 (en) | Secure authentication and payment system | |
AU2018264130B2 (en) | Systems and methods for providing risk based decisioning service to a merchant | |
US8660955B2 (en) | Method and apparatus for consumer driven protection for payment card transactions | |
WO2008050132A2 (en) | Secure authentication and payment system | |
US8370265B2 (en) | System and method for managing status of a payment instrument | |
US8280776B2 (en) | System and method for using a rules module to process financial transaction data | |
US20070198410A1 (en) | Credit fraud prevention systems and methods | |
US20100179906A1 (en) | Payment authorization method and apparatus | |
US20140032410A1 (en) | Method and system for linking and controling of payment cards with a mobile | |
CN108292398A (en) | Utilize holder's authentication token of enhancing | |
US20060173776A1 (en) | A Method of Authentication | |
US20100293093A1 (en) | Alterable Security Value | |
WO2006062998A9 (en) | System and method for identity verification and management | |
EP1134707A1 (en) | Payment authorisation method and apparatus | |
GB2360383A (en) | Payment authorisation | |
EP3633575A1 (en) | Buy - bye- pay |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |