Methods and systems for verifying transactions

专利摘要:
The present invention relates in part to a computer-implemented method for verifying authorization of a transaction. The method includes the steps of receiving a request to process an electronic transaction for a predetermined amount (215), dividing the predetermined amount into a plurality of debits (225), providing a plurality of debits to facilitate debiting of the financial instrument with each one (235), debits from a user of the financial instrument after the debits (245) of said plurality of debits receives information regarding the plurality and verifies the transaction only if the information is correct (255). (Figure 2A)
公开号:SE539328C2
申请号:SE1251231
申请日:2011-03-31
公开日:2017-07-04
发明作者:John Karantzis Nickolas
申请人:Isx Ip Ltd；
IPC主号:

专利说明:

The present invention relates generally to payment transactions and to particular verification of electronic payment transactions and / or financial instruments used in such transactions. BACKGROUND Widespread availability and use of computer systems and the Internet has resulted in electronic financial transactions becoming more common. The use of financial instruments such as credit cards, debit cards and bank accounts to buy goods services from online retailers or online sellers is extremely convenient. However, the number of fraudulent transactions has increased significantly. Merchants have limited protection against fraudulent credit or payment transactions, especially in situations without card access (CNP) "card not present" (ie when the cardholder's authenticity can not be verified using conventional comparison of signatures or identification checks at the point of sale), and may be liable for the cost of such transactions and transport costs in relation to the goods. To make matters worse, traders may also be liable for bank penalties.
During a payment transaction using a payment card (eg credit card, debit card or prepaid card) it is advantageous to verify a buyer's (cardholder's) ownership of the card or an account associated with the card to avoid a number of potential problems, such as unauthorized use, disputed use or a later will change on the part of the buyer (also referred to as "friendly" or "not me" fraud). Authentication of the buyer is the process by which a cardholder's ownership of an account is verified. A common method for authenticating a buyer's ownership of an account is routinely done at the point of sale in what is called a "card present" transaction. At a card-present transaction, the merchant's representative passes the card through a card payment terminal to verify account status and credit availability, and then checks that the signature on the back of the card matches the buyer's signature. This can be accompanied by checking a photo identification such as, for example, a buyer's driving license. The process identifies the buyer and provides specific authorization for a particular transaction. Given that the buyer follows the specific guidelines for such transactions, the merchant is guaranteed payment for the authorized amount minus the discount and fees.
For CNP transactions, such as those made online, by post or landline payments, payments to the merchant are generally not guaranteed. The primary reason why CNP transactions are not guaranteed is that buyers (cardholders) are not authenticated in situations where merchants and buyers are not physically present with the card at the time of transactions. This gives rise to financial risks associated with the transaction, which are generally borne by the trader. Such risks include: recovery of payment transactions to online merchants (eg questioned use transactions), fraud for both merchants and cardholders (eg unauthorized use of stolen account information to buy goods and services online) and increased expenses for financial institutions (which are often transferred to traders). Unfortunately, this leads to a growing general perception that it is unsafe and unsafe to shop for goods and services online, which prevents some consumers from buying online. Questioned use transactions occur when a buyer who is the authorized cardholder questions that a transaction has occurred, even if the knowledgeable person initiated such a transaction but later changed. Even if it is rarer than unauthorized use or fraudulent transactions, questioned transactions still pose a risk to traders as they are grounds for potential recoveries. Merchants often rely on delivery services with "signing on delivery" as the main means of combating this type of fraud, which, however, can be ineffective because packages can be signed by others, the signature may be illegible or different from the cardholder's normal signature or the package is delivered to different addresses. from the invoice address. All of these make it possible to create a scenario for a possible dispute with the cardholder and are susceptible to recovery.
In view of the continued growth in e-commerce, it is desirable to provide methods that can authenticate buyers as an authorized cardholder (or a person authorized by the cardholder) and link such authorization to each transaction (equivalent to short-term transactions) during online purchase transactions, which reduces fraud. and recoveries, thereby reducing the costs associated with each of these events. Authentication of the buyer as the authorized cardholder (or a person authorized by the cardholder) also addresses the consumer's security interests and is likely to lead to increased online sales. In view of the above, it is desirable to have a system for authentication of the buyer's identity and his authorization regarding the specific online transaction for the individual case when the transaction is carried out by card access (CNP transaction). Such an authentication system should preferably be simple to implement and use, require a minimal investment of resources and provide a high level of confidence around the authorization of the transaction. Such an authentication system should preferably also provide for exchange transactions whereby one currency linked to the buyer's card differs from the transaction currency of the seller or merchant.
Various types of checks are currently used to identify and dismiss fraudulent transactions. Credit card portals generally recommend, for example (Address AVS) and Card Verification Value CVV. Non-compliance with address verification service verification The ACP verification service indicates that the person giving rise to the transaction may not hold the card in question. However, these types of checks are not completely secure as fraudsters often have the opportunity to obtain the necessary information with sufficient effort. These checks, even if they are provided at the time of the pre-transaction, do not always protect the merchant from "recovery" whereby the cardholder can question that the transaction was authorized and claim that it was initiated by an unauthorized third party.
Another check is to look up a buyer's IP address with a geoposition service that also detects anonymous proxy servers _ In most cases, the geographic location of an IP address should match either the buyer's billing or delivery address. Orders from anonymous proxy servers are generally considered to pose a higher risk because fraudsters often use anonymous proxy servers to hide their actual IP addresses.
Another control is to compare the geographical position of the buyer's IP address with a list of high-risk countries or areas.
Another check is to determine whether the goods will be sent to a forwarding company in cases where the delivery and invoice address differ. Such orders can be risky because the goods can be sent abroad.
Another check is to determine whether the postal / zip code provided by the buyer corresponds to the city and state. The above-mentioned ACP check examines the postal code number and a numeric part of a street address. Fraudsters do not always have access to the complete address and may even be too lazy to do a reverse lookup of zip codes for additional address information.
Another check is to request that the buyer send a signed authorization form with a copy on the front and back of the card via fax. However, this is impractical and is only requested in suspicious circumstances. Furthermore, fraudsters have been known to create credit card images using graphic design software.
Another check is to request that the buyer provide the name of the bank and customer service telephone number according to the information on the card. Customer service can then be called to determine if the information corresponds to the bank details for the cardholder. This control is usually effective but takes a lot of time and is impractical.
Another check is to provide the buyer with a personal identification number (PIN) for use in each transaction in advance for all transactions. This is perceived as effective, but the buyer usually needs to apply separately and in advance for PlN for CNP transactions and can often lose or confuse PlN codes.
There is a need for improved methods and systems that prove or verify that an account or cardholder has authorized a specific transaction or payment from a specific account or card, without introducing undesired delays and / or unnecessary additional transactions or actions. SUMMARY OF THE INVENTION An Embodiment of the present invention provides end computer implemented method for verifying authorization of a transaction. The method includes the steps of: receiving a request to process an electronic transaction for a predetermined amount, requesting data identifying a particular financial instrument, dividing the predetermined amount into a plurality of debits, providing debiting of the financial instrument with each of the plurality of debits; receive information regarding the majority of debits from the origin of the said request and verify the transaction only if the information is correct.
Another embodiment of the present invention provides a computer system for verifying authorization of a transaction. The system includes: a memory for storing data and program instructions; and at least one processor connected to the memory. The at least one processor is programmed to: receive a request for processing an electronic transaction for a predetermined amount, request including data identifying a particular financial instrument, divide the predetermined amount into a plurality of debits, effect debiting of the financial instrument with each of the plurality of debits; receive information regarding the majority debits from the origin of the said request and verify the transactions only when the information is correct.
Another embodiment of the present invention comprises a computer program product comprising a computer readable medium comprising a computer program stored therein to verify authorization of a transaction.
The computer program product includes: computer program code means for receiving a request night processing an electronic transaction for a predetermined amount, requesting data identifying a particular financial instrument, computer program code means for dividing the predetermined amount into a plurality of debits, computer program code means for providing the debit. one of several debits; computer program code means for receiving information regarding the majority of charges from the origin of this request and computer program code means for verifying the transaction only when the information is correct.
Another embodiment of the present invention provides a computer-implemented method for verifying transactions. The method comprises the steps of: receiving a request for verification of an electronic transaction for a predetermined amount, dividing the predetermined amount into a plurality of debits, providing said plurality of debits to facilitate debiting of the financial instrument with each of said plurality of debits, receiving information regarding a plurality of debits. debits, information derived from a user of the financial instrument after debiting the plurality of debits from the financial instrument and verifying the transaction only if the information received is correct.
Another embodiment of the present invention provides a computer system for transaction verification. The computer system includes: a memory for storing data and program instructions and at least one processor connected to the memory. The at least one processor is programmed to receive a request to verify an electronic transaction for a predetermined amount, divide the predetermined amount into a plurality of debits, provide the plurality of debits to facilitate debiting of the financial instrument with each of the plurality of debits; receive information regarding the majority of debits, the information originating from a user of the financial instrument after the majority of debits have been debited from the financial instrument and verify the transaction only when the information received is correct.
Another embodiment of the present invention provides a computer program product comprising a computer readable medium comprising a computer program stored therein for verifying transactions. The computer program product includes: program code means for receiving a request to process an electronic transaction for a predetermined amount, a request comprising data identifying a particular financial instrument; computer program code means for dividing the predetermined amount into a plurality of charges, computer program code means for affecting the financial instrument to be charged with each of the plurality of charges from the origin of said request and computer program means for verifying the transaction only when the information is correct.
Another embodiment of the present invention provides a computer-implemented method for verifying transactions. The method comprises the steps of: receiving a request to verify an electronic transaction regarding a predetermined amount; divide the predetermined amount into a plurality of charges; receive information regarding the majority of debits, the information deriving from a single user of the financial instrument after debiting from the financial instrument of the majority of debits and verify the transaction only when the information received is correct.
Another embodiment of the present invention provides a computer system for verifying transactions. The computer system includes: a memory for storing data and program instructions; and at least one processor connected to the memory. The at least one processor is programmed to receive a request to verify an electronic transaction for a predetermined amount; divide the predetermined amount into a plurality of charges; providing said plurality of debits to facilitate debiting from the financial instrument with each and every plurality of debits, receiving information regarding the plurality of debits, the information deriving from a single user of the financial instrument after said plurality of debits have been debited from the financial instrument and verifying the transaction only when information is received is correct.
Another embodiment of the present invention provides a computer program product comprising a computer readable medium comprising a computer program stored therein for verifying transactions. The computer program product includes: computer program code means for receiving a request to verify an electronic transaction for a predetermined amount; computer program code means for dividing the predetermined amount into a plurality of charges; computer program code means for providing said plurality of transactions to facilitate debiting of the financial instrument in respect of each of said plurality of charges; computer program code means for receiving information relating to the plurality of debits, the information deriving from a user of the financial instrument after said plurality of debits has been debited financial instrument and computer program code means to verify the transaction only if the information received is correct. In some embodiments, said plurality of charges comprises two charges.
In certain embodiments, information regarding said plurality of charges may be stored and compared with the received information, when it has subsequently been received, to determine whether the received information is correct.
The financial instrument may, for example, include a bank account, a credit card, a bank card, a debit card, a store card and a direct debit account facility.
Information regarding said plurality of charges may include: the amount of each of said plurality of charges or the number of said plurality of charges.
In some embodiments, an exchange rate associated with the transaction may be stored.
BRIEF DESCRIPTION OF THE DRAWINGS A small number of embodiments of the present invention will hereinafter be described with reference to the following drawings in which: Figure 1A is a schematic block diagram of a transaction verification or transaction authorization system in accordance with an embodiment of the present invention; Figure 1B is a schematic block diagram of a transaction verification or transaction authorization system in accordance with an embodiment of the present invention; Figure 1C is a schematic block diagram of a transaction verification or transaction authorization system in accordance with an embodiment of the present invention; Figure 1D is a schematic block diagram of a transaction verification or transaction authorization system in accordance with an embodiment of the present invention; Figure 1E is a schematic block diagram of a transaction verification or transaction authorization system in accordance with an embodiment of the present invention; Figure 1F is a schematic block diagram of a transaction verification or transaction authorization system in accordance with an embodiment of the present invention; Figure 2A is a flow chart of a transaction verification or transaction authentication method in accordance with an embodiment of the present invention; Figure 2B is a flow chart of a transaction verification or transaction authentication method in accordance with an embodiment of the present invention; Figure 2C is a flow chart of a method for verifying exchange transactions or authorizing exchange transactions in accordance with an embodiment of the present invention; Figure 2D is a flow chart of a method for verifying exchange transactions or authorizing exchange transactions in accordance with another embodiment of the present invention, and Figures 3A and 3B are schematic block diagrams of a computer system with which embodiments of the invention may be practiced. Identical reference numerals in different figures are intended to denote identical or substantially identical objects unless the opposite is expressed. DETAILED DESCRIPTION Embodiment of methods and systems for verifying transaction authorization is described below. The methods and systems described below can be used to verify the legitimacy of the person who gives rise to a cardless transaction (CNP), to use the financial instrument and consequently to authorize a transaction.
For simplicity, the described embodiments will be based on credit cards or debit cards as financial instruments. However, the invention is not limited to these embodiments but has wide application also to other financial instruments including, but not limited to, bank accounts or other cards with stored value.
Also for convenience, the embodiments are described with reference to the buyer, who alternatively can also be referred to as the cardholder or originator of a transaction.
Also for the sake of simplicity, the embodiments are generally described with reference to the online purchase of a product from a merchant (eg a seller of physical or virtual goods, or a service provider) by a buyer who is the originator of the CNP transaction via the network. However, the scope of the invention is not intended to be limited by this as the invention can be widely applied to transactions without short access (CNP transactions), including mail orders and telephone sales orders ("IVIOTO") linking subordinate information such as e-mail address or SMS, MMS or IP telephones to the verified the transactions, thereby also verifying in addition to linking this subordinate information to the transaction and the payer (buyer).
The verification methods and systems described below confirm that the buyer (such as the person giving rise to a CNP transaction) has access to an account associated with the financial instrument and is most likely the authorized cardholder or a person authorized by the cardholder.
The embodiments described below can be practiced independently of or together with the various methods and controls described in the background section OVan.
Figure 1A is a schematic block diagram of a system for verifying electronic transactions or authorizing electronic transactions.
Referring to Figure 1A, a buyer (or originator) 110, sole trader 120, a payment portal 130, and the buyer's financial institution (i.e., in the role of providing the financial instrument) 140 are usually represented or designed computer systems such as the computer system 300 described below with reference to Figures 3A. and 3B. The payment portal 130 may comprise an independent intermediary such as the clearing house or may alternatively be provided by the buyer's financial institution or the merchant's financial institution. The computer system of the buyer 110, the merchant 120, the payment portal 130 and the merchant's financial institution 140 are connected via a communication network (not shown). Area Network) or WAN (Wide Area Network) _ Such networks may include private networks, public networks, wired or wireless networks, or any combination thereof. The above computer systems may preferably be connected via the Internet (not shown in Figure 1A).
In operation, the buyer (or originator) 110 sends a request 112 to the merchant 120 to process an electronic transaction for a predetermined amount. The request 112 may, for example, be a result of the buyer 110 having browsed to a merchant's website 120 (eg an online retailer) and choosing to purchase an item offered to the merchant's website. In this case, the predetermined amount may correspond to the advertised price or the list price of the item. Request 112 typically includes identification details for a particular financial instrument (eg, credit card, debit card, bank or other account, etc.) that buyer 110 wishes to use when paying for the item.
Upon receipt of request 112, the merchant 120 sends a request 122 to the payment portal 130 to process an electronic transaction for the predetermined amount using the financial instrument designated by the buyer (in accordance with the processing requirements of the card system network or financial institution).
Upon receipt of request 122, the payment portal 130 proceeds to debit the financial instrument designated by the buyer 110 by two or more132. The payment portal 130 divides the predetermined amount into the multiples (ie two or debits 134 which add up to the predetermined amount.more) the debits, preferably in a random manner (e.g. using a software application comprising a random number generator).
In an alternative embodiment, the predetermined amount may be divided into the multiple charges of the merchant 120 and the multiple charges may be communicated to the payment portal 130 in request 122.
Upon successful debiting of the financial instrument identified by the buyer in requests 112 and 122, the buyer 110 receives information (via the merchant in communications 124 and 114) that the buyer's financial instruments have been debited. The buyer also receives a request to provide information regarding the number of debits made from the buyer's financial instruments and / or the size of each charge. In another embodiment, the payment portal 130 may communicate directly with the buyer 110 with respect to this.
The buyer 110 checks 116 his account linked to the financial instrument and determines or receives 142 the number of debits and / or the individual amounts carried by the multiple debits made by the payment portal 130 on behalf of the dealer 120.
The buyer 110 then informs or confirms 118 the individual amounts brought by the multiple debits to the merchant 120. Such information or confirmation from the buyer 119 can, for example, be made via electronic data transmission, electronic mail (e-mail), SMS via a mobile phone, completion of an electronic form / input visa made available via the network or any other available, suitable means, including verbal (by telephone). In alternative embodiments, the buyer 110 may provide advice or confirmation to or through another party, such as the payment portal or the merchant's financial institution 130. 12 Upon receipt of the confirmation of the number of charges and the individual amounts in the multiple charges, the merchant 120 verifies the authorization of the transaction. Successful verification may, for example, be based on an internal requirement for the merchant 120 before the item in question is released or sent to a buyer 110.
In an alternative embodiment, it is the buyer's 110 to check the account linked to his / her financial instrument after submitting request 112 to determine the number of debits made and / or the amount of each debit (ie unsolicited) and to inform merchant 120 or payment portal or merchant's financial institution 130 accordingly.
In other embodiments, the merchant's financial institution 130 or the buyer's financial institution 140 may verify the transaction or authorization of the transaction with the dealer 120, directly or through the payment portal. Verification can, for example, be linked to information about authorization, clearing or actual regulation of funds to the merchant 120, after which the merchant 120 can release or send current goods to the buyer 110.
In other embodiments, a card system network to which the financial instrument is connected (eg Visa, MasterCard®, American Express ®, JCB, etc.) can verify the transaction, either directly or through the merchant's financial institution or payment portal 130 to the merchant 120. This can be done in conjunction with de-authorization processes used by the relevant financial institutions. The verification may, for example, refer to advice from a card system network via the merchant's financial institution or payment portal 130 regarding verification and / or authorization, or verification and initiation of clearing or actual settlement of funds to merchant 120, after which merchant 120 may release or send the goods to buyer 110 .
Dividing a predetermined amount into a plurality of charges can be performed by a verification agent, which typically includes a software application. The verification agent may, for example, be included in and / or executed on: o the merchant's computer system or network; o the payment portal's computer system or network; v a computer system or network of the merchant's financial institution; or an independent computer system (eg a server accessible via the Internet by merchants, payment portals and / or merchants' financial institutions; 13 o a computer system or network associated with a credit or debit card system such as Visa, MasterCard®, American Express ®, etc. or o a combination of some of the above.
Upon a request for verification of a transaction regarding a predetermined amount or authorization of a transaction, the verification agent determines the number of debits into which the predetermined amount is to be divided and the value associated with each of the debits. As previously described, the number of charges and / or the amount of each charge is preferably determined randomly (e.g. using a random number generator implemented as a software application in a computer). The information (ie the number of debits and / or the amount of each debit) is stored and forwarded to a payment portal or financial institution for actual debiting to an account linked to the buyer's financial instruments.
Information subsequently received from the buyer (eg the number of charges and / or the amount of each charge) is compared with the stored information to determine whether the version of the information provided by the buyer is correct. If this is correct, the authorization for the transaction is verified.
Comparison between the stored information and the information received from the buyer is preferably performed by the verification agent, regardless of whether this has been implemented in the payment portal's computer system, the merchant's computer system, the merchant's financial institution's computer system, current card system network computer system or in an independent computer system.
Communication between the buyer and the verification agent can be direct or indirect (for example via the payment portal, the merchant, the merchant's financial institutions or the card system network). Such communication can, for example, take place via electronic data transmission, direct or forwarded electronic mail (e-mail), directly or SMS via form / input view available via the web or any other form of suitable means, forwarded mobile phone, completion of an electronic-containing verbal (by phone) to an operator who enters the appropriate data. In cases where the communication is electronic, the address and unit information regarding the buyer can be associated with the buyer or the transaction and stored for identification of the buyer in subsequent transactions. When such information is received as part of a verification process via electronically routable addresses such as e-mail addresses, SMS-activated mobile phones, IP protocol addresses, etc., these electronically routable addresses can be associated with the buyer or the transaction after verification and stored for subsequent identification by the buyer.
In cases where the buyer's financial instruments and the trader use different currencies, the exchange rate linked to a transaction may be requested from the financial institution and stored on a transaction-by-transaction basis to enable conversion and subsequent direct or indirect response from the buyer to the verification agent. .
Figure 1B is a schematic block diagram of another system for verifying transactions or authorizing transactions.
Referring to Figure 1B, a buyer 210, a trader 220, a single payment portal 230, the trader's financial institution 240 and the buyer's financial institution (which provides the financial instrument) 250 are usually represented or designed computer systems such as the computer system described below with reference to Figures 3A and 3B. . The above-mentioned computer systems are usually communicatively connected via one or more communication networks (not shown). Such networks may include, for example, private networks, public networks, wired networks, wireless networks, LAN (Local Area Networks) type, Wide Area Networks (WAN) type and any combination of the aforementioned networks. In particular, the above-mentioned computer systems can be connected via the Internet (not shown in Figure 1B).
An authentication agent 260 operates in conjunction with the merchant220 computer system. The verification agent may, for example, comprise a software application stored in or executed by a computer system for the merchant 220. Alternatively, the verification agent 260 may comprise a separate computer server connected to the computer system for the merchant 220 (eg via internet or a LAN (Local Area Network)).
In operation, the buyer (or originator) 210 sends a request 212 to the merchant 220 to process an electronic transaction for a predetermined amount. The request may, for example, be a result of the buyer 210 having visited a website for the merchant220 (eg an online retailer) and choosing to buy an item that is marketed on the merchant's website. In this case, the predetermined amount may correspond to the advertised price or the list price of the item. Request 212 typically includes identification details for a particular financial instrument (eg, credit card, debit card, bank or other account, etc.) that buyer 210 wishes to use when paying for the item.
Upon receipt of request 212, merchant 210 forwards request 222 to verification agent 260.
Upon receipt, the verification agent 260 divides the predetermined amount into two or more debits, preferably in a random manner (e.g., using software including a random number generator) and returns said plurality of debit amounts 262 to the merchant 220. Said plurality of debit amounts sum to the predetermined amount. Thereafter, the trader 220 requests the buyer's financial instrument identified in requests 212, 224 with the two or more debits summing up to the predetermined amount.
The trader's financial institution 240 debits the 242 account that is linked to the buyer's financial instrument (at the buyer's financial institution 250) with the mentioned number of debits.
After the buyer's financial instrument has been debited with the said multiple debits, the buyer 210 receives information 244, 234, 226 that his / her financial instrument has been debited by the merchant's financial institution 240 via the payment portal230 and the merchant 220.
The buyer 210 checks 214 his account linked to the financial instrument at the buyer's financial institution 250 and receives 252 the number of debits and the individual amount for each of the multiple debits made by the trader's financial institution 240.
The buyer 210 then informs or confirms 216 the individual amounts for 220 and / or the verification agent 260. In an alternative embodiment to that shown in Figure 1B, each of said plurality of charges to the merchant buyer 210 may inform or confirm the individual amounts for each mentioned plurality of charges directly to the verification agent 260 (ie not via the merchant220). Such information or confirmation may, for example, take place via electronic data transmission, electronic mail (e-mail), SMS via mobile phone, completion of an electronic form / entry view via the network or any other suitable, accessible means, including verbal (by telephone). Confirmation of the number of debits and / or the 16 individual amount for said plurality of debits is intended to authorize the transaction, which in turn can act as an authorization or impulse for the merchant to release or send the item in question to the buyer 210.
In an alternative embodiment, it is the responsibility of the buyer 210 to check the account linked to his / her financial instrument after a request 212 has been made, in order to determine the number of debits made and / or the amount of each debit (ie without prompting).
Figure 1C is a schematic block diagram of another system for verifying transactions or authorizing transactions.
The system of Figure 1C is substantially similar to the system of Figure 1B. However, the verification agent 260 is connected to the payment portal 230 instead of the merchant 220. That is, the communications 222 and 262 in Figure 1B are replaced by the communications 236 and 264 in Figure 1C, respectively. The other elements of the system of Figure 1C are identical or substantially similar to the corresponding elements of Figure 1B. Sub-elements having the same reference numerals in Figures 1B and 1C have identical, corresponding or similar functionality. In an alternative embodiment to that shown in Figure 1C, the buyer 210 may inform or confirm individual amounts for each mentioned plurality of charges directly to the verification agent 260 (ie not via the merchant 220 and / or the payment portal 230).
In a further embodiment, the verification agent 260 may be connected to the merchant's financial institution 240 instead of to the payment portal 230 or to the merchant 220.
In a further embodiment, the verification agent 260 may be exercised as an independent computer server available to the computer systems for which by the merchant 220, the payment portal 230 or the merchant's financial institution 240 via the Internet.
The system according to Figure 1D is substantially similar to the system according to Figure 1C, but also shows the card system network 270 (eg Visa, MasterCard ®, American Express ®, etc.) communicatively connected to the verification agent 260, the merchant's financial institution 240 and the buyer's financial institution 250. The verification agent 260 enables billing 266, 276 via the card system network 270, which process the transfer of funds said debit amounts via the communications via two-way communication 244 and 254 with the merchant's financial institutions and the buyer's 17 financial institutions 250. Elements with similar reference numerals in Figures 1B, 1C and 1D have identical, corresponding or similar functionality.
In a further embodiment, the verification agent 260 may be connected to the merchant financial institution 240 or the card system network 270 instead of to the payment portal 230 or the merchant 220.
In a further embodiment, the verification agent 260 may be exercised as an independent computer server available to the computer systems of any of the merchant 220, the payment portal 230, the merchant's financial institution 240 or the card system network 270 via the Internet.
Figure 1E is a schematic block diagram of another system for verifying transactions or authorizing transactions.
Figure 1E includes an independent verification agent 260 communicatively connected to the systems 270 and 280, which correspond to the systems of Figures 1B and 1C, respectively. The verification agent 260 of Figure 1E typically includes a computer software application running on and executed on a computer server independent of the systems, vendors, merchants, payment port, payment port the financial institutions for buyers and / or traders.
Figure 1F is a schematic block diagram of another system for verifying transactions or authorizing transactions.
The system of Figure 1F is substantially similar to the system of Figure 1E. According to the system, Figure 1F also includes an independent verification agent 260 communicatively coupled to the system 290 similar to the systems 270 and 280 of Figures 1B and 1C, respectively. A card system network 295 (eg Visa, MasterCard ®, American Express ®, JCB etc.) is shown sandwiched between the merchant's financial institution and the verification agent260. As in Figure 1E, the verification agent 260 in Figure 1F typically includes a software application that is part of and executed on a computer server that is independent of the computer systems of buyers, merchants, payment portals and / or merchants' financial institutions and the card system network.
It should be noted that the payment portal and the merchant's financial institution may be different or different organizations. In the present figures, however, payment portals and / or the merchant's financial institutions represent the 18 organization / organizations designated by the merchant for the purpose of electronically processing transactions using the purchaser's financial instruments. It should further be noted that this document does not describe complete intercommunication between the different clearing houses, payment portals, card system networks and financial institutions as this may vary according to position and is known to those skilled in the art.
The verification agent does not necessarily provide payment processing services and generally operates in conjunction with third-party payment portals, financial institutions, card system networks and clearing houses. Furthermore, details of the actual financial instrument used to process a transaction (eg card number, cardholder name, etc.) need not be known by the verification agent as each transaction can be processed on a case-by-case basis with reference only to the transaction itself, regardless of the type or source of the financial instrument.
Optional integration of a verification agent in accordance with the embodiments of the present invention into existing authorization, clearing and cash transfer processes for the financial institutions and / or card system network in addition to the potential to reduce costs associated with processing credit card transactions. Card system networks and financial institutions generally implement a three-step process for credit card payments, namely: 1) authorization, 2) clearing and 3) cash transfer. Embodiments of the present invention can be advantageously integrated into the authorization and clearing steps, thereby reducing overall processing costs. Accordingly, the transactions of the intermediary of the merchant and the cardholder will not be completed if verification is not achieved. This leads to the advantage of reduced processing between banks and fewer "recoveries" (procedure for recovering funds transferred between banks).
The information that can be transferred and / or stored by the verification agent on a per-transaction basis may, as an option, include the following, but is not limited to: Date and time of original transaction; merchant identifier portal portal identifier merchant financial institution identifier; 19 Transaction identifier (assigned by the merchant, portal or verification agent); Predefined debit amount; card system network identifiers (eg Visa, MasterCard ®, American Express ®, etc.); Unique buyer identifier (assigned regardless of the financial instrument account information from the verification agent, trader or portal); Issuing country of the financial instrument; Currency of the financial instrument; Exchange rate applied to transaction; IP address of the buyer during the transaction, as mediated by the merchant or portal; Buyer's Email Address; Buyer's telephone number, for an SMS or MMS-enabled telephone; Amounts for charges provided by buyers; Date and time of amounts for charges provided by buyers; Buyer's IP address and / or email address and / or chat service address or other electronically routable addresses used during Buyer's provision of multiple billing amounts; Buyer's telephone contact information, such as an SMS or MMS or similar message enabled telephone used or designated by Buyer in providing multiple billing amounts; Acquired MAC addresses, lMEl, ESN, serial number or other hard-coded data linked to a device used by a buyer upon delivery of several debit amounts: The buyer's personal identification number (PIN) nominated in connection with the provision of several debit amounts.
Figure 2A is a flowchart of a computer-implemented method for verifying transactions or authorizing transactions.
Referring to Figure 2A, a request for processing an electronic transaction regarding a predetermined amount is received in step 410. The request includes data identifying a particular financial instrument specified by the originator of the request.
In step 420, the predetermined amount is divided into a plurality of debits so that the sum of the individual amounts for said plurality of debits corresponds to the predetermined amount (i.e., the total transaction amount). The number of individual debits and current amounts are preferably determined or selected at random (eg through a computer software program using a pseudo-random generator). The number of individual charges and the current amount are stored for later collection.
At step 430, the specified financial instrument is debited separately with each of said plurality of debits.
At step 440, confirmation of said plurality of debits (ie the number of separate debits and / or respective amounts) is received from the originator upon request. The originator retrieves the number of separate debits and / or respective amounts through the access hand / her account linked to the financial instrument and forwarded information for verification. Given that the confirmation information received in step 440 is correct, the transaction is verified in step 450. In determining whether the information received in step 440 is correct, the number of individual charges and / or respective amounts received from the buyer is compared with the number of charges and / or respective amounts as determined. in step 420.
Figure 2B is a flow chart of a computer-implemented method for verifying transactions.
Referring to Figure 2B, a request to verify an electronic transaction for a predetermined amount is received in step 415.
At step 425, the predetermined amount is divided into a plurality of debits such that the sum of the individual amounts for the debits corresponds to the predetermined amount (ie, the total transaction amount). The number of individual debits and actual amounts are preferably determined or selected in a random manner (eg by means of computer software programs using a pseudo-random generator).
The number of individual charges and current amounts are stored for later collection.
At step 435, the multiple debits (eg, amounts) are provided to a unit to facilitate the debiting of a financial instrument.
At step 445, confirmation of the charges is received (ie, the number of different charges and / or the respective amount). This information originates from the 21 user of the financial instrument and is typically obtained by the user who accesses his account linked to the financial instrument.
Given that the confirmation information received in step 445 is correct, the verification transaction at step 455. In determining whether the information received in step 445 is correct, the individual charges and / or respective amounts as received from the user of the financial instrument are compared with the number of charges and / or respective amounts. as determined in step 425.
The methods and systems described above with reference to Figures 2A and 2B can be advantageously practiced for currency exchange transactions (ie transactions in which currency for issuance or operation of a particular financial instrument (eg credit card, debit card, prepaid card, bank account, etc.) differ from the currency of the transaction (as processed by the merchant)). A particular disadvantage of conventional currency exchange transactions, which are typically only completed several days after the origin of the current transaction, is that the exchange rate applied is not known at the same time by the buyer (eg the cardholder) and the merchant.
Said plurality of debits summing up to the predetermined transaction amount are stored by the verification agent and later compared with the value provided by the buyer for authentication purposes. The debits are preferably stored as debit ratios relative to a predetermined amount (ie, the total transaction amount) for later matching with values provided to the buyer. The values received by the verifying agent from the buyer are modified at the exchange rate between the currency of the financial instrument (ie the buyer's currency) and the trader's currency (ie the currency in the price of the advertised product or product). Each of the values provided by the buyer (eg from his / her bank statement) is converted by the verification agent to the value ratio by dividing each of said plurality of values received, by the sum of the values received. The value ratio is compared with the stored debit ratios and the transaction is authenticated or verified if each of the value ratios matches a respective stored debit ratio within a predefined margin of error or fault tolerance (ie due to rounding).
Each of the plurality of charges is converted into a ratio and stored as a stored charge value ratio (SV) as follows: 22 SV1 = Value 1 / (Predefined amount) SV2 = Value 2 / (Predefined amount) SVN = Value N / (Predefined amount) where Value1, Value2, ValueN are the chargesDetermined amount is the total amount of the transaction andSum (Z) [Value1, Value2, _ stored in the currency of the original transaction (ie in the merchant's currency).
ValueN] corresponds to the predetermined value, such as the sum of the stored conditions Sum (Z) [SV1, SV2, SVN] = 1.
The buyer's response includes a number of response values (RV) corresponding to the said multiple debits, but modified with the current daily exchange rate (ie the current exchange rate between the currency of the financial instrument used and the currency of the transaction (ß)) _ The exchange rate (ß) need not be known and is usually not felt as part of the method, the method mathematically removes the need to know (ß) to compare stored relatively received values.
Upon receipt of the buyer's response, the response values are converted to buyer response ratios (PR) as follows: PR1 = RV1 / 2 (RV1, RV2_ _ _ RVN) P R2 = RV2 / 2 (RV1, RV2_ _ _ RVN) PRN = RVN / 2 (RV1 , RV2 ___ RVN) whereby RV1, RV2, the debit values RVN are response values received from the buyer and linked to Value1, Value2, ... ValueN by the factor (ß) PR1, PR2, "PRN is the buyer's response conditions and 23 Sum (2) [PR1, PR2 , .. PRN] ~ 1 subject to a fault tolerance (s).
If SV1 is equal to that of PR1 to PRN, within a predefined fault tolerance (s), then this is assumed to be a correct answer for predetermined Value1 for verification purpose. A similar procedure is performed for all remaining stored conditions by comparing and matching SV2 to SVN with a corresponding response ratio PR2 to PRN subject to fault tolerance (s).
Each stored value (SV) must be assigned a corresponding PR value until all are exhausted. In cases where there is an imbalance in the values or in the current number of SVs to PR, the authentication procedure results in a rejection.
The comparison of stored ratios, calculated using the debits as the numerator and the predetermined amount as the denominator, co-response ratios calculated using the response values as the numerator and the sum of the total response values as the denominator, mathematically eliminates the requirement to know the exchange rate factor. procedure.Example A trader sells a product for US $ 105. A buyer agrees to purchase the product for US $ 105 and enters the information regarding their financial instruments (data) on the merchant's website. The data is transferred to the verification agent who divides the US $ 105 (ie the predetermined amount) into two different debits by means of a random number generator, for example US $ 59.99 and US $ 45.01. The sum of the two different US $ 105 (ie the Verification Agent stores the two different charges as amounts and as conditions: US $ 59.99 / US $ 105 = 0.5713333333 and US $ 40.01 / US $ 105 = 0.381047619. The charges amount to the predetermined amount) .
However, the buyer's financial instrument is issued in another currency, so the current amount shown on the buyer's bank statement will be modified at the exchange rate for the day (ß) for this currency: $ 59.99ß and $ 40.01ß respectively. The predetermined amount can also be modified by the exchange rate. The buyer will then respond to the verification agent with two numerical amounts that differ in absolute numerical value, but have the same relationship to the predetermined amount, namely $ 59.99ß and $ 40.01 ß. 24 The verification agent then calculates the following conditions relative to the modified predetermined amount: $ 59, 99ß / ($ 59.99ß + $ 41.01ß) = O, 571333333 and $ 45.01ß / ($ 59.99ß + $ 41, O1ß) = O, 381047619.
As can be noted, the ß variable can be eliminated mathematically, so that only the derelative conditions remain, subject to rounding errors. To further illustrate, the dealer's currency is the same as the buyer's currency, so ß corresponds to one unit (1), since the PR values will correspond exactly to the SV values.
Figure 2C is a flowchart of a computer-implemented method for verifying exchange transactions or authorizing exchange transactions. The method of Figure 2C is similar to the method of Figure 2A, except for the addition of steps 422, 442 and 444, which specifically refer to switching aspects. In step 422, the plurality of debits are converted to debit ratios by dividing each of the plurality of debits by the predetermined amount and then storing. In step 444, the stored debit conditions are compared with the information received from the originator to the request (ie buyer) to perform the verification of the transaction. The information received from the originator upon request includes a plurality of values corresponding to said debit goods and one modified by an exchange rate (ie an exchange rate between the buyer's currency and the trader's currency). The values are typically obtained from the originator's bank statement and transfer to the authentication agent for authentication or verification. Before performing the comparison, the values are first converted to the respective ratio by dividing each of the mentioned values by the sum of the values. The transaction is verified or authenticated as each of the value ratios matches a respective stored debit ratio within a predefined margin of error. Step 442 is an optional step, in which identification data is captured (eg IP address, serial number, MAC address, IMEI address, etc.) and linked to the transaction and authentication of the payer (buyer).
Figure 2D is a flowchart of a computer-implemented method for verifying exchange transactions. The method of Figure 2D is similar to the method of Figure 2B, except for additional steps 427, 447 and 449 which specifically relate to the switching aspect. In step 427, the debits are converted to debit ratios by dividing each of the debits by the predetermined amount and then storing. In step 449, the stored billing conditions are compared with the information received from the originator upon request (ie, the buyer) to perform verification of the transaction. The information received from the originator upon request includes a plurality of values corresponding to a plurality of charges each modified at .the exchange rate between the buyer's currency and the merchant's currency). The values are typically obtained from the originator's bank statement and transferred to the authentication agent for authentication or verification. Before performing the comparison, the plurality of values are first converted to the respective ratios by dividing each of the values by the sum of the values.
The transaction is verified or authenticated if each of the value ratios matches a respective stored debit ratio within a predefined margin of error. Step 447 is an optional step, at which identification date is captured (eg IP address, serial number, MAC address, IMEI address, etc.) and linked to the transaction and authentication by the payer (buyer).
The methods described above with reference to Figures 2A, 2B, 2C and 2D are typically performed by a verification agent, as also described above.
Figures 3A and 3B illustrate a conventional computer system 300 through which the various arrangements described herein may be performed.
As shown in Figure 3A, the computer system 300 includes a computer module 301, input devices such as a keyboard 301, a mouse 303 and scanner 326, a single camera 327 and a microphone 380, and output devices including a printer 315, a display unit 314 and speakers 317. An external modem 316 The computer module 301 may be used for communication to and from a communication network 320 via connection 321. The communication network 320 may be a WAN type network, such as the Internet, a cellular telecommunication network or a private WAN. 316 be a connection 321 is a When connection 321 is a traditional high speed connection (eg cable), the modem may be a broadband modem. A telephone line, the modem can "dial" modem. Alternatively, a wireless modem can also be used for wireless connection to the communication network 320.
The computer module 301 typically includes at least one processor unit 305 and one memory unit 306. The memory unit 306 may, for example, have a semiconductor RAM and a semiconductor ROM. The computer module 301 also includes a plurality of input / output interfaces 26 (I / O interfaces) including: an audio / video interface 307 which connects the video display 314, the speaker 317 and the microphone 380; an I / O interface 313 that connects to the keyboard 302, the mouse 303, the scanner 326, the camera 327 and the optional joystick or other device in the human interface (not illustrated) and an 316 and the printer 315. In implementations, the modem may be included in the computer module 301. for example, within interface 308 of the external modem certain interface 308. The computer module 301 also has a local network interface 311, which allows connection of the computer system 300 via a connection 323 to a LAN-type network 322. As illustrated in Figure 3A, the LAN network 322 may also be connected to the WAN network 320 via a connection 324, which would typically include a so-called firewall unit or unit with similar functionality. The local area network interface 311 may include an EthernetTM circuit board, a BluetoothTM wireless device, or an IEEE802.11 wireless device; a variety of other types of interfaces can also be applied to the interface 311.
The I / O interfaces 308 and 313 may offer either or both serial or parallel connection, the former typically being implemented according to the Universal Serial Bus (USB) standard and having corresponding USB connections (not shown). Storage devices 309 are provided and typically include a hard disk drive ( HDD) 310. Other storage devices such as a floppy disk drive and a magnetic tape drive (visa stick) may also be used. An optical disk drive 312 is typically provided to function as a non-volatile data source. Portable memory devices such as optical discs (such as CD-ROMs, DVDs, DiscTMs), USB-RAM, hard disk drives and floppy disks can be used as suitable data sources for the system 300.
Blu-ray Portable External Components 305 to 313 for computer module 301 typically communicate via interconnect bus 304 and in a manner that results in a conventional mode of operation for computer system 300 known to those skilled in the art. Processor 305 is connected to system bus 304 using connections 319, for example. Computers to which the described arrangements can be applied include IBM personal computers and compatible, Sun Sparc stations, Apple lvlacTM or similar computer systems.
The method for verifying authorization of a transaction as described above is implemented using the computer system 300 wherein the methods of Figures 1 and 2 may be implemented as one or more software application programs executable within the computer system 300. Preferably, the steps of the method for verifying an electronic transaction are performed 331 (see Figure 3B) in the software 333 executed within the computer system 300. The software instructions 331 may be formed as one or more code modules, each to perform one or more special tasks. The software may also be divided into two separate parts, in which the first part and the corresponding code modules perform the transaction verification methods and the second part and the corresponding code modules handle a user interface between the first part and the user.
The software can be stored in a computer readable medium, for example the sub-storage units described below. The software is stored in the computer system 300 from the computer readable medium and is then executed by the computer system 300. A computer readable medium having such software or computer program code stored on the computer readable medium is a computer program product. The use of the computer program product in the computer system 300 preferably gives rise to an advantageous device for verifying electronic transactions.
The software 333, is typically stored in the HDD 310 or the memory 306. The software is stored in the computer system 300 from a computer readable medium and is executed by the computer system. The software can thus be stored on an optically readable disk storage medium (eg CD-ROM) 325 which can be read by the optical disk drive 312 A computer readable medium having such software or computer software stored thereon constitutes a computer software product. The use of a computer software product in the computer system 300 preferably gives rise to a device for verifying electronic transactions.
In some cases, application programs 333 may be provided to users encoded on one or more CD-ROMs 325 and read via the corresponding drive unit 312, or alternatively read by the user of the network 320 or 322. Furthermore, the software 300 from storage medium may refer to any storage medium providing stored instructions loaded into the computer system. other computer readable medium. Computer readable and / or data to the computer system 300 for execution and / or processing. Examples of such storage media include floppy disks, magnetic tapes, CD-ROMs, DVDs, Blu-ray discs, hard disk drives, a ROM or integrated circuit, USB memory, magnetic-optical disk or a computer-readable card such as a PCMCIA card or the like, whether or not these devices are internal or external to the computer module 301. Examples of such computer readable transmission media which may assist in providing 28 software, application programs, instructions and / or data to the computer module 301 including radio or infrared transmission channel as well as a network connection to another computer or networked device, and the Internet or intranets including e-mail transmissions and information stored on web pages or the like.
The second part of the application program 333 and the above-mentioned code modules can also be executed to implement one or more graphical user interfaces (GUls) which are displayed or otherwise presented on the display 314. By manipulating the typical keyboard and mouse, one user of the computer system 300 and the application in a functionally customizable manner to provide control commands and / or input to the applications associated with said GUI. Other forms of functionally customizable user interfaces may also be implemented as an audio interface using voice prompts output through the speakers 317 and user voice commands input via the microphone 380. Figure 3B is a detailed schematic block diagram of the processor 304 and a "memory" 334. The memory 334 represents 309 and the semiconductor memory (306) which can be accessed via the computer module 301 in Fig. 3A.
When the computer module 301 is initially started, a power-onself test (POST) program / startup diagnostic test program 350 is executed. The POST program is typically stored in a ROM 349 of the semiconductor memory 306 of Figure 3A. A hardware device such as the ROM 349 as software. The POST program 350 evaluates hardware within the computer module 301 for storage software may also be termed as built-in to ensure adequate operation and typically examines the processor 305, memory 334 (309, 306) and a basic module for BIOS input / output system software. also usually stored in ROM 349 for proper operation. Near POST Program 350 BIOS 351 Hard Disk Drive 310 for Figure 3A. Activation of the hard disk drive 310 affects successfully run, the activator program loader program 352 located in the hard disk drive 310 to be executed via the processor 305. This loads an operating system 353 in the RAM 306 after which the operating system 353 begins operation. The operating system 353 is a system level application, executable by the processor 305, to perform various high level functions, including process management, memory management, device management, storage management, software application interface and generic user interface. The operating system 353 manages the memory 334 (309, 306) to ensure that each process or application running on the memory module 301 has sufficient memory in which it can be executed without colliding with memory allocated to another process. Furthermore, the different types of memory available in the system 300 of Figure 3 is used properly so that each process can be run efficiently. Accordingly, the detached memory 334 is not intended to illustrate how different memory segments are allocated (other than when expressed), but rather to provide an overall view of the memory that can be accessed by the computer system 300 and how one is used.
As shown in Figure 3B, the processor 305 includes a plurality of function modules including a controller 339, an arithmetic logic unit (ALU) 340, and a local or internal memory 348, sometimes referred to as cache memory. The cache 348 typically includes a plurality of memory registers 344-346 in a register section. One or more internal buses 341 functionally interconnect these functional modules. The processor 305 typically has one or more interfaces 342 for communicating with external devices via the system bus 304, using a connection 318. The memory 334 is connected to the bus 304 through a connection 319.
The application program 333 includes a sequence of instructions 331 that may include conditional branch or loop instructions. The program 333 may also include data 332 used in executing the program 333. The instructions 331 and data 332 are stored in the memory spaces 328, 329, 330 and 335, 336, 337, respectively. Depending on the relative size of the instructions 331 and the memory spaces 328-330, some instruction may be stored. in a single memory space as illustrated by the instruction shown in memory space 330. Alternatively, an instruction may be divided into a number of dividers each stored in separate memory functions, as illustrated by the memory segments shown in memory spaces 328 and 329.
Processor 305 is generally provided with a set of instructions executed therein.
The processor waits for subsequent input, to which the processor 305 responds by executing a set of instructions. Each input may be provided from one or more of a number of sources, including data generated by one or more output units 302, 303, data received from an external source over one of the networks 320, 302, data received from one of the storage units 306, 309 or data received from a storage medium 325 inserted into the corresponding reader 312, all illustrated in Figure 3A. The execution of a set of instructions may in some cases result in the output of data. The execution may also include storing data or variables in the memory 334.
The transaction verification devices shown use invariables 354 such as 355, 356, 357.
The transaction verification devices generate output variables 361 which are stored in the memory 334 are stored in the memory 334 in the associated memory spaces corresponding to the memory spaces 362, 363, 364. Intermediate variables 358 can be stored in the memory spaces 349, 360, 366 and 367.
Referring to the processor 305 of Figure 3B, registers 344, 345, 346, arithmetic logic unit (ALU) 340, and controller 339 work together to perform sequences of microoperations required to perform "retrieve, decode, and execute" cycles for each instruction in the instruction set set forth. each program comprises 333. Each retrieve, decode and execute cycle comprises: a) a retrieval operation, wherein instructions 331 are retrieved or read from a memory space 328,329, 330; b) a decoding operation in which the controller 339 determines which instructions have been retrieved and c) an execution operation in which the controller 339 and the ALU 340 execute the instruction.
Thereafter, an additional retrieval, decoding, and execution cycle for next instruction can be performed. Correspondingly, a stored cycle can be performed by which the control unit 339 stores or writes a value to a memory space 332.
Each step or subprocess of the processes of Figures 1 and 2 is associated with one or more segments of the program 333 and is performed by the register section 344,345, 347, the ALU 340 and the controller 339 of the processor 305 working together to perform retrieval, decoding and execution cycles for each instruction. in the instruction set for specified segments of the program 333.
The payer authentication procedure described above may also form part of a more extensive procedure involving an electronic signature for signing a contract or document, the authentication procedure being connected to or logically associated with a contract or other document and executed or adopted by a person with the intention of sign the document. The predetermined amount may, for example, (i) be part of a monetary performance associated with the contract, (ii) be a payment associated with the execution or filing of a contract or document, or (iii) be a fee charged individually to any, some or all parties to a contract from a (third party) service provider that acts as an independent authentication provider of electronic signatures. In each case, successful application of the procedure acts as a connected or associated process for authenticating each party's electronic signature in relation to the contract or document.
The generation of the charges (which add up to the predetermined amount) also acts as a system for dynamically generating one-time keys that must be provided by the cardholder in response to a call from the verification agent to authenticate this specific transaction. To access the value of those dynamic keys, the cardholder typically needs to access their existing internet or telephone banking system to look up and reload the value of the keys.
The methods and systems described above can be advantageously practiced on a per-transaction basis. Unlike other existing systems, pre-registration of users (eg customers or buyers) is not necessary, which significantly increases user-friendliness. Furthermore, financial instruments and / or details do not need to be temporarily stored, which further contributes to security.
The embodiments described above include debiting as opposed to crediting a financial instrument. This is advantageous in that financial instruments such as credit and debit cards are essentially debited instantly. Crediting of such financial instruments, on the other hand, usually involves longer time frames due to approval checks, etc., and is thus much slower and not as flexible or simple. According to the embodiments described above, verification benefit can be provided substantially immediately upon receipt of a request from a user or buyer.
The embodiments described above include actual payment transactions to merchants regarding goods or services instead of initial, fictitious pre-authorization transactions. Such fictitious transactions may affect a buyer's desire to retrieve the merchant and close a transaction and may also be restrictive in countering fraud. For example, a financial instrument may be pre-authorized through the use of a fictitious transaction, subsequently lost or stolen, may still act as authorized for use until it is withdrawn by the financial institution in question. The period between loss and withdrawal is typically the period during which fraud occurs, which makes pre-authorization less attractive than if it had not been invoked.
The embodiments described above preferably use data or information regarding or included within the transactions to verify the authenticity of the pre-transaction. This data or information is known only to the authorized holder of the relevant financial instrument and the financial institution of the holder of the financial instrument.
In some embodiments, the methods and systems described herein may be implemented after a set of risk criteria has been identified, regardless of whether the method or system has previously been implemented for a particular financial risk criterion payment portal. Such criteria may, for example, include: the product (s) instruments. may, for example, be determined by the merchant and / or the service (s) purchased as part of a transaction identified as a high-risk transaction, the purchased product (s) or service / services exceeding a monetary threshold, the buyer's request originating from an IP address outside the range normally associated with the financial instrument or from a financial instrument that has been used to make a recent high-frequency purchase, or otherwise. Some advantages of one or more of the embodiments described above include: i) Full information regarding the financial instrument (t. ex credit card number and / or buyer information) does not need to be transferred to the verification agent, as the verification agent verifies each unique transaction on a case-by-case basis (ie the transaction is assigned a unique identifier that does not necessarily correspond to the financial instrument, payment portal or merchant).
Knowledge of data linked to the financial instrument is not necessary to perform the verification. 33 ii) The verification agent is not susceptible to loss of sensitive data in case of intrusion, as complete data regarding financial instrument and / or user details are not stored by the verification agent. iii) In some embodiments, the transfer of funds from the buyer's financial instrument to the merchant is initiated immediately and verification of the authorization can be performed immediately or shortly after the transfer of funds is requested. (iv) In certain embodiments where the verification takes place via a financial institution or card system network using a verification agent, the merchant receives authorization for the transaction that has been the subject of the verification from the payment portal. The verification agent is thus transparent to the trader while the existing procedure continues to be used. Initiation of clearing funds and transfer of the financial institutions can be postponed to such a time that the buyer's authorization is complete, thereby providing benefits to the financial institution. This also has the advantage of minimal, if any, changes in the communication between the merchant and the payment portal for the purpose of processing the transactions. v) The buyer does not have to complete, prior to an actual transaction, an initiation procedure or other process not directly associated with the purchase. vi) Depending on the chosen implementation, the merchant does not need to supplement any intermediate or third party registration / account creation, or manage any financial institution, payment portal and / or card system network other than those already managed. vii) Verification of the authorization can be performed on a case-by-case basis including and up to the case for each transaction. viii) Where a card or other financial instrument operates in a currency that differs from the currency used by the trader, there is no need to know the exchange rate between the currency of the financial instrument and the trader's currency. ix) The sum of the individual amounts charged to the financial instrument designated by the buyer amounts to the total amount of the transaction in question initiated by the buyer without the need for additional separate transactions to provide credit or debit balancing. xii) Xiu) 34 Confirmation of most charges and random amounts charged (where the sum corresponds to the predetermined amount) provides a high level of confidence with regard to fraud.
Devices, electronically routable addresses or electronic files used or provided as part of the verification process can also be linked to the successful buyer authentication and used to identify the buyer subsequent applications or link each combination of real world customer names, customer identification, device serial numbers, electronically routable addresses, files, financial instruments and transactions.
Devices, electronically routable addresses, serial numbers, MAC addresses, IMEI numbers, etc. can be captured for later use as evidence in recovery situations on a transactional basis and can also optionally be linked to the payer for future reference.
Unlike pre-assigned static PlN codes logically associated with a 3D SecureW 'SecureCodeTM, the generation of said plurality of charges acts as a financial instrument such as Visa or MasterCard, dynamically generated code associated with only one specific transaction. This is advantageous because a static PlN is not stored centrally, with such a static PlN subject to hacking and unauthorized use, and thanks to the majority of debits acting as one-time codes, each transaction has its own unique authorization characteristics. This achievement security is several times more difficult to crack with hacking methods than hacking a conventional PlN. It also does not suffer from the security issues associated with storing card data along with the PlN server system and the catastrophic consequences of using card numbers and PlNs by unauthorized parties. xiv) The time adjustment and the optional IP address of the customer who accesses said plurality of debits via their existing internet banks can be stored by the financial institutions and compared with the time adjustment and optionally the IP address in the verification agent's response, provides further proof of cardholder authorization.
INDUSTRIAL APPLICABILITY The described devices are applicable to computer and data processing industries and in particular for processing and verifying electronic transactions. The foregoing description provides exemplary embodiments only and is not intended to limit the scope, applicability, or configurations of the present invention. Rather, the description of the exemplary embodiments will provide those skilled in the art with a description by which embodiments of the invention may be implemented. Various changes can the function of elements without deviating from be made in and the arrangement the inventive concept or scope as presented in the claims below.
In cases where specific features, elements and steps referred to herein have known equivalents within the scope of the invention, such known equivalents are considered to be included herein in the same manner as if they had been highlighted individually. Furthermore, features, elements and steps which refer to or are described in relation to a certain embodiment of the invention may form part of any other embodiment unless the opposite is stated.

