Method and apparatus for online check processing

[0001] The present invention relates generally to data processing, and more particularly to methods and apparatus for processing a bank instrument.

[0002] The development of the Internet has created new online markets and marketplaces. For example, a user (e.g., a consumer) with an Internet connection can search for a variety of items (including, for example, physical products, services, digital media or content, and the like) provided by online merchants. Users can typically pay for items using a number of different online payment processing options. One common online payment processing option includes payment through credit cards. In a typical credit card payment purchasing scheme, a user accesses a website (e.g., of a merchant or other provider of items) and provides required personal information and a credit card number. The merchant submits a charge to a corresponding credit card company, and completes the online payment purchase with the user once the credit card company authorizes the charge. Online merchants, however, are exposed to high costs associated with fraud and charge back fees, and bear liability because typically no credit card signature is required when a user pays online using a credit card.

[0003] Another online payment processing option includes payment using electronic checks (referred to herein also as e-checks) through a funds transfer system associated with the Automated Clearing House (ACH) network. The ACH network is an electronic funds transfer system governed by NACHA (National Automated Clearing House Association) which sets operating rules that provide for inter-bank clearing of electronic payments for participating depository financial institutions. However, as with the credit card payment purchasing scheme, payments made using e-checks through a funds transfer system associated with the ACH network can be charged back or reversed long after a transaction date. In addition, not all financial institutions (including banks) participate in the ACH network. Other conventional e-check payment systems typically require merchants (or other check processors) to buy special check printing equipment and proprietary checks, so that the merchants can print out and then deposit physical paper copies of the consumer check. Merchants, however, must typically wait a long period of time (e.g., 5-7 days) for a printed check to clear.

[0004] Accordingly, what is needed is an improved online consumer payment solution. The present invention addresses such a need.

[0005] In general, in one aspect, this specification describes a computer-implemented method for processing an online payment for an item. The method includes receiving information from a user corresponding to the online payment for the item. The information from the user is received through a graphical user interface, and includes an authorization to pay for the item using an electronic check. The method further includes creating an electronic image of an authorized demand draft based on the authorization received from the user. The electronic image of the authorized demand draft is created directly from the information provided by the user through the graphical user interface.

[0006] Particular implementations can include one or more of the following features. Creating an electronic image of an authorized demand draft can include creating an electronic image of an authorized demand draft that is compliant with the Check Clearing for the 21st Century Act (Check 21). The electronic image of the authorized demand draft can be unsigned by the user. The method can further include transmitting the electronic image of the authorized demand draft to a financial institution, and receiving funds from the financial institution based on the electronic image of the authorized demand draft to provide payment for the item. Creating an electronic image of an authorized demand draft, transmitting the electronic image of the authorized demand draft to a financial institution, and receiving funds from the financial institution based on the electronic image of the authorized demand draft can be performed substantially in real-time. The method can further include performing one or more real-time verifications on the user prior to creating the electronic image of the authorized demand draft. Performing one or more real-time verifications on the user can include generating a blended risk score on the user. The blended risk score can correspond to a degree of risk associated with successfully performing an online payment transaction with the user. The blended risk score can be a composite of a plurality of individual risk scores. The information from the user can be received through a graphical user interface associated with a website of a merchant through which the item is purchasable.

[0007] In general, in another aspect, this specification describes a check processing system for processing an online payment from a user, in which the online payment is for an item that is purchasable through a website of a merchant. The check processing system includes a first engine to receive information from the user corresponding to the online payment for the item. The information from the user is received through a graphical user interface associated with the website of the merchant. The information from the user includes a name of the user, bank data associated with the user, and an authorization to pay for the item using an electronic check. The check processing system further includes a second engine to create an electronic image of an authorized demand draft based on the authorization received from the user. The electronic image of the authorized demand draft is created directly from the information provided by the user through the graphical user interface associated with the website of the merchant. The electronic image of the authorized demand draft includes the name of the user, the bank data associated with the user. The check processing system further includes a third engine to transmit the electronic image of the authorized demand draft to a financial institution corresponding to the bank data associated with the user, and a fourth engine to receive funds from the financial institution based on the electronic image of the authorized demand draft to provide payment for the item.

