1. Field of the Invention
The present invention relates generally to the field of e-commerce and marketing, and more particularly to a system and method for optimizing order process flow using a web browser by generating and displaying dynamic transactional pages based on information entered by a consumer.
2. Description of the Related Art
Initially, payment options accepted by merchants for online transactions were limited to credit cards, such as Visa® and Mastercard®. As online commerce has expanded, additional payment options have become more widespread, including the use of debit cards and Automated Clearing House (ACH) billing as well as payment services such as PayPal®, BillMeLater®, and Google Checkout™. This expansion of payment options has allowed online merchants to process a greater number of transactions than was previously possible.
A merchant typically pays a service or processing fee to an acquiring bank when the merchant accepts a credit card as payment for goods or services. Most other common payment services also require the merchant to pay a fee for use of the service. Fees paid by merchants for accepting credit cards and other payment methods typically range from about one to about three percent of the total purchase price for the transaction. The service fees charged to merchants can have a significant effect on the merchant's bottom line, especially if the merchant has razor-thin profit margins or a high volume of transactions. Naturally, merchants seek to maximize the number of transactions while minimizing the cost of the transaction. It is therefore essential to take into account the transaction processing costs to make a well-informed decision as to which payment options to accept and how to present those options to a consumer during an order process.
Local phone bills have recently become a viable payment option for online merchants. For many years, local phone carriers have allowed third-parties to include charges for services in a consumer's local phone bill. In the past, third-party services eligible for billing through a local phone bill have generally been limited to telecommunications-related services. However, within the last few years, local carriers have begun to allow customers to charge a wide variety of different third-party services—many unrelated to telecommunications—to their local phone bills. This change has come about as a response to competitive pressure within the industry; it is an attempt to prevent current customers from switching to competing carriers. The rationale for this change is that once customers set up a recurring payment for a desired service on their local phone bills, the customers will be less likely to switch carriers to avoid the added hassle of dealing with several third-parties to change payment options. As a result, local phone companies have begun to allow to use a local phone bill as a viable payment device. Currently, all of these merchants must have a digital component to their service.
There are a number of drawbacks to billing third-party service through a local phone bill, and as a result, the marketplace has been slow to adopt this payment option. First, navigating the process for obtaining clearance to bill a third-party service on a local phone bill can be daunting and may require significant time and effort. Second, the fee charged to a third party for billing a service to a local phone bill is very high relative to the fee charged to a merchant for accepting a credit card or one of the other standard payment methods discussed above. Finally, the delay in receiving payment from a customer is also a significant drawback to billing a third-party service through a local phone bill. When a merchant uses a local phone bill to charge for a service, the merchant may not receive payment for that service for 90 days or more after the transaction occurs. In contrast, receipt of payment when accepting a credit card is nearly instantaneous. Because of these drawbacks, most merchants have opted not to pursue billing of their services through a local phone bill.
Despite the onerous process of become approved to accept payment, the amount of time it takes to receive payment, and other operational hurdles, there are still benefits in certain cases to accepting payment using a local phone bill. One such benefit is tapping into the market of consumers that still do not have credit cards. An additional benefit is immediacy and convenience. Local phone billing only requires a customer to remember his or her phone number. Most everyone can recite their phone number from memory. It is much less likely that a consumer has memorized his or her credit card number.
Consequently, there is a need for systems and methods of presenting online order information that captures the greatest number of transactions at the lowest possible cost, using a wide variety of payment options, including charging services to a local phone bill. Due to the large cost associated with billing to a local phone bill, an optimal order process will capture the maximum number of total transactions, while ensuring that the maximum subset of those transactions are billed to a credit card or other similarly priced method of payment and the remainder of the transactions are billed to a phone bill. The present invention provides such an order process.
Advantages of the present invention are set forth in the brief description that follows. Additional advantages of the invention may be realized by the methods and systems particularly pointed out in the written description and claims, as well as from the appended drawings.
The invention includes a computer-implemented method for optimizing process flow of an online order. The method includes the steps of providing a client device displaying a user interface, presenting a consumer with an information page in the user interface requesting a set of information, including the phone number of the consumer; receiving first level information from the consumer, including the consumer's phone number, and determining whether the phone number is eligible for third party local exchange carrier billing. When the phone number is eligible for third party local exchange carrier billing, the consumer is presented with a phone billing option. When the phone number is not eligible for third-party local exchange carrier billing, the consumer is presented with a credit card billing page. In one exemplary embodiment, the phone number is a home phone number. But the phone number may be any number that is eligible for third-party local exchange carrier billing.
A system for optimizing process flow of an online order is also provided. The system includes a server having a processor and a memory, a database interfacing with the server, and a client device interfacing with the server and displaying a user interface. The user interface includes an information page configured to request a set of first level information, including the phone number of the consumer. The server is configured to determine whether the phone number is eligible for third party local exchange carrier billing, and is further configured to present the consumer with a credit card billing page and then a phone billing page if no credit card information is received from the consumer when the phone number is eligible for third-party local exchange carrier billing, and to present the consumer with a credit card billing page when the phone number is not eligible for third-party local exchange carrier billing.
The general description above and the following detailed description are exemplary and are intended to provide further explanation of the claimed invention. The accompanying drawings, which constitute part of this specification, are included to illustrate and provide a further understanding of the methods and systems of the invention. Together with the description, the drawings serve to explain principles of the invention.
So that those skilled in the art to which the subject invention pertains will readily understand how to implement the methods and systems of optimizing online order process flow without undue experimentation, preferred embodiments of the methods and systems will be described in detail below with reference to the following figures:
The present invention provides methods and systems for optimizing an online purchase transactional path to maximize the total number of transactions, while ensuring that the largest possible subset of those transactions are effectuated using a credit card or similarly priced payment method, with the remainder of the transactions being effectuated using third-party billing to a local phone bill. In one exemplary embodiment, asynchronous technology, such as asynchronous JavaScript and XML (Ajax) is used to present a user with a number of dynamic pages in the required and optimal order for each individual consumer.
For purposes of explanation and illustration, and not limitation, an exemplary embodiment of a system in accordance with the present invention is shown in
System 100 may comprise software components running on either billing management server 102 or clients 106. Billing management server 102 and clients 106 may run any suitable operating system and may include a variety of hardware configurations. Both billing management server 102 and clients 106 may include a processor coupled to a memory module and to a mass storage device via a bus or other communication medium; a display or other output device interfacing with the processor; and a keyboard, mouse, touchpad, or other input device that receives input from a user and interfaces with the processor. In one exemplary embodiment, clients 106 each include an input device for receiving user input and a display device for displaying content. The software implementing system 100 may include instructions written in a high level computer language and stored in a mass storage device. In one exemplary embodiment, a plurality of Ajax software components run on both billing management server 102 and client devices 106. These software components can be used to implement an application in a web browser that communicates with server 102 in the background, without interfering with the current rendering of the displayed web page.
First level information may include the consumer's first name, last name, and email address, although other information could be included as well. At step 204, the first level information received from the consumer is stored in database 104. First level information may be sent from the web browser running on client 106 to billing server 102 using Ajax or other asynchronous technology. Billing server 102 then writes the first level information to database 104. In one exemplary embodiment, the web browser does not send the information until the consumer clicks on or otherwise selects a “continue” or “send” button. In another exemplary embodiment, the information is sent as it is being entered by the consumer.
At step 206, the web browser displays a second page to the consumer requesting that the consumer provide second level information. Second level information may include, for example, name, address, city, country, state, postal code, phone number, and a security question and answer.
At step 208, billing server 102 runs a real-time, asynchronous check against a billable phone list housed within a database at phone billing consolidator 110 or other server to determine whether the phone number entered by the consumer is billable, that is, whether local exchange carrier 108 allows third-party billing on the consumer's local phone bill. In one exemplary embodiment, this check occurs immediately when the consumer fills out the phone number field. The list stored in the database may be a proprietary list of billable phone numbers used to determine if the consumer's local exchange carrier allows for such a transaction at a block level. In this context, a block level represents a block of phone numbers that have the same first seven digits. For example, the block of numbers beginning with 212-555-5XXX (where the Xs represent different number combinations) contains 1,000 possible numbers.
Step 210 is a decision step in which server 102 responds to the query from the web browser and indicates whether the entered phone number is billable. The web browser will then dynamically change the order page presented to the consumer based on the response from server 102. At step 212, if the block of numbers to which the consumer's phone number belongs is not billable, the web browser automatically adjusts the page to remove the disclosures and data fields required by the local exchange carriers for third-party billing, and to add fields for the consumer to input his or her credit card information. If billing server 102 determines that the consumer's phone number is not eligible for third-party billing, alternative payment options such as a credit card become the consumer's only option and the purchase transaction continues as it otherwise would without a phone billing option.
At step 214, if the block of numbers to which the consumer's phone number belongs is billable, the web browser does not remove any disclosures, fields or other visual objects from the page. It should be understood that in another embodiment, fields, disclosures or other visuals could be added at this step based upon the result of decision step 210.
At step 216, the consumer decides, based on the terms and conditions presented, whether to finalize the transaction and bill it to the consumer's local phone bill. At step 218, if the consumer elects not to continue with the transaction, the consumer's first level information, which was provided in step 202 and written to database 104, is saved and can be utilized to contact the consumer in the future for remarketing purposes. At step 220, if the consumer elects to continue with the transaction, billing server 102 runs a real-time check with phone billing consolidator 110 to determine if the consumer can use his or her local phone number as a method of payment. This real-time check of the consumer's individual number is distinct from the block-level check performed at step 208. This second check validates that the consumer's local exchange carrier 108 allows billing at the individual consumer level, rather than just at the block level.
Referring now to
Step 230 is the final decision step. If the consumer decides not to use a credit card or other alternate form of payment, the consumer is then categorized as a phone bill order. Once the consumer completes the order fields, the consumer is presented with a page that confirms the purchase and may also be configured to send the consumer a confirmation email. At step 234, if the consumer decides to use the alternate form of payment such as a credit card, the consumer is designated in database 104 as a credit card order (or other appropriate category) and thus not subject to phone billing. The consumer is then presented with a confirmation page as well as an email confirmation confirming the transaction and the alternative billing option.
In one exemplary embodiment, once the consumer has been presented with the credit card billing page and has entered his or her credit card number, billing server 102 checks the entered credit card number against a Bank Identification Number (BIN) database. A Bank Identification Number consists of a predetermined number of digits shown on the front of a credit card or other payment card, for example, the first six digits. The BIN is used to identify the party who issued the card to the consumer. Checking the consumer's entered credit card number with the BIN database allows the merchant to determine whether the card is legitimate, thus helping to prevent fraud. In one exemplary embodiment, the BIN database is a local database integrated with database 104. In another exemplary embodiment, billing server 102 may access the BIN database through network 112.
If billing server 102 cannot verify that the entered credit card number is legitimate based on a comparison with the data in the BIN database, the consumer may be recategorized as a phone bill order. The consumer may then be presented with a phone billing page along with an indication that the credit card could not be verified. In one exemplary embodiment, credit card billing page may change dynamically to a phone billing page once billing server 102 has determined that the entered credit card number may not be legitimate or trustworthy. Once the consumer completes the phone billing order fields, the consumer is presented with a page that confirms the purchase and may also be sent a confirmation email.
If billing server 102 determines that the consumer is not eligible for either phone billing—based on a check with phone billing consolidator 110, or credit card billing—based on a check with the BIN database, the consumer's previously entered information is saved in database 104 and may be used to raise potential flags for future transactions or to remarket to the consumer at a later time.
Second level information page 312 may also include terms of use language 334 relating to third-party billing through a local exchange carrier, as well as a checkbox 336 allowing the consumer to consent to the terms of use. Second level information page 312 may also include a Continue button 338. In one exemplary embodiment, system 100 does not send a request to billing server 102 to check whether the consumer's phone number is eligible for phone billing until the customer selects Continue button 338. In another exemplary embodiment, the request is sent to billing server 102 as soon as the phone number is entered into Phone Number field 328.
In one exemplary embodiment, credit card billing page 342 is generated dynamically using asynchronous technology. For example, billing address window 313 may remain on the page and billing information window 344 may dynamically appear without input from the consumer. In another exemplary embodiment, credit card billing page 342 may be a new page. Credit card billing page 342 may also include a Continue button 346. If the consumer enters his or her credit card information into billing information window 344 before clicking Continue button 346, the consumer will be taken to a credit card order confirmation page 348, as shown in
The present invention, as described above and shown in the drawings, provides for improved methods and systems for optimizing process flow of an online order to maximize efficiency while minimizing costs. It will be apparent to those skilled in the art that various modifications can be made to the systems and methods of the present invention without departing from the scope of the invention as outlined in the appended claims and their equivalents.
This application claims priority to U.S. Provisional Patent Application No. 61/186,301, filed Jun. 11, 2009, the disclosure of which is incorporated herein by reference in its entirety.
Number | Date | Country | |
---|---|---|---|
61186301 | Jun 2009 | US |