权利要求:
Claims (19)
[1]
A computer-implemented method, performed in a transaction verification system, for verifying a transaction originator's authority to authorize an electronic transaction in respect of a financial instrument, said method comprising the steps of: receiving, via a first user interface, a request to process an electronic transaction for a predetermined amount; said request comprising data identifying a particular financial instrument; generating, in a processor in the transaction verification system, a plurality of verification transactions with respect to the financial instrument, the predetermined amount being divided into a plurality of debits in such a way that the number of plotted multiple debits and / or the amount of each of said plurality debits is determined at random; storing, in a memory in the transaction verification system, information such as said associate plurality of verification transactions with the electronic transaction and the transaction originator; influence, via a second interface, said financial instrument to be debited with each of said plurality of debits; receiving, via the first user interface or a third user interface, information regarding said plurality of charges from the transaction originator; and verifying the transaction originator's authority to authorize said electronic transaction when said received information regarding said plurality of charges matches said stored information.
[2]
The computer-implemented method of claim 1, wherein the sum of said plurality of charges corresponds to said predetermined amount.
[3]
The computer-implemented method of claim 1, wherein said plurality of charges comprises two charges.
[4]
A computer-implemented method according to any one of the preceding claims, wherein said financial instrument comprises a credit card. 37
[5]
A computer-implemented method according to any one of the preceding claims, wherein said financial instrument comprises one of the group of financial instruments comprising: a credit card; a bank card; a debit card; a store card; a direct debit facility and a bank account.
[6]
A computer-implemented method according to any one of the preceding claims, wherein said received and stored information comprises the amount of each of said plurality of charges.
[7]
A computer-implemented method according to any one of the preceding claims, wherein said received and stored information comprises the number of said plurality of charges.
[8]
A computer-implemented method according to any one of the preceding claims, wherein said received information comprises a plurality of values each modified by a single currency exchange rate and said method further comprising the steps of: converting, by said processor in the transaction verification system, each of said plurality of debits to a respective debiting ratio by dividing each of said plurality of debits by the predetermined amount; storing, in said memory in the transaction verification system, each of said debiting ratios; converting each of said received plurality of values to a corresponding value ratio by dividing each of said plurality of values by the sum of said plurality of values; comparing, by means of said processor in the transaction verification system, each of said value ratios to said stored value ratios; and verifying said transaction if each of said value ratios matches a corresponding stored value ratio within a predefined margin of error. 38
[9]
A computer-implemented method according to any one of the preceding claims, wherein the respective amounts of said plurality of charges correspond to the value of the respective one-time keys, which must be provided by the transaction originator to the transaction verification system to authenticate the transaction.
[10]
Computer system for verifying authorization of transactions, said computer system comprising: a memory for storing data and program instructions and at least one processor connected to said memory, said at least one processor programmed to: receive a request to process an electronic transaction for a predetermined amount, said request generating data identifying a particular financial instrument; generating a plurality of verification transactions with respect to the financial one plurality of debits such that the number of said plurality of debits and / or the amount of the instrument, the predetermined amount being divided for each of said plurality of debits being determined at random; influence said financial instruments to be debited with each of said plurality of debits; receiving information regarding said plurality of charges from the transaction originator; comparing, in the processor, received information regarding said plurality of debits with information stored in said memory associating said plurality of verification transactions with the electronic transaction and the transaction originator; and verifying the transaction originator's authority to authorize said electronic transaction when said received information regarding said plurality of charges matches said stored information.
[11]
The computer system of claim 10, wherein the sum of the plurality of said plurality of charges corresponds to said predetermined amount.
[12]
The computer system of claim 10 or 11, wherein said plurality of charges comprises two charges.
[13]
13.
[14]
14.
[15]
15.
[16]
16.
[17]
A computer system according to any one of claims 10-12, wherein said financial instrument comprises a credit card. A computer system according to any one of claims 10-13, wherein said financial instrument comprises one of the group of financial instruments consisting of: a credit card; a bank card; a debit card; a store card; a direct debit facility and a bank account. Computer system according to any one of claims 10-14, wherein said at least one processor is programmed to confirm the amount of each of said plurality of charges. Computer system according to any one of claims 10-15, wherein said at least one processor is programmed to confirm the number of said plurality of charges. Computer systems according to any one of claims 10-16, wherein said received information comprises a plurality of values each modified by a single currency exchange rate and said at least one processor is further programmed to: convert each of said plurality of debits to a respective debiting ratio by dividing each of said debits with the predetermined amount; storing each of said charging conditions; converting each of said received plurality of values to a corresponding value ratio by dividing each of said plurality of values by the sum of said plurality of values: comparing each of said value ratios with said stored value ratios and verifying said transaction of each of said value ratios corresponds to a respective stored value ratio within a predefined margin of error.
[18]
A computer system according to any one of claims 10-17, wherein the respective amounts of said plurality of charges correspond to the value of the respective one-time keys, which must be provided by the transaction originator to the transaction verification system to authenticate the transaction.
[19]
A computer program product comprising a computer readable medium comprising a computer program stored thereon for verifying authorization of a transaction, said computer program product comprising: computer program code means for receiving a request to process an electronic transaction for a predetermined amount, said requesting instrument including data; computer program code means for generating a plurality of voucher transactions with respect to the financial instrument, the predetermined amount being divided into a plurality of debits such that the number of said plurality of debits and / or the amount of each of said plurality of debits is determined at random; computer program code means for storing information associating the plurality of verification transactions with the electronic transaction and the transaction originator; computer program code means for influencing said financial instruments are debited with each of said plurality of debits; computer program code means for receiving information regarding the plurality of debits from the transaction originator; and computer program code means for verifying the transaction originator's authority to authorize said electronic transaction when said received information regarding said plurality of charges corresponds to said stored information.