[0008] Implementations can include one or more of the following features. The fourth engine can be operable to receive the funds from the financial institution substantially in real-time relative to when the electronic image of the authorized demand draft is created and transmitted to the financial institution. The first engine, the second engine, the third engine, and the fourth engine can be components of the same engine. The check processing system can further include a fifth engine operable to perform one or more real-time verifications on the user prior to the second engine creating the electronic image of the authorized demand draft. The fifth engine can be operable to perform one or more real-time verifications including generating a blended risk score on the user.

[0009] In general, in another aspect, this specification describes a computer-implemented method for processing an online payment from a user, in which the online payment is for an item that is purchasable through a website of a merchant. The method includes receiving information from the user corresponding to the online payment for the item. The information from the user is received through a graphical user interface associated with the website of the merchant, and includes a name of the user, bank data associated with the user, and an authorization to pay for the item using an electronic check. The method further includes creating an electronic image of an authorized demand draft based on the authorization received from the user. The electronic image of the authorized demand draft is created directly from the information provided by the user through the graphical user interface associated with the website of the merchant, and includes the name of the user, the bank data associated with the user. The method further includes transmitting the electronic image of the authorized demand draft to a financial institution corresponding to the bank data associated with the user, and receiving funds from the financial institution based on the electronic image of the authorized demand draft to provide payment for the item.

[0010] Particular implementations can include one or more of the following features. The item can comprise one of a physical product, a service, digital media, or digital content. The financial institution can be one of a bank, savings and loan (S&L), credit union, or Federal Reserve.

[0011] Implementations may provide one or more of the following advantages. In one implementation, a fully integrated online check processing system is provided that functions much like credit card authorization and settlement, but is much more universally available to consumers or other users. Unlike transactions involving credit cards or a funds transfer system associated with the ACH network, the electronic images of authorized demand drafts created by the check payment/processing system cannot be easily or readily reversed, and are acceptable at every U.S. bank. Moreover, the check processing system is not subject to NACHA rules and/or other regulatory oversight.

[0012] The details of one or more implementations are set forth in the accompanying drawings and the description below. Other features and advantages will be apparent from the description and drawings, and from the claims.

[0019] Like reference symbols in the various drawings indicate like elements.

[0020] Implementations of the present invention relates generally to data processing, and more particularly to methods and apparatus for processing a bank instrument. The following description is presented to enable one of ordinary skill in the art to make and use the invention and is provided in the context of a patent application and its requirements. Various modifications to implementations and the generic principles and features described herein will be readily apparent to those skilled in the art. Thus, the present invention is not intended to be limited to the implementations shown but is to be accorded the widest scope consistent with the principles and features described herein.

[0021] FIG. 1 illustrates an online payment system 100 in accordance with one implementation. In one implementation, the online payment system 100 includes a user system 102, a check processing system 104 and a merchant system 106. In one implementation, the user system 102, the check processing system 104 and the merchant system 106 are interconnected through a network (e.g., the Internet or other wide area network). Other types of networks through which the online payment system 100 can be interconnected include, for example, telephone networks, wireless digital networks, serial cable networks, ATM or credit card networks, or other private networks and collections of networks including intranets, and/or local area networks. In one implementation, the check processing system 104 permits a user (using the user system 102) to pay for items (including, e.g., physical products, services, digital media or content, and the like) that are displayed on (or available/purchasable through) a website, e.g., a merchant website provided by the merchant system 106. In one implementation, the check processing system 104 generates an electronic image of an (unsigned) authorized demand draft, or other bank instrument, (based on user information) that is compliant with the Check Clearing for the 21st Century Act (Check 21), which electronic image is then processed at a financial institution to provide payment for an item. Such financial institutions include, for example, banks, savings and loans (S&Ls), credit unions, the Federal Reserve, and other check processing centers. In general, the electronic image of the authorized demand draft is a bank instrument corresponding to, for example, a personal check, business check, certified check, bank check, sight draft, demand draft, money order, and the like. Unlike transactions involving credit cards or a funds transfer system associated with the ACH network, the electronic images of authorized demand drafts created by the check processing system 104 cannot be easily or readily reversed and are acceptable at all U.S. banks and other financial institutions.

