WO2001084517A2 - Systeme et procede de transactions securisees sur reseau - Google Patents

Systeme et procede de transactions securisees sur reseau Download PDF

Info

Publication number
WO2001084517A2
WO2001084517A2 PCT/US2001/013814 US0113814W WO0184517A2 WO 2001084517 A2 WO2001084517 A2 WO 2001084517A2 US 0113814 W US0113814 W US 0113814W WO 0184517 A2 WO0184517 A2 WO 0184517A2
Authority
WO
WIPO (PCT)
Prior art keywords
consumer
transaction
payment
information
authentication process
Prior art date
Application number
PCT/US2001/013814
Other languages
English (en)
Other versions
WO2001084517A3 (fr
Inventor
Michele Malconian
Original Assignee
Equifax, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Equifax, Inc. filed Critical Equifax, Inc.
Priority to AU2001257415A priority Critical patent/AU2001257415A1/en
Publication of WO2001084517A2 publication Critical patent/WO2001084517A2/fr
Publication of WO2001084517A3 publication Critical patent/WO2001084517A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/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/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems

Definitions

  • the invention relates to the field of electronic commerce, and more particularly to a payment engine for networked transactions permitting a selection of check or other cash account, credit card account and other credit, debit or other payment options using authenticated payment channels.
  • the present invention provides systems and methods for a merchant to authenticate a consumer and to accept on-line payments from the consumer.
  • the system authenticates the consumer and creates a certainty score for this consumer. This certainty score may affect the level of on-line credit granted by the merchant.
  • the on-line payment system utilizes risk parameters to determine whether to authorizes an online payment request.
  • the invention in one embodiment may deploy a suite of transaction services including secure authentication, point of sale retail promotions, check warranty and check verification/self-risk functions, Automated Clearing House (ACH) settlement, collection services and complete credit card services for the Internet and other use.
  • ACH Automated Clearing House
  • the invention in another regard may support transaction settlement, private label card issuance and processing and other affinity or marketing programs.
  • the invention may support initiation, verification, and payment completion through a variety of networked or non-networked channels, such as virtual storefronts or mail/telephone order.
  • the invention may be implemented in a modular fashion to allow the transaction services to be unbundled in order to meet specific client needs.
  • the invention furthermore allows checks to be authorized by telephone or by fax, and settled electronically.
  • the invention may record authentication information on a relational database along with the consumer's driver's license, state, date of birth and full MICR information, which may become part of a new comprehensive consumer database. It is consequently one object of the invention to provide an electronic payment system capable of complete transaction support, including to provide electronic retail
  • ACH Automated Clearing House Association
  • Figure 1 illustrates payment architecture according to one embodiment of the invention.
  • FIG. 2 illustrates a flowchart of payment processing according to an embodiment of the invention.
  • Figure 3 illustrates a user process according to another embodiment of the present invention.
  • Figure 4 illustrates an authentication process according to an embodiment of the present invention.
  • Figure 5 illustrates a payment process according to an embodiment of the present invention.
  • a consumer operating a client device 102 may access a transaction vendor 106 via a communications link 104 to investigate or execute an electronic transaction, such as a purchase, rental or other transaction over the Internet or other network.
  • the transaction vendor 106 may be an electronic retailer such as Amazon.comTM, a catalog retailer such as Service MerchandizeTM, or a traditional retailer with a storefront who has a web presence on the Internet.
  • the transaction vendor 106 generally subscribes to a secure network transaction service from a service provider. However, the transaction vendor 106 can also be the service provider.
  • the client device 102 may be or include, for instance, a personal computer running the Microsoft Windows 95, 98, Millenium , or 2000, Windows CE , PalmOS , Unix, Linux, Solaris , OS/2 , BeOS , MacOS or other operating system or platform.
  • Client device 102 may also be or include a network-enabled appliance such as a WebTV unit, radio-enabled Palm Pilot or similar unit, a set-top box, a networkable game-playing console such as Sony Playstation or Sega Dreamcast , a browser-equipped cellular telephone, or other TCP/IP client or other device.
  • a network-enabled appliance such as a WebTV unit, radio-enabled Palm Pilot or similar unit, a set-top box, a networkable game-playing console such as Sony Playstation or Sega Dreamcast , a browser-equipped cellular telephone, or other TCP/IP client or other device.
  • the communications link 104 over which the client device 102 communicates with the transaction vendor 106 may be, include or interface to any one or more of, for instance, the Internet, an intranet, a PAN (Personal Area Network), a LAN (Local Area Network), a WAN (Wide Area Network) or a MAN (Metropolitan Area Network), a frame relay connection, an Advanced Intelligent Network (AIN) connection, a synchronous optical network (SONET) connection, a digital Tl, T3, El or E3 line,
  • AIN Advanced Intelligent Network
  • SONET synchronous optical network
  • DDS Digital Data Service
  • DSL Digital Subscriber Line
  • Ethernet connection
  • ISDN Integrated Services Digital network
  • dial-up port such as a V.90, N.34 or V.24bis analog modem connection
  • cable modem an ATM (Asynchronous Transfer Mode) connection
  • FDDI Fiber Distributed Data Interface
  • CDDI Copper Distributed Data Interface
  • Communications link 104 may furthermore be, include or interface to any one or more of a WAP (Wireless Application Protocol) link, a GPRS (General Packet Radio Service) link, a GSM (Global System for Mobil Communication) link, a CDMA (Code Division Multiple Access) or TDMA (Time Division Multiple Access) link such as a cellular phone channel, a GPS (Global Positioning System) link, CDPD (cellular digital packet data), a RIM (Research in Motion, Limited) duplex paging type device, a Bluetooth radio link, or an IEEE 802.11 -based radio frequency link.
  • WAP Wireless Application Protocol
  • GPRS General Packet Radio Service
  • GSM Global System for Mobil Communication
  • CDMA Code Division Multiple Access
  • TDMA Time Division Multiple Access
  • a cellular phone channel such as a cellular phone channel
  • GPS Global Positioning System
  • CDPD cellular digital packet data
  • RIM Research in Motion, Limited
  • Communications link 104 may yet further be, include or interface to any one or more of an RS-232 serial connection an IEEE- 1394 (Firewire) connection, a Fibre Channel connection, an IrDA, (infrared) port, a SCSI (Small Computer Systems Interface) connection a USB (Universal Serial Bus) connection or other wired or wireless, digital or analog interface or connection.
  • Other communications links described herein may be or include similar communications resources.
  • the consumer on client device 102 may click on "check out” via the user interface 150 and then selects a payment type, e.g., "Pay by Check.”
  • the transaction vendor 106 may then communicate the transaction to a transaction server 110 over a communication link 108.
  • the transaction server 110 and other servers described herein may be or include, for instance, a workstation running the Microsoft Windows NT , Windows 2000, Unix, Linux, Xenix, IBM ATXTM, Hewlett-Packard UXTM, Novell NetwareTM, Sun
  • Microsystems Solaris OS/2 , BeOS , Mach, Apache, OpenStep or other operating system or platform.
  • an interactive authentication process may begin.
  • the authentication process may be handled by a third party vendor from who the transaction vendor 106 subscribes the authentication service.
  • the consumer may apply for authentication via the transaction vendor 106 which links to an authentication server 114 via the transaction server 110 and communications link 112.
  • Consumer information entered on a web site or other data port of transaction vendor 106 such as name, address, telephone SSN, driver's license number etc., is then communicated to authentication server 114.
  • the consumer may be prompted on user interface 150 to enter additional information not processed by the transaction vendor 106. If the captured or entered data does not meet the initial formatting or other criteria applied by authentication server 114, a message may be returned to the consumer requesting the data in question, to be corrected and resubmitted.
  • the authentication process may be a multi-step process.
  • the authentication process asks initially some basic information from the user. If the user provides the correct basic information, the authentication process then proceeds to ask for additional information normally not easily known by third parties. The additional information asked may derive from the user's credit file history or other sources.
  • the information is forwarded to a further verification step, i.e. the second step of the authentication process.
  • the information may be compared to external databases such as the commercial credit databases from a credit-reporting agency such as Equifax Inc., or telephone number or driver's license databases.
  • Matching algorithms may be used to determine the quality or degree of the match and a score indicating that degree may be generated.
  • the scoring, authentication and related algorithms may be or include those described in co-pending U.S. Patent Application Serial Nos.
  • 09/315,128 filed May 20th, 1999 entitled “System and Method For Authentication of Network Users”; 09/315,129 filed May 20, 1999 entitled “System and Method For Authentication of Network Users And Issuing a Digital Certificate”; and 09/315,130 filed May 20, 1999 entitled “System and Method For Authentication of Network Users With Preprocessing”, each assigned to the same assignee as this application and incorporated by reference herein, or others.
  • a further stage of verification may be employed, in which an interactive query may be presented to the consumer to answer multiple choice questions non-wallet data. Those questions may be weighted, and the responses scored.
  • a composite scoring algorithm may then be used, based upon the scores from the ID compare, interactive query or other stages to create an overall certainty score, for instance on a scale of 1-100. If the certainty score is low enough, the authentication may be denied.
  • the authentication server 114 provides the user with an identification code (ID) and a password.
  • ID identification code
  • the consumer may be prompted to create a login/password.
  • the certainty score may be stored via the login/password in consumer database 122, and other data fields such as driver's license number, full magnetic ink character recognition (MICR) number (the bank number and the bank account number that appear on the lower corner of a check), date of birth, positive/negative check writing history, etc. may be recorded in that media or otherwise.
  • MICR full magnetic ink character recognition
  • the consumer may enter their login/password and the transaction server 110 may validate the login information against the consumer database. If the login/password do not match the information in consumer database 122, then the consumer may be given a predetermined number of chances, such as 1 additional opportunity to correct and enter the information. If the consumer cannot enter the correct information, the consumer may be instructed to contact an administrator of transaction through the transaction server 110 or other party via preferably email for assistance, through a hot link, or alternatively to go through the authentication process once again depending on implementation.
  • the consumer's resulting certainty score is compared to a threshold score, which may be established by transaction vendor 106 or otherwise.
  • a vendor may employ one threshold for check transactions and a separate threshold for card transactions.
  • the service provider who validates payment transactions, may establish a common threshold for all transaction using a same payment type.
  • the consumer is prompted to enter the remaining payment information required for authorization. If the certainty score does not meet the threshold for the payment type for the transaction vendor 106, but the score is high enough for an alternative payment type, then only those alternative options may be displayed and the consumer may choose one of those options. If the consumer's certainty score meets neither threshold, the service provider may deny the authentication, and the consumer may be instructed on how to obtain a disclosure via the Internet, phone or mail. Manual updates to consumer database 122 and other resources may preferably be allowed to ensure that files are accurate. For example, if the consumer provides the appropriate documentation offline, a score would then be generated and the consumer database 122 would be updated for future use.
  • the consumer wishes to pay by check or other cash-based instrument, then the necessary consumer and sale information may be accepted by the authorization system of the invention.
  • the invention using risk management technologies, may determine whether the transaction is approved or declined for that type of fulfillment.
  • the risk management technologies may employ statistical models that use recent user information such as number of checks and cumulative dollar amount recently written by the user, historical data on returned checks presented to the system, etc. Additionally, positive information on the consumer or transaction may be used to authorize a transaction that otherwise would be deemed high risk.
  • the risk management technologies may also use artificial intelligence when interpreting the user information. With the amount of information gathered on Internet check transactions, processes normally confined to voice referral transactions may now be made available for Internet transactions, including the commercially known A 1 model, credit score access via name and address, and others. These transactions and analyses may be executed in real time, to provide the retailer and consumer an online response, or through batch processing, based on the vendor's preference or otherwise.
  • an ACH funds transfer may be initiated, or a paper draft may be generated, based on the retailer's requirements or whether the transaction can be "ACHed". If the transaction vendor 106 (retailer) has subscribed to a settlement service from the service provider and the transaction can be processed through ACH, then an ACH fund transfer may be initiated. This may be done by transmitting the transaction to an ACH provider in an offline batch or other mode. Funds from ACH transactions are usuallymade available within two banking days, depending on the transacting bank's ability to post the funds.
  • the warranty program is a service where a service provider guarantees that a check transaction, once properly approved by the service provider, will not be returned.
  • the self-risk program is a program where the transaction vendor 106 bears the risk of a return check. A check may be returned for many different reasons, even after it has been approved by the service provider of secure network transactions.
  • the transaction is routed to transaction card server 140 for processing or to the vendor's designated card processor. If the transaction vendor 106 offers a private label card, then the point of sale (POS) promotion server 128 may be used. Alternately, the transaction card server 140 may also be used when a private label card is selected as the payment method.
  • a private label card is a credit card offered by a merchant, such as SearsTM card or ShellTM card.
  • the invention offers an increased customer base/transaction volume for electronic commerce, and permits a unified provider of payment solutions for vendors for all of their transactions, whether generated through store outlet, virtual storefront (Internet), telephone, mail, fax order, or others.
  • the payment architecture of the invention also promotes increased purchaser satisfaction and loyalty. Many retailers are expanding their businesses by creating Internet storefronts.
  • the invention provides a complete collection of payment services, along with value-added services such as pre-approved private label credit card offers in both online and offline environments under the safe payment mechanisms offered by the invention.
  • Consumers operating the client device 102 may have two or more data entry options to input their authorization data elements. They can build into a prefilled payment option screen on the client device 102 the required fields for check and credit card authorization, then transmit that information to transaction server 110 or over an established direct link to authorization server 114 for each transaction. Alternatively, data entry may be automatically triggered when transaction vendor 106 notifies automation server 114 that the consumer is requesting to pay by check or card.
  • An authorization query box to process the payment through an electronic funds transfer may thus be included on the pay by check screen presented on the user interface 150 of client device 102. If the consumer does not agree to that type of electronic funds transfer, then the consumer may be prompted for another form of payment.
  • the consumer may be advised and asked to acknowledge that should an attempt to execute an ACH transaction fail, a signatureless paper draft will be created and processed through normal banking channels.
  • the consumer may also be notified of applicable service fees associated with any returned items (electronic or paper draft).
  • Delivery of the transaction may be through a true web transaction with the transaction server 110 serving as a web server.
  • the transaction server 110 provides security through transaction encryption.
  • indicators may be established to identify merchants who have a compatible capability process transactions over the Internet or otherwise.
  • a new service restriction (for example "web) may be added on associated servers and on one or more files or client device 102.
  • a new code (for example "I") may be used within the inquiry log file (ILF) and OASys log file, to indicate remote transactions processed and paid through the Internet or other channels.
  • ILF is a file that logs all check transactions.
  • OASys is a maintenance application that assists access of log files.
  • a front-end authentication engine may authenticate the consumer to confirm his identity.
  • the consumer may be prompted to create a password that is tied to the login ID, which may be stored in the consumer database 122.
  • a link from the check authorization server 124 to the authentication server 114 may be established.
  • the transaction server 110 will validate the login/password by retrieving the consumer's login information from the consumer database 122.
  • the transaction vendor will pass the transaction to the authentication engine, and the consumer will be prompted to enter a login/password.
  • the login/password also index the consumer database 122 and may be used to reference other consumer records. For instance, the login/password may be used to obtain consumer records such as driver license information and full MICR data used to populate the authorization request for processing.
  • the authentication server 114 may have processes responsible for removing aged records (active and inactive), deleting fraudulent data, and removing records associated with uncollected checks.
  • the transaction server 110 may have additional processes. One process may handle consumer support for declined transactions based upon certainty scores or the inability to authenticate the consumer. Other process may prevent fraudulent check writers from reregistering and obtaining new certainty scores according to the invention.
  • the transaction server 110 may develop and maintain the consumer database 122 to store the various elements required to process associated transaction information such as check warranty, check verification, self-risk, ACH settlement, paper draft deposit, and POS promotion transactions. Collections information may be made available for ACH and paper draft returns. A flag may indicate if the information in the consumer database 122 was obtained directly from the consumer, or retrieved from other databases. Records may be purged from the consumer database 122 after a predetermined time to keep the consumer information up to date. The purging of records from the consumer database 122 may coincide with the purging of aged records on the authentication server 114, which would require previously authenticated consumers to re-authenticate on the next transaction.
  • the transaction server 110 may house or interface to an auxiliary log file 152 containing transaction data that will enable returned items to match consumer information.
  • the key data used to match a returned ACH transaction or paper draft to the log file 152 to obtain the consumer data may include transaction data such as ACH full MICR number, amount, check date, ACH tracking number (if item was ACHed), and merchant ID.
  • the log file 152 may contain at least the following information:
  • the consumer database 122 may contain at least the following information:
  • the authorization message generated by transaction server 110 may be based upon a direct link field specification, four fields: Ship to Indicator, Company Name, Company Address, Company phone, consumer login and password.
  • a certainty score of 0-100 or other scales may be used to determine whether the consumer will be permitted to use a selected payment option.
  • the consumer's score may be compared to the threshold selected by transaction vendor 106 or otherwise.
  • the transaction server 110 may set the threshold for warranty accounts.
  • Self-risk accounts may be set to self- determined thresholds for individual vendors. Separate scores may be set for check and card service under the same vendor.
  • the transaction vendor 106 or the service provider may perform, on an ongoing basis, analysis, validation, and adjustment of score thresholds. Such adaptations may ensure that thresholds are set properly in order to detect not only frauds, but also to avoid the system declining desirable consumers.
  • the system may report periodically to transaction vendor 106 the total number of turndowns due to scores not meeting retailer's requirements.
  • the transaction vendor 106 or the service provider may impose a turndown cap for each type of transaction. If the number of the turndowns reaches the turndown cap, the system may notify the transaction vendor 106 or may suspend future operations for that type of transactions.
  • the certainty score may be incorporated into a transaction model used to determine whether the transaction should be accepted.
  • the transaction server 110 may also submit inquiries to a third party or internally , operated database that houses negative address information.
  • the information housed in this database may consist of known addresses associated with fraudulent activity, addresses associated with prison, correctional institution, mail drops, etc.
  • the address information may be processed by a standardization routine. This information may be compared to the "bill to" and "ship to" address fields included in the transaction or from consumer database 122. If a match is made, additional risk parameters may be enabled or thresholds adjusted.
  • address standardization and matching logic routines may not be 100% accurate, it is preferable not to generate a turndown based solely on an address that has been recognized as negative. Instead, this factor may incorporated in an Al or other model used in conjunction with other factors to make the appropriate decision.
  • the transaction server 110 may in some cases, prior to ACH origination, identify non-ACHable items or identify them after they had been returned by an origination depository financial institution (ODFI).
  • ODFI origination depository financial institution
  • the transaction server 110 processes these non- ACHable items using commercial check drafting software modules.
  • the transaction server 110 prints the paper drafts in-house, and submits these items for deposit using traditional methods.
  • transaction vendor 106 may opt to integrate check drafting into an order fulfillment process, using the secure payment process of the invention for authorization only.
  • check drafts may not be electronically represented per National Automated Clearing House Association (NACHA) regulation. Therefore, various adaptations may be made to identify drafts and exclude them from electronic re-presentment, for instance by tagging them for manual redeposit.
  • NACHA National Automated Clearing House Association
  • various adaptations may be made to identify drafts and exclude them from electronic re-presentment, for instance by tagging them for manual redeposit.
  • check processing techniques are possible and extensible using the invention.
  • Fig. 2 illustrates a flowchart of a process that may be used according to the invention to service ACH transaction origination and returns.
  • processing begins.
  • each consumer is set up in consumer database 122 with an associated bank account or other financial account number designated for ACH debits and credits. For merchants who are warranty clients, all funds may be credited to the client's account within two banking days. For merchants who are self-risk clients, funds from cleared items may be credited in two banking days.
  • ACH transactions are formatted into the ACH record format known in the industry, using the standard entry class code.
  • a unique ACH tracking number may be generated and inserted into the record of consumer database 122.
  • the name field may be filled with the consumer name, which is an optional field by NACHA standards, but preferably used in the invention to help ensure the ACH is processed, along with other required fields.
  • the full MICR may be run against the consumer database 122 to determine if an NOC (notice of change) of MICR number was received from the financial institution on a previous ACH.
  • the full MICR may be run through the TEPS system to convert to the correct MICR number.
  • the TEPS system possesses files with negative information collected from different financial institutions.
  • the full MICR may be run against a conversion package, such as the commercially available Thomson Epic Ware System. Epic Ware may change or convert the full MICR to the one that the financial institution needs to perform the ACH.
  • the ACH transaction file may be originated through ODFI or directly through the Federal Reserve. Auditing may be done on this process, from file creation through receipt by ODFI/Fed, and finally through settlement. Settlement/reconciliation reports may be generated daily or at other intervals.
  • the consumer database 122 may be updated with any NOC records. An NOC is sent to the originator when the full MICR sent on the ACH is different than the full MICR the bank uses to do the ACH.
  • the invention may expand Claims system, ERMS/CUBS, Collections'
  • Derogatory Information File System DIFS
  • Pathways self-risk or any other files or information that carry return codes to allow a 2-byte ACH return code, or other desired format.
  • ACH returns file is received, step 224, each item is matched to an ACH log file to retrieve all consumer information needed to create a Claims record, add to the Claims system, then to ERMS/CUBS if self-risk and transaction server 110 or other parties are doing collections.
  • the Claims system is a system for handling returned checks and collections.
  • step 226 the system may generate Internet and US mail collection letters for those ACH transactions that were returned (Warranty Collections and ERMS). Criteria to determine which letters are sent, and via which medium, may include several variables, such as total transaction amount and certainty score. In step 228, this type of processing ends.
  • ACH return codes may be defined in the system as administrative return codes. These returns preferably do not feed DIFS, and preferably do not generate the normal collection letters. The ability to designate special processing, such as creating paper drafts for deposit, may be included in implementations of the invention.
  • Re-presentment parameters may be defined to determine whether the payment instrument is eligible for re-presentment and the timing of the re-presentment and may include such variables as ACH reason code, dollar amount, ACH origination date, and date of return. Timing of the re-presentment may be managed and adjusted so that the item is represented on a date or day of the month most likely to clear. In addition, the number of representations may be tracked, so that an item is not re-presented more than a predetermined number of times (e.g. two).
  • Warranty Collections and CUBS systems may be flagged when an item is in redeposit. If the item goes out on redeposit and does not come back as a return within a predetermined number of days, then the item may be marked as paid. At that time, any service fee ACH that was authorized by the consumer may be originated. Within a predetermined number of days, ACH may clear the service fee and the fee may be posted as paid.
  • the authorization server 114 or other resource may also present a user interface to allow transaction managers to apply debit/credits manually. That manual adjustment interface may preferably have a highly secure, restricted access, with audit reports to show activity by user. This interface may be preferably used where an ACH error needs to be corrected. Adjustment date, dollar amount, full MICRnumber (credit), full MICR number (debit), and a comment line to enter reason for adjustment may be included in the input.
  • the transaction server 110 may permit settlement with the transaction vendor 106 within 2 banking days of the transaction being processed.
  • Transaction vendors 106 operating on a warranty basis may receive all funds within that timeframe even if the funds do not clear. Paper drafts created for a non-ACHable warranty items may be settled in the same timeframe.
  • reporting mechanisms may be preferably configured to allow vendors to accumulate data over a requested time period.
  • the system may generate check warranty reports that contain daily settlement information showing items that were sent out for ACH each banking day and non-ACHable items that we submitted via paper draft for settlement.
  • a daily settlement report may be generated that shows what was submitted as an ACH and what vas submitted via paper draft.
  • Reporting statements, which depict returned items, may preferably include original transaction date, date submitted, return date and return code. Reports may be accessible through the Internet or other communications channels, as well as by paper delivery.
  • an audit report may be generated for the purpose of reconciling chargebacks (warranty returned items) to funds debited from any settlement account accessed by the transaction server 110.
  • An operator of a transaction server 110 may establish a settlement bank account to keep warranty-clients "whole" through the settlement process, i.e., the warranty returned items are charged against the settlement bank account and not charged to the warranty clients.
  • a third party ACH originator/provider may front all funds to the warranty client, and debit all returns against the settlement account. This type of reconciliation is particularly helpful if a third party handles the ACH origination and settlement functions, since they will debit accounts of the operator of the transaction server 110 for all warranty returns.
  • An automated claims data entry system may be employed to allow a high volume of claims to be processed efficiently.
  • Commercial solutions such as Elec Check by Equifax Check Solutions, may be used. All ACH returns may be used to trigger an update to claims and the negative file without human intervention. The ACH returns need to be matched against the consumer database 122 to pull additional consumer information needed for collections.
  • ACH return codes may be incorporated into data fields or resources such as Claims, ERMS (CUBS), IXFS, IVR, and Collections.
  • Collection letters may be generated incorporating ACH codes into the process.
  • Warranty and ERMS collections letters for items processed through the Internet may require modifications.
  • the modifications may include the Internet and ACH return- related indications or verbiage.
  • Collections letters may be sent via electronic email or US mail. It is preferable that an electronic mail be sent first and followed by a standard US mail if no response from the consumer is obtained. It is preferable that if a consumer receives information about their claim status over the Internet. If the money is owed, a link with Western Union may be established for payment arrangements mirroring the Quick CollectTM or other programs.
  • the invention provides for delivery of current consumer disclosure information. Declined or delayed consumers may be able to call into an operator of transaction server 110 and access an Interactive Voice Response (IVR) or other system. Where applicable, return codes and other identifiers may be assigned to distinguish Internet transactions. For example, a code may be used to identity those where the consumer's certainty score falls below a vendor's assigned threshold. To provide true Internet disclosures, IVR and other service applications may be integrated into a Web portal site by the use of Periphonics' PeriWeb or other products. The invention may incorporate the ability to automatically generate email disclosing to the consumer the events associated with a particular transaction.
  • IVR Interactive Voice Response
  • FIG. 3 describes a user process 300 according on one embodiment of the present invention.
  • the present invention is particularly useful to assist merchants to handle non-cash payment consumer transactions in a secure way.
  • a system according to the present invention can handle a consumer shopping through the Internet, placing an order through a telephone, or purchasing in parson at a storefront.
  • the user process 300 described herein is based on a consumer shopping through the Internet, but people skilled in the art will appreciate the process is equally applicable for other situation described above.
  • the consumer shops on line by visiting a virtual storefront through a web site, step 310. After selecting products, the consumer proceeds to check out, step 320, and selects the appropriate payment type.
  • the web site, or the virtual store redirects the consumer to the authentication process.
  • the authentication process checks whether the consumer has been authenticated, step 330. The authentication process verifies the consumer's identity. The identification process is preferably handled by an outside vendor, such as EquifaxTM, who is specialized in authentication process. If the consumer has not been authenticated, then he is referred to the authentication process, step 340. After the consumer goes through the authentication, if the authentication is successful, step 350, he proceeds to complete the payment method, step 370. If the authentication fails, his purchase is declined.
  • the consumer If the consumer has been authenticated before, either by this merchant or a different merchant, the consumer would have been assigned an identification code (ID) and a password.
  • ID identification code
  • the system may not issue a login ID nor a password to the consumer. The consumer would provide his ID and the password, step 360. After he provides his ID and his password, the system retrieves his record from a database. This record has consumer's information such as consumer's certainty score. The system then prompts him to complete payment, step 370.
  • the present invention support equally on-line check payment, debit card payment, credit card payment, or other form of on-line or off-line payment method.
  • step 380 After the consumer completes his payment, and the system starts a payment process, step 380.
  • the payment process is also preferably handledby an outside vendor who has expertise in handling on-line transactions.
  • a merchant can easily set up a virtual storefront by subcontracting the authentications and payment services from an outside service provider and handling the product ordering process internally. After the payment method is handled properly, the merchant is ready to ship the merchandise to the consumer.
  • Fig. 4 illustrates an authentication process 400 used in one embodiment of the present invention.
  • the authentication process prompts and receives the consumer's identification information, step 410.
  • the identification can be consumer's name, address, driver license number, etc.
  • the authentication process then checks the information received against some database generally available for this purpose, step 420.
  • the authentication process may be a multi-stage authentication process, where the first stage employs a commonly accessible "wallet-type” information, such as name, address, telephone number, driver license number, social security number, etc. and the second stage relies on information not easily obtainable, such as credit related information.
  • a commonly accessible "wallet-type” information such as name, address, telephone number, driver license number, social security number, etc.
  • the second stage relies on information not easily obtainable, such as credit related information.
  • steps 410 and 420 are repeated as necessary.
  • the format employed to gather information may be "question and answer" or multiple-choice formats .
  • the authentication process After the information is received, either through a simple authentication process or a multi-stage process, the authentication process generates a certainty score, step 440, based on the information provided by the user.
  • the certainty score may be calculated using different algorithms. The algorithms take into consideration the level of acceptable risk and the correctness of the information provided by the consumer.
  • step 450 If the certainty score is high enough, step 450, then a user ID and a password are generated, step 460. This user ID and password may be used in subsequent access to the same virtual store or to other stores that employs the same system.
  • the system also creates a record for the consumer, step 470. The authentication process then returns the consumer and his information to the calling user process.
  • Fig. 5 illustrates a payment process 500 according to one embodiment of the present invention.
  • the payment process receives information about the consumer, step 510.
  • the payment process determines whether a payment from the consumer should be accepted or declined.
  • the consumer may have been properly authenticated with a high certainty score by the authentication process, but nevertheless has his payment declined.
  • the payment process employs artificial intelligent algorithms based on different risk factors.
  • the check authorization process first checks the consumer's identification numbers against validation files.
  • the check authorization process checks the consumer's information against a negative file, step 520.
  • the system After checking the negative file, the system proceeds to retrieve the consumer's record from transactional and consumer databases, step 530.
  • the system may analyze the information from the consumer' record against a risk model to determine whether the payment should be accepted, step 540.
  • the risk model may employ different algorithms that consider different risk factors.
  • the system if the system detects any problem, the system sets a flag indicating the problem. If the consumer or transaction has a positive attribute, the flag may be overridden and the payment approved.
  • the system checks whether any flag was set, step 550. If no flag was set, then the payment is approved, step 560, otherwise the payment is denied, step 570. If the payment is approved and the merchant has subscribed to a payment settlement service from the service provider, then the payment information is forwarded to a settlement process.
  • the payment settlement process as described above prepares payment information in a proper format and sends it for processing by a centralized clearing house. The funds will be credited to the merchant's account automatically.

Landscapes

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

Abstract

L'invention concerne une architecture globale de paiement et de sécurité qui offre au client sur l'Internet ou autre la capacité de payer des transactions sur réseau au moyen de chèques authentifiés ou d'autres comptes au comptant, de débit, de crédit et possibilités de paiement. Un serveur de transaction peut authentifier l'identité du client et vérifier le montant à payer et le type de paiement. Il peut également déterminer si la transaction peut ou non être traitée par le biais d'un système de chambre de compensation automatisée. Divers niveaux d'authentification peuvent donner lieu à la présentation de différentes possibilités de paiement. Des factures sans signature peuvent être produites pour des transactions réglées par chèque, en fonction de la banque participante et d'autres variables. La souplesse des paiements et la sécurité des transactions sont ainsi renforcées.
PCT/US2001/013814 2000-04-28 2001-04-30 Systeme et procede de transactions securisees sur reseau WO2001084517A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2001257415A AU2001257415A1 (en) 2000-04-28 2001-04-30 System and method for secure network transactions

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US20033700P 2000-04-28 2000-04-28
US60/200,337 2000-04-28

Publications (2)

Publication Number Publication Date
WO2001084517A2 true WO2001084517A2 (fr) 2001-11-08
WO2001084517A3 WO2001084517A3 (fr) 2002-02-28

Family

ID=22741290

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2001/013814 WO2001084517A2 (fr) 2000-04-28 2001-04-30 Systeme et procede de transactions securisees sur reseau

Country Status (2)

Country Link
AU (1) AU2001257415A1 (fr)
WO (1) WO2001084517A2 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7171420B2 (en) * 2000-02-18 2007-01-30 International Business Machines Corporation Method and system for utilizing a database as a service
US10521782B2 (en) 2000-05-15 2019-12-31 Efunds Corporation System for and method of effecting an electronic transaction
US20220122091A1 (en) * 2020-10-21 2022-04-21 Coupang Corp. System and method for return fraud detection and prevention

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5724424A (en) * 1993-12-16 1998-03-03 Open Market, Inc. Digital active advertising
US5732400A (en) * 1995-01-04 1998-03-24 Citibank N.A. System and method for a risk-based purchase of goods
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
US5873072A (en) * 1991-07-25 1999-02-16 Checkfree Corporation System and method for electronically providing customer services including payment of bills, financial analysis and loans

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5873072A (en) * 1991-07-25 1999-02-16 Checkfree Corporation System and method for electronically providing customer services including payment of bills, financial analysis and loans
US5724424A (en) * 1993-12-16 1998-03-03 Open Market, Inc. Digital active advertising
US5732400A (en) * 1995-01-04 1998-03-24 Citibank N.A. System and method for a risk-based purchase of goods
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

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7171420B2 (en) * 2000-02-18 2007-01-30 International Business Machines Corporation Method and system for utilizing a database as a service
US10521782B2 (en) 2000-05-15 2019-12-31 Efunds Corporation System for and method of effecting an electronic transaction
US20220122091A1 (en) * 2020-10-21 2022-04-21 Coupang Corp. System and method for return fraud detection and prevention

Also Published As

Publication number Publication date
WO2001084517A3 (fr) 2002-02-28
AU2001257415A1 (en) 2001-11-12

Similar Documents

Publication Publication Date Title
US10657588B2 (en) Method and system for funding a financial account
US5953710A (en) Children's credit or debit card system
US7890393B2 (en) Method and system for completing a transaction between a customer and a merchant
AU2009200162B2 (en) Method and system for completing a transaction between a customer and a merchant
US8851371B2 (en) In-lane money transfer systems and methods
US7395241B1 (en) Consumer-directed financial transfers using automated clearinghouse networks
CN110070348B (zh) 交易处理系统及交易处理方法
US8407140B2 (en) Global remittance platform
US20070244778A1 (en) System and method for cash distribution and management
US20070005467A1 (en) System and method for carrying out a financial transaction
US20110137751A1 (en) Computerized system for facilitating transactions between parties on the internet using e-mail
US20130346313A1 (en) Methods and systems for user authentication
WO2000046725A1 (fr) Systeme et procede pour l'execution de transactions financieres en ligne via des reseaux de transfert de fonds electroniques et de communication publics
US20060089909A1 (en) Cardless transaction system
US20050205662A1 (en) Method and system for manual authorization
CN101390123A (zh) 汇款卡、系统和方法
US20030182227A1 (en) Payment monitoring system
WO2005091145A1 (fr) Traitement de transactions authentifiees et reparties
CA2435993A1 (fr) Systemes et methodes pour verifier electroniquement les cheques
WO2004012062A2 (fr) Systemes et procedes de calcul de prestations
US20090299901A1 (en) Automated remittance machine and method
WO2001084517A2 (fr) Systeme et procede de transactions securisees sur reseau
AU2002247093B8 (en) Method and system for completing a transaction between a customer and a merchant
AU2002247093A1 (en) Method and system for completing a transaction between a customer and a merchant

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
AK Designated states

Kind code of ref document: A3

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A3

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase in:

Ref country code: JP