类似技术:

---

公开号 | 公开日 | 专利标题

---

SE539328C2|2017-07-04|Methods and systems for verifying transactions

---

US20190287104A1|2019-09-19|Adaptive authentication options

---

US10242363B2|2019-03-26|Systems and methods for performing payment card transactions using a wearable computing device

---

JP5575935B2|2014-08-20|System and method for validating financial instruments

---

US20130018793A1|2013-01-17|Methods and systems for payments assurance

---

US20080077526A1|2008-03-27|Online payer authorization systems and methods

---

JP2011508924A|2011-03-17|Approve credit and debit card transactions using location verification

---

JP2013157036A|2013-08-15|Methods and systems for enhancing consumer payment

---

EP3055819A1|2016-08-17|Broker-mediated payment systems and methods

---

US20170357965A1|2017-12-14|System and method for token based payments

---

US20140365368A1|2014-12-11|Systems and methods for blocking closed account transactions

---

WO2009140731A1|2009-11-26|A system and method for facilitating a payment transaction

---

US20180047021A1|2018-02-15|System and method for token-based transactions

---

ES2765005T3|2020-06-05|Transaction verification procedures and systems

---

BR112012024646B1|2022-02-08|METHOD IMPLEMENTED BY COMPUTER TO VERIFY AUTHORIZATION OF AN ELECTRONIC TRANSACTION.