[0022] Check 21 is a new federal law that was signed on Oct. 28, 2003, and became effective on Oct. 28, 2004. Check 21 is designed to foster innovation in the payments system and to enhance efficiency by reducing some of the legal impediments to check truncation. The law facilitates check truncation by creating a new negotiable instrument called a substitute check, which permits banks to truncate original checks, to process check information electronically, and to deliver substitute checks to banks that want to continue receiving paper checks. A substitute check is the legal equivalent of the original check and includes all the information contained on the original check. Accordingly, Check 21 permits banks to process paper checks electronically for faster, more efficient check clearing. Instead of physically moving paper checks between banks, Check 21 permits banks to capture a picture of the front and back of a check and transmit the picture electronically.

[0023] Referring to FIG. 1, in one implementation, the electronic image of the authorized demand draft generated by the check processing system 104 is made payable to an entity (e.g., a person or business) associated with the check processing system 104. In this implementation, the check processing system 104 can provide funds received from a financial institution (responsive to a corresponding electronic image of an authorized demand draft) to an entity (e.g. a person or business) associated with the merchant system 106. The check processing system 104 can provide the funds to the merchant system 106 through (e.g.) wire, ACH, or a paper check. In one implementation, the electronic image of the authorized demand draft generated by the check processing system 104 is made payable to an entity associated with the merchant system 106. In this implementation, the funds are provided from the financial institution (or drawee bank) directly to the merchant system 106. In this implementation, the electronic image can be sent directly from the check processing system 104 to the financial institution (or indirectly through a 3^rd party or the merchant system 106). For example, the electronic image can first be sent to a bank associated with the merchant system 106, which will then forward the electronic image to the drawee bank. The financial system can provide the funds to the merchant system 106 through (e.g.) wire, ACH, or a paper check. Alternatively, the electronic image of the authorized demand draft generated by the check processing system 104 can be made payable to an entity associated with a 3^rd party not associated with the check processing system 104 or the merchant system 106. In this implementation, the settlement of funds for payment of an item is provided by the 3^rd party.

[0024] In addition to making payments for items that are available through a website, the check processing system 104 can be used to make payments for items generally. For example, the check processing system 104 can be used to provide payment for car payments, insurance payments, mortgage payments, payroll checks, and so on. In one implementation, the check processing system 104 is operable to automatically make recurring payment by generating electronic images of the authorized demand drafts on a pre-determined reoccurring basis. The recurring payments can involve creation of an electronic image of an authorized demand draft based on a previous authorization made for other electronic images.

[0025] FIG. 2 illustrates a block diagram of a check processing system 200 in accordance with one implementation. In one implementation, the check processing system 200 includes a user validation engine 202 and a check processing engine 204. Although the check processing system 200 is shown as including two separate engines—e.g., the user validation engine 202 and the check processing engine 204—the check processing system can include other engines (not shown) operable to perform the functions described below. In addition, the two separate engines can be combined into a single engine.

[0026] In one implementation, the user validation engine 202 performs a series of real-time verifications to ensure that every electronic check (or demand draft) is authorized by a user (or account owner), and that the check will clear the user's bank (or other financial institution associated with the user). More generally, the user validation engine 202 provides bank data, age and identity verification for users of the check processing system 200. In one implementation, the user validation engine 202 generates a blended risk score for each user that registers with the check processing system 200 as described in pending U.S. patent application Ser. No. 10/405,410—entitled “Fraud Control Method and System For Network Transactions”, which is incorporated by reference herein. In one implementation, the blended risk score corresponds to a degree of risk associated with successfully performing an online payment transaction with a given user. For example, a good blended risk score for a user can indicate a greater likelihood of a successful online payment transaction.

