WO2000057374A1 - System and method for pre-authorization of individual account remote transactions - Google Patents
System and method for pre-authorization of individual account remote transactions Download PDFInfo
- Publication number
- WO2000057374A1 WO2000057374A1 PCT/US2000/007975 US0007975W WO0057374A1 WO 2000057374 A1 WO2000057374 A1 WO 2000057374A1 US 0007975 W US0007975 W US 0007975W WO 0057374 A1 WO0057374 A1 WO 0057374A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- authorization
- account
- transaction
- transactions
- parameter
- Prior art date
Links
Classifications
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
- G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/04—Payment circuits
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/403—Solvency checks
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/403—Solvency checks
- G06Q20/4037—Remote solvency checks
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/02—Banking, e.g. interest calculation or account maintenance
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/03—Credit; Loans; Processing thereof
Definitions
- the present invention relates to electronic authorization of financial transactions, and in particular, to electronic authorization of specific predetermined transactions. More particularly, the present invention relates to specific authorization of individual transactions otherwise inhibited or prohibited.
- Figure 1 represents a standardized authorization process for transaction verification.
- An account manager such as a fleet manager or other entity, desiring cashless transaction privileges contacts a card issuer 1 14 to request the extension of transaction privileges through an established account request 1 16.
- card issuer 1 14 places restrictions such as transaction amount limitations upon the card user.
- account manager 102 may request that card issuer 1 14 deny certain transactions and strictly enforce other limitations on transactions.
- Exemplary desired account limitations include restrictions on the types of services and goods that may be procured by an account user 104 as directed by account manager 102.
- Industry standards have been established for the partitioning of goods and services into categories designated by a standard industrial code (SIC).
- SIC standard industrial code
- a merchant 106 is assigned a specific standard industrial code corresponding to their predominate business function.
- transactions originating at a point of sale terminal having a restricted SIC identifier may be unable to obtain proper authorization to complete a transaction with an account user.
- Other limitations frequently desired by account managers include transactional limits. Transactional limits may include single transaction limits or aggregate limitations upon successive transactions.
- Card issuer 1 14 upon the establishment of an account may employ a third party authorizing agent to provide authorization services and strictly enforce transaction limitations as agreed upon between account manager 102 and card issuer 1 14.
- Card issuer 1 14 through an establish authorization request 1 18 informs authorizing agent 1 12 of the transaction terms under which transaction authorization may be granted.
- account manager 102 provides the account information necessary to enable account user 104 to engage in commerce transactions.
- Such account information generally includes an account number as assigned by card issuer 1 14.
- the predominate form of providing account information to account user 104 is to provide account user 104 with a transaction card generally taking the form of a credit card-like card bearing the account number thereon.
- Account user 104 upon initiating a transaction with a merchant 106 engages in a payment presentment step 120 by providing the requisite account information to merchant 106.
- Merchant 106 engages in an authorization process to verify that the transaction parameters of the present transaction are within the boundaries or limitations placed upon the account as requested by account manager 102 or imposed by card issuer 1 14.
- An authorization request 122 issued by merchant 106 is comprised of an account number, a transaction amount and other parameters such as a standard industrial code (SIC), a merchant identifier (MID) and an acquiring bank identification number (BIN).
- SIC standard industrial code
- MID merchant identifier
- BIN acquiring bank identification number
- a merchant 106 typically associates with an acquiring bank 108 which provides funding services of merchant transactions.
- Authorization requests may electronically pass through acquiring bank 108 as designated by the BIN of the authorization request and additionally may route through a card company 1 10 (e.g., MasterCard®, VISA®, Discover Card® or American Express®) prior to reaching authorizing agent 1 12 for comparison of account parameters.
- a card company 1 10 e.g., MasterCard®, VISA®, Discover Card® or American Express®
- Authorizing agent 1 12 compares the transaction parameters for conformance with account limitations.
- Authorizing agent 1 12 issues an authorization response 124 comprising an acceptance or denial indicator.
- funds generally do not transfer at that time.
- a settlement generally occurs at a periodic time such as evenings or nights when a merchant re-initiates communication with an authorizing agent and presents a series of accepted and authorized transactions occurring throughout the previous period and requests financial settlement of such transactions.
- Merchant 106 initiates a settlement request 126 with authorizing agent 1 12 which generally comprises the account number to be debited, the amount of the debit and other information such as SIC, MID and BIN designators.
- authorizing agent 1 12 issues a settlement request 128 to card issuer 1 14.
- a settlement request 128 includes less cryptic merchant information (i.e. , merchant name and city/state address instead of MID) for later presentment to an account manager.
- Card issuer 1 14 in a payment settlement response step 130 passes payment information on to merchant's acquiring bank 108 with the appropriate funds transferring in a step 131.
- card issuer 1 14 provides a billing account 132 to account manager 102 for notification of payment due or for other record keeping purposes.
- billing account information may be presented in various forms including printed statements as well as electronic reporting.
- billing account information contains relatively little and non-descriptive information such as an account number, a transaction amount and merchant information.
- authorization performed by authorizing agent 1 12 provides a regulation of transactions by either proscribing transactions originating at a merchant having a proscribed SIC goods/services designator, or withholding authorization from transactions that exceed transactional limits. Such an authorization process approves transactions of values less than the transactional limits transpiring at non-proscribed merchant point of sale terminals having a non-barred SIC goods/services designator.
- Prior art authorization techniques do not provide a method or system for enforcing strict transaction parameters prior to authorization of restricted transaction types on a transaction by transaction basis. Additionally, prior art techniques do not permit an account manager to create transaction authorization parameters without reinitiating account establishment procedures.
- a second shortcoming of the authorization processing in the prior art relates to billing account information sent from card issuer 1 14 for evaluation by account manger 102.
- the billing account information is comprised of an account number and an amount coupled to merchant information such as the name and city of the merchant.
- An account manager does not have a tracking mechanism to track the execution of a specific transaction and the billing of such a transaction on a billing statement if the vendor and acquiring bank cannot provide this functionality.
- the account manager only discerns that a certain amount of money, a transaction amount, was exchanged with a specific merchant.
- a third short coming of the authorization processing in the prior art relates to the inability to prevent fraudulent successive transactions using the account number of an account user once it has been divulged to a merchant.
- transactions are performed remotely from the physical presence of the account user thereby foreclosing the account user from discretionary evaluation of the credibility of the merchant with which an account user's account number would be divulged.
- the rogue merchant would be free to utilize the account number in successive authorization requests and alternatively could resell or post an account user's account number for indiscriminate use by other devious entities.
- an account processing method and system for facilitating the general denial of all or specific categories of transactions unless they are specifically pre-authorized with specified parameters and the parameters of the requested transaction conform to those pre-authorized parameters is provided. Additionally, the present invention provides a system and method for the pre-authorization of specific transactions to be performed by an account manager via a service provided by an account issuer to their customers such as account managers and users.
- a further advancement of the present invention provides a method and system for allowing an account manager to define a transaction identifier (e.g., insurance claim number, purchase order number, work order number, etc.) and attach the transaction identifier through a pre-authorization of a transaction.
- a transaction identifier e.g., insurance claim number, purchase order number, work order number, etc.
- the transaction identifier is included with the generic billing information (e.g., transaction amount, merchant information, etc.) thus allowing an account manager to reconcile their accounting from a billing account information containing the transaction having the transaction identifier associated thereto with a pre-transaction assignment of a traditional identifier such as purchase order number, work order number, or insurance claim number.
- the above described system and method includes an account establishment phase of an account process wherein an account manager approaches a card issuer to establish an account in an establish account step.
- limitations on transactions relating to that account are negotiated between the account manager and card issuer.
- Transaction limitations generally include items such as transaction limits, account balance limit, limitations on categories of goods or services as denoted by standard industrial codes (SIC) and other parameters that may be incorporated into a specific accounting scheme.
- SIC standard industrial codes
- a system and method is described wherein a consumer-to-business transaction environment, the account user personally initiates the account establishment phase with the card issuer.
- a card issuer employs the services of an authorizing agent for performing account authorization upon the initiation of a transaction request from a merchant.
- the card issuer in an establish authorization step, forwards various parameters such as SIC limits that wholly bar categories of transactions, transaction limits relating to non-pre-authorization transactions and pre-authorization SICs designating categories of goods or services requiring specific authorization in conformance with pre-authorization parameters subsequently dispatched to the designated authorizing agent in a pre-authorization process.
- an account manager may perform pre-authorization of transactions with the card issuer directly.
- an account manager using a communication device such as a personal computer may routinely generate pre- authorization requests by transferring pre-authorization parameters to the card issuer via communication channel such as the INTERNET.
- the account user may personally perform the transaction pre-authorization directly with the card issuer.
- the account user may pre-authorize the transaction by employing a network such as the INTERNET which enables the account user to interface with the card issuer through a card issuer's interactive interface such a web page.
- a typical scenario wherein the present invention is practiced provides for a pre-authorization transaction phase that commences with a request by an account user for a specified good or service that requires pre-authorization prior to initiating the transaction.
- the account user consults with the account manager for requesting restricted goods or services.
- the account manager in turn contacts the merchant for negotiating or obtaining a price quotation for the requested goods or services, or optionally, the account manager arrives at a quotation amount by consulting other traditional pricing sources such as directories or catalogs.
- the account manager issues a pre-authorization request to the card issuer via a personal computer.
- the account manager in the pre-authorization request specifies an account number for which pre-authorization transaction parameters apply.
- one or more transaction parameters including a quote amount resulting from the quotation process, an acceptable variance or deviation range from the quotation amount, a merchant identifier (MID) or an acquiring bank identification number (BIN) are dispatched to the card issuer.
- MID merchant identifier
- BIN acquiring bank identification number
- the card issuer relays the pre-authorization parameters to the authorizing agent for storage and usage during authorization processing.
- the account user assumes the role of the account manager by both seeking out the goods or services to be procured and additionally by pre- authorizing or approving a future transaction that undergoes a merchant authorization request.
- Another aspect of the present invention includes the ability to input or provide a transaction identifier for association with an authorized completed transaction.
- the transaction identifier in the preferred embodiment, provides an alpha-numeric field wherein an identifier may be specified and associated with a pre-authorized transaction and upon the initiation and authorization of the requested transaction, the transaction identifier is reported in the billing account information.
- Such a transaction identifier enables an account manager to associate a pre-authorization of a transaction with a transaction reported in a billing account thereby allowing reconciliation of accounting entries.
- the pre-authorization parameter record remains within the authorizing agent until a matching transaction is initiated by an account user.
- a merchant initiates an authorization request for approval.
- the authorization request takes the form of presentment of a transaction card or other credit card-like credentials bearing an account number as previously assigned for use by the account user.
- An account user or account manager may present the account number to the merchant using means other than a transaction card such as the presentment, verbal disclosure, electronic disclosure or written disclosure of an account number to the merchant.
- the merchant forwards the account number, the transaction amount, and alternatively other information such as the merchant's SIC denoting its category of goods or services, the merchant's MID and the acquiring BIN associated with the merchant.
- the authorizing agent performs the authorization process which includes consulting the pre-authorization table when the merchant SIC presented in the authorization request corresponds to a pre- authorization SIC presented during the establishment of the account.
- the authorizing agent issues an authorization response listing the acceptance or denial status resulting from the authorization process.
- the merchant forwards the account numbers, the transaction amounts and other pertinent and related information such as the merchant's SIC and city location relating to each of the authorized transactions for the day.
- the authorizing agent additionally forwards the transaction identifier as received in the pre-authorization request.
- the billing account issued by the account issuer to the account manager the billing account includes details of the account number, the transaction amount, merchant information and when present the transaction identifier.
- a networked consumer user-to-merchant environment such as in an electronic commerce environment
- the individual pre-authorization of each transaction by a user prior to the actual payment presentment activity minimizes the fraudulent use of an account user's account number when divulged during a payment presentment step.
- Such misuse is curbed due to the fact that any subsequent authorization requests by a merchant or unauthorized user would be denied since the account user would not have individually pre-authorized each and every transaction attempted by the user rogue merchant thereby denying subsequent debits against the account user's account.
- FIG. 1 is a flow diagram of an authorization process, in accordance with the prior art
- Figure 2 is a flow diagram of a pre-authorization process, in accordance with a preferred embodiment of the present invention.
- FIG. 3 is a block diagram of an authorization table including both standard and pre-authorization tables as stored within an authorizing agent, in accordance with a preferred embodiment of the present invention
- Figure 4 is a flow chart of a transaction authorization procedure in a pre- authorization-capable authorizing agent, in accordance with an embodiment of the present invention
- Figure 5 is a representative billing statement containing a transaction identifier as associated with a pre-authorized transaction and subsequently forwarded to an account manager upon completion of a pre-authorized transaction, in accordance with an embodiment of the present invention
- Figure 6 is a flow diagram illustrating account processing which employs pre-authorization of select transactions without requiring an account user to i perform a payment presentation step, in accordance with an embodiment of the
- Figure 7 is a simplified transaction diagram for use in a wide-area
- Figure 8 is a flow diagram of a pre-authorization process for use in a wide-
- Figure 9 is a block diagram of an authorization table including both 10 standard and pre-authorization tables as stored within an authorizing agent, in ⁇ accordance with a preferred network embodiment of the present invention.
- account manager refers to an individual or organization charged with establishing and monitoring an account.
- An account manager may be in charge of many accounts and take the form of fleet managers, accounting managers, claims adjusters and also prudent account users.
- account user refers to an individual, consumer or organization seeking goods or services and may also take the form of fleet users, business personnel and insured parties. It should be noted that an account manager and an account user may be the same party.
- the term "merchant” refers to an individual or organization providing goods or services in exchange for a fee. Merchants generally facilitate the reimbursement transaction by providing a point-of-sale terminal or other device through which a transaction is initiated including a computer network interface for interacting over a network such as a LAN or WAN including the Internet.
- acquiring bank refers to a financial institution providing financial services for an associated merchant.
- An acquiring bank is generally a bank or like organization at which a merchant maintains an account for reconciliation of funds.
- bank card association refers to a sponsoring organization that provides financial services and brings organization and infrastructure into the account processing.
- the term "authorizing agent” refers to an organization which may be part of a card company and provides assurances to a merchant of the good standing of the account in question and conformity of the requested transaction to limitations and parameters placed upon a transaction.
- the term "account or card issuer” refers to an- organization providing administrative services to an account user or account manager. Account issuer may also provide augmented services to an account user or manager such as access to an authorizing agent for account establishment and other functions such as pre-authorization.
- authorization web page refers to a computer network-accessible intermediary interface into which a web account user (consumer) may place parametric transaction authorization information that is forwarded to an authorizing agent for use in evaluating the legitimacy of a specific transaction.
- Figure 1 is a flow diagram of an authorization process in accordance with the prior art.
- FIG. 2 is a flow diagram of account processing incorporating pre- authorization of individual transactions or transaction types, in accordance with a preferred embodiment of the present invention.
- account processing has become increasingly prevalent and sophisticated, the complexities of account processing have also increased. For example, in the establishment and processing of an account, additional specified participants are incorporated into the processing flow.
- an account manager 202 approaches a card issuer 214 to establish an account as represented in Figure 2 by establish account step 216.
- limitations on transactions relating to that account are negotiated between account manager 202 and card issuer 214.
- Transaction limitations generally include items such as transaction limits, account balance limit, limitations on categories of goods or services as denoted by standard industrial codes (SIC) and other parameters that may be incorporated into a specific account scheme.
- SIC standard industrial codes
- transactions involving certain categories of goods or services as denoted by pre-authorization SICs denote goods or services that require individual parametric constraints upon such transactions.
- account manager 202 may establish an account for use by an account user 204 for performing maintenance upon a fleet vehicle.
- account manager 202 designates the SIC associated with maintenance as a pre-authorization SIC requiring conformity to transaction parameters subsequently defined by account manager 202.
- Card issuer 214 employs the services of an authorizing agent 212 for performing account authorization upon the initiation of a transaction request from a merchant.
- Card issuer 214 in establish authorization step 218 forwards SIC limits controlling categories of transactions, transaction limits relating to non-pre- authorization transactions and pre-authorization SICs designating categories of goods or services requiring specific authorization according to pre-authorization parameters subsequently dispatched to authorizing agent 212.
- account manager 202 may perform pre-authorization of transactions with card issuer 214 directly.
- account manager 202 using a personal computer may routinely generate pre-authorization requests by transferring pre-authorization parameters to card issuer 214 via the INTERNET.
- a pre-authorization transaction phase commences with a request 220 by an account user 204 for a specified good or service that requires pre-authorization prior to initiating the transaction.
- Account user 204 consults with account manager 202 to obtain restricted goods or services.
- Account manager 202 in turn contacts a merchant 206 for negotiating or obtaining a price quotation 222, including a quote amount for the requested goods or services.
- account manager 202 may consult a price quotation directory or catalog containing price quotations for goods or services as requested by account user 204.
- account manager 202 may independently generate or approximate a quote amount for a requested goods or service for use in the pre-authorization process.
- Account manager 202 issues a pre-authorization request 224 to card issuer 214, in the preferred embodiment, using a personal computer that is electronically coupled to card issuer 214.
- Account manager 202 in pre- authorization request 224 specifies an account number for which pre-authorization transaction parameters apply.
- one or more transaction parameters including a quote amount resulting from the quotation process, an acceptable variance, or deviation range from the quotation amount, a merchant identifier (MID) and an acquiring bank identification number (BIN) are dispatched to card issuer 214.
- MID merchant identifier
- BIN acquiring bank identification number
- account manager 202 may specify a quote amount and a variance or deviation from the quote amount, such as in the case permitting the inclusion of sales tax with the quoted transaction amount, while leaving the merchant identifier and acquiring bank identification number unspecified, thereby permitting an account user to seek out the goods or services of any merchant for processing the requested transaction.
- the transaction identifier provides an alpha-numeric field wherein an identifier may be associated with a pre-authorized transaction and upon the initiation and authorization of the requested transaction, the transaction identifier is reported in the billing account information.
- Such a transaction identifier enables an account manager to associate a pre-authorization of a transaction with a transaction reported in a billing account thereby allowing reconciliation of accounting entries.
- card issuer 214 employs its established relationship with authorizing agent 212 to forward a pre-authorization request 226 comprised of the account number and other transaction parameters which may optionally include a transaction identifier.
- Authorizing agent 212 retains and stores the pre- authorization transaction parameters in a pre-authorization table 318 ( Figure 3) for subsequent authorization when a transaction presents an SIC corresponding to one designated as a pre-authorization SIC.
- the pre-authorization parameter records remain within authorizing agent 212 until a matching transaction is initiated by an account user.
- pre-authorization parameters may become stale and expire if not timely used.
- Account user 204 requests goods or services from merchant 206 and thereafter initiates a payment presentment 228 for reimbursement to merchant 206.
- payment presentment 228 takes the form of presentment of a transaction card or other credit card-like credentials bearing an account number as previously assigned for use by account user 204.
- the present invention does not require account user 204 to present tangible credentials bearing an account number, but also accommodates the presentment of an account number to a merchant in intangible form, such as the recitation of an account number to merchant 206 for discrete key entry by merchant 206 at the commencement of the authorization process.
- account manager 202 rather than account user 204 ( Figure 2) divulges an account number for use by merchant 206 ( Figure 2) upon the rendering of goods or services.
- account manager 202 may play the role of a claims adjuster disclosing an account number to merchant 206 for payment of services rendered for an insurance claim.
- merchant 206 upon receipt of the account number information verifies the status and acceptance parameters of the present account by performing an authorization request 230 with authorizing agent 212.
- Merchant 206 forwards the account number, transaction amount, the merchant's SIC denoting its category of goods or services, the merchant's MID and the acquiring BIN associated with merchant 206.
- Authorizing agent 212 performs the authorization process which includes consulting the pre-authorization table when the merchant SIC presented in authorization request 230 corresponds to a pre-authorization SIC presented in establish authorization step 218.
- the authorization process of authorizing agent 212 is detailed in the flowchart of Figure 4.
- authorizing agent 212 issues an authorization response 232 listing the acceptance or denial status resulting from the authorization process to merchant 206.
- a settle account phase generally occurs at a periodic point in time such as at the end of a business day or week.
- merchant 206 compiles a complete listing of authorized transactions occurring within the specified period which includes the present transaction of the previous discussion, and initiates a settlement request 234 with authorizing agent 212 by divulging the account number, the transaction amount and other pertinent and related information such as the merchant's SIC, MID and BIN.
- authorizing agent 212 may also act as an account clearinghouse providing account settlements for card issuers having an established relationship with authorizing agent 212.
- Authorizing agent 212 issues a settlement request 236 to card issuer 214 which may contain the same or similar information as received from settlement request 234 or as shown in settlement request 236 may contain more descriptive information such as a merchant name and city as opposed to an MID.
- authorizing agent 212 additionally forwards the transaction identifier as received in pre-authorization request 226.
- Card issuer 214 issues payment settlement response 238 to acquiring bank 208 with the subsequent settlement response 239 for settlement of the account resulting from the present transaction.
- Card issuer 214 issues a billing account 240 to account manager 202 detailing the account number, the transaction amount, merchant information and, when present, the transaction identifier.
- account manager 202 By presenting the transaction identifier to account manager 202 transactions authorized in the pre-authorize transaction phase may be traced through the authorization, settlement and reporting phases of account processing. By tracing or having a designator assigned to a specific transaction, the accounting resources of account manager 202 may close out such transactions upon the reporting of the completion of the transaction.
- Figure 3 is a simplified diagram of authorization tables employed by an authorizing agent for use in comparison of parameters of a requested transaction with authorization limitations placed upon transaction, in accordance with an embodiment of the present invention.
- An authorization agent 212 ( Figure 2) stores therein an authorization table 300 containing parameter limitations as previously designated during the establish account phase of an account processing procedure.
- the authorizing agent references a standard authorization table containing limitations such as an SIC limit 312, a transaction limit 314 and a balance limit 316.
- specified categories of transactions may be allowed to proceed when a pre-authorization process has taken place.
- Such transaction categories are stored within authorization table 300 in a pre-authorization SIC table 302.
- SICs 304, 306 and 308 correspond to SIC category codes X, Y and Z, respectively, and designate transaction categories requiring consultation with a pre-authorization table 318 to determine the authorization of a requested transaction.
- pre- authorization table 318 is comprised of a series of fields designating transaction parameters that must be in compliance prior to issuing an authorization of the requested transaction.
- Such transaction parameters include a quote amount 322, a variance 324, a merchant ID (MID) 326 and an acquiring bank identification number (BIN) 328.
- Quote amount 322 is comprised of an upper price boundary for an approved transaction.
- a variance parameter 324 optionally provides tolerance values for accommodating variations in "amounts.” For example, a variance may typically take the form of sales tax or regionalized price fluctuations or other variations.
- Merchant identifier 326 optionally may provide a parameter requiring the transaction to originate from a designated merchant or point of sale location.
- acquiring bank identification number 328 may optionally provide a further grouping of select merchants and employ a specified bank before authorizing the transaction in question.
- a transaction identifier 330 is associated with pre- authorization transaction parameters during the pre-authorization process.
- a pre-authorizing agent such as an account manager to specify a purchase order number, a work order number or an insurance claim number to be included within the pre-authorization parameters of such goods or such services.
- the transaction identifier is attached with the settlement request information, depicted as settlement request 236 ( Figure 2), for conveying the transaction information to a card issuer for reconveyance to the account manager.
- Upon receipt of the transaction identifier associated with the completed transaction account manager 202 may rectify accounting books or other records referencing the transaction identifier because the transaction identifier was associated with the billing account and request for payment. Such a technique enables a merchant to receive payment almost immediately upon the dispatch of a settlement request and relieves the accompanying correspondence associated with "cutting" a purchase order and writing a check for accounts payable.
- pre-authorization table 318 further comprises an SIC identifier field 320 for associating with a specific set of pre-authorization parameters. Furthermore, each parameter within the pre-authorization table need not be specified allowing greater flexibility to an account user in selecting vendors of goods or services.
- Figure 4 is a flowchart of an authorization process incorporating pre- authorization, in accordance with a preferred embodiment of the present invention.
- An authorizing agent pre-authorization verification process 402 is carried out within an authorizing agent such as authorizing agent 212 described in Figure 2.
- an account manager 202 ( Figure 2) and account user 204 ( Figure 2) may easily be combined into a single entity that both manages and uses an established account. Additionally, acquiring banks and card companies may further be included within other entities such as a card issuer or authorizing agent.
- Authorizing agent pre-authorization verification process 402 is carried out by an authorizing agent 212 ( Figure 2) by consulting a pre-authorization's SIC table 302 ( Figure 3) of authorization table 300.
- a query task 404 compares the SIC value of the requested transaction with those previously stored within the pre-authorization SIC table 302 ( Figure 3) during the establishment of the account phase.
- a standard authorization processing task 406 occurs wherein the standard authorization table 310 ( Figure 3) having specific limitations such as transaction or balance limits is performed.
- a query task 408 When query task 404 determines that the SIC code of the requested transaction corresponds with a SIC code requiring pre-authorization, a query task 408 performs a cursory evaluation upon the pre-authorization table to determine if there is a pre-authorization entry present. When a pre-authorization entry is not present, a deny transaction task 410 returns a deny transaction status in the authorization response 232 ( Figure 2).
- a query task 412 evaluates the requested transaction amount against the quote amount including any variance parameters included within the pre-authorization table. When the requested transaction amount exceeds the quote amount including any variances, the requested transaction is denied as described above. When the requested transaction amount does not exceed the boundaries established by the quote amount including any variances, a query task 414 further evaluates any other specified parameters such as merchant ID (MID) or acquiring bank identification number (BIN) against those supplied by the requested transaction. Again, if the parameters of the requested transaction do not conform of those specified in the pre-authorization table, the transaction is denied.
- MID merchant ID
- BIN bank identification number
- an approved transaction task 416 authorizes the transaction in the affirmative.
- FIG. 5 is a depiction of a billing account report associating a transaction identifier with a transaction yet to be billed, in accordance with an embodiment of the present invention.
- a transaction identifier 510 may be associated to a pre-authorized transaction generated by an account manager.
- Traditional billing statements presented to an account manager contain generic information such as an account number, a transaction amount and information identifying a merchant. Historically, an account manager was then left to search back through claims, work orders or purchase orders to align a transaction amount and merchant identifier contained within the billing statement to an earlier authorization.
- a billing account 502 is comprised of an account number 504, merchant information 506, a transaction amount 508 and a transaction identifier 510.
- Transaction identifier 510 by containing descriptive information unique to the transaction, enables an account manager to quickly identify a corresponding authorization document for account reconciliation.
- transaction identifier 510 contains an alphanumeric field which is defined by account manager 202 ( Figure 202) and distributed to card issuer 214 using pre-authorization request 224, which in turn is forwarded to authorizing agent 212 and pre-authorization request 226, respectively.
- a transaction identifier By allowing a transaction identifier to be associated with pre-authorization process, less sophisticated equipment such as transaction processing equipment resident at a merchant point of sale may remain relatively unsophisticated as such equipment does not process or pass through any additional parameters such as a transaction identifier but the account manager still gets a unique per transaction identification code.
- Figure 6 is a flow diagram illustrating account processing which employs pre-authorization of select transactions without requiring an account user to perform a payment presentment step, in accordance with an embodiment with the present invention.
- the established account phase proceeds according to that of the previous embodiment wherein an established account 616 and an established authorization step 618 establish an account number, SIC limitations, transaction limitations and pre-authorization SICs requiring individual pre-authorization.
- An account user 604 requests goods or services of an account manager 602 in a task 620.
- Account manager 602 negotiates a price quotation 622 from a merchant 606.
- Account manager 602 either upon resolution of a price quotation from a merchant 602 or, as discussed above, account manager 602 may obtain a quote amount value for placing within a pre-authorization request from other sources such as other standard pricing materials.
- account manager 602 provides merchant 606 as opposed to account user 604 with an account number in account disclosure step 624 for utilization in a subsequent authorization request initiated by merchant 606. Following the disclosure of the account number to merchant 606, account manager 602 performs a pre-authorization request 626 in accordance with the description of the previous embodiment.
- a pre-authorization request 628 then flows from card issuer 614 to authorizing agent 612 for population of the pre- authorization table 318 ( Figure 3). Such steps complete the pre-authorization phase of the account processing procedure.
- merchant 606 Upon the rendering of service or delivery of goods, merchant 606 commences an authorization transaction process by issuing an authorization request 630 to authorizing agent 612 utilizing the account number delivered thereto by account manager 602 in account disclosure steps 624.
- Such an account number distribution technique is useful for applications such as insurance claim processing.
- account user 604 assumes the role of an insured placing a claim against account manager 602, who further assumes the role of the insurer, or alternatively, a claims adjuster.
- Account manger 602 negotiates a repair price with a merchant 606 assuming the role, in the case of auto insurance, of a repair shop.
- account manager 602 i.e.
- claims adjuster discloses an account number for use by merchant 606 (i.e. , repair shop) for use in obtaining reimbursement for goods and services upon the completion of rendering such goods or services.
- Account manager 602 i.e. , claims adjuster
- account manager 602 includes a transaction identifier, which by way of example may be in the form of an insurance claim number uniquely identifying the requested claim by the insured.
- merchant 606 Upon the rendering of services or the delivery of goods, merchant 606 (i.e., repair shop) issues an authorization request 630 comprising the account number disclosed with the amount of the transaction and other identifiers flowing therewith.
- Authorizing agent 612 performs an authorization procedure and renders an authorization response 632 stating the status of either acceptance or denial of the requested transaction to merchant 606.
- Authorizing agent 612 processes the settlement request in conjunction with card issuer 614 in a settlement request 636 including the account and transaction-related information such as account number, transaction amount, merchant number/name/address and the transaction identifier tieing the present billing line item to the originating claim number as delivered to account manger 602 in billing account step 640 as further received from settlement request step 636, and settlement response steps 638 and 639.
- the present invention provides a mechanism for utilizing existing account processing infrastructure such as existing point of sale terminals which are generally incapable of inputting additional information such as a transaction identifier into a transaction.
- associating a transaction identifier to a specific transaction is transparent to an account user, merchant, acquiring bank and bank card association.
- the account manager may establish, edit and delete pre-authorizations at will without exhaustive and expensive account-modifying parameters as historically required.
- FIG. 7 is a simplified transaction diagram for use in wide-area networking environment in accordance with a preferred network embodiment of the present invention.
- the present embodiment finds application for use in an environment wherein an account user must divulge an account number in order to make a purchase using a transaction device such as a credit card or other similar device.
- a transaction device such as a credit card or other similar device.
- a transaction device such as a credit card or other similar device.
- a transaction device such as a credit card or other similar device.
- a transaction device such as a credit card or other similar device.
- a user/consumer is issued an account number that when used will be denied unless a specific transaction has been individually pre-authorized by the user/consumer.
- a process is detailed in Figures 7 and 8.
- a consumer discovers through whatever process the consumer chooses, a particular product of interest. The consumer may discover such a product either by shopping on the Internet or through other forms of shopping which include other forms of remote shopping such as catalog perusal as well as other imaginable forms of shopping. In prior remote shopping environment applications, a user would immediately thereupon divulge their account number.
- the consumer in a step 702 transitions to a pre- authorization environment such as a pre-authorization web page on the Internet.
- a pre-authorization web page on the Internet.
- the user performs a login procedure or other security procedure for authenticating or otherwise identifying the accessing user/consumer as being a bona fide user/consumer.
- Such an authentication process may take the form of a login and password or PIN or other verification or authentication processes known by those of skill in the art.
- the user/consumer may alternatively present the account number to such an authorization page, or the authorization page may match the user/consumer's login and password data with a stored account number.
- the pre-authorization values entered by the user/consumer are stored in a database 704 and may be comprised of an account number, a transaction valid duration (good through) date, a quote or value amount, a variance, and any other miscellaneous identification fields.
- the pre-authorization information is forwarded to a database that is accessible by the transaction authorizing agent.
- the transaction authorizing agent may be one and the same as the authorization web page provider or any of the other transactional entities including the bank card association or card issuer.
- the consumer returns in a step 706 to the web merchant's web page, in the instance of an Internet environment, to proceed with the purchasing transaction.
- the user/consumer offers to the web merchant an account number.
- the user/consumer operating with an account number that specifically requires the pre-authorization process performed immediately above derives a sense of security knowing that the act of divulging the account number to a merchant would only enable that specific merchant to successfully utilize the divulged account number in at most a single transaction and for a specific amount. Therefore, the consumer is protected from unscrupulous merchants that would heretofore misuse a divulged account number.
- Such a pre-authorization embodiment as described herein appears transparent to all merchants.
- the web merchant in a step 708 performs a traditional authorization request which in a step 710 passes through an acquiring bank, a bank card association to an authorizing agent.
- the authorizing agent thereupon performs an authorization with the account number and any other associated information passed on from the merchant such as the transaction amount.
- the account number with its accompanying transaction amount is compared against the previously pre-authorized information which was in the preferred embodiment sent to the authorizing agent for storage as received at the authorization web page.
- the authorizing agent will thereafter either approve or deny the transaction according to the pre-authorization parameters.
- the authorizing agent in a step 714 also subjects the transaction to the traditional standard authorization checks such as credit limits and any variations including an account in good standing.
- the authorizing agent may thereupon either decline the transaction in a step 716 or approve the transaction in a step 718.
- the pre-authorization process previously performed is either deleted from the system or deactivated, thereby preventing any unscrupulous subsequent attempts to utilize the divulged account number. Any additional transactions desired to be performed by the user/consumer require the user/consumer to undergo the pre-authorization process described above in steps 702 and 704. Since each of the pre-authorization requests is valid for only a single transaction, a particular user/consumer derives additional peace of mind in employing an otherwise vulnerable account number in performing remote commerce such as electronic commerce.
- Figure 8 is a flow diagram of the immediately above described pre- authorization process for use in a wide-area networking environment.
- a potential user of the system would need to establish an account.
- a web account user or a consumer 804 interacts with a card issuer 814 to obtain an account number and other various limits such as transaction limits and even specific transaction type limits.
- a step 818 establishes the authorization restrictions with the authorizing agent 812. While not explicitly shown, the authorizing agent must also be aware of the corresponding account number as well as the transactional limits and other various limits placed upon a user's account transactions.
- card issuer 814 may issue a unique series of account numbers which uniquely identify to authorizing agent 812 that particular transaction employing such a unique account number require the pre- authorization process before any transactions may be approved.
- a user engages in traditional shopping or browsing of the preferred environment, one of which may take the form of electronic shopping on the Internet.
- the web account user 804 discovers a web merchant page 806 bearing a preferred good or service to be acquired by web account user 804.
- web merchant page 806 discloses a price quotation or a quotation amount which may in its simplest form be a textual listing on the web merchant page of a sale amount.
- a web account user 804 determines the desirability of a web merchant's good or service
- the web account user 804 engages in a pre-authorization process with an authorization web page 815 which is affiliated in some manner with a card issuer or other service provider which presents a front-end interactive environment to the web account user 804.
- an alternate embodiment may employ a telephonic or other interactive front-end enabling a web account user the ability to pre-authorize a forthcoming transaction.
- the user may interface with the authorization web page 815 in any of several traditional login procedures such as the offering of a login alpha numeric string followed by the input of a password and may alternatively require the user to enter an account number.
- the web account user 804 includes the specific parameters within which a forthcoming transaction must comply. Such parameters may include the divulging of an account number, a transaction amount or quotation amount including a variance which may allow a user to approximate a percentile taxation rate.
- Alternative parametric information may also include a duration in which a transaction must be performed else the pre-authorization becomes stale and therefore invalid.
- a transaction valid duration date also known as a "good through" date enables a user that anticipates an imminent transaction to specify a duration date or time which minimizes the exposure to any account number misuse.
- the pre- authorization request is forwarded from the authorization web page 815 to the authorizing agent 812 that will subsequently perform any authorization requests received from a merchant.
- the web account user 804 returns to the web merchant page 806 in a step 828 to consummate the transaction by presenting the web account user's account number. Thereafter the web merchant performs an authorization request 830 with authorizing agent 812 in a traditional transaction fashion by submitting an account number and a transaction amount along with any other miscellaneous identifying parameters.
- Authorizing agent 812 thereafter performs the authorization process described above in Figure 7 and returns in a step 832 an authorization response in the form of an acceptance or a denial of the account number for use in payment for the requested transaction.
- Account settlement and account reporting take a similar form as to the other embodiments described in previous figures in that in a step 834 the web merchant requests a settlement with the authorizing agent which thereafter transfers a settlement request in a step 836 to the card issuer which sends payment in steps 838 and 839 to the web merchant's acquiring bank.
- the report accounting stage also forwards in a step 840 a billing account from the card issuer to the web account user which contains traditional account statement information described above.
- Figure 9 depicts a block diagram of an authorization table including both standard and pre-authorization table as stored within an authorizing agent in accordance with a preferred network embodiment described herein.
- the authorizing agent described herein in the network embodiment stores an authorization table 900 containing a list of accounts which require pre- authorization as established during an account establishment stage.
- the authorizing agent upon receiving the established account authorization for a particular account number populates a corresponding standard authorization table 910 with traditional information such as account limits 912, transaction limit 914, and a balance limit 916.
- a particular account such as account number 904 requiring pre-authorization prior to authorizing a transaction also has associated therewith a pre-authorization table 918 which has the corresponding account number 920 and other pre-authorization fields described herein above.
- a quotation amount 922 which is the pre-authorized amount that a user/consumer input during the pre-authorization stage.
- Other values input by the user/consumer during the pre-authorization phase may include a variance amount and a transaction valid duration or "good through" date as well as any other miscellaneous I.D. information. Such information is thereafter referenced by the authorizing agent during an authorization transaction stage.
- a particular network embodiment has been described herein having applications to a consumer to business transaction.
- a user specifically pre-authorizes a forthcoming transaction thereby providing a narrow window in which a transaction must be consummated.
- By enabling a user to specifically pre-authorize a forthcoming transaction with the inclusion of specific transaction parameters provides an additional control against misuse of account numbers which must be divulged to engage in remote commerce where physical presentment of a physical instrument such as a credit or debit card is infeasible. It is contemplated that other remote environments may employ the process as described herein without departing from the spirit of the invention. Such additional environments and embodiments are contemplated within the scope.
Abstract
An account processing method and system for providing specific pre-authorization parameters for transactions that require specific pre-authorization by a network user specifying conformity parameters within which any requested transaction parameters must comply in order to enable the requested transaction to be approved. Upon establishment of an account, transaction types by standard industrial code (SIC) are specified as needing specific authorization prior to approving the transaction as requested by a merchant. An account issuer provides a service to account members that permits network user to independently specify the parametric conditions under which to approve a transaction within such categories. Once a transaction is approved, the pre-authorization is spent and requires individual pre-authorization of each transaction, thereby minimizing misuse of an account number by merchants or others that come into possession of the network user's account number.
Description
SYSTEM AND METHOD FOR PRE-AUTHORIZATION OF INDIVIDUAL ACCOUNT REMOTE TRANSACTIONS
RELATED APPLICATIONS This application is a continuation-in-part of U.S. Patent Application Serial No. 08/957,419 filed October 24, 1997 entitled "System and Method for Pre- Authorization of Individual Account Transactions."
BACKGROUND OF THE INVENTION 1. The Field of the Invention The present invention relates to electronic authorization of financial transactions, and in particular, to electronic authorization of specific predetermined transactions. More particularly, the present invention relates to specific authorization of individual transactions otherwise inhibited or prohibited.
2. Present State of the Art Modernly, more and more transactions in commerce have come to rely upon the convenience of utilizing a transaction card such as a credit card for the purchasing of goods and services. As credit cards have become more ubiquitous, so also has the infrastructure supporting the use of credit cards in commerce. At one point, what was a simple relationship between a card issuer and a cardholder has evolved to include intermediaries providing authorization services and financial distribution services. Such an expansive infrastructure has come to facilitate on-line or near real-time transaction authorization. Furthermore, because of the extensive nature of the credit card infrastructure, additional users, not necessarily relying upon credit, also utilize the existing infrastructure in carrying out commerce. For example, businesses or corporations may establish a series of accounts with a card issuer and distribute
transaction cards to their members for use in executing cashless transactions. To minimize fraud and abuse in the purchasing of goods and services, authorization standards have been established. Figure 1 represents a standardized authorization process for transaction verification. An account manager, such as a fleet manager or other entity, desiring cashless transaction privileges contacts a card issuer 1 14 to request the extension of transaction privileges through an established account request 1 16. Typically, when establishing a credit account, card issuer 1 14 places restrictions such as transaction amount limitations upon the card user. However when establishing accounts for business or other like users, account manager 102 may request that card issuer 1 14 deny certain transactions and strictly enforce other limitations on transactions.
Exemplary desired account limitations include restrictions on the types of services and goods that may be procured by an account user 104 as directed by account manager 102. Industry standards have been established for the partitioning of goods and services into categories designated by a standard industrial code (SIC). A merchant 106 is assigned a specific standard industrial code corresponding to their predominate business function. For business transactions that adhere to the SIC coding, transactions originating at a point of sale terminal having a restricted SIC identifier may be unable to obtain proper authorization to complete a transaction with an account user. Other limitations frequently desired by account managers include transactional limits. Transactional limits may include single transaction limits or aggregate limitations upon successive transactions.
Card issuer 1 14 upon the establishment of an account may employ a third party authorizing agent to provide authorization services and strictly enforce transaction limitations as agreed upon between account manager 102 and card issuer 1 14. Card issuer 1 14 through an establish authorization request 1 18 informs
authorizing agent 1 12 of the transaction terms under which transaction authorization may be granted.
Once an account has been established account manager 102 provides the account information necessary to enable account user 104 to engage in commerce transactions. Such account information generally includes an account number as assigned by card issuer 1 14. The predominate form of providing account information to account user 104 is to provide account user 104 with a transaction card generally taking the form of a credit card-like card bearing the account number thereon. Account user 104 upon initiating a transaction with a merchant 106 engages in a payment presentment step 120 by providing the requisite account information to merchant 106. Merchant 106 engages in an authorization process to verify that the transaction parameters of the present transaction are within the boundaries or limitations placed upon the account as requested by account manager 102 or imposed by card issuer 1 14. An authorization request 122 issued by merchant 106 is comprised of an account number, a transaction amount and other parameters such as a standard industrial code (SIC), a merchant identifier (MID) and an acquiring bank identification number (BIN).
A merchant 106 typically associates with an acquiring bank 108 which provides funding services of merchant transactions. Authorization requests may electronically pass through acquiring bank 108 as designated by the BIN of the authorization request and additionally may route through a card company 1 10 (e.g., MasterCard®, VISA®, Discover Card® or American Express®) prior to reaching authorizing agent 1 12 for comparison of account parameters. Authorizing agent 1 12 compares the transaction parameters for conformance with account limitations. Authorizing agent 1 12 issues an authorization response 124 comprising an acceptance or denial indicator.
During general authorization processing, funds generally do not transfer at that time. A settlement generally occurs at a periodic time such as evenings or nights when a merchant re-initiates communication with an authorizing agent and presents a series of accepted and authorized transactions occurring throughout the previous period and requests financial settlement of such transactions. Merchant 106 initiates a settlement request 126 with authorizing agent 1 12 which generally comprises the account number to be debited, the amount of the debit and other information such as SIC, MID and BIN designators. As part of the settlement process, authorizing agent 1 12 issues a settlement request 128 to card issuer 1 14. Frequently a settlement request 128 includes less cryptic merchant information (i.e. , merchant name and city/state address instead of MID) for later presentment to an account manager. Card issuer 1 14 in a payment settlement response step 130 passes payment information on to merchant's acquiring bank 108 with the appropriate funds transferring in a step 131.
At yet another periodic point in time, card issuer 1 14 provides a billing account 132 to account manager 102 for notification of payment due or for other record keeping purposes. Such billing account information may be presented in various forms including printed statements as well as electronic reporting. In such generic authorization processing as described above, billing account information contains relatively little and non-descriptive information such as an account number, a transaction amount and merchant information.
At least three particular shortcomings of the authorization process as described in Figure 1 should be pointed out. First, authorization performed by authorizing agent 1 12 provides a regulation of transactions by either proscribing transactions originating at a merchant having a proscribed SIC goods/services designator, or withholding authorization from transactions that exceed
transactional limits. Such an authorization process approves transactions of values less than the transactional limits transpiring at non-proscribed merchant point of sale terminals having a non-barred SIC goods/services designator. Prior art authorization techniques do not provide a method or system for enforcing strict transaction parameters prior to authorization of restricted transaction types on a transaction by transaction basis. Additionally, prior art techniques do not permit an account manager to create transaction authorization parameters without reinitiating account establishment procedures.
A second shortcoming of the authorization processing in the prior art relates to billing account information sent from card issuer 1 14 for evaluation by account manger 102. As shown in Figure 1 , the billing account information is comprised of an account number and an amount coupled to merchant information such as the name and city of the merchant. An account manager does not have a tracking mechanism to track the execution of a specific transaction and the billing of such a transaction on a billing statement if the vendor and acquiring bank cannot provide this functionality. In prior art configurations, the account manager only discerns that a certain amount of money, a transaction amount, was exchanged with a specific merchant.
Other transaction systems have incorporated item descriptions generally ascertainable from SKU numbers listing goods or services obtained from the listed merchant into their billing statements. It should be noted that such techniques still do not provide a tracking mechanism for linking a specific authorization procedure to a billing account printout.
A third short coming of the authorization processing in the prior art relates to the inability to prevent fraudulent successive transactions using the account number of an account user once it has been divulged to a merchant. In many
instances and applications, transactions are performed remotely from the physical presence of the account user thereby foreclosing the account user from discretionary evaluation of the credibility of the merchant with which an account user's account number would be divulged. In such an application, the rogue merchant would be free to utilize the account number in successive authorization requests and alternatively could resell or post an account user's account number for indiscriminate use by other devious entities. Because such an opportunity exists such as in the case of remote network and chiefly Internet purchasing environments, account users have theretofore been hesitant to engage in electronic commerce using a credit or other form of transaction card or vehicle that exposes an account user's account number into an environment whose security is at best suspect.
Accordingly, what is needed is a method and system for authorizing in advance or pre-authorizing transactions that but for specific authorization, are otherwise proscribed.
What is also needed is a method and system for enforcing parameters upon such pre-authorized transactions such as transaction amounts, specific merchants and other transaction related parameters.
Also, what is yet needed, is a method and system for facilitating an audit or record reconciliation from a pre-authorized transaction through the billing of the account thus informing an account manager of the completion of a pre-authorized transaction.
SUMMARY AND OBJECTS OF THE INVENTION
It is an object of the present invention to provide a method for authorizing an account when a portion of the account transactions require individual pre- authorization according to specified pre-authorization parameters.
It is another object of the present invention to provide a system for authorizing an account when a portion of the account transactions require individual pre-authorization according to specified pre-authorization parameters.
It is a further object of the present invention to provide a method for authorizing a portion of account transactions otherwise denied by requiring individual pre-authorization according to parameters pre-authorized in a pre- authorization process.
It is yet another object of the present invention to provide a method and system for associating a transaction identifier within a pre-authorization process such that upon the completion of the transaction, the associated transaction identifier follows the transaction information through the billing account phase, thus allowing reconciliation of a specific transaction from a previously assigned transaction identifier.
It is still yet another object of the present invention to provide a method and system for authorizing all account transactions which without such pre- authorization would otherwise be denied in wholesale. Such a method and system enforces a collateral pre-authorization of each and every transaction in order to approve or accept an authorization transaction initiated by a merchant entity.
Additional objects and advantages of the invention will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by the practice of the invention. The objects and advantages of the
invention may be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims.
To achieve the foregoing objects, and in accordance with the invention as embodied and broadly described herein, an account processing method and system for facilitating the general denial of all or specific categories of transactions unless they are specifically pre-authorized with specified parameters and the parameters of the requested transaction conform to those pre-authorized parameters is provided. Additionally, the present invention provides a system and method for the pre-authorization of specific transactions to be performed by an account manager via a service provided by an account issuer to their customers such as account managers and users.
A further advancement of the present invention provides a method and system for allowing an account manager to define a transaction identifier (e.g., insurance claim number, purchase order number, work order number, etc.) and attach the transaction identifier through a pre-authorization of a transaction. Upon the initiation and authorization of a requested transaction conforming to the specified pre-authorization parameters, the transaction identifier is included with the generic billing information (e.g., transaction amount, merchant information, etc.) thus allowing an account manager to reconcile their accounting from a billing account information containing the transaction having the transaction identifier associated thereto with a pre-transaction assignment of a traditional identifier such as purchase order number, work order number, or insurance claim number.
The above described system and method includes an account establishment phase of an account process wherein an account manager approaches a card issuer to establish an account in an establish account step. During the establishment of an account, limitations on transactions relating to that account are
negotiated between the account manager and card issuer. Transaction limitations generally include items such as transaction limits, account balance limit, limitations on categories of goods or services as denoted by standard industrial codes (SIC) and other parameters that may be incorporated into a specific accounting scheme. In an alternate embodiment, a system and method is described wherein a consumer-to-business transaction environment, the account user personally initiates the account establishment phase with the card issuer.
In the present invention, upon the establishment of an account or during the amending or changing of an account, transactions involving certain categories of goods or services as denoted by pre-authorization SICs that denote categories of goods or services, have individual parametric constraints placed upon them. A card issuer employs the services of an authorizing agent for performing account authorization upon the initiation of a transaction request from a merchant. The card issuer, in an establish authorization step, forwards various parameters such as SIC limits that wholly bar categories of transactions, transaction limits relating to non-pre-authorization transactions and pre-authorization SICs designating categories of goods or services requiring specific authorization in conformance with pre-authorization parameters subsequently dispatched to the designated authorizing agent in a pre-authorization process.
In the present invention, once an account is established with a card issuer, an account manager may perform pre-authorization of transactions with the card issuer directly. In the preferred embodiment, an account manager using a communication device such as a personal computer may routinely generate pre- authorization requests by transferring pre-authorization parameters to the card issuer via communication channel such as the INTERNET. In an alternate embodiment such as a consumer-to-business environment, the account user may
personally perform the transaction pre-authorization directly with the card issuer. In a remote or networking-type environment, the account user may pre-authorize the transaction by employing a network such as the INTERNET which enables the account user to interface with the card issuer through a card issuer's interactive interface such a web page.
A typical scenario wherein the present invention is practiced provides for a pre-authorization transaction phase that commences with a request by an account user for a specified good or service that requires pre-authorization prior to initiating the transaction. The account user consults with the account manager for requesting restricted goods or services. The account manager in turn contacts the merchant for negotiating or obtaining a price quotation for the requested goods or services, or optionally, the account manager arrives at a quotation amount by consulting other traditional pricing sources such as directories or catalogs.
The account manager issues a pre-authorization request to the card issuer via a personal computer. The account manager in the pre-authorization request specifies an account number for which pre-authorization transaction parameters apply. In the preferred embodiment, one or more transaction parameters including a quote amount resulting from the quotation process, an acceptable variance or deviation range from the quotation amount, a merchant identifier (MID) or an acquiring bank identification number (BIN) are dispatched to the card issuer. It should be pointed out that in the present invention, one or more of the pre-authorization parameters may be specified while others may not be specified thus permitting the spectrum of possible options for such criteria. The card issuer relays the pre-authorization parameters to the authorizing agent for storage and usage during authorization processing. In an alternate consumer-to- merchant environment, the account user assumes the role of the account manager
by both seeking out the goods or services to be procured and additionally by pre- authorizing or approving a future transaction that undergoes a merchant authorization request.
Another aspect of the present invention includes the ability to input or provide a transaction identifier for association with an authorized completed transaction. The transaction identifier, in the preferred embodiment, provides an alpha-numeric field wherein an identifier may be specified and associated with a pre-authorized transaction and upon the initiation and authorization of the requested transaction, the transaction identifier is reported in the billing account information. Such a transaction identifier enables an account manager to associate a pre-authorization of a transaction with a transaction reported in a billing account thereby allowing reconciliation of accounting entries.
The pre-authorization parameter record remains within the authorizing agent until a matching transaction is initiated by an account user. When an account user initiates a transaction for goods or services, a merchant initiates an authorization request for approval. In the present invention, the authorization request takes the form of presentment of a transaction card or other credit card-like credentials bearing an account number as previously assigned for use by the account user. An account user or account manager may present the account number to the merchant using means other than a transaction card such as the presentment, verbal disclosure, electronic disclosure or written disclosure of an account number to the merchant.
During the authorization, the merchant forwards the account number, the transaction amount, and alternatively other information such as the merchant's SIC denoting its category of goods or services, the merchant's MID and the acquiring BIN associated with the merchant. The authorizing agent performs the
authorization process which includes consulting the pre-authorization table when the merchant SIC presented in the authorization request corresponds to a pre- authorization SIC presented during the establishment of the account. The authorizing agent issues an authorization response listing the acceptance or denial status resulting from the authorization process.
During the settlement of the account, generally at the end of the business day, the merchant forwards the account numbers, the transaction amounts and other pertinent and related information such as the merchant's SIC and city location relating to each of the authorized transactions for the day. In one embodiment of the present invention, the authorizing agent additionally forwards the transaction identifier as received in the pre-authorization request. In the billing account issued by the account issuer to the account manager, the billing account includes details of the account number, the transaction amount, merchant information and when present the transaction identifier. By presenting the transaction identifier to the account manager, transactions authorized in the pre-authorize transaction phase may be traced through the authorization, settlement and reporting phases of account processing. By tracing or having a designator assigned to a specific transaction, the accounting resources of the account manager may close out such transactions upon reporting the completion of the transaction.
In a networked consumer user-to-merchant environment, such as in an electronic commerce environment, the individual pre-authorization of each transaction by a user prior to the actual payment presentment activity, minimizes the fraudulent use of an account user's account number when divulged during a payment presentment step. Such misuse is curbed due to the fact that any subsequent authorization requests by a merchant or unauthorized user would be denied since the account user would not have individually pre-authorized each and
every transaction attempted by the user rogue merchant thereby denying subsequent debits against the account user's account.
These and other objects and features of the present invention will become more fully apparent from the following description and appended claims, or may be learned by the practice of the invention as set forth hereinafter.
BRIEF DESCRIPTION OF THE DRAWINGS
In order that the manner in which the above-recited and other advantages and objects of the invention are obtained, a more particular description of the invention briefly described above will be rendered by reference to specific embodiments thereof which are illustrated in the appended drawings. Understanding that these drawings depict only typical embodiments of the invention and are not therefore to be considered limiting of its scope, the invention will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:
Figure 1 is a flow diagram of an authorization process, in accordance with the prior art;
Figure 2 is a flow diagram of a pre-authorization process, in accordance with a preferred embodiment of the present invention;
Figure 3 is a block diagram of an authorization table including both standard and pre-authorization tables as stored within an authorizing agent, in accordance with a preferred embodiment of the present invention;
Figure 4 is a flow chart of a transaction authorization procedure in a pre- authorization-capable authorizing agent, in accordance with an embodiment of the present invention;
Figure 5 is a representative billing statement containing a transaction identifier as associated with a pre-authorized transaction and subsequently forwarded to an account manager upon completion of a pre-authorized transaction, in accordance with an embodiment of the present invention;
Figure 6 is a flow diagram illustrating account processing which employs pre-authorization of select transactions without requiring an account user to
i perform a payment presentation step, in accordance with an embodiment of the
2 present invention;
3 Figure 7 is a simplified transaction diagram for use in a wide-area
4 networking environment, in accordance with a preferred network embodiment of
5 the present invention;
6 Figure 8 is a flow diagram of a pre-authorization process for use in a wide-
7 area networking environment, in accordance with a preferred network embodiment
8 of the present invention; and
9 Figure 9 is a block diagram of an authorization table including both 10 standard and pre-authorization tables as stored within an authorizing agent, in π accordance with a preferred network embodiment of the present invention.
12 13 14 15 16 17 18 19 0 1 2 3 4 5 6
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
As used herein, the term "account manager" refers to an individual or organization charged with establishing and monitoring an account. An account manager may be in charge of many accounts and take the form of fleet managers, accounting managers, claims adjusters and also prudent account users.
As used herein, the term "account user" refers to an individual, consumer or organization seeking goods or services and may also take the form of fleet users, business personnel and insured parties. It should be noted that an account manager and an account user may be the same party.
As used herein, the term "merchant" refers to an individual or organization providing goods or services in exchange for a fee. Merchants generally facilitate the reimbursement transaction by providing a point-of-sale terminal or other device through which a transaction is initiated including a computer network interface for interacting over a network such as a LAN or WAN including the Internet.
As used herein, the term "acquiring bank" refers to a financial institution providing financial services for an associated merchant. An acquiring bank is generally a bank or like organization at which a merchant maintains an account for reconciliation of funds.
As used herein, the term "bank card association" refers to a sponsoring organization that provides financial services and brings organization and infrastructure into the account processing.
As used herein, the term "authorizing agent" refers to an organization which may be part of a card company and provides assurances to a merchant of the good standing of the account in question and conformity of the requested transaction to limitations and parameters placed upon a transaction.
As used herein, the term "account or card issuer" refers to an- organization providing administrative services to an account user or account manager. Account issuer may also provide augmented services to an account user or manager such as access to an authorizing agent for account establishment and other functions such as pre-authorization.
As used herein, the term "authorization web page" refers to a computer network-accessible intermediary interface into which a web account user (consumer) may place parametric transaction authorization information that is forwarded to an authorizing agent for use in evaluating the legitimacy of a specific transaction.
It should also be appreciated that the functions of the "bank card association," "authorizing agent," "card issuer," and the sponsor of an "authorization web page" may be one or several entities providing a combination of these functions.
As described in the Background of the Invention, Figure 1 is a flow diagram of an authorization process in accordance with the prior art.
Figure 2 is a flow diagram of account processing incorporating pre- authorization of individual transactions or transaction types, in accordance with a preferred embodiment of the present invention. As account processing has become increasingly prevalent and sophisticated, the complexities of account processing have also increased. For example, in the establishment and processing of an account, additional specified participants are incorporated into the processing flow. In one preferred embodiment, during an account establishment phase of an account process, an account manager 202 approaches a card issuer 214 to establish an account as represented in Figure 2 by establish account step 216. During the establishment of an account, limitations on transactions relating to that account are
negotiated between account manager 202 and card issuer 214. Transaction limitations generally include items such as transaction limits, account balance limit, limitations on categories of goods or services as denoted by standard industrial codes (SIC) and other parameters that may be incorporated into a specific account scheme.
In the present embodiment of the invention, upon the establishment of an account or during the amending or changing of an account, transactions involving certain categories of goods or services as denoted by pre-authorization SICs denote goods or services that require individual parametric constraints upon such transactions. For example, account manager 202 may establish an account for use by an account user 204 for performing maintenance upon a fleet vehicle. In order to police the use of the account for limited maintenance purposes, account manager 202 designates the SIC associated with maintenance as a pre-authorization SIC requiring conformity to transaction parameters subsequently defined by account manager 202.
Card issuer 214 employs the services of an authorizing agent 212 for performing account authorization upon the initiation of a transaction request from a merchant. Card issuer 214 in establish authorization step 218 forwards SIC limits controlling categories of transactions, transaction limits relating to non-pre- authorization transactions and pre-authorization SICs designating categories of goods or services requiring specific authorization according to pre-authorization parameters subsequently dispatched to authorizing agent 212.
In the present invention, once an account is established with a card issuer, account manager 202 may perform pre-authorization of transactions with card issuer 214 directly. In the preferred embodiment, account manager 202 using a personal computer may routinely generate pre-authorization requests by
transferring pre-authorization parameters to card issuer 214 via the INTERNET.
A pre-authorization transaction phase commences with a request 220 by an account user 204 for a specified good or service that requires pre-authorization prior to initiating the transaction. Account user 204 consults with account manager 202 to obtain restricted goods or services. Account manager 202 in turn contacts a merchant 206 for negotiating or obtaining a price quotation 222, including a quote amount for the requested goods or services. Optionally, account manager 202 may consult a price quotation directory or catalog containing price quotations for goods or services as requested by account user 204. In yet another option, account manager 202 may independently generate or approximate a quote amount for a requested goods or service for use in the pre-authorization process.
Account manager 202 issues a pre-authorization request 224 to card issuer 214, in the preferred embodiment, using a personal computer that is electronically coupled to card issuer 214. Account manager 202 in pre- authorization request 224 specifies an account number for which pre-authorization transaction parameters apply. In the preferred embodiment, one or more transaction parameters including a quote amount resulting from the quotation process, an acceptable variance, or deviation range from the quotation amount, a merchant identifier (MID) and an acquiring bank identification number (BIN) are dispatched to card issuer 214. It should be pointed out that in the present invention, one or more of the pre-authorization parameters may be specified while others may not be specified, thus permitting the spectrum of possible options for such criteria. For example, account manager 202 may specify a quote amount and a variance or deviation from the quote amount, such as in the case permitting the inclusion of sales tax with the quoted transaction amount, while leaving the merchant identifier and acquiring bank identification number unspecified, thereby
permitting an account user to seek out the goods or services of any merchant for processing the requested transaction.
Another field that may be input or provided by account manager 202 is a transaction identifier field. The transaction identifier, in the preferred embodiment, provides an alpha-numeric field wherein an identifier may be associated with a pre-authorized transaction and upon the initiation and authorization of the requested transaction, the transaction identifier is reported in the billing account information. Such a transaction identifier enables an account manager to associate a pre-authorization of a transaction with a transaction reported in a billing account thereby allowing reconciliation of accounting entries.
Referring to Figure 2, card issuer 214 employs its established relationship with authorizing agent 212 to forward a pre-authorization request 226 comprised of the account number and other transaction parameters which may optionally include a transaction identifier. Authorizing agent 212 retains and stores the pre- authorization transaction parameters in a pre-authorization table 318 (Figure 3) for subsequent authorization when a transaction presents an SIC corresponding to one designated as a pre-authorization SIC.
The pre-authorization parameter records remain within authorizing agent 212 until a matching transaction is initiated by an account user. Optionally, pre-authorization parameters may become stale and expire if not timely used. Account user 204 requests goods or services from merchant 206 and thereafter initiates a payment presentment 228 for reimbursement to merchant 206. In the preferred embodiment, payment presentment 228 takes the form of presentment of a transaction card or other credit card-like credentials bearing an account number as previously assigned for use by account user 204. It should be noted that the present invention does not require account user 204 to present tangible credentials
bearing an account number, but also accommodates the presentment of an account number to a merchant in intangible form, such as the recitation of an account number to merchant 206 for discrete key entry by merchant 206 at the commencement of the authorization process.
In yet another embodiment as detailed in Figure 6, account manager 202 (Figure 2) rather than account user 204 (Figure 2) divulges an account number for use by merchant 206 (Figure 2) upon the rendering of goods or services. Such a process has application to businesses such as the insurance industry wherein account manager 202 may play the role of a claims adjuster disclosing an account number to merchant 206 for payment of services rendered for an insurance claim.
Returning to a discussion of the embodiment depicted in Figure 2, merchant 206 upon receipt of the account number information verifies the status and acceptance parameters of the present account by performing an authorization request 230 with authorizing agent 212. Merchant 206 forwards the account number, transaction amount, the merchant's SIC denoting its category of goods or services, the merchant's MID and the acquiring BIN associated with merchant 206. Authorizing agent 212 performs the authorization process which includes consulting the pre-authorization table when the merchant SIC presented in authorization request 230 corresponds to a pre-authorization SIC presented in establish authorization step 218. The authorization process of authorizing agent 212 is detailed in the flowchart of Figure 4. At the conclusion of the authorization process, authorizing agent 212 issues an authorization response 232 listing the acceptance or denial status resulting from the authorization process to merchant 206.
Generally at the authorization phase of a transaction, funds do not transfer between the parties. Rather, a settle account phase generally occurs at a periodic
point in time such as at the end of a business day or week. At such time, merchant 206 compiles a complete listing of authorized transactions occurring within the specified period which includes the present transaction of the previous discussion, and initiates a settlement request 234 with authorizing agent 212 by divulging the account number, the transaction amount and other pertinent and related information such as the merchant's SIC, MID and BIN.
In some financial configurations, authorizing agent 212 may also act as an account clearinghouse providing account settlements for card issuers having an established relationship with authorizing agent 212. Authorizing agent 212 issues a settlement request 236 to card issuer 214 which may contain the same or similar information as received from settlement request 234 or as shown in settlement request 236 may contain more descriptive information such as a merchant name and city as opposed to an MID. In one embodiment of the present invention, authorizing agent 212 additionally forwards the transaction identifier as received in pre-authorization request 226. Card issuer 214 issues payment settlement response 238 to acquiring bank 208 with the subsequent settlement response 239 for settlement of the account resulting from the present transaction.
Card issuer 214 issues a billing account 240 to account manager 202 detailing the account number, the transaction amount, merchant information and, when present, the transaction identifier. By presenting the transaction identifier to account manager 202 transactions authorized in the pre-authorize transaction phase may be traced through the authorization, settlement and reporting phases of account processing. By tracing or having a designator assigned to a specific transaction, the accounting resources of account manager 202 may close out such transactions upon the reporting of the completion of the transaction.
Figure 3 is a simplified diagram of authorization tables employed by an authorizing agent for use in comparison of parameters of a requested transaction with authorization limitations placed upon transaction, in accordance with an embodiment of the present invention. An authorization agent 212 (Figure 2) stores therein an authorization table 300 containing parameter limitations as previously designated during the establish account phase of an account processing procedure. During a traditional authorization procedure, the authorizing agent references a standard authorization table containing limitations such as an SIC limit 312, a transaction limit 314 and a balance limit 316. In the present invention specified categories of transactions may be allowed to proceed when a pre-authorization process has taken place. Such transaction categories are stored within authorization table 300 in a pre-authorization SIC table 302.
As illustrated in Figure 3, SICs 304, 306 and 308 correspond to SIC category codes X, Y and Z, respectively, and designate transaction categories requiring consultation with a pre-authorization table 318 to determine the authorization of a requested transaction. In the preferred embodiment, pre- authorization table 318 is comprised of a series of fields designating transaction parameters that must be in compliance prior to issuing an authorization of the requested transaction. Such transaction parameters include a quote amount 322, a variance 324, a merchant ID (MID) 326 and an acquiring bank identification number (BIN) 328. Quote amount 322 is comprised of an upper price boundary for an approved transaction. A variance parameter 324 optionally provides tolerance values for accommodating variations in "amounts." For example, a variance may typically take the form of sales tax or regionalized price fluctuations or other variations. Merchant identifier 326 optionally may provide a parameter requiring the transaction to originate from a designated merchant or point of sale location.
Furthermore, acquiring bank identification number 328 may optionally provide a further grouping of select merchants and employ a specified bank before authorizing the transaction in question.
In another embodiment, a transaction identifier 330 is associated with pre- authorization transaction parameters during the pre-authorization process. Such association of an identifier permits a pre-authorizing agent such as an account manager to specify a purchase order number, a work order number or an insurance claim number to be included within the pre-authorization parameters of such goods or such services. Following the initiation and authorization of a transaction wherein the pre-authorization parameters were matched, the transaction identifier is attached with the settlement request information, depicted as settlement request 236 (Figure 2), for conveying the transaction information to a card issuer for reconveyance to the account manager. Upon receipt of the transaction identifier associated with the completed transaction account manager 202 may rectify accounting books or other records referencing the transaction identifier because the transaction identifier was associated with the billing account and request for payment. Such a technique enables a merchant to receive payment almost immediately upon the dispatch of a settlement request and relieves the accompanying correspondence associated with "cutting" a purchase order and writing a check for accounts payable.
In an alternate embodiment of the present invention, pre-authorization table 318 further comprises an SIC identifier field 320 for associating with a specific set of pre-authorization parameters. Furthermore, each parameter within the pre-authorization table need not be specified allowing greater flexibility to an account user in selecting vendors of goods or services.
Figure 4 is a flowchart of an authorization process incorporating pre- authorization, in accordance with a preferred embodiment of the present invention. An authorizing agent pre-authorization verification process 402 is carried out within an authorizing agent such as authorizing agent 212 described in Figure 2. Although the previous discussions including Figure 2 have illustrated entities such as authorizing agents being separate from card issuers, nothing prevents the combination of these elements into a single entity canying out both processes therein. For example an account manager 202 (Figure 2) and account user 204 (Figure 2) may easily be combined into a single entity that both manages and uses an established account. Additionally, acquiring banks and card companies may further be included within other entities such as a card issuer or authorizing agent.
Authorizing agent pre-authorization verification process 402, in the preferred embodiment, is carried out by an authorizing agent 212 (Figure 2) by consulting a pre-authorization's SIC table 302 (Figure 3) of authorization table 300. A query task 404 compares the SIC value of the requested transaction with those previously stored within the pre-authorization SIC table 302 (Figure 3) during the establishment of the account phase. When the SIC code of the requested transaction does not match a SIC code specifically requiring additional pre- authorization, a standard authorization processing task 406 occurs wherein the standard authorization table 310 (Figure 3) having specific limitations such as transaction or balance limits is performed.
When query task 404 determines that the SIC code of the requested transaction corresponds with a SIC code requiring pre-authorization, a query task 408 performs a cursory evaluation upon the pre-authorization table to determine if there is a pre-authorization entry present. When a pre-authorization
entry is not present, a deny transaction task 410 returns a deny transaction status in the authorization response 232 (Figure 2).
When query task 408 locates pre-authorization data within the pre- authorization table, a query task 412 evaluates the requested transaction amount against the quote amount including any variance parameters included within the pre-authorization table. When the requested transaction amount exceeds the quote amount including any variances, the requested transaction is denied as described above. When the requested transaction amount does not exceed the boundaries established by the quote amount including any variances, a query task 414 further evaluates any other specified parameters such as merchant ID (MID) or acquiring bank identification number (BIN) against those supplied by the requested transaction. Again, if the parameters of the requested transaction do not conform of those specified in the pre-authorization table, the transaction is denied.
When query task 414 determines that the parameters of the requested transaction conform to all other parameters specified in the pre-authorization table, an approved transaction task 416 authorizes the transaction in the affirmative. Although the above flow diagram has been specified in terms of task ordering, nothing precludes the evaluation of parameters or conditions in varying orders. For example, a merchant identifier specified in the pre-authorization table may be compared primary to the evaluation of the transaction amount without affecting the spirit of the invention.
Figure 5 is a depiction of a billing account report associating a transaction identifier with a transaction yet to be billed, in accordance with an embodiment of the present invention. As discussed above, a transaction identifier 510 may be associated to a pre-authorized transaction generated by an account manager. Traditional billing statements presented to an account manager contain generic
information such as an account number, a transaction amount and information identifying a merchant. Historically, an account manager was then left to search back through claims, work orders or purchase orders to align a transaction amount and merchant identifier contained within the billing statement to an earlier authorization.
In the present invention, a billing account 502 is comprised of an account number 504, merchant information 506, a transaction amount 508 and a transaction identifier 510. Transaction identifier 510, by containing descriptive information unique to the transaction, enables an account manager to quickly identify a corresponding authorization document for account reconciliation. In the preferred embodiment of the present invention, transaction identifier 510 contains an alphanumeric field which is defined by account manager 202 (Figure 202) and distributed to card issuer 214 using pre-authorization request 224, which in turn is forwarded to authorizing agent 212 and pre-authorization request 226, respectively. By allowing a transaction identifier to be associated with pre-authorization process, less sophisticated equipment such as transaction processing equipment resident at a merchant point of sale may remain relatively unsophisticated as such equipment does not process or pass through any additional parameters such as a transaction identifier but the account manager still gets a unique per transaction identification code.
Figure 6 is a flow diagram illustrating account processing which employs pre-authorization of select transactions without requiring an account user to perform a payment presentment step, in accordance with an embodiment with the present invention. In the present embodiment, the established account phase proceeds according to that of the previous embodiment wherein an established account 616 and an established authorization step 618 establish an account number,
SIC limitations, transaction limitations and pre-authorization SICs requiring individual pre-authorization.
An account user 604 requests goods or services of an account manager 602 in a task 620. Account manager 602 negotiates a price quotation 622 from a merchant 606. Account manager 602 either upon resolution of a price quotation from a merchant 602 or, as discussed above, account manager 602 may obtain a quote amount value for placing within a pre-authorization request from other sources such as other standard pricing materials.
In the present embodiment, account manager 602 provides merchant 606 as opposed to account user 604 with an account number in account disclosure step 624 for utilization in a subsequent authorization request initiated by merchant 606. Following the disclosure of the account number to merchant 606, account manager 602 performs a pre-authorization request 626 in accordance with the description of the previous embodiment. A pre-authorization request 628 then flows from card issuer 614 to authorizing agent 612 for population of the pre- authorization table 318 (Figure 3). Such steps complete the pre-authorization phase of the account processing procedure.
Upon the rendering of service or delivery of goods, merchant 606 commences an authorization transaction process by issuing an authorization request 630 to authorizing agent 612 utilizing the account number delivered thereto by account manager 602 in account disclosure steps 624. Such an account number distribution technique is useful for applications such as insurance claim processing. For example, account user 604 assumes the role of an insured placing a claim against account manager 602, who further assumes the role of the insurer, or alternatively, a claims adjuster. Account manger 602 negotiates a repair price with a merchant 606 assuming the role, in the case of auto insurance, of a repair shop.
Upon completion of the negotiation process and the resolution of a claim amount, account manager 602 (i.e. , claims adjuster) discloses an account number for use by merchant 606 (i.e. , repair shop) for use in obtaining reimbursement for goods and services upon the completion of rendering such goods or services. Account manager 602 (i.e. , claims adjuster) initiates pre-authorization request 626 by including the divulged account number, and any other parameters deemed necessary (e.g. , merchant identification number). Furthermore, to aid account manager 602 (i.e. , claims adjuster) in reconciling their accounting system, account manager 602 includes a transaction identifier, which by way of example may be in the form of an insurance claim number uniquely identifying the requested claim by the insured.
Upon the rendering of services or the delivery of goods, merchant 606 (i.e., repair shop) issues an authorization request 630 comprising the account number disclosed with the amount of the transaction and other identifiers flowing therewith. Authorizing agent 612 performs an authorization procedure and renders an authorization response 632 stating the status of either acceptance or denial of the requested transaction to merchant 606. Merchant 606, at a periodic interval, issues a settlement request 634 containing the account number, transaction amount and other identifying fields to authorizing agent 612 for account reconciliation. Authorizing agent 612 processes the settlement request in conjunction with card issuer 614 in a settlement request 636 including the account and transaction-related information such as account number, transaction amount, merchant number/name/address and the transaction identifier tieing the present billing line item to the originating claim number as delivered to account manger 602 in billing account step 640 as further received from settlement request step 636, and settlement response steps 638 and 639.
As briefly described above, the present invention provides a mechanism for utilizing existing account processing infrastructure such as existing point of sale terminals which are generally incapable of inputting additional information such as a transaction identifier into a transaction. In the present embodiment, associating a transaction identifier to a specific transaction is transparent to an account user, merchant, acquiring bank and bank card association. Furthermore, because of the services provided by the card issuer to the account manager, the account manager may establish, edit and delete pre-authorizations at will without exhaustive and expensive account-modifying parameters as historically required.
Figure 7 is a simplified transaction diagram for use in wide-area networking environment in accordance with a preferred network embodiment of the present invention. The present embodiment finds application for use in an environment wherein an account user must divulge an account number in order to make a purchase using a transaction device such as a credit card or other similar device. In environments where the physical or personal presentment of such a transaction card or device is impracticable such as in a telephonic transaction or in a preferred embodiment such as in the use of a computer network such as the Internet network. Users or consumers have heretofore been reluctant to divulge their account number into an amorphous and unknown domain for fear of an unscrupulous merchant acquiring their account number and utilizing the account number for unauthorized transactions. An account user or consumer has heretofore been required to rely upon the integrity of a remote merchant in order to safeguard against such abuses. In the present embodiment, however, a user/consumer is issued an account number that when used will be denied unless a specific transaction has been individually pre-authorized by the user/consumer. Such a process is detailed in Figures 7 and 8. In Figure 7, in a step 700 a consumer discovers through whatever process the
consumer chooses, a particular product of interest. The consumer may discover such a product either by shopping on the Internet or through other forms of shopping which include other forms of remote shopping such as catalog perusal as well as other imaginable forms of shopping. In prior remote shopping environment applications, a user would immediately thereupon divulge their account number. In the present network embodiment, the consumer in a step 702 transitions to a pre- authorization environment such as a pre-authorization web page on the Internet. In the network embodiment of the present invention, the user performs a login procedure or other security procedure for authenticating or otherwise identifying the accessing user/consumer as being a bona fide user/consumer. Such an authentication process may take the form of a login and password or PIN or other verification or authentication processes known by those of skill in the art. The user/consumer may alternatively present the account number to such an authorization page, or the authorization page may match the user/consumer's login and password data with a stored account number. During such a pre-authorization process, the pre-authorization values entered by the user/consumer are stored in a database 704 and may be comprised of an account number, a transaction valid duration (good through) date, a quote or value amount, a variance, and any other miscellaneous identification fields. Upon the termination of the pre-authorization step 702 and the storage in database 704, the pre-authorization information is forwarded to a database that is accessible by the transaction authorizing agent. It should be appreciated that the transaction authorizing agent may be one and the same as the authorization web page provider or any of the other transactional entities including the bank card association or card issuer.
Following the pre-authorization process described above, the consumer returns in a step 706 to the web merchant's web page, in the instance of an Internet
environment, to proceed with the purchasing transaction. In the' step 706, the user/consumer offers to the web merchant an account number. In the present embodiment, the user/consumer operating with an account number that specifically requires the pre-authorization process performed immediately above derives a sense of security knowing that the act of divulging the account number to a merchant would only enable that specific merchant to successfully utilize the divulged account number in at most a single transaction and for a specific amount. Therefore, the consumer is protected from unscrupulous merchants that would heretofore misuse a divulged account number.
Such a pre-authorization embodiment as described herein appears transparent to all merchants. Following the account number divulging act by the consumer to the merchant, the web merchant in a step 708 performs a traditional authorization request which in a step 710 passes through an acquiring bank, a bank card association to an authorizing agent. The authorizing agent thereupon performs an authorization with the account number and any other associated information passed on from the merchant such as the transaction amount. As part of the authorizing act, in a step 712 the account number with its accompanying transaction amount is compared against the previously pre-authorized information which was in the preferred embodiment sent to the authorizing agent for storage as received at the authorization web page. Once a comparison has been made of the pre-authorized "amount" and the transaction amount as received in the authorization process from the merchant, the authorizing agent will thereafter either approve or deny the transaction according to the pre-authorization parameters. The authorizing agent in a step 714 also subjects the transaction to the traditional standard authorization checks such as credit limits and any variations including an account in good standing. Following the pre-authorization checks in
step 712 and the standard authorization checks in step 714, the authorizing agent may thereupon either decline the transaction in a step 716 or approve the transaction in a step 718.
If a transaction is approved, the pre-authorization process previously performed is either deleted from the system or deactivated, thereby preventing any unscrupulous subsequent attempts to utilize the divulged account number. Any additional transactions desired to be performed by the user/consumer require the user/consumer to undergo the pre-authorization process described above in steps 702 and 704. Since each of the pre-authorization requests is valid for only a single transaction, a particular user/consumer derives additional peace of mind in employing an otherwise vulnerable account number in performing remote commerce such as electronic commerce.
Those skilled in the art appreciate that other applications of the above- described technology may also be employed in applications such as transactions engaged in by a user/consumer to other remote entities such as catalog merchants by using a computer interface pre-authorization approach or alternatively through a telephonic interface which enables a user to specify an account number and a quotation or potential transaction amount.
Figure 8 is a flow diagram of the immediately above described pre- authorization process for use in a wide-area networking environment.
It is appreciated that a potential user of the system would need to establish an account. In a step 816 a web account user or a consumer 804 interacts with a card issuer 814 to obtain an account number and other various limits such as transaction limits and even specific transaction type limits. Following the establishment of an account step 816 between a potential web account user and a card issuer, a step 818 establishes the authorization restrictions with the
authorizing agent 812. While not explicitly shown, the authorizing agent must also be aware of the corresponding account number as well as the transactional limits and other various limits placed upon a user's account transactions. In one implementation of the present embodiment, card issuer 814 may issue a unique series of account numbers which uniquely identify to authorizing agent 812 that particular transaction employing such a unique account number require the pre- authorization process before any transactions may be approved.
Following the establishment of account stage, a user engages in traditional shopping or browsing of the preferred environment, one of which may take the form of electronic shopping on the Internet. In a step 820, the web account user 804 discovers a web merchant page 806 bearing a preferred good or service to be acquired by web account user 804. In a step 822, web merchant page 806 discloses a price quotation or a quotation amount which may in its simplest form be a textual listing on the web merchant page of a sale amount. Once a web account user 804 determines the desirability of a web merchant's good or service, the web account user 804 engages in a pre-authorization process with an authorization web page 815 which is affiliated in some manner with a card issuer or other service provider which presents a front-end interactive environment to the web account user 804. As alluded to above, an alternate embodiment may employ a telephonic or other interactive front-end enabling a web account user the ability to pre-authorize a forthcoming transaction.
In the login step 823, the user may interface with the authorization web page 815 in any of several traditional login procedures such as the offering of a login alpha numeric string followed by the input of a password and may alternatively require the user to enter an account number. In a step 824 the web account user 804 includes the specific parameters within which a forthcoming
transaction must comply. Such parameters may include the divulging of an account number, a transaction amount or quotation amount including a variance which may allow a user to approximate a percentile taxation rate. Alternative parametric information may also include a duration in which a transaction must be performed else the pre-authorization becomes stale and therefore invalid. The use of a transaction valid duration date also known as a "good through" date enables a user that anticipates an imminent transaction to specify a duration date or time which minimizes the exposure to any account number misuse. In a step 826 the pre- authorization request is forwarded from the authorization web page 815 to the authorizing agent 812 that will subsequently perform any authorization requests received from a merchant.
Following the pre-authorization phase, the web account user 804 returns to the web merchant page 806 in a step 828 to consummate the transaction by presenting the web account user's account number. Thereafter the web merchant performs an authorization request 830 with authorizing agent 812 in a traditional transaction fashion by submitting an account number and a transaction amount along with any other miscellaneous identifying parameters. Authorizing agent 812 thereafter performs the authorization process described above in Figure 7 and returns in a step 832 an authorization response in the form of an acceptance or a denial of the account number for use in payment for the requested transaction.
Account settlement and account reporting take a similar form as to the other embodiments described in previous figures in that in a step 834 the web merchant requests a settlement with the authorizing agent which thereafter transfers a settlement request in a step 836 to the card issuer which sends payment in steps 838 and 839 to the web merchant's acquiring bank. The report accounting stage also
forwards in a step 840 a billing account from the card issuer to the web account user which contains traditional account statement information described above.
Figure 9 depicts a block diagram of an authorization table including both standard and pre-authorization table as stored within an authorizing agent in accordance with a preferred network embodiment described herein. The authorizing agent described herein in the network embodiment stores an authorization table 900 containing a list of accounts which require pre- authorization as established during an account establishment stage. The authorizing agent upon receiving the established account authorization for a particular account number populates a corresponding standard authorization table 910 with traditional information such as account limits 912, transaction limit 914, and a balance limit 916. A particular account such as account number 904 requiring pre-authorization prior to authorizing a transaction also has associated therewith a pre-authorization table 918 which has the corresponding account number 920 and other pre-authorization fields described herein above. One such field is a quotation amount 922 which is the pre-authorized amount that a user/consumer input during the pre-authorization stage. Other values input by the user/consumer during the pre-authorization phase may include a variance amount and a transaction valid duration or "good through" date as well as any other miscellaneous I.D. information. Such information is thereafter referenced by the authorizing agent during an authorization transaction stage.
A particular network embodiment has been described herein having applications to a consumer to business transaction. In such an environment, a user specifically pre-authorizes a forthcoming transaction thereby providing a narrow window in which a transaction must be consummated. By enabling a user to specifically pre-authorize a forthcoming transaction with the inclusion of specific
transaction parameters, provides an additional control against misuse of account numbers which must be divulged to engage in remote commerce where physical presentment of a physical instrument such as a credit or debit card is infeasible. It is contemplated that other remote environments may employ the process as described herein without departing from the spirit of the invention. Such additional environments and embodiments are contemplated within the scope.
The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.
What is claimed and desired to be secured by United States Letters Patent is:
Claims
1 . In a network environment, an account authorization method wherein a portion of account transactions require individual pre-authorization, said method comprising the steps of: a) establishing an account between network user and an account issuer, said account having an imposed pre-authorization transaction designator for denoting said portion of account transactions that require said individual pre-authorization; b) said network user pre-authorizing said account upon a match of each of at least one specified transaction parameter of said imposed pre- authorization transaction designator to authorize a requested transaction; and c) authorizing said requested transaction when in conformity with each of said at least one specified transaction parameter.
2. In a network environment, the account authorization method as recited in claim 1, wherein said establishing an account step comprises the step of designating a transaction valid duration period as said imposed pre-authorization transaction parameters.
3. In a network environment, the account authorization method as
2 recited in claim 1 , wherein said pre-authorizing step comprises the step of
3 designating said at least one specified transaction parameter as a quotation amount describing a price boundary under which to authorize said requested transaction.
5
6 4. In a network environment, the account authorization method as
7 recited in claim 3, wherein said designating said at least one specified transaction
8 parameter as a quotation amount step further comprises the step of designating a
9 variance parameter from said quotation amount as one of said at least one specified 10 transaction parameters, n 12
13 14 15 16 17 18 19 0 1 2 3 24 25 26
5. In an account authorization system for facilitating the authorization of account transactions occurring in a network environment wherein a portion of said account transactions require individual pre-authorization, a method for authorizing said portion of said account transactions requiring individual pre- authorization comprising the steps of: a) receiving an authorization table of an account established between a network user and an account issuer, said authorization table capable of having a pre-authorization transaction designator to denote said portion of account transactions that require said individual pre- authorization; b) receiving in a pre-authorization table within said authorization table as a result of a pre-authorization process by said network user at least one specified transaction parameter for association with said pre-authorization transaction designator; and c) authorizing said requested transaction when parameters from a requested transaction authorization are in conformity with each of said at least one specified transaction parameter.
6. In an account authorization system for facilitating the authorization of account transactions occurring in a network environment wherein a portion of said account transactions require individual pre-authorization, the method for authorizing said portion of account transactions requiring individual pre-authorization as recited in claim 5, wherein said receiving in a pre- authorization table step further comprises the step of receiving a quotation amount as said at least one specified transaction parameter describing a price boundary under which to authorize said requested transaction.
7. In an account authorization system for facilitating the authorization of account transactions occurring in a network environment wherein a portion of said account transactions require individual pre-authorization, the method for authorizing said portion of account transactions requiring individual pre-authorization as recited in claim 6, wherein said receiving a quotation amount as said at least one specified transaction parameter step further comprises the step of receiving a variance parameter designating an allowable deviation from said quotation amount as one of said at least one specified transaction parameters.
8. An account authorization system for facilitating the authorization of account transactions occurring in a network environment wherein said account transactions require individual pre-authorization, said system comprising: a) an account between a network user and an account issuer, said account having associated therewith an authorization table to designate said account transactions that require said individual pre-authorization; b) a pre-authorization table comprising at least one specified transaction parameter as required to authorize a requested transaction; and c) means for authorizing said requested transaction when in conformity with said at least one specified transaction parameter.
9. The account authorization system as recited in claim 8, wherein said at least one specified transaction parameter is a quotation amount describing a price to authorize said requested transaction.
10. The account authorization system as recited in claim 9, wherein said at least one specified transaction parameter further comprises a variance parameter from said quotation amount.
1 1. The account authorization system as recited in claim 8, wherein said means for authorizing said requested transaction comprises an authorizing agent for receiving said at least one specified transaction parameter, comparing said at least one specified transaction parameter against at least one corresponding requested transactions parameter and approving said requested transaction upon conformity therewith.
12. In an account authorization system for facilitating the authorization of account transactions occurring in a network environment wherein a portion of said account transactions require individual pre-authorization, a computer-readable medium having computer-executable instructions for authorizing said portion of account transactions requiring individual pre-authorization for performing the steps of: a) receiving an authorization table of an account established between a network user and an account issuer, said authorization table capable of having a pre-authorization transaction designator to denote said portion of account transactions that require said individual pre- authorization; b) receiving in a pre-authorization table within said authorization table as a result of a pre-authorization process by said network user at least one specified transaction parameter for association with said pre-authorization transaction designator; and c) authorizing said requested transaction when parameters from a requested transaction authorization are in conformity with each of said at least one specified transaction parameter.
1 3. The computer-readable medium of claim 12 having further computer- readable instructions wherein said receiving in a pre-authorization table step further comprises the step of receiving a quotation amount as said at least one specified transaction parameter describing a price boundary under which to authorize said requested transaction.
14. The computer-readable medium of claim 13 having further computer- readable instructions wherein said receiving a quotation amount as said at least one specified transaction parameter step further comprises the step of receiving a variance parameter designating an allowable deviation from said quotation amount as one of said at least one specified transaction parameters.
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
GB0028740A GB2353390B (en) | 1999-03-25 | 2000-03-24 | System and method for pre-authorization of individual account remote transactions |
CA002332955A CA2332955A1 (en) | 1999-03-24 | 2000-03-24 | System and method for pre-authorization of individual account remote transactions |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/276,289 | 1999-03-24 | ||
US09/276,289 US6226624B1 (en) | 1997-10-24 | 1999-03-25 | System and method for pre-authorization of individual account remote transactions |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2000057374A1 true WO2000057374A1 (en) | 2000-09-28 |
Family
ID=23056043
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US2000/007975 WO2000057374A1 (en) | 1999-03-24 | 2000-03-24 | System and method for pre-authorization of individual account remote transactions |
Country Status (4)
Country | Link |
---|---|
US (1) | US6226624B1 (en) |
CA (1) | CA2332955A1 (en) |
GB (1) | GB2353390B (en) |
WO (1) | WO2000057374A1 (en) |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2002183640A (en) * | 2000-12-14 | 2002-06-28 | Nippon Shinpan Co Ltd | Approval success determining method and settlement server system |
WO2002082392A2 (en) * | 2001-04-05 | 2002-10-17 | International Business Machines Corporation | Account-based transactions using personal authorization criteria |
JP2002342688A (en) * | 2001-05-17 | 2002-11-29 | Ricoh Co Ltd | Method for electric commerce, settlement proxy method, information issuing method of disposable and post-paying system and settlement requesting method |
EP1503329A2 (en) * | 2003-07-28 | 2005-02-02 | Menahem Kroll | Method and system for determining whether a situation is logically true or false upon occurrence of an event |
US7509289B2 (en) | 2002-02-11 | 2009-03-24 | Total System Services, Inc. | System and method for single event authorization control of transactions |
US8190484B2 (en) | 2001-03-12 | 2012-05-29 | Ricoh Company, Ltd. | Electronic commerce system and electronic commerce method |
Families Citing this family (204)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP0789883A4 (en) * | 1994-09-28 | 2002-07-31 | Gordon T Brown | Automated accounting system |
US7386485B1 (en) | 2004-06-25 | 2008-06-10 | West Corporation | Method and system for providing offers in real time to prospective customers |
US6055513A (en) | 1998-03-11 | 2000-04-25 | Telebuyer, Llc | Methods and apparatus for intelligent selection of goods and services in telephonic and electronic commerce |
US8315909B1 (en) | 1998-03-11 | 2012-11-20 | West Corporation | Methods and apparatus for intelligent selection of goods and services in point-of-sale commerce |
US7437313B1 (en) | 1998-03-11 | 2008-10-14 | West Direct, Llc | Methods, computer-readable media, and apparatus for offering users a plurality of scenarios under which to conduct at least one primary transaction |
US7364068B1 (en) | 1998-03-11 | 2008-04-29 | West Corporation | Methods and apparatus for intelligent selection of goods and services offered to conferees |
US7729945B1 (en) | 1998-03-11 | 2010-06-01 | West Corporation | Systems and methods that use geographic data to intelligently select goods and services to offer in telephonic and electronic commerce |
US6233389B1 (en) | 1998-07-30 | 2001-05-15 | Tivo, Inc. | Multimedia time warping system |
US7558472B2 (en) | 2000-08-22 | 2009-07-07 | Tivo Inc. | Multimedia signal processing system |
US6324526B1 (en) * | 1999-01-15 | 2001-11-27 | D'agostino John | System and method for performing secure credit card purchases |
US8131648B2 (en) * | 1999-10-20 | 2012-03-06 | Tivo Inc. | Electronic content distribution and exchange system |
US6728713B1 (en) | 1999-03-30 | 2004-04-27 | Tivo, Inc. | Distributed database management system |
DE19926472C2 (en) | 1999-06-10 | 2001-11-15 | Call A Bike Mobilitaetssysteme | Method of transmitting a code |
US7333955B2 (en) * | 2001-09-24 | 2008-02-19 | E2Interactive, Inc. | System and method for securing communication service |
EP1077436A3 (en) * | 1999-08-19 | 2005-06-22 | Citicorp Development Center, Inc. | System and method for performing an on-line transaction using a single-use payment instrument |
US8706630B2 (en) | 1999-08-19 | 2014-04-22 | E2Interactive, Inc. | System and method for securely authorizing and distributing stored-value card data |
EP1214842B1 (en) | 1999-09-20 | 2010-11-17 | TiVo, Inc. | Closed caption tagging system |
US7319986B2 (en) * | 1999-09-28 | 2008-01-15 | Bank Of America Corporation | Dynamic payment cards and related management systems and associated methods |
US7742967B1 (en) * | 1999-10-01 | 2010-06-22 | Cardinalcommerce Corporation | Secure and efficient payment processing system |
US9430769B2 (en) * | 1999-10-01 | 2016-08-30 | Cardinalcommerce Corporation | Secure and efficient payment processing system |
US8596527B2 (en) * | 1999-11-05 | 2013-12-03 | Lead Core Fund, L.L.C. | Methods for locating a payment system utilizing a point of sale device |
US8275704B2 (en) * | 1999-11-05 | 2012-09-25 | Lead Core Fund, L.L.C. | Systems and methods for authorizing an allocation of an amount between transaction accounts |
US20090164329A1 (en) * | 1999-11-05 | 2009-06-25 | American Express Travel Related Services Company, Inc. | Systems for Processing a Payment Authorization Request Utilizing a Network of Point of Sale Devices |
US8820633B2 (en) * | 1999-11-05 | 2014-09-02 | Lead Core Fund, L.L.C. | Methods for a third party biller to receive an allocated payment authorization request |
US20090048885A1 (en) * | 1999-11-05 | 2009-02-19 | American Express Travel Related Services Company, Inc. | Systems and Methods for Facilitating Cost-Splitting Transactions |
US8234212B2 (en) * | 1999-11-05 | 2012-07-31 | Lead Core Fund, L.L.C. | Systems and methods for facilitating transactions with interest |
US8190514B2 (en) * | 1999-11-05 | 2012-05-29 | Lead Core Fund, L.L.C. | Systems and methods for transaction processing based upon an overdraft scenario |
US7996307B2 (en) * | 1999-11-05 | 2011-08-09 | American Express Travel Related Services Company, Inc. | Systems and methods for facilitating transactions between different financial accounts |
US20090265249A1 (en) * | 1999-11-05 | 2009-10-22 | American Express Travel Related Services Company, Inc. | Systems and methods for split tender transaction processing |
US20090164331A1 (en) * | 1999-11-05 | 2009-06-25 | American Express Travel Related Services Company, Inc. | Systems for Locating a Payment System Utilizing a Point of Sale Device |
US20090265250A1 (en) * | 1999-11-05 | 2009-10-22 | American Express Travel Related Services Company, Inc. | Systems and methods for processing a transaction according to an allowance |
US8646685B2 (en) * | 1999-11-05 | 2014-02-11 | Lead Core Fund, L.L.C. | Device for allocating a payment authorization request to a payment processor |
US8103584B2 (en) * | 1999-11-05 | 2012-01-24 | American Express Travel Related Services Company, Inc. | Systems and methods for authorizing an allocation of an amount between transaction accounts |
US20090048887A1 (en) * | 1999-11-05 | 2009-02-19 | American Express Travel Related Services Company, Inc. | Systems and Methods for Facilitating Transactions Involving an Intermediary |
US20090265241A1 (en) * | 1999-11-05 | 2009-10-22 | American Express Travel Related Services Company, Inc. | Systems and methods for determining a rewards account to fund a transaction |
US20090164328A1 (en) * | 1999-11-05 | 2009-06-25 | American Express Travel Related Services Company, Inc. | Systems and Methods for Locating a Payment System and Determining a Taxing Authority Utilizing a Point of Sale Device |
US8851369B2 (en) * | 1999-11-05 | 2014-10-07 | Lead Core Fund, L.L.C. | Systems and methods for transaction processing using a smartcard |
US8195565B2 (en) * | 1999-11-05 | 2012-06-05 | Lead Core Fund, L.L.C. | Systems and methods for point of interaction based policy routing of transactions |
US8180706B2 (en) * | 1999-11-05 | 2012-05-15 | Lead Core Fund, L.L.C. | Systems and methods for maximizing a rewards accumulation strategy during transaction processing |
US20090164325A1 (en) * | 1999-11-05 | 2009-06-25 | American Express Travel Related Services Company, Inc. | Systems and Methods for Locating an Automated Clearing House Utilizing a Point of Sale Device |
US7979349B2 (en) * | 1999-11-05 | 2011-07-12 | American Express Travel Related Services Company, Inc. | Systems and methods for adjusting crediting limits to facilitate transactions |
US20090271278A1 (en) * | 1999-11-05 | 2009-10-29 | American Express Travel Related Services Company, Inc. | Systems and methods for routing a transaction request to a payment system via a transaction device |
US8794509B2 (en) * | 1999-11-05 | 2014-08-05 | Lead Core Fund, L.L.C. | Systems and methods for processing a payment authorization request over disparate payment networks |
US20090048886A1 (en) * | 1999-11-05 | 2009-02-19 | American Express Travel Related Services Company, Inc. | Systems and Methods for Facilitating Gifting Transactions |
US8814039B2 (en) * | 1999-11-05 | 2014-08-26 | Lead Core Fund, L.L.C. | Methods for processing a payment authorization request utilizing a network of point of sale devices |
US8073772B2 (en) * | 1999-11-05 | 2011-12-06 | American Express Travel Related Services Company, Inc. | Systems and methods for processing transactions using multiple budgets |
US8458086B2 (en) * | 1999-11-05 | 2013-06-04 | Lead Core Fund, L.L.C. | Allocating partial payment of a transaction amount using an allocation rule |
US8875990B2 (en) * | 1999-11-05 | 2014-11-04 | Lead Core Fund, L.L.C. | Systems and methods for allocating a payment authorization request to a payment processor |
US8103585B2 (en) * | 1999-11-05 | 2012-01-24 | American Express Travel Related Services Company, Inc. | Systems and methods for suggesting an allocation |
US6529880B1 (en) * | 1999-12-01 | 2003-03-04 | Intermec Ip Corp. | Automatic payment system for a plurality of remote merchants |
US7783537B1 (en) | 1999-12-01 | 2010-08-24 | Walker Digital, Llc | Method and apparatus for conditional payment to a seller |
JP3732699B2 (en) * | 1999-12-27 | 2006-01-05 | 富士通株式会社 | Electronic purchasing system and method |
US7308429B1 (en) * | 2000-02-08 | 2007-12-11 | Tozzi Mario S | Electronic withdrawal authorization store and forward for cash and credit accounts |
US8171520B2 (en) * | 2000-03-02 | 2012-05-01 | Tivo Inc. | Method of sharing personal media using a digital recorder |
US20010056409A1 (en) * | 2000-05-15 | 2001-12-27 | Bellovin Steven Michael | Offline one time credit card numbers for secure e-commerce |
US7702580B1 (en) | 2000-06-13 | 2010-04-20 | Fannie Mae | System and method for mortgage loan pricing, sale and funding |
US6988082B1 (en) | 2000-06-13 | 2006-01-17 | Fannie Mae | Computerized systems and methods for facilitating the flow of capital through the housing finance industry |
US7593893B1 (en) | 2000-06-13 | 2009-09-22 | Fannie Mae | Computerized systems and methods for facilitating the flow of capital through the housing finance industry |
US20020029192A1 (en) * | 2000-06-29 | 2002-03-07 | Hitachi, Ltd | Settlement method and system |
DK1356438T3 (en) | 2000-07-10 | 2014-09-22 | Paypal Inc | System and method for verifying a financial instrument |
US7398919B2 (en) | 2000-07-12 | 2008-07-15 | Tcf Financial Corporation | Transaction card system and approach |
US7383223B1 (en) * | 2000-09-20 | 2008-06-03 | Cashedge, Inc. | Method and apparatus for managing multiple accounts |
US20020174062A1 (en) * | 2001-05-16 | 2002-11-21 | Sines Randy D. | Purchasing on the internet using verified order information and bank payment assurance |
US7006986B1 (en) | 2000-09-25 | 2006-02-28 | Ecardless Bancorp, Ltd. | Order file processes for purchasing on the internet using verified order information |
US9202206B2 (en) | 2000-09-25 | 2015-12-01 | Ecardless Bancorp, Ltd. | Secure financial transaction processing using location information |
US20050038715A1 (en) * | 2000-09-25 | 2005-02-17 | Ecardless Bancorp Ltd. | Customer processing for purchasing on the internet using verified order information |
US7080048B1 (en) | 2000-09-25 | 2006-07-18 | Ecardless Bancorp, Ltd. | Purchasing on the internet using verified order information and bank payment assurance |
US7337144B1 (en) * | 2000-09-28 | 2008-02-26 | Microsoft Corporation | Method and system for restricting the usage of payment accounts |
US8145567B2 (en) | 2000-10-31 | 2012-03-27 | Wells Fargo Bank, N.A. | Transaction ID system and process |
US6752313B1 (en) * | 2000-11-14 | 2004-06-22 | Online Data Corp. | Method and system for establishing a credit card transaction processing merchant account |
US6839692B2 (en) * | 2000-12-01 | 2005-01-04 | Benedor Corporation | Method and apparatus to provide secure purchase transactions over a computer network |
US20020087463A1 (en) * | 2000-12-28 | 2002-07-04 | First Data Corporation | Method and system for authorizing negotiable instrument encashment |
US7114177B2 (en) * | 2001-03-28 | 2006-09-26 | Geotrust, Inc. | Web site identity assurance |
US7739162B1 (en) | 2001-05-04 | 2010-06-15 | West Corporation | System, method, and business method for setting micropayment transaction to a pre-paid instrument |
US6796497B2 (en) | 2002-04-23 | 2004-09-28 | American Express Travel Related Services Company, Inc. | System and method for facilitating a subsidiary card account |
US7899742B2 (en) * | 2001-05-29 | 2011-03-01 | American Express Travel Related Services Company, Inc. | System and method for facilitating a subsidiary card account |
US7401049B2 (en) * | 2001-05-29 | 2008-07-15 | American Express Travel Related Services Company, Inc. | System and method for a prepaid card issued by a foreign financial institution |
US7249092B2 (en) * | 2001-05-29 | 2007-07-24 | American Express Travel Related Services Company, Inc. | System and method for facilitating a subsidiary card account with controlled spending capability |
US7174302B2 (en) | 2001-06-11 | 2007-02-06 | Evolution Benefits, Inc. | System and method for processing flexible spending account transactions |
CA2463504C (en) * | 2001-10-12 | 2013-02-19 | Geo Trust, Inc. | Methods and systems for automated authentication, processing and issuance of digital certificates |
US7415471B1 (en) | 2001-11-30 | 2008-08-19 | Midland Loan Services, Inc. | Methods and systems for automated data collection and analysis for use in association with asset securitization |
CA2364142A1 (en) * | 2001-11-30 | 2003-05-30 | Ibm Canada Limited-Ibm Canada Limitee | Authorizing multiple categories of card based financial transactions |
GB2384096A (en) * | 2001-12-01 | 2003-07-16 | Grass Roots Group Uk Ltd | Payment system and related methods |
US7805376B2 (en) * | 2002-06-14 | 2010-09-28 | American Express Travel Related Services Company, Inc. | Methods and apparatus for facilitating a transaction |
US6901387B2 (en) | 2001-12-07 | 2005-05-31 | General Electric Capital Financial | Electronic purchasing method and apparatus for performing the same |
US20090177563A1 (en) * | 2001-12-07 | 2009-07-09 | American Express Travel Related Services Company, Inc. | Authorization refresh system and method |
US7577585B2 (en) * | 2001-12-07 | 2009-08-18 | American Express Travel Related Services Company, Inc. | Method and system for completing transactions involving partial shipments |
US7729963B1 (en) | 2001-12-28 | 2010-06-01 | The Pnc Financial Services Group, Inc. | Methods and systems for processing and communicating financial transaction data |
US7937305B1 (en) | 2001-12-28 | 2011-05-03 | The Pnc Financial Services Group, Inc. | Methods and systems for analyzing the status of an entity and its financial transactions |
US7389275B2 (en) * | 2002-03-05 | 2008-06-17 | Visa U.S.A. Inc. | System for personal authorization control for card transactions |
US20030187765A1 (en) * | 2002-03-27 | 2003-10-02 | First Data Corporation | Systems and methods for monitoring credit risk |
US20070239614A1 (en) * | 2002-07-10 | 2007-10-11 | Union Beach, L.P. | System and method for the storage of data in association with financial accounts |
US20040015371A1 (en) * | 2002-07-16 | 2004-01-22 | Zachary Thomas | System and method for managing job applicant data |
US20060146839A1 (en) * | 2002-09-06 | 2006-07-06 | Hurwitz Harlan A | Payment and media management |
WO2004023258A2 (en) * | 2002-09-06 | 2004-03-18 | De La Rue International Limited | Exception reporting and management |
US7765135B2 (en) * | 2002-09-06 | 2010-07-27 | Talaris Holdings Limited | Count and login management |
US20050246277A1 (en) * | 2002-10-23 | 2005-11-03 | Bloem Nicolaas C | Transaction processing system |
US7937302B1 (en) * | 2002-11-20 | 2011-05-03 | The Pnc Financial Services Group, Inc. | Methods and systems for monitoring, analyzing and reporting information in association with collateralized financial instruments |
US20050102226A1 (en) * | 2002-12-30 | 2005-05-12 | Dror Oppenheimer | System and method of accounting for mortgage related transactions |
US7742981B2 (en) * | 2002-12-30 | 2010-06-22 | Fannie Mae | Mortgage loan commitment system and method |
AU2003295787A1 (en) * | 2002-12-30 | 2004-07-29 | Fannie Mae | System and method for facilitating delivery of a loan to a secondary mortgage market purchaser |
WO2004061556A2 (en) * | 2002-12-30 | 2004-07-22 | Fannie Mae | System and method of processing data pertaining to financial assets |
WO2004061565A2 (en) * | 2002-12-30 | 2004-07-22 | Fannie Mae | System and method for facilitating sale of a loan to a secondary market purchaser |
US8666879B1 (en) | 2002-12-30 | 2014-03-04 | Fannie Mae | Method and system for pricing forward commitments for mortgage loans and for buying committed loans |
US20050080722A1 (en) * | 2002-12-30 | 2005-04-14 | Kemper John L. | Online system for delivery of loans to a secondary market purchaser |
US20040128230A1 (en) | 2002-12-30 | 2004-07-01 | Fannie Mae | System and method for modifying attribute data pertaining to financial assets in a data processing system |
WO2004060040A2 (en) * | 2002-12-30 | 2004-07-22 | Fannie Mae | System and method for processing data pertaining to financial assets |
US7593889B2 (en) * | 2002-12-30 | 2009-09-22 | Fannie Mae | System and method for processing data pertaining to financial assets |
US7885889B2 (en) | 2002-12-30 | 2011-02-08 | Fannie Mae | System and method for processing data pertaining to financial assets |
WO2004061557A2 (en) * | 2002-12-30 | 2004-07-22 | Fannie Mae | System and method for creating and tracking agreements for selling loans to a secondary market purchaser |
AU2003295771A1 (en) * | 2002-12-30 | 2004-07-29 | Fannie Mae | System and method for defining loan products |
WO2004061564A2 (en) * | 2002-12-30 | 2004-07-22 | Fannie Mae | System and method for pricing loans in the secondary mortgage market |
US8306908B1 (en) | 2002-12-31 | 2012-11-06 | West Corporation | Methods and apparatus for intelligent selection of goods and services in telephonic and electronic commerce |
US9307884B1 (en) | 2003-01-27 | 2016-04-12 | The Pnc Financial Services Group, Inc. | Visual asset structuring tool |
US7856399B2 (en) * | 2003-02-05 | 2010-12-21 | Propay Usa. Inc. | Linking a merchant account with a financial card |
US8712857B1 (en) | 2003-03-31 | 2014-04-29 | Tuxis Technologies Llc | Methods and apparatus for intelligent selection of goods and services in mobile commerce |
GB0308102D0 (en) * | 2003-04-08 | 2003-05-14 | Secure Transaction Proc Ltd | System for secure transactions |
US7895119B2 (en) * | 2003-05-13 | 2011-02-22 | Bank Of America Corporation | Method and system for pushing credit payments as buyer initiated transactions |
US20040230526A1 (en) * | 2003-05-13 | 2004-11-18 | Praisner C. Todd | Payment control system and associated method for facilitating credit payments in the accounts payable environment |
US7765153B2 (en) * | 2003-06-10 | 2010-07-27 | Kagi, Inc. | Method and apparatus for verifying financial account information |
US8046298B1 (en) | 2003-07-21 | 2011-10-25 | Fannie Mae | Systems and methods for facilitating the flow of capital through the housing finance industry |
US8396792B1 (en) | 2003-09-10 | 2013-03-12 | Propay Usa. Inc. | Dynamically specifying a merchant identifier in an electronic financial transaction |
US20050097015A1 (en) * | 2003-10-30 | 2005-05-05 | Wilkes W. B. | Electronic financial transactions with portable merchant accounts |
US8655309B2 (en) | 2003-11-14 | 2014-02-18 | E2Interactive, Inc. | Systems and methods for electronic device point-of-sale activation |
US8489498B1 (en) | 2003-12-01 | 2013-07-16 | Fannie Mae | System and method for processing a loan |
US7657475B1 (en) | 2003-12-31 | 2010-02-02 | Fannie Mae | Property investment rating system and method |
US7822680B1 (en) | 2003-12-31 | 2010-10-26 | Fannie Mae | System and method for managing data pertaining to a plurality of financial assets for multifamily and housing developments |
US20050171908A1 (en) * | 2004-01-29 | 2005-08-04 | Carlsen James K. | System and method for aggregating and delegating signature authority to third parties in commercial transactions |
US20050203843A1 (en) * | 2004-03-12 | 2005-09-15 | Wood George L. | Internet debit system |
US7413112B2 (en) * | 2004-03-16 | 2008-08-19 | American Express Travel Related Services Company, Inc. | Method and system for manual authorization |
US7694135B2 (en) * | 2004-07-16 | 2010-04-06 | Geotrust, Inc. | Security systems and services to provide identity and uniform resource identifier verification |
US20060026097A1 (en) * | 2004-07-30 | 2006-02-02 | Kagi, Inc. | Method and apparatus for verifying a financial instrument |
US7321877B2 (en) * | 2004-09-29 | 2008-01-22 | International Business Machines Corporation | Managing a virtual persona through selective association |
US7178720B1 (en) | 2004-09-30 | 2007-02-20 | West Corporation | Methods, computer-readable media, and computer program product for intelligent selection of items encoded onto portable machine-playable entertainment media |
US20060089906A1 (en) * | 2004-10-21 | 2006-04-27 | Michael Rowley | Method for securing a payment transaction over a public network |
AU2005306361B2 (en) * | 2004-11-19 | 2011-02-10 | Tivo Inc. | Method and apparatus for secure transfer of previously broadcasted content |
US8365293B2 (en) * | 2005-01-25 | 2013-01-29 | Redphone Security, Inc. | Securing computer network interactions between entities with authorization assurances |
CA2542068C (en) * | 2005-04-05 | 2016-01-26 | Dxstorm.Com Inc. | Electronic balance checking and credit approval system for use in conducting electronic transactions |
US7801809B1 (en) | 2005-06-24 | 2010-09-21 | Fannie Mae | System and method for management of delegated real estate project reviews |
US7588181B2 (en) | 2005-09-07 | 2009-09-15 | Ty Shipman | Method and apparatus for verifying the legitamacy of a financial instrument |
EP1783709A1 (en) * | 2005-10-06 | 2007-05-09 | First Data Corporation | System and method for executing electronic transactions |
US20070100748A1 (en) * | 2005-10-19 | 2007-05-03 | Sanjeev Dheer | Multi-channel transaction system for transferring assets between accounts at different financial institutions |
US7828204B2 (en) * | 2006-02-01 | 2010-11-09 | Mastercard International Incorporated | Techniques for authorization of usage of a payment device |
US7747526B1 (en) | 2006-03-27 | 2010-06-29 | Fannie Mae | System and method for transferring mortgage loan servicing rights |
US7818264B2 (en) | 2006-06-19 | 2010-10-19 | Visa U.S.A. Inc. | Track data encryption |
US20070294164A1 (en) * | 2006-05-26 | 2007-12-20 | Total System Services, Inc. | Credit account management |
US20070100773A1 (en) * | 2006-08-11 | 2007-05-03 | Regions Asset Company | Transaction security system having user defined security parameters |
US7698220B2 (en) | 2006-09-14 | 2010-04-13 | E2Interactive, Inc. | Virtual terminal for payment processing |
WO2008039942A1 (en) * | 2006-09-27 | 2008-04-03 | Electronic Commerce Protection Corporation | Mechanism for fraud-resistant consumer transactions |
EP2078285A4 (en) * | 2006-09-29 | 2010-08-11 | Dun & Bradstreet Corp | Process and system for the automated collection of business information directly from a business entity's accounting system |
US20080082626A1 (en) * | 2006-09-29 | 2008-04-03 | Microsoft Corporation | Typed authorization data |
US7739197B2 (en) * | 2006-10-05 | 2010-06-15 | International Business Machines Corporation | Guest limited authorization for electronic financial transaction cards |
US10068220B2 (en) | 2006-10-11 | 2018-09-04 | Visa International Service Association | Systems and methods for brokered authentication express seller links |
TW200834446A (en) | 2006-10-11 | 2008-08-16 | Visa Int Service Ass | Method and system for processing micropayment transactions |
US7606766B2 (en) * | 2006-12-21 | 2009-10-20 | American Express Travel Related Services Company, Inc. | Computer system and computer-implemented method for selecting invoice settlement options |
US20080208748A1 (en) * | 2006-12-22 | 2008-08-28 | Frank Ozment | Transaction system and method |
US8566240B2 (en) * | 2007-01-16 | 2013-10-22 | E2Interactive, Inc. | Systems and methods for the payment of customer bills utilizing payment platform of biller |
US20080172331A1 (en) * | 2007-01-16 | 2008-07-17 | Graves Phillip C | Bill Payment Card Method and System |
US7810134B2 (en) | 2007-01-22 | 2010-10-05 | First Data Corporation | Authentication system for financial transactions |
WO2008137748A1 (en) * | 2007-05-02 | 2008-11-13 | Cashedge, Inc. | Multi-channel and cross-channel account opening |
US8818879B2 (en) * | 2007-09-04 | 2014-08-26 | First Data Corporation | Data element specific transaction routing |
US9292850B2 (en) * | 2007-09-10 | 2016-03-22 | Visa U.S.A. Inc. | Host capture |
US8286186B2 (en) * | 2008-04-14 | 2012-10-09 | International Business Machines Corporation | System and method for extensible data interface for shared service module |
US8219489B2 (en) * | 2008-07-29 | 2012-07-10 | Visa U.S.A. Inc. | Transaction processing using a global unique identifier |
US20100125526A1 (en) * | 2008-11-14 | 2010-05-20 | Crossloop Inc. | Three Party Services Transaction System |
US8725601B2 (en) * | 2008-11-21 | 2014-05-13 | Pscu Financial Services | Method and apparatus for consumer driven protection for payment card transactions |
US7827108B2 (en) * | 2008-11-21 | 2010-11-02 | Visa U.S.A. Inc. | System and method of validating a relationship between a user and a user account at a financial institution |
FR2940489B1 (en) * | 2008-12-22 | 2021-05-28 | Compagnie Ind Et Financiere Dingenierie Ingenico | ASSISTANCE PROCESS FOR THE CONTROL OF TRANSACTION RECORDS, TRANSACTION DEVICE, SERVER, MOBILE TERMINAL AND CORRESPONDING COMPUTER PROGRAMS. |
US8447687B2 (en) * | 2009-03-30 | 2013-05-21 | Albert OGRODSKI | Method and system for centralized identity and account controls |
US20100276484A1 (en) * | 2009-05-01 | 2010-11-04 | Ashim Banerjee | Staged transaction token for merchant rating |
BRPI1014111A2 (en) | 2009-05-04 | 2016-04-12 | Visa Int Service Ass | method for providing an incentive to a consumer, computer program product, and, computer system. |
US20100318463A1 (en) * | 2009-06-12 | 2010-12-16 | Mastercard International Incorporated | Method and apparatus for addressing issuer hold for automated fuel dispenser transactions in an electronic payment system |
US8676639B2 (en) | 2009-10-29 | 2014-03-18 | Visa International Service Association | System and method for promotion processing and authorization |
US20110106674A1 (en) * | 2009-10-29 | 2011-05-05 | Jeffrey William Perlman | Optimizing Transaction Scenarios With Automated Decision Making |
US8280788B2 (en) | 2009-10-29 | 2012-10-02 | Visa International Service Association | Peer-to-peer and group financial management systems and methods |
US20110137740A1 (en) | 2009-12-04 | 2011-06-09 | Ashmit Bhattacharya | Processing value-ascertainable items |
US10255591B2 (en) * | 2009-12-18 | 2019-04-09 | Visa International Service Association | Payment channel returning limited use proxy dynamic value |
CN102298758A (en) * | 2010-06-22 | 2011-12-28 | 安智金融与工业公司 | Method for assisting to inspect transaction record as well as relevant equipment and computer program thereof |
US9911154B2 (en) | 2010-07-08 | 2018-03-06 | Mastercard International Incorporated | Apparatus and method for dynamic offline balance management for preauthorized smart cards |
US10692081B2 (en) | 2010-12-31 | 2020-06-23 | Mastercard International Incorporated | Local management of payment transactions |
US10586227B2 (en) | 2011-02-16 | 2020-03-10 | Visa International Service Association | Snap mobile payment apparatuses, methods and systems |
CN109118199A (en) | 2011-02-16 | 2019-01-01 | 维萨国际服务协会 | Snap mobile payment device, method and system |
US8856043B2 (en) * | 2011-02-18 | 2014-10-07 | Visa International Service Association | Method and system for managing data and enabling payment transactions between multiple entities |
SG193510A1 (en) | 2011-02-22 | 2013-10-30 | Visa Int Service Ass | Universal electronic payment apparatuses, methods and systems |
US9582598B2 (en) | 2011-07-05 | 2017-02-28 | Visa International Service Association | Hybrid applications utilizing distributed models and views apparatuses, methods and systems |
WO2013006725A2 (en) | 2011-07-05 | 2013-01-10 | Visa International Service Association | Electronic wallet checkout platform apparatuses, methods and systems |
US9355393B2 (en) | 2011-08-18 | 2016-05-31 | Visa International Service Association | Multi-directional wallet connector apparatuses, methods and systems |
US10242358B2 (en) | 2011-08-18 | 2019-03-26 | Visa International Service Association | Remote decoupled application persistent state apparatuses, methods and systems |
US9710807B2 (en) | 2011-08-18 | 2017-07-18 | Visa International Service Association | Third-party value added wallet features and interfaces apparatuses, methods and systems |
US10825001B2 (en) | 2011-08-18 | 2020-11-03 | Visa International Service Association | Multi-directional wallet connector apparatuses, methods and systems |
US10223730B2 (en) | 2011-09-23 | 2019-03-05 | Visa International Service Association | E-wallet store injection search apparatuses, methods and systems |
AU2013214801B2 (en) | 2012-02-02 | 2018-06-21 | Visa International Service Association | Multi-source, multi-dimensional, cross-entity, multimedia database platform apparatuses, methods and systems |
US11694171B2 (en) * | 2012-02-15 | 2023-07-04 | Ingo Money, Inc. | Funds network and method |
US20140025571A1 (en) * | 2012-07-23 | 2014-01-23 | Its, Inc. | System and method for dual message consumer authentication value-based eft transactions |
US20140258008A1 (en) * | 2013-03-07 | 2014-09-11 | Ebay Inc. | Systems, Methods, And Computer Program Products Providing Designation Of Money With An Account |
US20150134302A1 (en) | 2013-11-14 | 2015-05-14 | Jatin Chhugani | 3-dimensional digital garment creation from planar garment photographs |
US10366439B2 (en) | 2013-12-27 | 2019-07-30 | Ebay Inc. | Regional item reccomendations |
US20150332251A1 (en) * | 2014-05-16 | 2015-11-19 | Datavi, LLC | Methods and Systems for Managing Payments Between Payor and Payee |
US10592900B2 (en) | 2014-06-13 | 2020-03-17 | Sungard Avantgard Llc | Systems and methods for authenticating and providing payment to a supplier |
US20160092956A1 (en) | 2014-09-30 | 2016-03-31 | Jonathan Su | Garment size mapping |
US10803428B2 (en) * | 2015-08-10 | 2020-10-13 | Greenlight Financial Technology, Inc. | Method, non-transitory computer-readable medium, and system for payment approval |
CN107392499A (en) | 2017-08-10 | 2017-11-24 | 成都牵牛草信息技术有限公司 | Approval process and its method for approval node mandate are carried out to user |
US11113691B2 (en) * | 2018-09-25 | 2021-09-07 | American Express Travel Related Services Company, Inc. | Voice interface transaction system using audio signals |
US11132692B2 (en) | 2019-03-08 | 2021-09-28 | International Business Machines Corporation | Shared voting for accounting |
Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4812628A (en) * | 1985-05-02 | 1989-03-14 | Visa International Service Association | Transaction system with off-line risk assessment |
US4874932A (en) * | 1987-09-26 | 1989-10-17 | Omron Tateisi Electronics Co. | Card authorization terminal |
US5500513A (en) * | 1994-05-11 | 1996-03-19 | Visa International | Automated purchasing control system |
EP0745961A2 (en) * | 1995-05-31 | 1996-12-04 | AT&T IPM Corp. | Transaction authorization and alert system |
WO1997022073A1 (en) * | 1995-12-12 | 1997-06-19 | Citibank, N.A. | System and method for performing on-line reviews and approvals of credit and liability applications |
US5649116A (en) * | 1995-03-30 | 1997-07-15 | Servantis Systems, Inc. | Integrated decision management system |
US5797133A (en) * | 1994-08-31 | 1998-08-18 | Strategic Solutions Group, Inc | Method for automatically determining the approval status of a potential borrower |
WO1999014711A2 (en) * | 1997-09-17 | 1999-03-25 | Andrasev Akos | Method for checking rightful use of a debit card or similar means giving right of disposing of a bank account |
Family Cites Families (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US3719927A (en) | 1970-12-28 | 1973-03-06 | Trw Data Syst Inc | Credit control system |
US4417136A (en) | 1981-08-05 | 1983-11-22 | Ncr Canada Ltd - Ncr Canada Ltee | Method and apparatus for improving bank operation productivity |
JPH0642244B2 (en) | 1982-07-09 | 1994-06-01 | オムロン株式会社 | Margin transaction processing device |
US4491725A (en) | 1982-09-29 | 1985-01-01 | Pritchard Lawrence E | Medical insurance verification and processing system |
US4734564A (en) | 1985-05-02 | 1988-03-29 | Visa International Service Association | Transaction system with off-line risk assessment |
US5070452A (en) | 1987-06-30 | 1991-12-03 | Ngs American, Inc. | Computerized medical insurance system including means to automatically update member eligibility files at pre-established intervals |
US4916611A (en) | 1987-06-30 | 1990-04-10 | Northern Group Services, Inc. | Insurance administration system with means to allow an employer to directly communicate employee status data to centralized data storage means |
US4891503A (en) | 1988-03-29 | 1990-01-02 | Gascard, Inc. | Distributed authorization system |
US5301105A (en) | 1991-04-08 | 1994-04-05 | Desmond D. Cummings | All care health management system |
US5832447A (en) | 1994-05-24 | 1998-11-03 | Envoy Corporation | Automated system and method for providing real-time verification of health insurance eligibility |
US5826241A (en) | 1994-09-16 | 1998-10-20 | First Virtual Holdings Incorporated | Computerized system for making payments and authenticating transactions over the internet |
US5732400A (en) | 1995-01-04 | 1998-03-24 | Citibank N.A. | System and method for a risk-based purchase of goods |
US5781632A (en) | 1995-02-08 | 1998-07-14 | Odom; Gregory Glen | Method and apparatus for secured transmission of confidential data over an unsecured network |
US5748908A (en) | 1995-06-07 | 1998-05-05 | Yu; Mason K. | Automated, classified expenditure data card recording system |
US5790677A (en) | 1995-06-29 | 1998-08-04 | Microsoft Corporation | System and method for secure electronic commerce transactions |
JP2942478B2 (en) | 1995-09-14 | 1999-08-30 | 日立ソフトウエアエンジニアリング株式会社 | Network billing method |
US5757917A (en) | 1995-11-01 | 1998-05-26 | First Virtual Holdings Incorporated | Computerized payment system for purchasing goods and services on the internet |
JP3133243B2 (en) | 1995-12-15 | 2001-02-05 | 株式会社エヌケーインベストメント | Online shopping system |
US5822737A (en) | 1996-02-05 | 1998-10-13 | Ogram; Mark E. | Financial transaction system |
US5850446A (en) | 1996-06-17 | 1998-12-15 | Verifone, Inc. | System, method and article of manufacture for virtual point of sale processing utilizing an extensible, flexible architecture |
US5825881A (en) | 1996-06-28 | 1998-10-20 | Allsoft Distributing Inc. | Public network merchandising system |
-
1999
- 1999-03-25 US US09/276,289 patent/US6226624B1/en not_active Expired - Lifetime
-
2000
- 2000-03-24 GB GB0028740A patent/GB2353390B/en not_active Expired - Fee Related
- 2000-03-24 CA CA002332955A patent/CA2332955A1/en not_active Abandoned
- 2000-03-24 WO PCT/US2000/007975 patent/WO2000057374A1/en unknown
Patent Citations (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4812628A (en) * | 1985-05-02 | 1989-03-14 | Visa International Service Association | Transaction system with off-line risk assessment |
US4874932A (en) * | 1987-09-26 | 1989-10-17 | Omron Tateisi Electronics Co. | Card authorization terminal |
US5500513A (en) * | 1994-05-11 | 1996-03-19 | Visa International | Automated purchasing control system |
US5621201A (en) * | 1994-05-11 | 1997-04-15 | Visa International | Automated purchasing control system |
US5797133A (en) * | 1994-08-31 | 1998-08-18 | Strategic Solutions Group, Inc | Method for automatically determining the approval status of a potential borrower |
US5649116A (en) * | 1995-03-30 | 1997-07-15 | Servantis Systems, Inc. | Integrated decision management system |
EP0745961A2 (en) * | 1995-05-31 | 1996-12-04 | AT&T IPM Corp. | Transaction authorization and alert system |
WO1997022073A1 (en) * | 1995-12-12 | 1997-06-19 | Citibank, N.A. | System and method for performing on-line reviews and approvals of credit and liability applications |
WO1999014711A2 (en) * | 1997-09-17 | 1999-03-25 | Andrasev Akos | Method for checking rightful use of a debit card or similar means giving right of disposing of a bank account |
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2002183640A (en) * | 2000-12-14 | 2002-06-28 | Nippon Shinpan Co Ltd | Approval success determining method and settlement server system |
JP4508406B2 (en) * | 2000-12-14 | 2010-07-21 | 三菱Ufjニコス株式会社 | Payment server system |
US8190484B2 (en) | 2001-03-12 | 2012-05-29 | Ricoh Company, Ltd. | Electronic commerce system and electronic commerce method |
WO2002082392A2 (en) * | 2001-04-05 | 2002-10-17 | International Business Machines Corporation | Account-based transactions using personal authorization criteria |
WO2002082392A3 (en) * | 2001-04-05 | 2003-07-31 | Ibm | Account-based transactions using personal authorization criteria |
JP2002342688A (en) * | 2001-05-17 | 2002-11-29 | Ricoh Co Ltd | Method for electric commerce, settlement proxy method, information issuing method of disposable and post-paying system and settlement requesting method |
JP4616510B2 (en) * | 2001-05-17 | 2011-01-19 | 株式会社リコー | Electronic commerce method, payment agent method, disposable postpaid method information issuance method, and payment request method |
US7509289B2 (en) | 2002-02-11 | 2009-03-24 | Total System Services, Inc. | System and method for single event authorization control of transactions |
EP1503329A2 (en) * | 2003-07-28 | 2005-02-02 | Menahem Kroll | Method and system for determining whether a situation is logically true or false upon occurrence of an event |
EP1503329A3 (en) * | 2003-07-28 | 2006-05-17 | Menahem Kroll | Method and system for determining whether a situation is logically true or false upon occurrence of an event |
Also Published As
Publication number | Publication date |
---|---|
US6226624B1 (en) | 2001-05-01 |
CA2332955A1 (en) | 2000-09-28 |
GB2353390A (en) | 2001-02-21 |
GB2353390B (en) | 2003-11-12 |
GB0028740D0 (en) | 2001-01-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6226624B1 (en) | System and method for pre-authorization of individual account remote transactions | |
US5991750A (en) | System and method for pre-authorization of individual account transactions | |
US7472827B2 (en) | Limited use PIN system and method | |
US7835960B2 (en) | System for facilitating a transaction | |
US7676432B2 (en) | Methods and apparatus for transacting electronic commerce using account hierarchy and locking of accounts | |
US8036988B2 (en) | System and method for performing secure credit card transactions | |
US7496541B2 (en) | System for anonymous purchase of goods by providing a plurality of active account numbers | |
US8041646B2 (en) | Method and system for real time online debit transactions | |
US6208978B1 (en) | System and method for issuing security deposit guarantees based on credit card accounts | |
US9430769B2 (en) | Secure and efficient payment processing system | |
KR100841750B1 (en) | Electronic funds transfers-zipfund | |
AU775065B2 (en) | Payment method and system for online commerce | |
US20020123935A1 (en) | Secure commerce system and method | |
US20020103767A1 (en) | Transaction and logistics integrated management system (TALISMAN) for secure credit card payment and verified transaction delivery | |
AU2005100221A4 (en) | Credit card transaction processing |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AK | Designated states |
Kind code of ref document: A1 Designated state(s): CA GB |
|
ENP | Entry into the national phase |
Ref document number: 2332955 Country of ref document: CA |
|
ENP | Entry into the national phase |
Ref country code: GB Ref document number: 200028740 Kind code of ref document: A Format of ref document f/p: F |