---

US20130132281A1|2013-05-23|Computer-implemented method for capturing data using provided instructions

同族专利:

---

公开号 | 公开日

---

AU2010100533A4|2010-06-24|

---

EP3651096A1|2020-05-13|

---

KR20160070842A|2016-06-20|

---

US20150193772A1|2015-07-09|

---

NZ601718A|2015-02-27|

---

PL2553642T3|2020-04-30|

---

AU2016238964A1|2016-12-08|

---

EP2553642A1|2013-02-06|

---

AU2011235612A1|2012-04-26|

---

CN102812480A|2012-12-05|

---

US20160148205A1|2016-05-26|

---

PT2011120098W|2013-01-16|

---

CA2791752A1|2011-10-06|

---

KR20130064046A|2013-06-17|

---

CA2791752C|2019-04-23|

---

EP2553642A4|2016-10-05|

---

BR112012024646A2|2016-06-07|

---

AU2010100533B4|2010-12-16|

---

US20140222677A1|2014-08-07|

---

KR101947629B1|2019-02-13|

---

AU2012261779A1|2013-01-10|

---

US8620810B2|2013-12-31|

---

AU2011235612B2|2012-09-20|

---

AU2012261779B2|2016-07-07|

---

CN102812480B|2018-05-04|

---

SE1251231A1|2012-10-31|