[0027] For example, referring to FIG. 3, a method 300 for validating a user is shown according to one implementation. A plurality of individual risk scores are generated (e.g., by the user validation engine 202) (step 302). The plurality of individual risk scores can be generated based at least in part on information provided by a user that desires to pay for an item using the check processing system 200. In one implementation, a first individual risk score is generated from a credit history of a user. In this case, the first individual risk score can correspond to a credit score of a given user. In one implementation, a second individual risk score is generated using Network Geolocation Technology (NGT)) to determine a user's physical location, which is compared to a reported location and IP address of the user's (hardware) system. In this implementation, the second individual risk score corresponds to the certainty that a user is physically located near a user system through which the user's information was received. Other individual risk scores can be generated to verify user information and/or bank data using any type of suitable information including for example, publicly maintained databases (e.g., Department of Motor Vehicles (DMV) records, education records, and the like) or privately maintained databases (e.g., Lexis-Nexis, Martindale-Hubbell, and the like).

[0028] A blended (or composite) risk score is generated (e.g., by the user validation engine 202) (step 304). In one implementation, the blended risk score is generated by assigning weights to each of the plurality of individual risk scores, substantially according to equation 1 below:
(X)(1st risk score)+(Y)(2nd risk score)+ . . . +(Z)(nth risk score)=blended risk score  (eq. 1)
where X, Y, and Z represent a weight assigned to a given risk score. The weights can be assigned to give more (or less) influence to each of the individual risks scores on the (overall) blended risk score. A determination is made (e.g., by the user validation engine 202) whether the blended risk score meets a pre-determined threshold (step 306). The pre-determined threshold can correspond to a level of acceptable risk. If the blended risk score meets the predetermined threshold then a user request to pay using the check processing system is accepted (e.g., by the user validation engine 202) (step 308). If the blended risk score does not meet the pre-determined threshold then the user request to pay using the check processing system is rejected (e.g., by the user validation engine 202) (step 310).

[0029] Referring again to FIG. 2, (in one implementation) the check processing engine 204 is operable to create an electronic image of an authorized demand draft (or an electronic check) that can be processed to provide online payment for an item. For example, referring to FIG. 5, a screenshot 500 is shown of a user selecting (1) anvil for purchase through a merchant website. As shown in FIG. 6, a screenshot 600 is shown including a window 602 that provides a number of payment options for selection by the user. The window 602 includes a conventional credit card payment option 604 and an electronic check payment option 606 (“MyECheck”) through which an electronic image of an authorized demand draft can be generated to pay for the anvil. FIG. 4 illustrates one implementation of a method for processing an electronic image of an authorized demand draft.

[0030] As shown in FIG. 4, user information is received (step 402). In one implementation, the user information is received though a user registration process. For example, FIG. 7 shows a screenshot 700 of a login screen 702 that is displayable to a user once the user selects the electronic check payment option 606 (FIG. 6). In one implementation, the login screen 702 includes a registration section 704 for new users and a login section 706 for returning users. If a given user is a returning user, then the user's information can be retrieved from a database or other storage. FIG. 8 shows a screenshot 800 of a registration screen 802 that is displayable to new users of the electronic check payment option. In one implementation, the user information that is received includes date, name, address, driver's license identification number, bank data (e.g., including a bank routing number and a bank account number), payee information, and the amount to be paid. In one implementation, the information is entered directly into an electronic template 804 in the form of a conventional paper check as shown in FIG. 8. As discussed above, the payee can be an entity associated with the check processing system, the merchant system, or a 3^rd party. FIG. 9 shows a screenshot 900 of an authorization page 902. In one implementation, the authorization page 902 includes email and telephone contact numbers and includes an authorization selection button 904 indicating a user's authorization of an electronic check.

[0031] In one implementation, prior to completing registration, a user enters additional personal information including, for example, date of birth, social security number, previous home addresses, and so on, as shown in the screenshot 1000 of FIG. 10. FIG. 11 illustrates a screenshot 1100 of a confirmation page 1102 containing all of the information previously entered by a user. In one implementation, a quiz is presented to a user (e.g., by the user validation engine 202 (FIG. 2)) to further confirm identity of the user as shown in the screenshot 1200 of FIG. 12. The questions can be generated from public and/or private databases, or other information databases. FIG. 13 illustrates a screenshot 1300 of additional information that can be entered by a user to simplify future electronic check payment transactions. The additional information includes a username, password, account PIN (personal identification number), secret question and answer. The secret question and answer can be used to verify identity of a user should the user later forget a username, password, and/or account PIN.

[0032] Referring again to FIG. 4, a determination is made (e.g., by the user validation engine 202 of FIG. 2) whether the user is authorized to complete online payment using the electronic check payment option. In one implementation, a user is authorized to complete an online payment using the electronic check payment option if a blended risk score associated with the user meets a pre-determined threshold as discussed above. If the user is not authorized to complete the online payment, then the process ends. If the user is authorized to complete the online payment using the electronic check payment option, then an electronic image of an authorized demand draft is created (e.g., by the check processing engine 202 of FIG. 2) (step 406). In one implementation, the electronic image of the authorized demand draft is created directly from information provided by a user through a graphical user interface, e.g., running on (or associated with) a website of a merchant. For example, referring to FIG. 8, an electronic image of an authorized demand draft can be created based on the information provided on the electronic template of a conventional check. More generally, the information for generating an electronic image of an authorized demand draft can be received through data collection means or transmittal methods. For example, the information for generating an electronic image of an authorized demand draft can be received from a merchant (or payment gateway). In one implementation, the check processing engine generates electronic images of authorized demand draft in response to transactions that are sent to the check processing engine in batches. For example, a merchant may delay release of payment processing of a previously authorized transaction to the check processing system (e.g., the purchase of a charter flight plane ticket may require the merchant to defer issuance (by hours or days) pending confirmation of seat availability of a carrier).

[0033] In one implementation, the electronic image of the authorized demand draft is compliant with Check 21 to guarantee that the electronic image of the authorized demand draft will be acceptable at all U.S. banks or other financial institutions. In one implementation, the electronic image of the authorized demand draft is unsigned by the user. Alternatively, an electronic signature can be placed on the electronic image of the authorized demand draft. The electronic image of the authorized demand draft is transmitted (e.g., by the check processing system 200 (FIG. 2)) to a check processing center (e.g., the user's bank or other financial institution) (step 408). In one implementation, the electronic image of the authorized demand draft is transmitted substantially in real-time to the check processing center. Once the electronic image of the authorized demand draft is processed, funds are received (e.g., by the check processing system 200) (step 410). In one implementation, the funds are received by the check processing system substantially in real-time. The funds are then wired to the merchant (step 412). FIG. 14 shows a screenshot 1400 indicating successful online registration and payment through the electronic check payment option. Alternatively, as discussed above, the electronic image of the authorized demand draft can be made payable to the merchant (or a 3^rd party), in which case the check processing center (or financial institution) directly sends the funds to the merchant (or the 3^rd party).

[0034] FIGS. 15-30 illustrate one implementation of an electronic image of an authorized demand draft, and components (or data sources) thereof. The electronic images shown in FIGS. 15-30 are electronic X9.37 image files. In general, various financial institutions have different requirements regarding acceptance of an electronic image of an authorized demand draft and, therefore, the electronic image (and components thereof) shown in FIGS. 15-30 are exemplary.

[0035] Referring first to FIG. 15, one implementation of an electronic image of an authorized demand draft 1500 is shown. The electronic image of an authorized demand draft 1500 includes a front side 1502 and a back side 1504. As shown on the front side 1502, the electronic image of an authorized demand draft 1500 is unsigned. FIG. 16 shows file header that is associated with the electronic image of an authorized demand draft 1500. In one implementation, the file header includes origin and destination routing number information as shown, in addition to the total amount ($1044.99) to be transferred between the two accounts associated with the routing numbers. FIGS. 17-30 respectively illustrates other components (or data sources) that can be associated with the electronic image of an authorized demand draft 1500 including, for example, a record type 01, a cash letter, a record type 10, a bundle, a record type 20, an item identifier (item 1), a record type 25, a record type 50 (associated with the front side 1502), a record type 52 (associated with the front side 1502), a record type 50 (associated with the back side 1504), a record type 52 (associated with the back side 1504), a record type 70, a record type 90, and a record type 99.

[0036] Below is provided an exemplary process steps that can occur through a merchant website and a check processing system that is in accordance with the method steps discussed above.

• [0037] 1) Merchant Web Site
  • [0038] Merchant collects amount of item
  • [0039] Customer selects Check Processing System to pay for item