---

SG183509A1|2012-10-30|

---

ZA201206455B|2014-06-25|

---

US20120323791A1|2012-12-20|

---

EP2553642B1|2019-10-30|

---

WO2011120098A1|2011-10-06|

引用文献:

---

公开号 | 申请日 | 公开日 | 申请人 | 专利标题

---

---

US7096192B1|1997-07-28|2006-08-22|Cybersource Corporation|Method and system for detecting fraud in a credit card transaction over a computer network|

---

JP2002537619A|1999-02-18|2002-11-05|オービス・パテンツ・リミテッド|Credit card system and method|

---

US7908214B2|1999-11-05|2011-03-15|American Express Travel Related Services Company, Inc.|Systems and methods for adjusting loan amounts to facilitate transactions|

---

KR101015341B1|2000-04-24|2011-02-16|비자 인터내셔날 써비스 어쏘시에이션|Online payer authentication service|

---

EP1356438B1|2000-07-10|2014-06-18|PayPal, Inc.|System and method for verifying a financial instrument|

---

US20020103753A1|2001-01-31|2002-08-01|Michael Schimmel|Charge splitter application|

---

US20020184500A1|2001-05-29|2002-12-05|Michael Maritzen|System and method for secure entry and authentication of consumer-centric information|

---

WO2003017049A2|2001-08-15|2003-02-27|Shea Writer|Methods for verifying cardholder authenticity and for creating billing address database|

---

US6640294B2|2001-12-27|2003-10-28|Storage Technology Corporation|Data integrity check method using cumulative hash function|

---

US7437328B2|2003-11-14|2008-10-14|E2Interactive, Inc.|Value insertion using bill pay card preassociated with biller|

---

US20060036538A1|2004-08-12|2006-02-16|Wanda Griffis|Systems and methods for improved merchant processing|

---

US8249961B1|2008-03-19|2012-08-21|United States Automobile Association|Systems and methods for managing consolidated purchasing, billing and payment information|

---

DE102010041054A1|2010-04-01|2011-10-06|Schunk Gmbh & Co. Kg Spann- Und Greiftechnik|Centering device for centering a chuck on a rotating spindle and associated locking device|US10430873B2|2009-03-02|2019-10-01|Kabbage, Inc.|Method and apparatus to evaluate and provide funds in online environments|

---

JPWO2011148875A1|2010-05-25|2013-07-25|日本電気株式会社|Multi-payment realization method, multi-payment realization apparatus and multi-payment realization program using a plurality of payment means|

---

WO2012018569A1|2010-07-26|2012-02-09|Nyse Group, Inc.|Apparatuses, methods and systems for a dynamic transaction management and clearing engine|

---

US9037637B2|2011-02-15|2015-05-19|J.D. Power And Associates|Dual blind method and system for attributing activity to a user|