• [0040] 2) Check Processing System creates secure session with Customer inside frames on Merchant Web Site
  • [0041] Amount of item is electronically sent to Check Processing System
  • [0042] Check Processing System creates a unique session ID and transaction ID
  • [0043] Check Processing System serves a log-in page
  • [0044] Pre-registered users log-in user username and password, and new users click through to register
• [0045] 3) (a) New User Registration
  • [0046] Check Processing System serves customer registration pages
  • [0047] Customer enters name, address, phone number, driver license number, bank name, bank routing number, bank account number into fields on blank check image
  • [0048] Customer enters phone numbers, date of birth, other addresses, social security number into additional fields
  • [0049] Customer agrees to terms of use and authorizes transaction
  • [0050] Customer's identity attributes are verified by Check Processing System matching customer provided data with data in external private and public records databases
  • [0051] Check Processing System serves interactive quiz to customer to validate identity
  • [0052] Check Processing System verifies customer bank account funds availability through interfaces with external data providers
  • [0053] Check Processing System queries external negative check writer databases
  • [0054] Check Processing System uses risk assessment and decision tools to approve or decline transaction
  • [0055] Check Processing System serves Approved or Declined page to Customer, declined customers are redirected to the merchant web site
  • [0056] Check Processing System serves page for approved customer to enter a username, password, PIN and secret question to identify themselves to the Check Processing System on future transactions.
  • [0057] Customer and transaction data is posted to the Check Processing System database
  • [0058] Customer is redirected to the merchant website along with transaction data
  • [0059] An electronic, Check 21 compliant file containing an image of authorized demand draft is created and electronically sent to a financial institution for processing
  • [0060] Check Processing System sends receipt to customer email
• [0061] 3)(b) Pre-Registered Users
  • [0062] Check Processing System serves page containing image of demand draft for customer approval or editing
  • [0063] Customer enters PIN to authorize demand draft
  • [0064] Transaction data is posted to the Check Processing System database
  • [0065] Customer is redirected to the merchant website along with transaction data
  • [0066] An electronic, Check 21 compliant file containing an image of authorized demand draft is created and electronically sent to a financial institution for processing
  • [0067] Check Processing System sends receipt to customer email address

[0068] One or more of method steps described above can be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. Apparatus of the invention may be implemented in a computer program product tangibly embodied in a machine-readable storage device for execution by a programmable processor; and method steps of the invention can be performed by a programmable processor executing a program of instructions to perform functions of the invention by operating on input data and generating output. The invention can be implemented advantageously in one or more computer programs that are executable on a programmable system including at least one programmable processor coupled to receive data and instructions from, and to transmit data and instructions to, a data storage system, at least one input device, and at least one output device. Each computer program can be implemented in a high-level procedural or object-oriented programming language, or in assembly or machine language if desired; and in any case, the language can be a compiled or interpreted language. Suitable processors include, by way of example, both general and special purpose microprocessors. Generally, a processor will receive instructions and data from a read-only memory and/or a random access memory. Generally, a computer will include one or more mass storage devices for storing data files; such devices include magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; and optical disks. Storage devices suitable for tangibly embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM disks. Any of the foregoing may be supplemented by, or incorporated in specially-designed ASICs (application-specific integrated circuits).

[0069] To provide for interaction with a user, the invention can be implemented on a computer system having a display device such as a monitor or LCD screen for displaying information to the user, and a keyboard and a pointing device (e.g., a mouse or a trackball) by which the user can provide input to the computer system. The computer system can be programmed to provide a graphical user interface through which the computer programs interact with users.

[0070] Various implementations of an online payment system and methods for providing payment online have been described. Nevertheless, one of ordinary skill in the art will readily recognize that various modifications may be made to the implementations, and those variations would be within the scope of the present invention. For example, the steps of methods discussed above can be performed in a different order to achieve desirable results. In addition, although FIG. 1 depicts the user system 102, the check processing system 104 and the merchant system 106 as separate systems, two or more of the systems can be combined within a single system. Accordingly, many modifications may be made by one of ordinary skill in the art without departing from the spirit and scope of the following claims.