---

US20140019341A1|2012-04-10|2014-01-16|Kabbage, Inc.|Method, apparatus and computer readable storage to effectuate an instantaneous monetary transfer|

---

US20130304555A1|2012-05-14|2013-11-14|Mastercard International Incorporated|Method and system for applying coupon rules to a financial transaction|

---

US10255632B2|2012-07-02|2019-04-09|Kabbage, Inc.|Method and apparatus to evaluate and provide funds in online environments|

---

AU2013206800A1|2013-07-11|2015-01-29|Kogan.Com Holdings Pty Ltd|Method and Apparatus for Preventing Fraudulent Transactions Online|

---

US9582792B2|2013-07-29|2017-02-28|Exxonmobil Research And Engineering Company|System and method to purchase and dispense fuel and other products using a mobile device with improved user experience|

---

CA2972104A1|2014-12-24|2016-06-30|Isignthis Ltd|Securing a transaction|

---

US9953324B2|2015-03-19|2018-04-24|International Business Machines Corporation|Multi-point authentication for payment transactions|

---

US20160275507A1|2015-03-19|2016-09-22|International Business Machines Corporation|Multi-point authentication for payment transactions|

---

US9892396B2|2015-03-19|2018-02-13|International Business Machines Corporation|Multi-point authentication for payment transactions|

---

US20160335621A1|2015-05-12|2016-11-17|Gopesh Kumar|Method for Providing Secured Card Transactions During Card Not PresentTransactions|

---

US9870562B2|2015-05-21|2018-01-16|Mastercard International Incorporated|Method and system for integration of market exchange and issuer processing for blockchain-based transactions|

---

EP3335172A1|2015-08-14|2018-06-20|Mastercard International Incorporated|Managing customer uniqueness in tokenised transaction systems|

---

EP3131043A1|2015-08-14|2017-02-15|Mastercard International Incorporated|Managing customer uniqueness in tokenised transaction systems|

---

US20170083917A1|2015-09-21|2017-03-23|EZIC Inc.|System and method for authorizing transactions|

---

WO2017070638A1|2015-10-23|2017-04-27|Xivix Holdings Llc|System and method for authentication using a mobile device|

---

EP3542331A4|2016-11-21|2020-07-01|ISX IP Ltd|"identifying an entity"|

---

WO2019042511A1|2017-08-29|2019-03-07|Venture Capitals Aps|Method, system and computer implemented evaluation of electronic transactions|

---

CN108846650A|2018-05-24|2018-11-20|北京比特大陆科技有限公司|A kind of method and apparatus for realizing Transaction Information verifying|

---

CN108764867A|2018-05-24|2018-11-06|北京比特大陆科技有限公司|A kind of method and apparatus for realizing Transaction Information verification|

---

CN108764921A|2018-05-24|2018-11-06|北京比特大陆科技有限公司|A kind of method and apparatus for realizing Transaction Information verification|

---

CN108764869A|2018-05-28|2018-11-06|北京比特大陆科技有限公司|A kind of encrypted method and apparatus of realization Transaction Information|

---

US11200572B2|2019-02-27|2021-12-14|Mastercard International Incorporated|Encoding one-time passwords as audio transmissions including security artifacts|

法律状态:

优先权:

---

申请号 | 申请日 | 专利标题

---

US32059710P| true| 2010-04-02|2010-04-02|

---

US34974110P| true| 2010-05-28|2010-05-28|

---

AU2010100533A|AU2010100533B4|2010-04-02|2010-05-28|Method and system for verifying transactions|

---

PCT/AU2011/000377|WO2011120098A1|2010-04-02|2011-03-31|Methods and systems for verifying transactions|

---