US20090037290A1 - Distributed System for Commerce - Google Patents
Distributed System for Commerce Download PDFInfo
- Publication number
- US20090037290A1 US20090037290A1 US12/250,978 US25097808A US2009037290A1 US 20090037290 A1 US20090037290 A1 US 20090037290A1 US 25097808 A US25097808 A US 25097808A US 2009037290 A1 US2009037290 A1 US 2009037290A1
- Authority
- US
- United States
- Prior art keywords
- data
- merchant
- user
- intermediate server
- payment
- Prior art date
- Legal status (The legal status 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 status listed.)
- Abandoned
Links
Images
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/08—Payment architectures
- G06Q20/12—Payment architectures specially adapted for electronic shopping systems
-
- 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
-
- 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/20—Point-of-sale [POS] network systems
- G06Q20/204—Point-of-sale [POS] network systems comprising interface for record bearing medium or carrier for electronic funds transfer or payment credit
-
- 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/22—Payment schemes or models
- G06Q20/24—Credit schemes, i.e. "pay after"
-
- 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
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
-
- 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
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
- G06Q30/0601—Electronic shopping [e-shopping]
- G06Q30/0641—Shopping interfaces
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/03—Credit; Loans; Processing thereof
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/12—Accounting
Definitions
- the present invention relates generally to credit systems and consumer, merchant and credit issuer relationships, and in particular, to a distributed system for commerce for interactions between consumers, merchants and credit issuers, where content is communicated between the parties in an intermediary and distributed form.
- a consumer engages with a merchant at the point-of-sale, such as online at the merchant's website, at the merchant's business or store, over the telephone with the merchant's call/sales center, etc.
- the merchant sends a request to the credit issuer to obtain authorization or verification data allowing the consumer to consummate the sale.
- the credit issuer may indicate to the merchant whether the consumer is creditworthy, is over his or her limit, is verified, has the available funds/balance to make the purchase, etc.
- a consumer when a consumer wishes to obtain a credit product, such as a credit card or credit account, from a credit issuer, such as a bank, the consumer fills out an application, whether in hard copy of electronic form, and submits this application to the credit issuer.
- the credit issuer will make a decision regarding whether the applicant is eligible for credit product. If the person is, indeed, eligible, and meets the necessary requirements, the credit issuer establishes an account and provides the consumer with either the appropriate account information, or in most cases, a physical credit card for use in engaging in transactions.
- the consumer in order to successfully consummate the transaction, the consumer must have some preexisting relationship with some credit provider in order to facilitate any non-cash transaction, e.g., an online transaction, a telephone transaction, etc. Therefore, in order to engage in some non-cash purchases, the consumer must obtain credit, initiate the transaction with the merchant, and utilize the obtained credit product to consummate the transaction and receive the goods and/or services.
- some credit provider e.g., an online transaction, a telephone transaction, etc. Therefore, in order to engage in some non-cash purchases, the consumer must obtain credit, initiate the transaction with the merchant, and utilize the obtained credit product to consummate the transaction and receive the goods and/or services.
- the credit request is sent by a merchant to the payment processor.
- the payment processing industry is subject to the programming specifications and hierarchy of the payment processors. Therefore, the merchant communications, credit requests, authorization requests, etc. all “choke” at the payment processor system, which dictates the message format, required data and processing requirements. Accordingly, presently-existing payment processors impart severe limitations on new payment products and methods. In addition, small businesses and merchants do not have enough of a stake in the present process to convince payment processors to change process or the current systems.
- electronic payment companies mediate payment between a customer or buyer and a merchant or seller.
- the seller offers the electronic payment through their point-of-sale channels, e.g., call center, web-store, physical store, etc., and customers selecting the payment option need to be successfully authorized and settled by the merchant.
- This electronic authorization and settlement event may be done directly with the payment company, or done via an existing payment processor relationship that the merchant has in place for other payment options.
- the direct method is, by far, the less attractive of these options, because it forces the payment company to physically connect their payment systems to each merchant. This, in turn, increases the cost of implementation and maintenance for the payment company. The cost is also higher from the merchant's point of view, since the merchant must add a new physical connection to their network and develop custom software to interface to the transaction application provider interface (API) for the new payment option.
- API transaction application provider interface
- the preferred option for payment companies and merchants is to access new payment services through the merchants preexisting payment processing partners. Since the merchant already maintains a physical connection to the payment processor, and since the merchant has already developed the appropriate programs to interface with the API of the processor, the level of effort to add an additional payment option is much lower.
- the payment processor's APIs are normally very large and complex software applications that are difficult and expensive for the payment processor to modify. Therefore, while this approach works well for the merchant, it is not preferable for the payment company, since they now have to pay the cost of the API modification to the payment processor, and wait for a lengthy period of time for the changes to be implemented.
- payment processors are independent companies in a highly concentrated industry. Presently, the top three payment processors control the majority of payment processing in the United States. Further, these payment processors have formed strategic alliances with specific payment service providers, who may seek to influence and/or restrict the addition of new and valuable payment alternatives to the processor's API. This further raises the cost and slows the implementation cycle for new payment options.
- the present invention is directed to a distributed system for commerce.
- the system includes at least one merchant system, including a communications system for receiving, processing and/or transmitting data, as well as at least one intermediate server system in communication with the at least one merchant system.
- the intermediate server system includes a data storage system for storing data transmitted to the system and a communications system for receiving, processing and/or transmitting data.
- the system includes at least one payment processor system.
- This payment processor system includes a processing system for processing credit-based transactions and a communications system for receiving, processing and/or transmitting data. Further, the intermediate server system is in communication with the payment processor system.
- the system includes at least one credit issuer system.
- the credit issuer system includes a processing system for processing credit data directed to at least one credit product and a communications system for receiving, processing and/or transmitting data.
- the intermediate server system is in communication with the credit issuer system.
- FIG. 1 is a schematic view of one embodiment of a distributed system for commerce according to the principles of the present invention
- FIG. 2 is a schematic view of another embodiment of a distributed system for commerce according to the principles of the present invention.
- FIG. 3 is a schematic view of a still further embodiment of a distributed system for commerce according to the principles of the present invention.
- FIG. 4 is a schematic view of another embodiment of a distributed system for commerce according to the principles of the present invention.
- FIG. 5 is an example of a screen displayed to a user in connection with one embodiment of a distributed system for commerce according to the principles of the present invention.
- FIG. 6 is an example of another screen displayed to a user in connection with one embodiment of a distributed system for commerce according to the principles of the present invention.
- the present invention is directed to a system 10 for use in commerce, e.g., commercial transactions, consumer/merchant relationships, consumer/merchant/credit issuer relationships, etc.
- the system 10 of the present invention is distributed, and particularly useful in connection in a networked environment N.
- the system 10 facilitates commercial transactions between a user U (e.g., the consumer) and a merchant and/or credit issuer.
- the presently-invented system is equally useful in connection with debit issuers (financial institutions) and debit-based transactions, such that instances herein directed to “credit products” and “credit issuers” are interchangeable with “debit products” and “debit issuers”.
- the “credit issuer” may be a credit card company, a payment services system, a payment company, an electronic payment company, etc. In general, it is the credit issuer that supplies the credit product to the consumer, which credit product is used in a credit-based transaction, whether online (in the networked environment N), over the telephone or at a physical point-of-sale.
- Various embodiments of the presently-invented system 10 are illustrated in schematic form in FIGS. 1-4 .
- the system 10 includes a merchant system 12 , and this merchant system 12 is provided with a network interface 14 and a communications system 16 .
- the system 10 includes an intermediate server system 18 , which has a data storage system 20 and a communications system 22 . This arrangement and interaction is illustrated in FIG. 1 .
- the merchant system 12 and in particular the network interface 14 of the merchant system 12 , is programmed or otherwise configured to present content 24 to the user U, interact with the user U, accept input data 26 from the user U, etc. Further, and as is known in the art, the communications system 16 facilitates the receipt, processing and transmission of data.
- the network interface 14 that serves content 24 to the user U and accepts input data from the user U may be provided by the intermediate server system 12 directly to the user U (bypassing the merchant system 12 ). Similarly, this network interface 14 may be provided to the user from the credit issuer or other system directly to the user U or through the intermediate server system 12 .
- the intermediate server system 18 is in communication with the merchant system 12 .
- the data storage system 20 of the intermediate server system 18 allows for the storage of data transmitted to the intermediate server system 18 .
- the communications system 22 of the intermediate server system 18 also facilitates the receipt, processing and transmission of data. Accordingly, the communications systems 16 , 22 allow for the appropriate communication of data between the merchant system 12 and the intermediate server system 18 .
- Any means of communication is envisioned, and wireless platforms are used when the present invention is operating in the networked environment N.
- the communications may be over a network, over the Internet, over a networked system of computers, over a virtual private network, secured communications, etc. Any effective manner of transmitting, processing and receiving data is envisioned.
- the user U engages with the merchant system 12 via the network interface 14 .
- the network interface 14 may be interactive, thereby allowing content 24 to be displayed to the user U, as well as accepting input data 26 from the user U.
- This content 24 may take many forms.
- the content 24 presented to the user includes: terms relating to a credit product; conditions relating to a credit product; card member agreement data; credit product offer data; credit issuer data; application data; credit issuer description data; credit product description data; explanation data; advertisement data; promotional data; banner data; hyperlink data; transactional data; checkout data; user data; credit issuer data; merchant data; authorization data; permission data; payment data; transaction-specific data; identification data; network data; processing data; settlement data payment data, etc.
- the content 24 presented to the user U may take a variety of forms that allow for the successful interaction and transaction between the user U, the merchant system 12 , a credit issuer or some other network system in the networked environment N, e.g., the payment process (as discussed hereinafter).
- the user U engages with or otherwise operates a computer 28 , which includes a presentation device 30 , such as a computer monitor and the like. Accordingly, the network interface 14 is providing content 24 to the user U on the presentation device 30 . Further, in this embodiment, the merchant system 12 is in the form of an online location or website that either presents or distributes the content 24 to the user U on the user's presentation device 30 .
- the user U provides input data 26 to the computer 28 , and this input data 26 is saved on a data storage system 32 of the merchant system 12 .
- this input data 26 may also be provided directly to the data storage system 20 of the intermediate server system 18 .
- this input data 26 may be transmitted directly from the merchant system 12 to another system, e.g., a credit issuer, a payment company, an electronic payment company, a third-party data collection system, etc.
- the input data 26 may be routed through the intermediate server system 12 to another system for storage.
- the input data 26 of the user U is transmitted directly to the intermediate server system 12 or some other system, e.g., the credit issuer system.
- the content 24 in one embodiment is transmitted from the intermediate server system 18 to the merchant system 12 , and this content 24 is then served and presented to the user U directly by the merchant system 12 on the user's presentation device 30 . Further, this content 24 may be transmitted on a periodic basis, a dynamic basis, a request basis, etc. This means that the content 24 may be transmitted to the data storage system 32 of the merchant system 12 on some set basis, as the content 24 changes and/or when the merchant system 12 requests this content 24 . Accordingly, in this embodiment, the content 24 is stored on the merchant system 12 .
- this content 24 (or data) may be updated, modified, certified, deleted and/or monitored by the intermediate server system 18 , or alternatively by some other system, e.g., the payment processor, the credit issuer, a third-party application service provider, etc.
- the intermediate server system 18 is capable of monitoring the content 24 resident on the data storage system 20 of the merchant system 12 , and can thus ensure that this content 24 provided to the user U is appropriate and fully accurate.
- the content 24 may be simply referenced by the merchant system 12 at a location on the intermediate server system 18 , in particular, at a specified location on the data storage system 20 of the intermediate server system 18 . In this manner, the content 24 would be served by the intermediate server system 18 directly to the user U on the user's presentation device 30 , such as on the network interface 14 or in some other similar manner. Still further, the user U may be redirected to an intermediate server system interface 34 . As with the network interface 14 of the merchant system 12 , in this embodiment, the intermediate server system interface 34 would also be programmed or configured to present content 24 to the user U, interact with the user U, accept input data 26 from the user U, etc.
- this content 24 may be updated on a periodic basis, dynamic basis, request basis, etc.
- this content 24 would be updated on the data storage system 20 of the intermediate server system 18 by some third-party control system, referred to as a central system 36 . Therefore, the central system 36 maintains ultimate control over data integrity, as well as the makeup and accuracy of the content 24 provided to the user U.
- Such arrangement is especially useful when multiple intermediate server systems 18 are used for distributing this content 24 to a large number and wide variety of users U. All of the individual intermediate server systems 18 may also be in communication with each other via the communications system 22 , or may only be in communication with the central system 36 . In either case, the user U is provided with the relevant content 24 through the most appropriate intermediate server system 18 , e.g., the nearest location, the fastest connection, etc. In addition, such an arrangement allows for the utmost control of the content 24 . As discussed, and in one preferred embodiment, the content 24 is displayed in response to a user-selected hyperlink presented on a page of a merchant online location, e.g., a website, etc.
- the presently-invented system is useful in connection with credit-based and debit-based transactions, such as in an online, networked environment N.
- the credit issuer or payment company
- this mediation requires some direct path between the merchant system 12 and the credit issuer. This mediation often leads to the various drawbacks discussed above.
- the presently-invented system 10 serves to leverage the merchant's existing investment in distributed content 24 delivery by extending the use of the existing merchant content 24 delivery infrastructure, and by allowing it to also serve as a direct connection into the credit issuer for the customer or user U.
- the merchant may distribute their content throughout a global network of web servers maintained by a network provider.
- a user accesses the merchant's content, they are automatically routed to the closest web server to their personal computer, and therefore, the speed of delivery is maximized, and the customer experience is enhanced.
- Another benefit to the merchant is that this distributed system reduces the merchant's need to design their internal server capacity to handle peaks in usage. Because a portion of the shopping experience is offloaded to the distributed network, there is no need for the merchant to support this portion of the usage with internal resources. Should the customer fill the shopping cart and make a purchase, the user is transferred to the merchant's secure servers and the purchase is completed
- the presently-invented system 10 enhances this distributed content concept to serve as the platform for the payment step of the merchant's checkout process.
- the content delivery system (intermediate server system 18 ) delivers the appropriate web forms to complete the checkout process, i.e., the forms associated with the permission step of the transaction, and the user information is sent directly to the credit issuer, where it is further separated into useable data sets (as discussed hereinafter), and further routed to a payment processor and the credit issuer's internal processing platform.
- the advantages to the merchant and credit issuer using this solution include enhanced security, as customer personal information and authentication credentials are not collected or stored within the merchant's system (no chance for data breach), and low cost of implementation, i.e., this distributed content model in used by retailers by distributing the payment interface onto an existing, distributed and global platform.
- the present system 10 is particularly useful in connection with commercial transactions. Accordingly, the merchant system 12 (and/or the user U) transmits transactional data 38 to the intermediate server system 18 .
- the intermediate server system 18 is programmed or configured to receive, process and/or transmit this transactional data 38 to other systems in the networked environment N. While the transactional data 38 may take many forms and formats, in one embodiment, the transactional data 38 may include user data, credit issuer data, merchant data, authorization data, payment data, transaction-specific data, identification data, network data, processing data, settlement data, etc. Accordingly, the transactional data 38 generated by the user U, the merchant, the credit issuer, etc. is transmitted over and distributed over the distributed system 10 of the present invention, specifically through the intermediate server systems 18 .
- the payment processors serve to facilitate credit-based or debit-based transactions between users U and merchants using a credit or debit product of an issuer.
- the payment processors have payment processor systems 40 that serve to dictate the form and format of the transactional data 38 provided to the payment processor system 40 for use in consummating these credit-based or debit-based transactions.
- the payment processor system 40 is dis-intermediated from the merchant system 12 .
- the transactional data 38 is provided by the user U to the merchant system 12 via the computer 28 .
- This transactional data 38 includes a plurality of data points 42 , which are provided to the intermediate server system 18 by the merchant system 12 .
- the intermediate server system 18 may transmit only a portion of the transactional data 38 , i.e., only certain data points 42 , to the payment processor system 40 for use in completing the transaction, such as accepting requests and providing authorization.
- this portion of transactional data 38 provided to the payment processor system 40 may be placed in or formatted in a predetermined manner prior to transmission to the payment processor system 40 .
- the payment processor system 40 still receives the appropriate transactional data 38 in the appropriate form and format for completing the credit-based or debit-based transaction. Further, the payment processor system 40 is capable of transmitting transactional data 38 through the intermediate server system 18 , the merchant system 12 , etc. In this manner, the credit-based or debit-based transaction is appropriately completed.
- the system 10 may also include a credit issuer system 44 .
- This credit issuer system 44 is capable of receiving, processing and/or transmitting data, and the intermediate server system 18 is in communication with the credit issuer system 44 within the networked environment N.
- the intermediate server system 18 and credit issuer system 44 are capable of communicating appropriate transactional data 38 therebetween.
- this transactional data 38 may include input data 26 , user U data, credit issuer data, merchant data, authorization data, payment data, transaction-specific data, identification data, network data, processing data, settlement data, etc.
- all of the data points 42 i.e., all of the transaction data 38
- the intermediate server system 18 is communicated by the intermediate server system 18 to the credit issuer system 44 . Therefore, while only a portion of this transactional data 38 is provided to the payment processor system 40 , all data is provided to the credit issuer system 44 .
- only a portion of the data points 42 is transmitted to the credit issuer system, and the full set of transaction data is built by the intermediate server system 12 using the data returned from the credit issuer system 44 and the payment processor system 40 .
- the payment processor system 40 may provide appropriate transactional data 38 , e.g., fulfillment, payment or settlement data, directly to the credit issuer system 44 or to the credit issuer system 44 via the intermediate server system 18 .
- appropriate transactional data 38 e.g., fulfillment, payment or settlement data
- the intermediate server system 18 and/or the credit issuer system 44 receives the transactional data 38 from the payment processor system 40 , this data is recombined or otherwise matched with the appropriate and full set of transactional data 38 .
- Either one or both of the intermediate server system 18 and the credit issuer system 44 may include the appropriate algorithms to match the transactions and ensure full integration of the data points 42 received from all systems 12 , 18 , 40 , 44 . Accordingly, all of the relevant systems are receiving the appropriate data in the appropriate form and format based upon the seamless communication and operating features of the presently-invented system 10 .
- an example of some data that the payment processor system 40 does not desire to receive or use would be small business data, gift card information, enumeration data, loyalty information, new consumer data, etc. Therefore, while such transactional data 38 may be useful to the credit issuer or merchant, only a small portion related to the specific transaction is of interest to the payment processor system 40 . Therefore, the entire set of transactional data is analyzed by the intermediate server system 18 , and only a portion extracted for communication to the payment processor system 40 .
- the full data set (100%) of transactional data 38 is sent to the intermediate server system 18 .
- the intermediate server system 18 analyzes this transactional data 38 and extracts a partial set (60%), which includes data required by the payment processor system 40 .
- This partial set of data (60%) is appropriately formatted and forwarded to the payment processor system 40 , while the full data set (100%) is sent to the credit issuer system 44 .
- the payment processor system 40 receives the formatted data (60%), which would appear to be a processing request from the merchant via the credit issuer.
- the payment processor system 40 would then authorize the transaction and send the authorization to the credit issuer system 44 based upon the partial data set (60%).
- the credit issuer system 44 could then match the partial data set (60%) with the full data set (100%) on a transaction-by-transaction basis, and the full transaction would then be authorized, appended and communicated back to the merchant.
- the commercial transaction and specifically a credit-based or debit-based commercial transaction, is appropriately facilitated and all parties are able to use a variety of desired data points 42 , while receiving only specified data points 42 needed to process the transaction.
- the permission loop is defined by a message that contains an account or customer identifier, a merchant identifier, a transaction amount, a transaction date, a payment type and a permission or approval code. These fields are core to all payment types and always occur within the permission transaction loop.
- the financial settlement transaction loop is defined by a message that contains an account identifier, merchant identifier, a transaction amount, a transaction date, a payment type, a permission or approval code and a description field. Since these two parts are present for all payment options, they are referred to as a common feature data set, which represents the portion of the API that is constant across all payment options within a payment processor's API.
- variable feature data set There exists a second part of the payment option API, which may be referred to as a variable feature data set.
- This portion of the API represents the features of the payment option that are unique to a specific payment option.
- the variable feature data set represents the specifics of the payment method within the API. For example, a CVV code in a Visa authorization is Visa's specific implementation of a device authentication code that is unique to their payment option.
- a PIN code in a debit card transaction is a user authentication code specific to the debit card authorization transaction.
- the present invention allows for a significantly faster delivery and implementation of new payment options, at a far lower cost to the credit issuer.
- the credit issuer system 44 and/or the intermediate server system 18 may be provided with additional functionality in order to facilitate the transaction.
- additional functionality may include authenticating the user U, verifying the user U, approving or denying a user U application, verifying a transaction, processing user data, processing merchant data, processing credit (or debit) issuer data, processing transactional data 38 , processing credit or debit product data, etc. Therefore, a full range of functionality is provided to facilitate and transact a variety of credit-based or debit-based transactions.
- the merchant system 12 may take many forms.
- the merchant system 12 may be an online location, a merchant web page, a merchant call center, a merchant settlement system, etc.
- the merchant system 12 is in communication with the intermediate server system 18 , and may also be in communication with the payment processor system 40 and credit issuer system 44 .
- the above-discussed content 24 may be presented or provided to the user U prior to a transaction, during the transaction or after the transaction.
- the content 24 may be presented to the user U in a variety of forms.
- this content 24 may be presented in the form of a web page, an electronic document, a window, a pop-up window, etc.
- various transactional data 38 , data points 42 (or fields), content 24 or other information or data is provided to the user U.
- the network interface 14 of the merchant system 12 may be presented to the user U on the presentation device 30 of the user U.
- this network interface 14 (or the intermediate server system interface 34 ) may be interactive, such that a variety of data fields and points may be displayed to the user U, and the input data 26 accepted.
- the content 24 presented to the user U may be interest rate data, credit limit data, purchase data, charge data, cost data, expense data, annual fee data, interest accrual data, statement data, account data, fund advancement data, transfer data, delinquency data, payment term data, account review data, credit product data, credit issuer data, contract data, liability data, certification data, privacy data, personal information use data, collected information data, consent data, foreign data, access data, online service data, phone service data, liability data, representation data, warranty data, termination data, indemnity data, term variation data, communication data, assignment data, rights data, governing law data, or any combination thereof.
- the input data 26 may include user identification, a PIN, a name, a consumer key, a consumer identification, an account number, an address, a city, a state, a zip code, a country, a telephone number, an e-mail address, a social security number, a date of birth, the merchant's name, an identification, an order number, an authorization number, an authorization time, an authorization amount, a ship-to address, a bill-to address, a transaction amount, a consumer purchase demographic, a transaction date, a transaction type, a product identification, a service identification, shipping costs, delivery type, consumer type, a company identity, a merchant identity, previous transaction data, geographical data, credit account data, bankcard balance data, delinquency data, credit segment data, previous transaction data, time between transactions data, previous transaction amount, previous transaction approval status, previous transaction time stamp data, a response code, consumer payment method, consumer payment history, consumer account history, consumer credit account balance, income data, family data, employment data, relationship
- the central system 36 may already have on hand specific data that can be used to pre-populate various screens or input fields of the user U at the network interface 14 and/or intermediate server system interface 34 . Accordingly, such data may be stored at the credit issuer system, or otherwise stored on the data storage system 20 of the intermediate server system 18 . Therefore, the user U would not need to continually retype his or her information into the appropriate interface 14 , 34 , and instead, the data would be pre-populated to the extent possible.
- the content 24 is in the form of an offer of one or more credit products to the user U.
- the input data 26 may be directed to this offer. Therefore, the user U is presented with: terms of the credit product; conditions of the credit product; an account agreement; explanation data; promotional data, etc.
- the user U may choose to use a specific credit product that he or she does not currently own, such that an application for this credit product is provided to the user U on the network interface 14 and/or intermediate server system interface 34 .
- the input data 26 provided by the user U may include acknowledgement data from the user U, and further content 24 provided to the user U is a credit product application.
- the user U provides input data 26 in the form of application input data, which is transmitted to the intermediate server system 18 and/or the credit issuer system 44 .
- the intermediate server system 18 and/or credit issuer system 44 is programmed or configured to approve or deny an application by the user U for the credit product based at least in part upon the input data 26 provided by the user U. If approved, an account may be opened and established for the user U for the credit product of the credit issuer, and, if denied, denial data may be transmitted to the user U.
- consumer risk data may be determined based upon the input data 26 of the user U, the acknowledgment data, the application input data, etc.
- the system 10 of the present invention is illustrated in FIG. 4 .
- the content 24 may be downloaded to and served by the merchant system 12 .
- the content 24 may be referenced by the merchant system 12 , but directly served to the user U by the intermediate server system 18 .
- the merchant system 12 may send authorization messages directly to the intermediate server system 18 .
- the merchant system 12 may send authorization messages to the intermediate server system 18 for specific transactions, and redirect the user U to the intermediate server system 18 for other types of transactions.
- the merchant system 12 includes a merchant online location 46 , a merchant call center 48 and a merchant fulfillment system 50 .
- both the merchant online location 46 and the merchant call center 48 send or transmit authorization requests to the intermediate server system 18 , which is in communication with the payment processor system 40 .
- the payment processor system 40 is in communication with the credit issuer system 44 . After authorization is provided, these authorized orders are communicated from the merchant online location 46 and the merchant call center 48 to the merchant fulfillment system 50 , which provides settlement requests either to the intermediate server system 18 or directly to the payment processor system 40 . Finally, the payment processor system 40 funds the transaction with a communication to the merchant fulfillment system 50 .
- specific content 24 is downloaded by the merchant system 12 from the data storage system 20 of the intermediate server system 18 .
- This content 24 is served directly to the user U (i.e., at the network interface 14 on the user's browser).
- the content 24 may be provided directly from the data storage system 20 of the intermediate server system 18 to the user U.
- the merchant does not need to handle any type of consumer regulatory updates.
- the merchant system 12 will be provided with the appropriate URLs for the web content 24 , such as the terms and conditions, a What Is? section, FAQs, banners, logos, etc. The merchant system 12 would reference these URLs or establish a process to refresh the content 24 during some periodic maintenance window.
- the merchant system 12 directly references web content 24 on the intermediate server system 18 , and further, sends authorization requests as messages to the intermediate server system 18 .
- settlement and funding still occurs directly between the merchant fulfillment system 50 and the payment processor system 40 .
- merchants will create web services requests to the intermediate server system 18 for authorizations in both the merchant online location 46 and the merchant call center 48 , as well as for re-authorizations.
- the intermediate server system 18 would act as the “submitter” on behalf of the merchant to the payment processor system 40 .
- the merchant system 12 references web content 24 on the intermediate server system 18 , and is also sending authorization requests from the merchant call center 48 as messages to the intermediate server system 18 . Still further, users U are redirected from the merchant system 12 directly to pages hosted on the intermediate server system 18 , such as in the form of an intermediate server system interface 34 . Again, all settlement and funding occurs directly between the merchant fulfillment system 50 and the payment processor system 40 .
- Such integration provides a fully optimized transactional experience to the user U.
- the merchant system 12 does not need to handle any additional and ancillary transactional data 38 . The merchants would not need to build any specific interfaces or pages, as all of this information is provided directly from the intermediate server system 18 .
- the intermediate server system 18 acts as the “submitter” for the merchant to the payment processor system 40 .
- the merchant call center 48 may also interact directly with the payment processor system 40 , as opposed to acting through the intermediate server system 18 .
- the system 10 is also useful in connection with a first-time user U that is shopping anonymously.
- the merchant communicates user U and order information to the intermediate server system 18 using a pc-request web service call.
- the intermediate server system 18 validates the user U and order data and returns a URL to redirect the user U to a hosted page of the intermediate server system 18 .
- the user U is redirected to a hosted page (or the intermediate server system interface 34 ) on the intermediate server system 18 , where the user U enters authentication information and data, completes any required fields that have not been pre-populated or otherwise enters the appropriate input data 26 .
- the user U selects to process the transaction.
- the intermediate server system 18 captures the authentication information and any other required information, processes the authorization request and communicates with the payment processor system 40 .
- the user U will then be redirected to one of multiple URLs provided by the merchant in the pc-request depending upon its success or failure of the authorization.
- the merchant system 12 After the user U is redirected to a “success” URL, the merchant system 12 will use the pc-status call to capture the authorization response details for settlement. Accordingly, the merchant system 12 requests and records authorization responses for use in settlement processing, and the intermediate server system 18 returns status responses, which include account numbers and authorization codes for use in this settlement processing procedure.
- Another example of the presently-invented system 10 is usable for non-web-enabled systems (e.g., merchant call center 48 and merchant fulfillment system 50 ), as well as for returning authenticated web users U.
- the merchant system 12 uses the pc-request with a “process” action code to post the user U and order data to the intermediate server system 18 , as well as process any authorization request.
- the intermediate server system 18 will automatically provide the authorization responses back to the merchant system 12 .
- the process request transmitted from the merchant system 12 would include the purchase amount, the account number, information about the customer, date of birth, the last four digits of the social security number, merchant customer type, bill-to name/address, ship-to name/address, e-mail address, telephone number, IP address, etc.
- information about the transaction such as shipping costs, product type and channels, would also be included.
- the response from the intermediate server system 18 would be in the form of a standard credit card response, and utilize standard response codes and authorization control codes.
- the actual 16-digit account number would also be transmitted.
- the authorization requests and messages may take a variety of forms and formats.
- a merchant order number may be set and used during the submission process. This merchant order number would carry through to the intermediate server system 18 and the payment processor system 40 .
- the merchant order number may be useful in communication with the credit issuer system 44 regarding the transaction.
- this merchant order number can be used for authorization add-ons, where a user U contacts the merchant after an order has been placed to add additional items to the order.
- a set of business rules may be used to optimize the performance of the intermediate server system 18 , as well as the overall system 10 .
- three different web service calls may be used in connection with authorizations and status.
- the pc-request call with the action code of “set” allows the merchant to post the user U and order information.
- a pc-commit call allows the merchant to request that the information in the pc-request call now be processed for an authorization.
- the pc-request call with an action code of “process” allows the merchant to submit the user U and order information and process the request for the authorization in the same transaction.
- a pc-status call may be used by the merchant for requesting the current status of an authorization request that has already been processed.
- Table 1 illustrates various standard fields used in connection with the pc-request function.
- pc-update-info-url Optional (See PC A/N(200) Used to redirect the customer if Usage) they choose to update their address on the hosted page. Merchant generated. pc-choose-other-mop- SET A/N(200) Used to specify the redirect if the url customer chooses to go back to the payment options screen while sitting on the page. Merchant generated.
- pc-favicon-url Optional See PC A/N(200) Usage
- pc-css-stylesheet-url Optional See PC A/N(200) Usage
- soft-error-threshold Optional See PC N(1) Allows merchant to override the Usage
- payment-division ALL N(10) This is the Payment Processor Division.
- pc-merchant-id ALL N(15) Value used for Pricing, Terms, Merchant Settings. Defined value.
- merchant-order- Optional See PC A/N(22) A unique customer order number number Usage) that is typically used for reconciliation purposes. (NOTE: Will be generated by PC if left blank), Merchant generated.
- term-and-conditions- ALL N(5) Merchant will pass one of two code values based on the sales channel. Defined value.
- customer-registration- ALL Date Customer original registration date YYYY-MM- date. If not registered or new to DD the site, use the current date.
- delivery-method ALL A/N(3) Indicates how the majority of the product in the order was delivered. Valid values are: PHY—Physical, DIG—Digital, SVC—Service, CNC—Cash and Carry shipping-amount Optional (See PC N(6v2) Required if PHY delivery Usage) method.
- alternate-ip-address Optional (See PC A/N(15) This may be required in certain Usage) cases.
- split-tender-indicator Optional (See PC A/N(5) TRUE/FALSE Used to indicate Usage) that there is a split payment on this authorization.
- Preferred Account Fields bill-to-name ALL A/N(60) bill-to-address-1 ALL A/N(30) bill-to-address-2 Optional (See PC A/N(30) Usage) bill-to-city ALL A/N(30) bill-to-state ALL A/N(30)
- For US states and territories use standard two character abbreviation.
- bill-to-postal-code ALL A/N(30) Bill to zip code. Left justify, space fill.
- bill-to-country ALL A/N(2) bill-to-email-address ALL A/N(50 This field is required by BML for all web transactions and should be requested in all call center transactions if possible.
- An extension number XXXX can be passed or leave it blank.
- An extension number XXXX can be passed or leave it blank.
- the pc-commit call is used when the merchant wants to process a request that was previously submitted via the pc-request call with the “set” action code. This call may be used if the merchant has a confirmation screen after the hosted page of the intermediate server system 18 , but does not want the authorization to get processed until the customer or user U confirms the order on that page.
- the various field names for the pc-commit call are illustrated in Table 2.
- Constant PROCESS sub-action ALL Auth, Pre-approve, Score session-key ALL Long Key to existing customer data for operating in confirm mode (What is passed) consumer-ssn N N(9) Last four for MOP Full for SSN for PA MOP Pre-fill with leading zeros if only sending last four consumer-dob N Date YYYY-MM- DD term-and-conditions- N N(5) Defined Value code customer-ip-address ALL A/N(15) Customer's IP Address. (NOTE: this should be blank if authorization is originating from the Call Center or Retail channels.
- the pc-status request call is used when the merchant needs to get the status of a processed authorization. Normally, such a call is used by merchants to get the authorization response when the authorization is processed at the intermediate server system 18 .
- Table 3 illustrates the various fields associated with the pc-status call.
- the intermediate server system 18 provides an authorization response to the merchant system 12 .
- a specified account number e.g., of the credit issuer
- the account number may be stored with the order in case re-authorization, stand-loan credits or customer service inquiries are required.
- the account number would be used in connection with the customer profile for subsequent web purchases. If the user U has a secure login to the merchant online location 46 , the merchant may take advantage of the “authenticated” authorization format to allow a one-click purchase process.
- Table 4 illustrates the various fields that may be used in connection with a variety of payment, methods and for use in authorizing the transaction.
- Table 5 illustrates various suggested response codes and actions that the merchant should take for each code.
- delivery of content 24 between the intermediate server system 18 and the merchant system 12 may be in many different forms and formats.
- the content 24 may be referenced and provided to the user U in the form of a pop-up window.
- the merchants are insulated from making the required changes to various documents due to regulatory product changes.
- Two key files may be referenced by the merchant system 12 at the intermediate server system 18 , including an informational window 52 , which links from various credit issuer system 44 or intermediate server system 18 links, text messages and banners. This file would contain a description of the product, required disclosures and frequently ask questions.
- the user U would click on various banners 52 or text links 54 , as illustrated in FIG. 5 .
- the action of clicking on these banners 52 or text links 54 may either present content 24 to the user U from the merchant system 12 and/or the intermediate server system 18 .
- Another key file would be the terms and conditions 56 offered for the credit product.
- Such content 24 would generally be essentially served by the intermediate server system 18 , which allows the content 24 to be managed on behalf of the merchant.
- banner 52 or text link 54 is activated by the user U
- different versions will be provided and served to the user U.
- certain default content 24 may be provided and displayed to the user U when promotional financing is not being offered.
- certain other content 24 may be displayed to the user U when promotional financing is available.
- the terms and conditions 56 are presented to the user U on a payment page 58 .
- the terms and conditions 56 may be presented in a variety of formats.
- an HTML version 60 may be presented to the user U via text links 54
- a PDF version may be presented to the user U upon activating a “printer friendly version” link 62 .
- the links provided in this application or payment page may utilize well-known e-sign and other acknowledgement techniques.
- Activating a phone order link 64 directs the user U to the disclosure requirements for various phone orders, such as in a promotional financing informational window.
- the present invention provides a distributed system 10 for commercial transactions, and is particularly useful in connection with online and remote commerce between consumers and merchants.
- the distributed system 10 of the present invention provides content 24 to the user U through the merchant system 12 , and this content 24 is provided to the merchant through the intermediate server system 18 .
- certain content 24 is provided directly to the user U by the intermediate server system 18 , such as through the intermediate server system interface 34 .
- the present invention provides a system 10 that facilitates credit-based and debit-based transactions between a consumer, a merchant and a credit (or debit) issuer.
- the content 24 provided to the user U is dynamic and accurate.
- system 10 of the present invention provides an intermediary between the merchant system 12 and the payment processing system 40 and/or the credit issuer system 44 . Accordingly, the present invention is directed to a distributed system 10 for commerce that provides secure communications and facilitates transactions in an electronic, online, telephone or other remote environment.
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- Theoretical Computer Science (AREA)
- Strategic Management (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Marketing (AREA)
- Technology Law (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
Description
- This application is a continuation of U.S. patent application Ser. No. 11/799,667, filed May 2, 2007, which is incorporated herein by reference in its entirety.
- 1. Field of the Invention
- The present invention relates generally to credit systems and consumer, merchant and credit issuer relationships, and in particular, to a distributed system for commerce for interactions between consumers, merchants and credit issuers, where content is communicated between the parties in an intermediary and distributed form.
- 2. Description of the Related Art
- In order to enable convenient purchases of goods and services by consumers, the financial service industry has developed many alternative payment methods that allow a consumer to engage in a transaction and receive goods and services on credit. For example, such alternative payment methods may include checks, ATM or debit cards, credit cards, charge cards, etc. Prior to the birth of virtual commerce, as discussed below, such payment options provided adequate convenience and transactional security to consumers and merchants in the marketplace. Virtual commerce and the growth of the Internet as a medium for commerce have placed pressure on the payment options discussed above on the convenience, transactional security and profitability by the credit issuer. Currently, available payment options include significant shortcomings when applied to remote purchasers, such as purchases where the buyer and the seller (that is, the merchant) are not physically proximate during the transaction. Specific examples of remote purchases are mail order, telephone order, the Internet and wireless purchases.
- In a typical credit transaction and process, a consumer engages with a merchant at the point-of-sale, such as online at the merchant's website, at the merchant's business or store, over the telephone with the merchant's call/sales center, etc. The merchant sends a request to the credit issuer to obtain authorization or verification data allowing the consumer to consummate the sale. For example, the credit issuer may indicate to the merchant whether the consumer is creditworthy, is over his or her limit, is verified, has the available funds/balance to make the purchase, etc.
- According to the prior art, and in the first instance, when a consumer wishes to obtain a credit product, such as a credit card or credit account, from a credit issuer, such as a bank, the consumer fills out an application, whether in hard copy of electronic form, and submits this application to the credit issuer. Once the appropriate information is received from the consumer, the credit issuer will make a decision regarding whether the applicant is eligible for credit product. If the person is, indeed, eligible, and meets the necessary requirements, the credit issuer establishes an account and provides the consumer with either the appropriate account information, or in most cases, a physical credit card for use in engaging in transactions. In addition, in order to successfully consummate the transaction, the consumer must have some preexisting relationship with some credit provider in order to facilitate any non-cash transaction, e.g., an online transaction, a telephone transaction, etc. Therefore, in order to engage in some non-cash purchases, the consumer must obtain credit, initiate the transaction with the merchant, and utilize the obtained credit product to consummate the transaction and receive the goods and/or services.
- Once the credit product has been obtained by the consumer, and this credit product is used in connection with satisfying a transaction, the credit request is sent by a merchant to the payment processor. However, the payment processing industry is subject to the programming specifications and hierarchy of the payment processors. Therefore, the merchant communications, credit requests, authorization requests, etc. all “choke” at the payment processor system, which dictates the message format, required data and processing requirements. Accordingly, presently-existing payment processors impart severe limitations on new payment products and methods. In addition, small businesses and merchants do not have enough of a stake in the present process to convince payment processors to change process or the current systems.
- These and other deficiencies in the presently-existing processes in the electronic payment industry may be further illustrated as follows. According to the prior art, electronic payment companies (credit issuers) mediate payment between a customer or buyer and a merchant or seller. The seller offers the electronic payment through their point-of-sale channels, e.g., call center, web-store, physical store, etc., and customers selecting the payment option need to be successfully authorized and settled by the merchant. This electronic authorization and settlement event may be done directly with the payment company, or done via an existing payment processor relationship that the merchant has in place for other payment options. The direct method is, by far, the less attractive of these options, because it forces the payment company to physically connect their payment systems to each merchant. This, in turn, increases the cost of implementation and maintenance for the payment company. The cost is also higher from the merchant's point of view, since the merchant must add a new physical connection to their network and develop custom software to interface to the transaction application provider interface (API) for the new payment option.
- Therefore the preferred option for payment companies and merchants is to access new payment services through the merchants preexisting payment processing partners. Since the merchant already maintains a physical connection to the payment processor, and since the merchant has already developed the appropriate programs to interface with the API of the processor, the level of effort to add an additional payment option is much lower. However, from the payment company's standpoint, there are still material shortcomings to this approach. For example, the payment processor's APIs are normally very large and complex software applications that are difficult and expensive for the payment processor to modify. Therefore, while this approach works well for the merchant, it is not preferable for the payment company, since they now have to pay the cost of the API modification to the payment processor, and wait for a lengthy period of time for the changes to be implemented.
- Further, payment processors are independent companies in a highly concentrated industry. Presently, the top three payment processors control the majority of payment processing in the United States. Further, these payment processors have formed strategic alliances with specific payment service providers, who may seek to influence and/or restrict the addition of new and valuable payment alternatives to the processor's API. This further raises the cost and slows the implementation cycle for new payment options.
- Yet another drawback to online commerce arises from the distributed nature of these electronic transactions, with the merchants likened to spokes around a hub, which is the network credit system. Such a distributed checkout service creates many unmanageable security risks. If all sales occur at the payment process or banking system, certain confidential information is collected at the spokes (merchants) to complete the transaction. This information distribution creates unnecessary risk to the hub. If the information is collected directly at the hub (credit issuer) location, the customer is redirected to the hub from the spoke, which may be undesirable to the merchant. For example, if the hub is the data repository, the merchant often does not trust that the hub will not use consumer to their own ends. In addition, the hub-centric approach often leads to access problems, processing capacity issues, possible offers of other competing goods, etc., which makes this approach undesirable.
- Therefore, it is an object of the present invention to provide a distributed system for commerce, such as online and remote commerce between a consumer and a merchant, that overcomes the drawbacks and deficiencies of the prior art. It is a further object of the present invention to provide a distributed system for commerce that provides content to a user through a merchant system, where the content is provided by the merchant through an intermediary, or directly by an intermediary. It a still further object of the present invention to provide a distributed system for commerce that facilitates credit-based or debit-based transactions between a consumer, a merchant and a credit issuer. It is another object of the present invention to provide a distributed system for commerce that provides dynamic content to a user (or consumer) via the merchant system and/or intermediate server system. It is a further object of the present invention to provide a distributed system for commerce that provides an intermediary between the merchant and a credit issuer (payment company, electronic payment company, etc.) and a payment processor. It is a still further object of the present invention to provide a distributed system for commerce that provides secure communications and facilitates transactions in an electronic, online, telephone or remote environment.
- Accordingly, in one embodiment, the present invention is directed to a distributed system for commerce. The system includes at least one merchant system, including a communications system for receiving, processing and/or transmitting data, as well as at least one intermediate server system in communication with the at least one merchant system. The intermediate server system includes a data storage system for storing data transmitted to the system and a communications system for receiving, processing and/or transmitting data.
- In a further embodiment of the present invention, the system includes at least one payment processor system. This payment processor system includes a processing system for processing credit-based transactions and a communications system for receiving, processing and/or transmitting data. Further, the intermediate server system is in communication with the payment processor system.
- In a still further embodiment of the present invention, the system includes at least one credit issuer system. The credit issuer system includes a processing system for processing credit data directed to at least one credit product and a communications system for receiving, processing and/or transmitting data. Further, the intermediate server system is in communication with the credit issuer system.
- These and other features and characteristics of the present invention, as well as the methods of operation and functions of the related elements of structures and the combination of parts and economies of manufacture, will become more apparent upon consideration of the following description and the appended claims with reference to the accompanying drawings, all of which form a part of this specification, wherein like reference numerals designate corresponding parts in the various figures. It is to be expressly understood, however, that the drawings are for the purpose of illustration and description only and are not intended as a definition of the limits of the invention. As used in the specification and the claims, the singular form of “a”, “an”, and “the” include plural referents unless the context clearly dictates otherwise.
-
FIG. 1 is a schematic view of one embodiment of a distributed system for commerce according to the principles of the present invention; -
FIG. 2 is a schematic view of another embodiment of a distributed system for commerce according to the principles of the present invention; -
FIG. 3 is a schematic view of a still further embodiment of a distributed system for commerce according to the principles of the present invention; -
FIG. 4 is a schematic view of another embodiment of a distributed system for commerce according to the principles of the present invention; -
FIG. 5 is an example of a screen displayed to a user in connection with one embodiment of a distributed system for commerce according to the principles of the present invention; and -
FIG. 6 is an example of another screen displayed to a user in connection with one embodiment of a distributed system for commerce according to the principles of the present invention. - It is to be understood that the invention may assume various alternative variations and step sequences, except where expressly specified to the contrary. It is also to be understood that the specific devices and processes illustrated in the attached drawings, and described in the following specification, are simply exemplary embodiments of the invention.
- The present invention is directed to a
system 10 for use in commerce, e.g., commercial transactions, consumer/merchant relationships, consumer/merchant/credit issuer relationships, etc. In addition, thesystem 10 of the present invention is distributed, and particularly useful in connection in a networked environment N. In one embodiment, thesystem 10 facilitates commercial transactions between a user U (e.g., the consumer) and a merchant and/or credit issuer. The presently-invented system is equally useful in connection with debit issuers (financial institutions) and debit-based transactions, such that instances herein directed to “credit products” and “credit issuers” are interchangeable with “debit products” and “debit issuers”. Still further, and as used throughout the following specification, the “credit issuer” may be a credit card company, a payment services system, a payment company, an electronic payment company, etc. In general, it is the credit issuer that supplies the credit product to the consumer, which credit product is used in a credit-based transaction, whether online (in the networked environment N), over the telephone or at a physical point-of-sale. Various embodiments of the presently-inventedsystem 10 are illustrated in schematic form inFIGS. 1-4 . - In one preferred and non-limiting embodiment, the
system 10 includes amerchant system 12, and thismerchant system 12 is provided with anetwork interface 14 and acommunications system 16. Similarly, thesystem 10 includes anintermediate server system 18, which has adata storage system 20 and acommunications system 22. This arrangement and interaction is illustrated inFIG. 1 . - The
merchant system 12, and in particular thenetwork interface 14 of themerchant system 12, is programmed or otherwise configured to presentcontent 24 to the user U, interact with the user U, acceptinput data 26 from the user U, etc. Further, and as is known in the art, thecommunications system 16 facilitates the receipt, processing and transmission of data. Of course, it is also envisioned that thenetwork interface 14 that servescontent 24 to the user U and accepts input data from the user U may be provided by theintermediate server system 12 directly to the user U (bypassing the merchant system 12). Similarly, thisnetwork interface 14 may be provided to the user from the credit issuer or other system directly to the user U or through theintermediate server system 12. - The
intermediate server system 18 is in communication with themerchant system 12. Thedata storage system 20 of theintermediate server system 18 allows for the storage of data transmitted to theintermediate server system 18. In addition, and as discussed above in connection with thecommunications system 16 of the merchant system, thecommunications system 22 of theintermediate server system 18 also facilitates the receipt, processing and transmission of data. Accordingly, thecommunications systems merchant system 12 and theintermediate server system 18. Any means of communication is envisioned, and wireless platforms are used when the present invention is operating in the networked environment N. For example the communications may be over a network, over the Internet, over a networked system of computers, over a virtual private network, secured communications, etc. Any effective manner of transmitting, processing and receiving data is envisioned. - In operation, the user U engages with the
merchant system 12 via thenetwork interface 14. Thenetwork interface 14 may be interactive, thereby allowingcontent 24 to be displayed to the user U, as well as acceptinginput data 26 from the user U. Thiscontent 24 may take many forms. In one preferred embodiment, thecontent 24 presented to the user includes: terms relating to a credit product; conditions relating to a credit product; card member agreement data; credit product offer data; credit issuer data; application data; credit issuer description data; credit product description data; explanation data; advertisement data; promotional data; banner data; hyperlink data; transactional data; checkout data; user data; credit issuer data; merchant data; authorization data; permission data; payment data; transaction-specific data; identification data; network data; processing data; settlement data payment data, etc. Accordingly, thecontent 24 presented to the user U may take a variety of forms that allow for the successful interaction and transaction between the user U, themerchant system 12, a credit issuer or some other network system in the networked environment N, e.g., the payment process (as discussed hereinafter). - As illustrated in the preferred and non-limiting embodiment of
FIG. 2 , the user U engages with or otherwise operates acomputer 28, which includes apresentation device 30, such as a computer monitor and the like. Accordingly, thenetwork interface 14 is providingcontent 24 to the user U on thepresentation device 30. Further, in this embodiment, themerchant system 12 is in the form of an online location or website that either presents or distributes thecontent 24 to the user U on the user'spresentation device 30. - In addition, and as illustrated in
FIG. 2 , the user U providesinput data 26 to thecomputer 28, and thisinput data 26 is saved on adata storage system 32 of themerchant system 12. In addition, thisinput data 26 may also be provided directly to thedata storage system 20 of theintermediate server system 18. Still further, thisinput data 26 may be transmitted directly from themerchant system 12 to another system, e.g., a credit issuer, a payment company, an electronic payment company, a third-party data collection system, etc. In addition, theinput data 26 may be routed through theintermediate server system 12 to another system for storage. In a still further embodiment, theinput data 26 of the user U is transmitted directly to theintermediate server system 12 or some other system, e.g., the credit issuer system. - The
content 24 in one embodiment is transmitted from theintermediate server system 18 to themerchant system 12, and thiscontent 24 is then served and presented to the user U directly by themerchant system 12 on the user'spresentation device 30. Further, thiscontent 24 may be transmitted on a periodic basis, a dynamic basis, a request basis, etc. This means that thecontent 24 may be transmitted to thedata storage system 32 of themerchant system 12 on some set basis, as thecontent 24 changes and/or when themerchant system 12 requests thiscontent 24. Accordingly, in this embodiment, thecontent 24 is stored on themerchant system 12. - In order to ensure the integrity of the
content 24 provided from theintermediate server system 18 to themerchant system 12, this content 24 (or data) may be updated, modified, certified, deleted and/or monitored by theintermediate server system 18, or alternatively by some other system, e.g., the payment processor, the credit issuer, a third-party application service provider, etc. Accordingly, theintermediate server system 18 is capable of monitoring thecontent 24 resident on thedata storage system 20 of themerchant system 12, and can thus ensure that thiscontent 24 provided to the user U is appropriate and fully accurate. - In another preferred and non-limiting embodiment, and as also illustrated in
FIG. 2 , thecontent 24 may be simply referenced by themerchant system 12 at a location on theintermediate server system 18, in particular, at a specified location on thedata storage system 20 of theintermediate server system 18. In this manner, thecontent 24 would be served by theintermediate server system 18 directly to the user U on the user'spresentation device 30, such as on thenetwork interface 14 or in some other similar manner. Still further, the user U may be redirected to an intermediateserver system interface 34. As with thenetwork interface 14 of themerchant system 12, in this embodiment, the intermediateserver system interface 34 would also be programmed or configured to presentcontent 24 to the user U, interact with the user U, acceptinput data 26 from the user U, etc. - When the
merchant system 12 either references thecontent 24 on theintermediate server system 18, or uses the intermediateserver system interface 34 to receive thecontent 24, as discussed above, thiscontent 24 may be updated on a periodic basis, dynamic basis, request basis, etc. In particular, thiscontent 24 would be updated on thedata storage system 20 of theintermediate server system 18 by some third-party control system, referred to as acentral system 36. Therefore, thecentral system 36 maintains ultimate control over data integrity, as well as the makeup and accuracy of thecontent 24 provided to the user U. - In addition, such arrangement is especially useful when multiple
intermediate server systems 18 are used for distributing thiscontent 24 to a large number and wide variety of users U. All of the individualintermediate server systems 18 may also be in communication with each other via thecommunications system 22, or may only be in communication with thecentral system 36. In either case, the user U is provided with therelevant content 24 through the most appropriateintermediate server system 18, e.g., the nearest location, the fastest connection, etc. In addition, such an arrangement allows for the utmost control of thecontent 24. As discussed, and in one preferred embodiment, thecontent 24 is displayed in response to a user-selected hyperlink presented on a page of a merchant online location, e.g., a website, etc. - As discussed above, the presently-invented system is useful in connection with credit-based and debit-based transactions, such as in an online, networked environment N. In some instances, the credit issuer (or payment company) must mediate the transactions that utilize the credit issuer's credit products, and this mediation requires some direct path between the
merchant system 12 and the credit issuer. This mediation often leads to the various drawbacks discussed above. To overcome these drawbacks, and as previously discussed, the presently-inventedsystem 10 serves to leverage the merchant's existing investment in distributedcontent 24 delivery by extending the use of the existingmerchant content 24 delivery infrastructure, and by allowing it to also serve as a direct connection into the credit issuer for the customer or user U. - According to the prior art, the merchant may distribute their content throughout a global network of web servers maintained by a network provider. When a user accesses the merchant's content, they are automatically routed to the closest web server to their personal computer, and therefore, the speed of delivery is maximized, and the customer experience is enhanced. Another benefit to the merchant is that this distributed system reduces the merchant's need to design their internal server capacity to handle peaks in usage. Because a portion of the shopping experience is offloaded to the distributed network, there is no need for the merchant to support this portion of the usage with internal resources. Should the customer fill the shopping cart and make a purchase, the user is transferred to the merchant's secure servers and the purchase is completed
- As discussed above, the presently-invented
system 10 enhances this distributed content concept to serve as the platform for the payment step of the merchant's checkout process. According to the present invention, the content delivery system (intermediate server system 18) delivers the appropriate web forms to complete the checkout process, i.e., the forms associated with the permission step of the transaction, and the user information is sent directly to the credit issuer, where it is further separated into useable data sets (as discussed hereinafter), and further routed to a payment processor and the credit issuer's internal processing platform. The advantages to the merchant and credit issuer using this solution include enhanced security, as customer personal information and authentication credentials are not collected or stored within the merchant's system (no chance for data breach), and low cost of implementation, i.e., this distributed content model in used by retailers by distributing the payment interface onto an existing, distributed and global platform. - The
present system 10 is particularly useful in connection with commercial transactions. Accordingly, the merchant system 12 (and/or the user U) transmitstransactional data 38 to theintermediate server system 18. Theintermediate server system 18 is programmed or configured to receive, process and/or transmit thistransactional data 38 to other systems in the networked environment N. While thetransactional data 38 may take many forms and formats, in one embodiment, thetransactional data 38 may include user data, credit issuer data, merchant data, authorization data, payment data, transaction-specific data, identification data, network data, processing data, settlement data, etc. Accordingly, thetransactional data 38 generated by the user U, the merchant, the credit issuer, etc. is transmitted over and distributed over the distributedsystem 10 of the present invention, specifically through theintermediate server systems 18. - As discussed above in connection with the prior art, there exists many payment processors, which serve to facilitate credit-based or debit-based transactions between users U and merchants using a credit or debit product of an issuer. In particular, the payment processors have
payment processor systems 40 that serve to dictate the form and format of thetransactional data 38 provided to thepayment processor system 40 for use in consummating these credit-based or debit-based transactions. However, as seen inFIG. 3 , by using theintermediate server system 18, thepayment processor system 40 is dis-intermediated from themerchant system 12. - In particular, and in one preferred and non-limiting embodiment, the
transactional data 38 is provided by the user U to themerchant system 12 via thecomputer 28. Thistransactional data 38 includes a plurality ofdata points 42, which are provided to theintermediate server system 18 by themerchant system 12. However, in operation, theintermediate server system 18 may transmit only a portion of thetransactional data 38, i.e., onlycertain data points 42, to thepayment processor system 40 for use in completing the transaction, such as accepting requests and providing authorization. Still further, this portion oftransactional data 38 provided to thepayment processor system 40 may be placed in or formatted in a predetermined manner prior to transmission to thepayment processor system 40. Therefore, thepayment processor system 40 still receives the appropriatetransactional data 38 in the appropriate form and format for completing the credit-based or debit-based transaction. Further, thepayment processor system 40 is capable of transmittingtransactional data 38 through theintermediate server system 18, themerchant system 12, etc. In this manner, the credit-based or debit-based transaction is appropriately completed. - In a further embodiment, and as illustrated in
FIG. 3 , thesystem 10 may also include acredit issuer system 44. Thiscredit issuer system 44 is capable of receiving, processing and/or transmitting data, and theintermediate server system 18 is in communication with thecredit issuer system 44 within the networked environment N. In particular, theintermediate server system 18 andcredit issuer system 44 are capable of communicating appropriatetransactional data 38 therebetween. - In this embodiment, this
transactional data 38 may includeinput data 26, user U data, credit issuer data, merchant data, authorization data, payment data, transaction-specific data, identification data, network data, processing data, settlement data, etc. In the preferred embodiment ofFIG. 3 , all of the data points 42, i.e., all of thetransaction data 38, is communicated by theintermediate server system 18 to thecredit issuer system 44. Therefore, while only a portion of thistransactional data 38 is provided to thepayment processor system 40, all data is provided to thecredit issuer system 44. In a still further embodiment, only a portion of the data points 42 is transmitted to the credit issuer system, and the full set of transaction data is built by theintermediate server system 12 using the data returned from thecredit issuer system 44 and thepayment processor system 40. - After processing the data (such as authorizing the credit-based transaction), the
payment processor system 40 may provide appropriatetransactional data 38, e.g., fulfillment, payment or settlement data, directly to thecredit issuer system 44 or to thecredit issuer system 44 via theintermediate server system 18. Once either theintermediate server system 18 and/or thecredit issuer system 44 receives thetransactional data 38 from thepayment processor system 40, this data is recombined or otherwise matched with the appropriate and full set oftransactional data 38. Either one or both of theintermediate server system 18 and thecredit issuer system 44 may include the appropriate algorithms to match the transactions and ensure full integration of the data points 42 received from allsystems system 10. - In one specific example of this “disintermediation” of the
payment processor system 40, an example of some data that thepayment processor system 40 does not desire to receive or use would be small business data, gift card information, enumeration data, loyalty information, new consumer data, etc. Therefore, while suchtransactional data 38 may be useful to the credit issuer or merchant, only a small portion related to the specific transaction is of interest to thepayment processor system 40. Therefore, the entire set of transactional data is analyzed by theintermediate server system 18, and only a portion extracted for communication to thepayment processor system 40. - In one example, the full data set (100%) of
transactional data 38 is sent to theintermediate server system 18. Theintermediate server system 18 then analyzes thistransactional data 38 and extracts a partial set (60%), which includes data required by thepayment processor system 40. This partial set of data (60%) is appropriately formatted and forwarded to thepayment processor system 40, while the full data set (100%) is sent to thecredit issuer system 44. Thepayment processor system 40 receives the formatted data (60%), which would appear to be a processing request from the merchant via the credit issuer. Thepayment processor system 40 would then authorize the transaction and send the authorization to thecredit issuer system 44 based upon the partial data set (60%). Thecredit issuer system 44 could then match the partial data set (60%) with the full data set (100%) on a transaction-by-transaction basis, and the full transaction would then be authorized, appended and communicated back to the merchant. In this manner, the commercial transaction, and specifically a credit-based or debit-based commercial transaction, is appropriately facilitated and all parties are able to use a variety of desireddata points 42, while receiving only specifieddata points 42 needed to process the transaction. - In another example of the presently-invented
system 10, and according to the prior art, it has been recognized that all present electronic payment options supported by the payment processors application programming interfaces (API) were composed of two parts: a permission transaction loop and a financial settlement transaction loop. The permission loop is defined by a message that contains an account or customer identifier, a merchant identifier, a transaction amount, a transaction date, a payment type and a permission or approval code. These fields are core to all payment types and always occur within the permission transaction loop. The financial settlement transaction loop is defined by a message that contains an account identifier, merchant identifier, a transaction amount, a transaction date, a payment type, a permission or approval code and a description field. Since these two parts are present for all payment options, they are referred to as a common feature data set, which represents the portion of the API that is constant across all payment options within a payment processor's API. - There exists a second part of the payment option API, which may be referred to as a variable feature data set. This portion of the API represents the features of the payment option that are unique to a specific payment option. The variable feature data set represents the specifics of the payment method within the API. For example, a CVV code in a Visa authorization is Visa's specific implementation of a device authentication code that is unique to their payment option. Similarly, a PIN code in a debit card transaction is a user authentication code specific to the debit card authorization transaction. Separation of the payment processor API into a common feature data set and a variable feature data set creates the opportunity to abstract the variable feature data set from the payment processor API, and minimize or even eliminate the need for the payment processor to make significant changes to support a new payment option by limiting the payment processor's role to handling the common feature data set only. Accordingly, the present invention allows for a significantly faster delivery and implementation of new payment options, at a far lower cost to the credit issuer.
- In another embodiment, the
credit issuer system 44 and/or theintermediate server system 18 may be provided with additional functionality in order to facilitate the transaction. For example, such functions may include authenticating the user U, verifying the user U, approving or denying a user U application, verifying a transaction, processing user data, processing merchant data, processing credit (or debit) issuer data, processingtransactional data 38, processing credit or debit product data, etc. Therefore, a full range of functionality is provided to facilitate and transact a variety of credit-based or debit-based transactions. - As discussed above, the
merchant system 12 may take many forms. For example, themerchant system 12 may be an online location, a merchant web page, a merchant call center, a merchant settlement system, etc. In any case, themerchant system 12 is in communication with theintermediate server system 18, and may also be in communication with thepayment processor system 40 andcredit issuer system 44. In addition, the above-discussedcontent 24 may be presented or provided to the user U prior to a transaction, during the transaction or after the transaction. Still further, thecontent 24 may be presented to the user U in a variety of forms. For example, thiscontent 24 may be presented in the form of a web page, an electronic document, a window, a pop-up window, etc. In any of these forms, varioustransactional data 38, data points 42 (or fields),content 24 or other information or data is provided to the user U. - As discussed, the
network interface 14 of themerchant system 12 may be presented to the user U on thepresentation device 30 of the user U. In addition, this network interface 14 (or the intermediate server system interface 34) may be interactive, such that a variety of data fields and points may be displayed to the user U, and theinput data 26 accepted. - In one embodiment, the
content 24 presented to the user U may be interest rate data, credit limit data, purchase data, charge data, cost data, expense data, annual fee data, interest accrual data, statement data, account data, fund advancement data, transfer data, delinquency data, payment term data, account review data, credit product data, credit issuer data, contract data, liability data, certification data, privacy data, personal information use data, collected information data, consent data, foreign data, access data, online service data, phone service data, liability data, representation data, warranty data, termination data, indemnity data, term variation data, communication data, assignment data, rights data, governing law data, or any combination thereof. - In addition, in this embodiment, the
input data 26 may include user identification, a PIN, a name, a consumer key, a consumer identification, an account number, an address, a city, a state, a zip code, a country, a telephone number, an e-mail address, a social security number, a date of birth, the merchant's name, an identification, an order number, an authorization number, an authorization time, an authorization amount, a ship-to address, a bill-to address, a transaction amount, a consumer purchase demographic, a transaction date, a transaction type, a product identification, a service identification, shipping costs, delivery type, consumer type, a company identity, a merchant identity, previous transaction data, geographical data, credit account data, bankcard balance data, delinquency data, credit segment data, previous transaction data, time between transactions data, previous transaction amount, previous transaction approval status, previous transaction time stamp data, a response code, consumer payment method, consumer payment history, consumer account history, consumer credit account balance, income data, family data, employment data, relationship data, expense data, application data, acknowledgement data, selection data, choice data, or any combination thereof. - In many instances, the central system 36 (typically in the form of the credit issuer system 44) may already have on hand specific data that can be used to pre-populate various screens or input fields of the user U at the
network interface 14 and/or intermediateserver system interface 34. Accordingly, such data may be stored at the credit issuer system, or otherwise stored on thedata storage system 20 of theintermediate server system 18. Therefore, the user U would not need to continually retype his or her information into theappropriate interface - In another preferred and non-limiting embodiment, the
content 24 is in the form of an offer of one or more credit products to the user U. In this embodiment, theinput data 26 may be directed to this offer. Therefore, the user U is presented with: terms of the credit product; conditions of the credit product; an account agreement; explanation data; promotional data, etc. For example, the user U may choose to use a specific credit product that he or she does not currently own, such that an application for this credit product is provided to the user U on thenetwork interface 14 and/or intermediateserver system interface 34. - Accordingly, and as discussed above, all the data relating to the application, the terms, the conditions, etc. are provided to the user U either by the
merchant system 12, theintermediate server system 18, or some reference or hyperlink between thesystems credit issuer system 44 to be in control of this information and data, which ensures data integrity. Therefore, this process andsystem 10 increases merchant/creditor trust, reduces redundancy, etc. In particular, this goal is achieved through the intermediate and established network of servers orserver system 18 capable of serving theappropriate content 24, serving web forms, serving dynamic terms and conditions, serving checkout information, etc. - In one embodiment, the
input data 26 provided by the user U may include acknowledgement data from the user U, andfurther content 24 provided to the user U is a credit product application. Next, the user U providesinput data 26 in the form of application input data, which is transmitted to theintermediate server system 18 and/or thecredit issuer system 44. Once received, theintermediate server system 18 and/orcredit issuer system 44 is programmed or configured to approve or deny an application by the user U for the credit product based at least in part upon theinput data 26 provided by the user U. If approved, an account may be opened and established for the user U for the credit product of the credit issuer, and, if denied, denial data may be transmitted to the user U. Due to the dynamic nature of this process, the user U may use the approved credit product in connection with the transaction that may already be underway. In making the decision of whether to approve or deny the application for the credit product, consumer risk data may be determined based upon theinput data 26 of the user U, the acknowledgment data, the application input data, etc. - One specific example of the
system 10 of the present invention is illustrated inFIG. 4 . Specifically, a variety of merchant integration options are provided in thesystem 10. For example, thecontent 24 may be downloaded to and served by themerchant system 12. Also, thecontent 24 may be referenced by themerchant system 12, but directly served to the user U by theintermediate server system 18. With respect to authorization of transactions, themerchant system 12 may send authorization messages directly to theintermediate server system 18. Still further, themerchant system 12 may send authorization messages to theintermediate server system 18 for specific transactions, and redirect the user U to theintermediate server system 18 for other types of transactions. - For example, in one embodiment, the
merchant system 12 includes a merchantonline location 46, amerchant call center 48 and amerchant fulfillment system 50. In one variation, both the merchantonline location 46 and themerchant call center 48 send or transmit authorization requests to theintermediate server system 18, which is in communication with thepayment processor system 40. Thepayment processor system 40 is in communication with thecredit issuer system 44. After authorization is provided, these authorized orders are communicated from the merchantonline location 46 and themerchant call center 48 to themerchant fulfillment system 50, which provides settlement requests either to theintermediate server system 18 or directly to thepayment processor system 40. Finally, thepayment processor system 40 funds the transaction with a communication to themerchant fulfillment system 50. - In another level of integration,
specific content 24 is downloaded by themerchant system 12 from thedata storage system 20 of theintermediate server system 18. Thiscontent 24 is served directly to the user U (i.e., at thenetwork interface 14 on the user's browser). Alternatively, thecontent 24 may be provided directly from thedata storage system 20 of theintermediate server system 18 to the user U. One benefit of such interaction is that the merchant does not need to handle any type of consumer regulatory updates. For redirection purposes, themerchant system 12 will be provided with the appropriate URLs for theweb content 24, such as the terms and conditions, a What Is? section, FAQs, banners, logos, etc. Themerchant system 12 would reference these URLs or establish a process to refresh thecontent 24 during some periodic maintenance window. - In a further level of integration, the
merchant system 12 directly referencesweb content 24 on theintermediate server system 18, and further, sends authorization requests as messages to theintermediate server system 18. However, settlement and funding still occurs directly between themerchant fulfillment system 50 and thepayment processor system 40. Accordingly, merchants will create web services requests to theintermediate server system 18 for authorizations in both the merchantonline location 46 and themerchant call center 48, as well as for re-authorizations. Theintermediate server system 18 would act as the “submitter” on behalf of the merchant to thepayment processor system 40. - In yet another level of integration, and as also illustrated in
FIG. 4 , themerchant system 12references web content 24 on theintermediate server system 18, and is also sending authorization requests from themerchant call center 48 as messages to theintermediate server system 18. Still further, users U are redirected from themerchant system 12 directly to pages hosted on theintermediate server system 18, such as in the form of an intermediateserver system interface 34. Again, all settlement and funding occurs directly between themerchant fulfillment system 50 and thepayment processor system 40. Such integration provides a fully optimized transactional experience to the user U. In addition, themerchant system 12 does not need to handle any additional and ancillarytransactional data 38. The merchants would not need to build any specific interfaces or pages, as all of this information is provided directly from theintermediate server system 18. In addition, this reduces the compliance checking process and time at themerchant system 12, as theintermediate server system 18 acts as the “submitter” for the merchant to thepayment processor system 40. Of course, themerchant call center 48 may also interact directly with thepayment processor system 40, as opposed to acting through theintermediate server system 18. - In another example of a commercial transaction occurring through the
system 10, thesystem 10 is also useful in connection with a first-time user U that is shopping anonymously. First, the merchant communicates user U and order information to theintermediate server system 18 using a pc-request web service call. Theintermediate server system 18 validates the user U and order data and returns a URL to redirect the user U to a hosted page of theintermediate server system 18. The user U is redirected to a hosted page (or the intermediate server system interface 34) on theintermediate server system 18, where the user U enters authentication information and data, completes any required fields that have not been pre-populated or otherwise enters theappropriate input data 26. The user U then selects to process the transaction. Theintermediate server system 18 captures the authentication information and any other required information, processes the authorization request and communicates with thepayment processor system 40. The user U will then be redirected to one of multiple URLs provided by the merchant in the pc-request depending upon its success or failure of the authorization. After the user U is redirected to a “success” URL, themerchant system 12 will use the pc-status call to capture the authorization response details for settlement. Accordingly, themerchant system 12 requests and records authorization responses for use in settlement processing, and theintermediate server system 18 returns status responses, which include account numbers and authorization codes for use in this settlement processing procedure. - Another example of the presently-invented
system 10 is usable for non-web-enabled systems (e.g.,merchant call center 48 and merchant fulfillment system 50), as well as for returning authenticated web users U. Themerchant system 12 uses the pc-request with a “process” action code to post the user U and order data to theintermediate server system 18, as well as process any authorization request. Theintermediate server system 18 will automatically provide the authorization responses back to themerchant system 12. In this example, the process request transmitted from themerchant system 12 would include the purchase amount, the account number, information about the customer, date of birth, the last four digits of the social security number, merchant customer type, bill-to name/address, ship-to name/address, e-mail address, telephone number, IP address, etc. In addition, information about the transaction, such as shipping costs, product type and channels, would also be included. The response from theintermediate server system 18 would be in the form of a standard credit card response, and utilize standard response codes and authorization control codes. In addition, the actual 16-digit account number would also be transmitted. - The authorization requests and messages may take a variety of forms and formats. For example, a merchant order number may be set and used during the submission process. This merchant order number would carry through to the
intermediate server system 18 and thepayment processor system 40. In addition, the merchant order number may be useful in communication with thecredit issuer system 44 regarding the transaction. Still further, this merchant order number can be used for authorization add-ons, where a user U contacts the merchant after an order has been placed to add additional items to the order. - A set of business rules may be used to optimize the performance of the
intermediate server system 18, as well as theoverall system 10. In particular, three different web service calls may be used in connection with authorizations and status. The pc-request call with the action code of “set” allows the merchant to post the user U and order information. A pc-commit call allows the merchant to request that the information in the pc-request call now be processed for an authorization. The pc-request call with an action code of “process” allows the merchant to submit the user U and order information and process the request for the authorization in the same transaction. A pc-status call may be used by the merchant for requesting the current status of an authorization request that has already been processed. For example, Table 1 illustrates various standard fields used in connection with the pc-request function. -
TABLE 1 Required based on Field Name action-code Format PC Usage Standard fields which could be passed on all pc-request transactions regardless of Method of Payment pc-version ALL A/N(8) System Version. Defined value method-of-payment ALL A/N(2) Method of Payment = BL, PA or BB to be use by Payment Processor. product-type ALL A/N(2) “BL” for BML, “PA” for Preferred account or “BB” for Business Products production-indicator ALL A/N(5) TRUE/FALSE Used to verify transaction environment destination. Must use corresponding URLs merchant-group-id ALL N(10) Simple key to identify merchant could be first 10 digits of M/D with leading 0's. Defined value action-code ALL A/N(20) SET/PROCESS sub-action ALL A/N(20) Constant-AUTH pc-success-url SET A/N(200) Used to redirect customer if authorization was successful. Merchant generated. pc-failure-url SET A/N(200) Used to redirect customer if authorization was not successful. Will usually be the payment option selection page. Merchant generated. pc-interim-url Optional (See PC A/N(200) Used to specify interim pages for Usage) certain processing approaches such as a confirmation page. Merchant generated. pc-error-url SET A/N(200) Used to redirect customer before the input screen is presented if an error condition is detected. Merchant generated. pc-update-info-url Optional (See PC A/N(200) Used to redirect the customer if Usage) they choose to update their address on the hosted page. Merchant generated. pc-choose-other-mop- SET A/N(200) Used to specify the redirect if the url customer chooses to go back to the payment options screen while sitting on the page. Merchant generated. pc-favicon-url Optional (See PC A/N(200) Usage) pc-css-stylesheet-url Optional (See PC A/N(200) Usage) soft-error-threshold Optional (See PC N(1) Allows merchant to override the Usage) default of count of 3 for soft errors to allow customers to resubmit failed PC app. payment-division ALL N(10) This is the Payment Processor Division. pc-merchant-id ALL N(15) Value used for Pricing, Terms, Merchant Settings. Defined value. merchant-order- Optional (See PC A/N(22) A unique customer order number number Usage) that is typically used for reconciliation purposes. (NOTE: Will be generated by PC if left blank), Merchant generated. customer- Optional (See PC A/N(5) TRUE/FALSE Flag that authenticated-by- Usage) customer has logged into the merchant merchant site successfully. account-number Optional (See PC N(16) Merchant can pass the Account Usage) number if they have it. The merchant should pass a blank if they do not have it and the default account will be generated by PC. authorization-amount ALL N(10v2) Total amount of authorization including shipping and handling, taxes and special fees. Grand total for the order. channel-indicator ALL A/N(1) W—Web, C—Call Center, M—Mail, R—Retail, O—Other. Web is default. Use Other for reauth only. bank-office-indicator ALL A/N(5) TRUE/FALSE should be TRUE on authorizations that are sent from fulfillment system. term-and-conditions- ALL N(5) Merchant will pass one of two code values based on the sales channel. Defined value. customer-registration- ALL Date Customer original registration date YYYY-MM- date. If not registered or new to DD the site, use the current date. delivery-method ALL A/N(3) Indicates how the majority of the product in the order was delivered. Valid values are: PHY—Physical, DIG—Digital, SVC—Service, CNC—Cash and Carry shipping-amount Optional (See PC N(6v2) Required if PHY delivery Usage) method. st-equals-bt-name- Optional (See PC A/N(5) TRUE/FALSE indicator Usage) ship-to-name Optional (See PC A/N(30) Required if PHY delivery method Usage) and ST = BT-Name-Indicator not equal TRUE st-equals-bt-name- Optional (See PC A/N(5) TRUE/FALSE indicator Usage) ship-to-name Optional (See PC A/N(30) Required if PHY delivery method Usage) and ST = BT-Address-Indicator not equal TRUE st-equals-bt-address- Optional (See PC A/N(5) TRUE/FALSE indicator Usage) ship-to-address-1 Optional (See PC A/N(30) Required if PHY delivery method Usage) and ST = BT-Address-Indicator not equal TRUE ship-to-address-2 Optional (See PC A/N(30) Required if PHY delivery method Usage) and ST = BT-Address-Indicator not equal TRUE ship-to-city Optional (See PC A/N(30) Required if PHY delivery method Usage) and ST = BT-Address-Indicator not equal TRUE ship-to-state Optional (See PC A/N(30) Required if PHY delivery method Usage) and ST = BT-Address-Indicator not equal TRUE For US states and territories use standard two character abbreviation. ship-to-postal-code Optional (See PC A/N(30) Required if PHY delivery method Usage) and ST = BT-Address-Indicator not equal TRUE ship-to-country Optional (See PC A/N(2) Required if PHY delivery method Usage) and ST = BT-Address-Indicator not equal TRUE ship-to-phone PROCESS A/N(14) AAAEEENNNNXXXX where A = Area code, E = Exchange, N = Number. An extension number XXXX can be passed or leave it blank. customer-ip-address PROCESS A/N(15) Customer's IP Address. (NOTE: this should be blank if authorization is originating from the Call Center or Retail channels. alternate-ip-address Optional (See PC A/N(15) This may be required in certain Usage) cases. customer-type ALL A/N(1) Indicator of whether the customer is a new or returning customer for the merchant. Values: N—New to the merchant E—Existing customer at the merchant item-category ALL N(4) General categorization of the most expensive extended item cost in the shopping basket pre-approval- Optional (See PC N(16) Use used when the order has been invitation-number Usage) pre-approved, either internally or externally mag-stripe-data Optional (See PC A/N(39) Data from magnetic card stripe Usage) virtual-authentication- Optional (See PC N(4) Security code from card - such as key Usage) CCV expiration-date Optional (See PC MMYYYY Expiration date from card Usage) merchant- Optional (See PC A/N(4) For future use promotional-code Usage) merchant-reference-id Optional (See PC A/N(22) Transaction reference ID set by Usage) the merchant and echoed back on the response. split-tender-indicator Optional (See PC A/N(5) TRUE/FALSE Used to indicate Usage) that there is a split payment on this authorization. Preferred Account Fields bill-to-name ALL A/N(60) bill-to-address-1 ALL A/N(30) bill-to-address-2 Optional (See PC A/N(30) Usage) bill-to-city ALL A/N(30) bill-to-state ALL A/N(30) For US states and territories use standard two character abbreviation. bill-to-postal-code ALL A/N(30) Bill to zip code. Left justify, space fill. bill-to-country ALL A/N(2) bill-to-email-address ALL A/N(50 This field is required by BML for all web transactions and should be requested in all call center transactions if possible. bill-to-phone ALL A/N(10) Use format AAAEEENNNN where A = Area code, E = Exchange, N = Number. Do not capture or pass an extension number bill-to-ssn PROCESS N(9) Last four for MOP Full for SSN for PA MOP Pre-fill with leading zeros if only sending last four bill-to-date-of-birth PROCESS Date YYYY-MM- DD Preferred Account Only Fields - The values below should be sent if already known by the merchant work-phone PROCESS A/N(14) AAAEEENNNNXXXX where A = Area code, E = Exchange, N = Number. An extension number XXXX can be passed or leave it blank. employer-name PROCESS A/N(20) annual-income PROCESS N(8)v2 currency-name PROCESS A/N(3) residence-status PROCESS A(1) years-at-residence PROCESS N(2) years-at-employer PROCESS N(2) checking-account- PROCESS A/N(5) indicator savings-account- PROCESS A/N(5) indicator secret-question-code Optional (See PC A/N(2) Usage) secret-answer Optional (See PC A/N(25) Usage) Business-Level Only Fields - The values below should be sent if already known by the merchant business-legal-name PROCESS A/N(20) dba-name PROCESS A/N(35) business-address-1 PROCESS A/N(30) business-address-2 Optional (See PC A/N(30) Usage column) business-city PROCESS A/N(30) business-state PROCESS A/N(30) For US states and territories use standard two character abbreviation business-postal-code PROCESS A/N(30) business-main- PROCESS N(10) telephone-number user-id PROCESS A/N(50) pin PROCESS A/N(24) administrator-name PROCESS A/N(30) administrator-phone PROCESS N(14) AAAEEENNNNXXXX where A = Area code, E = Exchange, N = Number. An extension number XXXX can be passed or leave it blank. administrator-fax PROCESS N(14) AAAEEENNNNXXXX where A = Area code, E = Exchange, N = Number. An extension number XXXX can be passed or leave it blank. administrator-email PROCESS A/N(50) administrator-title PROCESS A/N(10) supervisor-name PROCESS A/N(30) supervisor-email- PROCESS A/N(50) address business-d-and-b- PROCESS A/N(9) number business-tax-id PROCESS N(9) business-naics-code PROCESS A/N(6) business-type PROCESS A/N(3) Company Type Field Includes: Corporation Partnership Sole Proprietor S Corp LLC LLP Non-Profit Government School Other business-years-in- PROCESS A/N(3) 0 business 1 2 3 4 5 6 7 8 9 10+ business-number-of- PROCESS A/N(3) 0 employees 1-5 6-20 21-100 101-200 201-800 800+ pg-last-name Optional (See PC A/N(35) All of the Personal Guarantor Usage) information is required for Sole Proprietorships and Partnerships and may be requested based on other factors pg-first-name Optional (See PC A/N(35) Usage) pg-ssn Optional (See PC A/N(9) Usage) pg-dob Optional (See PC Date Usage) YYYY-MM- DD pg-income-currency- Optional (See PC A/N(3) type Usage) pg-annual-income Optional (See PC N(8)v2 Usage) pg-residence-status Optional (See PC A(1) Usage) pg-checking-indicator Optional (See PC A(1) Usage) pg-savings-indicator Optional (See PC A(1) Usage) pg-years-at-employer Optional (See PC N(2) Usage) pg-years-at-residence Optional (See PC N(2) Usage) pg-home-address-1 Optional (See PC A/N(30) Usage) pg-home-address-2 Optional (See PC A/N(30) Usage) pg-home-city Optional (See PC A/N(30) Usage) pg-home-state Optional (See PC A/N(30) For US states and territories use Usage) standard two character abbreviation pg-home-postal-code Optional (See PC A/N(30) Usage) pg-email-address Optional (See PC A/N(50) Usage) pg-home-phone-number Optional (See PC N(14) Usage) pg-title Optional (See PC A/N(10) Required for Sole Proprietorships Usage) and may be requested based on other factors Principal Officer CEO CFO President Partner N/A - As discussed, the pc-commit call is used when the merchant wants to process a request that was previously submitted via the pc-request call with the “set” action code. This call may be used if the merchant has a confirmation screen after the hosted page of the
intermediate server system 18, but does not want the authorization to get processed until the customer or user U confirms the order on that page. The various field names for the pc-commit call are illustrated in Table 2. -
TABLE 2 PayCapture Field Name Required Format PC Usage pc-version ALL A/N(8) System Version. Defined value method-of-payment ALL A/N(2) Method of Payment = BL, PA or BB to be use by Payment Processor production-indicator All A/N(5) TRUE/FALSE Used to verify transaction environment destination. Must use corresponding URLs merchant-group-id ALL A/N(10) Simple key to identify merchant could be first 10 digits of MID action-code ALL A/N(5) Constant = PROCESS sub-action ALL Auth, Pre-approve, Score session-key ALL Long Key to existing customer data for operating in confirm mode (What is passed) consumer-ssn N N(9) Last four for MOP Full for SSN for PA MOP Pre-fill with leading zeros if only sending last four consumer-dob N Date YYYY-MM- DD term-and-conditions- N N(5) Defined Value code customer-ip-address ALL A/N(15) Customer's IP Address. (NOTE: this should be blank if authorization is originating from the Call Center or Retail channels. - Finally, the pc-status request call is used when the merchant needs to get the status of a processed authorization. Normally, such a call is used by merchants to get the authorization response when the authorization is processed at the
intermediate server system 18. Table 3 illustrates the various fields associated with the pc-status call. -
TABLE 3 Field Name Required Format PC Usage pc-version ALL A/N(8) System Version. Defined value method-of-payment ALL A/N(2) Method of Payment = BL, PA or BB to be use by Payment Processor production-indicator All A/N(5) TRUE/FALSE Used to verify transaction environment destination. Must use corresponding URLs. merchant-group-id ALL A/N(10) Simple key to identify merchant could be first 10 digits of MID action-code ALL A/N(20) Constant = STATUS sub-action ALL Auth, Pre-approve, Score session-key ALL A/N(16) Key to existing customer data for operating in confirm mode - After an authorization request is taken, the
intermediate server system 18 provides an authorization response to themerchant system 12. In one embodiment, a specified account number (e.g., of the credit issuer) should be appended to the order, as well as in the profile of the user U. The account number may be stored with the order in case re-authorization, stand-loan credits or customer service inquiries are required. In addition, the account number would be used in connection with the customer profile for subsequent web purchases. If the user U has a secure login to the merchantonline location 46, the merchant may take advantage of the “authenticated” authorization format to allow a one-click purchase process. Table 4 illustrates the various fields that may be used in connection with a variety of payment, methods and for use in authorizing the transaction. -
TABLE 4 Field Name Format Usage Standard fields which could be returned on all pc-status- request transactions regardless of Method of Payment session-key A/N(16) Handle to customer data persisted on PC handler system-status A/N(1) Used to indicate if system is processing normally. response-text A/N(200) authorization-id Long Internal use only authorization-code A/N(6) This required for settlement authorization-response- N(3) Numeric value indicating code approval or decline. authorization-sub-code N(3) account-number N(16) merchant-order-number A/N(22) A unique customer order number that is typically used for reconciliation purposes. (NOTE: Will be generated by PC if left blank), Merchant generated. merchant-reference-id A/N(22) Transaction reference ID set by the merchant and echoed back on the response redirect-or-child-url A/N(200) Standard fields which could be returned for Preferred Accounts and Business-Level Method of Payments requested-amount N(10).99 credit-line N(10).99 approved-amount N(10).99 approved-terms A/N(8) processing-indicators A/N(8) marketing-promotion A/N(8) address-indicator A/N(4) expiration-date N(4) - Finally, Table 5 illustrates various suggested response codes and actions that the merchant should take for each code.
-
TABLE 5 Response Response Code Description Action Taken Error Message Operations Action Default (if N/A Return user to Credit Issuer was Contact customer and not listed Page, allow 3 unable to authorize request another method below) attempts to use your transaction. of payment. May account before Please verify you escalate to merchant removing credit have entered your support for possible product as an information correctly resolution option 100 Approved Display “Thank You” page 547 Address Return user to Credit Issuer was This would be an Verification Page, allow 3 unable to authorize upfront decline only. Failed attempts to use your transaction. credit product Please verify you before removing have entered your credit issuer as an information correctly option 548 Not on Return user to Credit Issuer was This would be an Credit Page, allow 3 unable to authorize upfront decline only. Bureau attempts to use your transaction. credit product Please verify you before removing have entered your credit isssuer as information correctly an option - As discussed above in detail, delivery of
content 24 between theintermediate server system 18 and themerchant system 12 may be in many different forms and formats. For example, thecontent 24 may be referenced and provided to the user U in the form of a pop-up window. By using this referencing technique, the merchants are insulated from making the required changes to various documents due to regulatory product changes. Two key files may be referenced by themerchant system 12 at theintermediate server system 18, including aninformational window 52, which links from variouscredit issuer system 44 orintermediate server system 18 links, text messages and banners. This file would contain a description of the product, required disclosures and frequently ask questions. In this embodiment, the user U would click onvarious banners 52 ortext links 54, as illustrated inFIG. 5 . Again, the action of clicking on thesebanners 52 ortext links 54 may eitherpresent content 24 to the user U from themerchant system 12 and/or theintermediate server system 18. Another key file would be the terms and conditions 56 offered for the credit product.Such content 24 would generally be essentially served by theintermediate server system 18, which allows thecontent 24 to be managed on behalf of the merchant. - Depending upon what
banner 52 ortext link 54 is activated by the user U, different versions will be provided and served to the user U. For example,certain default content 24 may be provided and displayed to the user U when promotional financing is not being offered. However, and depending upon thebanner 52 ortext link 54, certainother content 24 may be displayed to the user U when promotional financing is available. - In one implementation, the terms and conditions 56 are presented to the user U on a
payment page 58. The terms and conditions 56 may be presented in a variety of formats. For example, anHTML version 60 may be presented to the user U viatext links 54, and a PDF version may be presented to the user U upon activating a “printer friendly version”link 62. The links provided in this application or payment page may utilize well-known e-sign and other acknowledgement techniques. Activating aphone order link 64 directs the user U to the disclosure requirements for various phone orders, such as in a promotional financing informational window. Once the user U agrees to the terms and conditions 56, he or she would activated anagreement button 66, which would complete the order using the associated credit product. - In this manner, the present invention provides a distributed
system 10 for commercial transactions, and is particularly useful in connection with online and remote commerce between consumers and merchants. The distributedsystem 10 of the present invention providescontent 24 to the user U through themerchant system 12, and thiscontent 24 is provided to the merchant through theintermediate server system 18. Alternatively,certain content 24 is provided directly to the user U by theintermediate server system 18, such as through the intermediateserver system interface 34. In addition, the present invention provides asystem 10 that facilitates credit-based and debit-based transactions between a consumer, a merchant and a credit (or debit) issuer. Still further, thecontent 24 provided to the user U is dynamic and accurate. Still further, thesystem 10 of the present invention provides an intermediary between themerchant system 12 and thepayment processing system 40 and/or thecredit issuer system 44. Accordingly, the present invention is directed to a distributedsystem 10 for commerce that provides secure communications and facilitates transactions in an electronic, online, telephone or other remote environment. - Although the invention has been described in detail for the purpose of illustration based on what is currently considered to be the most practical and preferred embodiments, it is to be understood that such detail is solely for that purpose and that the invention is not limited to the disclosed embodiments, but, on the contrary, is intended to cover modifications and equivalent arrangements that are within the spirit and scope of the appended claims. For example, it is to be understood that the present invention contemplates that, to the extent possible, one or more features of any embodiment can be combined with one or more features of any other embodiment.
Claims (20)
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/250,978 US20090037290A1 (en) | 2007-05-02 | 2008-10-14 | Distributed System for Commerce |
US14/817,180 US10580070B2 (en) | 2007-05-02 | 2015-08-03 | Distributed system for commerce |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/799,667 US20080272188A1 (en) | 2007-05-02 | 2007-05-02 | Distributed system for commerce |
US12/250,978 US20090037290A1 (en) | 2007-05-02 | 2008-10-14 | Distributed System for Commerce |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/799,667 Continuation US20080272188A1 (en) | 2007-05-02 | 2007-05-02 | Distributed system for commerce |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/817,180 Continuation US10580070B2 (en) | 2007-05-02 | 2015-08-03 | Distributed system for commerce |
Publications (1)
Publication Number | Publication Date |
---|---|
US20090037290A1 true US20090037290A1 (en) | 2009-02-05 |
Family
ID=39938858
Family Applications (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/799,667 Abandoned US20080272188A1 (en) | 2007-05-02 | 2007-05-02 | Distributed system for commerce |
US12/250,978 Abandoned US20090037290A1 (en) | 2007-05-02 | 2008-10-14 | Distributed System for Commerce |
US14/817,180 Active 2027-08-19 US10580070B2 (en) | 2007-05-02 | 2015-08-03 | Distributed system for commerce |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/799,667 Abandoned US20080272188A1 (en) | 2007-05-02 | 2007-05-02 | Distributed system for commerce |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/817,180 Active 2027-08-19 US10580070B2 (en) | 2007-05-02 | 2015-08-03 | Distributed system for commerce |
Country Status (3)
Country | Link |
---|---|
US (3) | US20080272188A1 (en) |
AU (1) | AU2008201859B2 (en) |
CA (1) | CA2631178C (en) |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060229974A1 (en) * | 2005-04-11 | 2006-10-12 | I4 Licensing Llc | Method of extending credit to at least one consumer and method of processing a transaction between a consumer and a merchant |
US20100153435A1 (en) * | 2008-12-15 | 2010-06-17 | International Business Machines Corporation | Opening Document Stored at Multiple Database Replicas |
US20110178901A1 (en) * | 2010-01-15 | 2011-07-21 | Imrey G Christopher | System and method for resolving transactions employing goal seeking attributes |
US8543508B2 (en) | 2010-07-09 | 2013-09-24 | Visa International Service Association | Gateway abstraction layer |
US8639846B2 (en) | 2005-06-29 | 2014-01-28 | Visa U.S.A. Inc. | Adaptive gateway for switching transactions and data on unreliable networks using context-based rules |
CN105426260A (en) * | 2015-10-30 | 2016-03-23 | 北京航天自动控制研究所 | Distributed system supported transparent interprocess communication system and method |
US20170185989A1 (en) * | 2015-12-28 | 2017-06-29 | Paypal, Inc. | Split group payments through a sharable uniform resource locator address for a group |
Families Citing this family (48)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8554669B2 (en) | 2007-01-09 | 2013-10-08 | Bill Me Later, Inc. | Method and system for offering a credit product by a credit issuer to a consumer at a point-of sale |
JP5144157B2 (en) * | 2007-07-25 | 2013-02-13 | 京セラ株式会社 | Receiver |
AU2009243168A1 (en) * | 2008-04-29 | 2009-11-05 | Visa U.S.A. Inc. | Device including user exclusive data tag |
US8719164B2 (en) | 2008-06-19 | 2014-05-06 | Bill Me Later, Inc. | Method and system for engaging in a transaction between a business entity and a merchant |
US8447669B2 (en) | 2008-08-26 | 2013-05-21 | Visa U.S.A. Inc. | System and method for implementing financial assistance programs |
US20100161404A1 (en) * | 2008-11-25 | 2010-06-24 | Mary Theresa Taylor | Promotional item identification in processing of an acquired transaction on an issued account |
US9619801B2 (en) * | 2010-08-02 | 2017-04-11 | Stanton Management Group, Inc. | User positive approval and authentication services (UPAAS) |
US8571937B2 (en) | 2010-10-20 | 2013-10-29 | Playspan Inc. | Dynamic payment optimization apparatuses, methods and systems |
US10204327B2 (en) | 2011-02-05 | 2019-02-12 | Visa International Service Association | Merchant-consumer bridging platform apparatuses, methods and systems |
US9953334B2 (en) | 2011-02-10 | 2018-04-24 | Visa International Service Association | Electronic coupon issuance and redemption apparatuses, methods and systems |
US20120209749A1 (en) | 2011-02-16 | 2012-08-16 | Ayman Hammad | Snap mobile payment apparatuses, methods and systems |
US10586227B2 (en) | 2011-02-16 | 2020-03-10 | Visa International Service Association | Snap mobile payment apparatuses, methods and systems |
EP2678812A4 (en) | 2011-02-22 | 2015-05-20 | Visa Int Service Ass | Universal electronic payment apparatuses, methods and systems |
WO2012118870A1 (en) | 2011-02-28 | 2012-09-07 | Visa International Service Association | Secure anonymous transaction apparatuses, methods and systems |
US9996838B2 (en) | 2011-03-04 | 2018-06-12 | Visa International Service Association | Cloud service facilitator apparatuses, methods and systems |
US8447693B2 (en) * | 2011-04-13 | 2013-05-21 | Citicorp Credit Services, Inc. | Methods and systems for routing payment transactions |
US9646291B2 (en) | 2011-05-11 | 2017-05-09 | Visa International Service Association | Electronic receipt manager apparatuses, methods and systems |
WO2012167202A2 (en) | 2011-06-03 | 2012-12-06 | Visa International Service Association | Virtual wallet card selection apparatuses, methods and systems |
AU2012278963B2 (en) | 2011-07-05 | 2017-02-23 | Visa International Service Association | Electronic wallet checkout platform apparatuses, methods and systems |
US9355393B2 (en) | 2011-08-18 | 2016-05-31 | Visa International Service Association | Multi-directional wallet connector apparatuses, methods and systems |
US9582598B2 (en) | 2011-07-05 | 2017-02-28 | Visa International Service Association | Hybrid applications utilizing distributed models and views apparatuses, methods and systems |
US10438176B2 (en) | 2011-07-17 | 2019-10-08 | Visa International Service Association | Multiple merchant payment processor platform apparatuses, methods and systems |
US10242358B2 (en) | 2011-08-18 | 2019-03-26 | Visa International Service Association | Remote decoupled application persistent state apparatuses, methods and systems |
US10318941B2 (en) | 2011-12-13 | 2019-06-11 | Visa International Service Association | Payment platform interface widget generation apparatuses, methods and systems |
US9710807B2 (en) | 2011-08-18 | 2017-07-18 | Visa International Service Association | Third-party value added wallet features and interfaces apparatuses, methods and systems |
US10825001B2 (en) | 2011-08-18 | 2020-11-03 | Visa International Service Association | Multi-directional wallet connector apparatuses, methods and systems |
US9117225B2 (en) | 2011-09-16 | 2015-08-25 | Visa International Service Association | Apparatuses, methods and systems for transforming user infrastructure requests inputs to infrastructure design product and infrastructure allocation outputs |
US10223730B2 (en) | 2011-09-23 | 2019-03-05 | Visa International Service Association | E-wallet store injection search apparatuses, methods and systems |
US9953378B2 (en) | 2012-04-27 | 2018-04-24 | Visa International Service Association | Social checkout widget generation and integration apparatuses, methods and systems |
WO2013090611A2 (en) | 2011-12-13 | 2013-06-20 | Visa International Service Association | Dynamic widget generator apparatuses, methods and systems |
US10223710B2 (en) | 2013-01-04 | 2019-03-05 | Visa International Service Association | Wearable intelligent vision device apparatuses, methods and systems |
US10262148B2 (en) | 2012-01-09 | 2019-04-16 | Visa International Service Association | Secure dynamic page content and layouts apparatuses, methods and systems |
US11308227B2 (en) | 2012-01-09 | 2022-04-19 | Visa International Service Association | Secure dynamic page content and layouts apparatuses, methods and systems |
AU2013214801B2 (en) | 2012-02-02 | 2018-06-21 | Visa International Service Association | Multi-source, multi-dimensional, cross-entity, multimedia database platform apparatuses, methods and systems |
US11507950B2 (en) * | 2012-07-31 | 2022-11-22 | Worldpay, Llc | Systems and methods for secure normative intermediation of payments processing peripherals |
US20150006358A1 (en) * | 2013-07-01 | 2015-01-01 | Mastercard International Incorporated | Merchant aggregation through cardholder brand loyalty |
US20150039490A1 (en) * | 2013-07-30 | 2015-02-05 | Capital One Financial Corporation | Systems and methods for providing user-controlled automobile financing |
US11216468B2 (en) | 2015-02-08 | 2022-01-04 | Visa International Service Association | Converged merchant processing apparatuses, methods and systems |
EP3385894B1 (en) * | 2017-04-03 | 2021-07-21 | PLC Group AG | Method for producing a cryptographically signed transaction |
US10929838B2 (en) | 2018-01-19 | 2021-02-23 | Leadot Innovation, Inc. | Card not present transaction system and method for operating card not present transaction system to simplify hardware required at client sites |
TWI722333B (en) * | 2018-01-19 | 2021-03-21 | 澧達科技股份有限公司 | Card reading transaction system and method for operating a card reading transaction system |
US10685192B2 (en) * | 2018-01-19 | 2020-06-16 | Leadot Innovation, Inc. | Card reading transaction system with an intermediate server |
US11182849B1 (en) * | 2018-05-04 | 2021-11-23 | Coupa Software Incorporated | Automatic virtual purchase card charge reconciliation against requisition in an online procurement system |
US11587082B1 (en) * | 2019-11-07 | 2023-02-21 | Stripe, Inc. | Systems and methods for reconciling electronic transactions facilitated by a commerce platform |
US11144910B2 (en) | 2020-02-14 | 2021-10-12 | Capital One Services, Llc | System and method for inserting data into an internet browser form |
US20220122138A1 (en) * | 2020-10-16 | 2022-04-21 | Stripe, Inc. | Systems and methods for real time system onboarding using identifier pooling |
US11869008B2 (en) * | 2021-10-29 | 2024-01-09 | Intuit Inc. | Minimizing risks posed to online services |
US11756012B2 (en) * | 2021-12-06 | 2023-09-12 | Bank Of America Corporation | Dynamically triggered automatic resource distribution identification and population system |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040230536A1 (en) * | 2000-03-01 | 2004-11-18 | Passgate Corporation | Method, system and computer readable medium for web site account and e-commerce management from a central location |
US20040257894A1 (en) * | 2003-06-20 | 2004-12-23 | Toshiyuki Onogi | Electric-field-effect magnetoresistive devices and electronic devices using the magnetoresistive devices |
US20060020542A1 (en) * | 2004-07-21 | 2006-01-26 | Litle Thomas J | Method and system for processing financial transactions |
US20080052244A1 (en) * | 1999-04-19 | 2008-02-28 | First Data Corporation | Anonymous transaction authentication |
US20080255947A1 (en) * | 2007-04-11 | 2008-10-16 | First Data Corporation | Mobile commerce infrastructure systems and methods |
US20090125430A1 (en) * | 1999-12-16 | 2009-05-14 | Scott Krueger | Secure networked transaction system |
US7752132B2 (en) * | 2001-02-23 | 2010-07-06 | Efunds Corporation | Electronic payment and authentication system with debit and identification data verification and electronic check capabilities |
Family Cites Families (112)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US3920908A (en) | 1974-06-25 | 1975-11-18 | Constantine R Kraus | Buyer credit service for a telephone system |
US4191860A (en) | 1978-07-13 | 1980-03-04 | Bell Telephone Laboratories, Incorporated | Data base communication call processing method |
US4291198A (en) | 1979-06-28 | 1981-09-22 | Bell Telephone Laboratories, Incorporated | General-purpose electronic telephone station set |
US6289319B1 (en) | 1984-05-24 | 2001-09-11 | Lawrence B. Lockwood | Automatic business and financial transaction processing system |
US4757267A (en) | 1987-06-17 | 1988-07-12 | Applied Telematics, Inc. | Telephone system for connecting a customer to a supplier of goods |
WO1988010467A1 (en) | 1987-06-19 | 1988-12-29 | Lucero, James, L. | Drive-through credit card payment device |
US4996705A (en) | 1987-09-01 | 1991-02-26 | At&T Bell Laboratories | Use of telecommunications systems for lotteries |
JPH0195362A (en) | 1987-10-07 | 1989-04-13 | Omron Tateisi Electron Co | Debit-cum-credit terminal |
US5010238A (en) | 1988-03-18 | 1991-04-23 | Hitachi, Ltd. | Automatic cash transaction system and method |
JPH06101072B2 (en) | 1988-04-21 | 1994-12-12 | オムロン株式会社 | Sales registration device |
US4969183A (en) | 1989-08-28 | 1990-11-06 | Morris Reese | Telephone lotto number system and service |
JP2849755B2 (en) | 1989-08-31 | 1999-01-27 | 株式会社日立製作所 | Cash automatic transaction system |
CA2059078C (en) | 1991-02-27 | 1995-10-03 | Alexander G. Fraser | Mediation of transactions by a communications system |
US5446885A (en) | 1992-05-15 | 1995-08-29 | International Business Machines Corporation | Event driven management information system with rule-based applications structure stored in a relational database |
ATE202864T1 (en) | 1993-08-27 | 2001-07-15 | Affinity Technology Inc | CLOSED LOOP FINANCIAL TRANSACTION METHOD AND DEVICE |
US5940811A (en) | 1993-08-27 | 1999-08-17 | Affinity Technology Group, Inc. | Closed loop financial transaction method and apparatus |
US5537315A (en) | 1994-03-23 | 1996-07-16 | Mitcham; Martin K. | Method and apparatus for issuing insurance from kiosk |
US6868408B1 (en) | 1994-04-28 | 2005-03-15 | Citibank, N.A. | Security systems and methods applicable to an electronic monetary system |
US5732400A (en) | 1995-01-04 | 1998-03-24 | Citibank N.A. | System and method for a risk-based purchase of goods |
JP3047092B2 (en) | 1995-05-02 | 2000-05-29 | 日本信販株式会社 | Credit card system and method of using credit card using the system |
US5794221A (en) | 1995-07-07 | 1998-08-11 | Egendorf; Andrew | Internet billing method |
US5793028A (en) | 1996-06-24 | 1998-08-11 | Fred N. Gratzon | Electronic transaction security system |
US7039603B2 (en) | 1996-09-04 | 2006-05-02 | Walker Digital, Llc | Settlement systems and methods wherein a buyer takes possession at a retailer of a product purchased using a communication network |
US6029150A (en) | 1996-10-04 | 2000-02-22 | Certco, Llc | Payment and transactions in electronic commerce system |
US6000832A (en) | 1997-09-24 | 1999-12-14 | Microsoft Corporation | Electronic online commerce card with customer generated transaction proxy number for online transactions |
US5883810A (en) | 1997-09-24 | 1999-03-16 | Microsoft Corporation | Electronic online commerce card with transactionproxy number for online transactions |
US6078891A (en) | 1997-11-24 | 2000-06-20 | Riordan; John | Method and system for collecting and processing marketing data |
US6477578B1 (en) | 1997-12-16 | 2002-11-05 | Hankey Mhoon | System and method for conducting secure internet transactions |
US6038597A (en) | 1998-01-20 | 2000-03-14 | Dell U.S.A., L.P. | Method and apparatus for providing and accessing data at an internet site |
US6202053B1 (en) | 1998-01-23 | 2001-03-13 | First Usa Bank, Na | Method and apparatus for generating segmentation scorecards for evaluating credit risk of bank card applicants |
US6098053A (en) | 1998-01-28 | 2000-08-01 | Citibank, N.A. | System and method for performing an electronic financial transaction |
US6122624A (en) | 1998-05-28 | 2000-09-19 | Automated Transaction Corp. | System and method for enhanced fraud detection in automated electronic purchases |
US6029890A (en) | 1998-06-22 | 2000-02-29 | Austin; Frank | User-Specified credit card system |
WO2000002150A1 (en) | 1998-07-01 | 2000-01-13 | Webcard Inc. | Transaction authorisation method |
US7107243B1 (en) | 1998-08-10 | 2006-09-12 | Citibank, N.A. | System and method for automated bill payment service |
US7051001B1 (en) | 1998-08-27 | 2006-05-23 | Citibank, N.A. | System and method for merchant function assumption of internet checking and savings account transactions |
US6317783B1 (en) | 1998-10-28 | 2001-11-13 | Verticalone Corporation | Apparatus and methods for automated aggregation and delivery of and transactions involving electronic personal information or data |
US6567791B2 (en) | 1998-11-03 | 2003-05-20 | Nextcard, Inc. | Method and apparatus for a verifiable on line rejection of an application for credit |
US6405181B2 (en) | 1998-11-03 | 2002-06-11 | Nextcard, Inc. | Method and apparatus for real time on line credit approval |
US7047416B2 (en) * | 1998-11-09 | 2006-05-16 | First Data Corporation | Account-based digital signature (ABDS) system |
US6820202B1 (en) | 1998-11-09 | 2004-11-16 | First Data Corporation | Account authority digital signature (AADS) system |
US6032136A (en) | 1998-11-17 | 2000-02-29 | First Usa Bank, N.A. | Customer activated multi-value (CAM) card |
US6889325B1 (en) | 1999-04-28 | 2005-05-03 | Unicate Bv | Transaction method and system for data networks, like internet |
WO2000067177A2 (en) | 1999-04-30 | 2000-11-09 | X.Com Corporation | System and method for electronically exchanging value among distributed users |
US6704714B1 (en) | 1999-05-03 | 2004-03-09 | The Chase Manhattan Bank | Virtual private lock box |
US6227447B1 (en) | 1999-05-10 | 2001-05-08 | First Usa Bank, Na | Cardless payment system |
US6957334B1 (en) | 1999-06-23 | 2005-10-18 | Mastercard International Incorporated | Method and system for secure guaranteed transactions over a computer network |
US6675153B1 (en) | 1999-07-06 | 2004-01-06 | Zix Corporation | Transaction authorization system |
US7127427B1 (en) | 1999-10-05 | 2006-10-24 | Andrew Casper | Secure transaction processing system and method |
US6332134B1 (en) | 1999-11-01 | 2001-12-18 | Chuck Foster | Financial transaction system |
US7177836B1 (en) | 1999-12-30 | 2007-02-13 | First Data Corporation | Method and system for facilitating financial transactions between consumers over the internet |
WO2001054038A1 (en) | 2000-01-20 | 2001-07-26 | David Thieme | System and method for facilitating secure payment with privacy over a computer network including the internet |
US6505171B1 (en) | 2000-02-04 | 2003-01-07 | Robert H. Cohen | System and method for handling purchasing transactions over a computer network |
US20010034702A1 (en) | 2000-02-04 | 2001-10-25 | Mockett Gregory P. | System and method for dynamically issuing and processing transaction specific digital credit or debit cards |
US6847953B2 (en) | 2000-02-04 | 2005-01-25 | Kuo James Shaw-Han | Process and method for secure online transactions with calculated risk and against fraud |
US6915272B1 (en) | 2000-02-23 | 2005-07-05 | Nokia Corporation | System and method of secure payment and delivery of goods and services |
US7366695B1 (en) | 2000-02-29 | 2008-04-29 | First Data Corporation | Electronic purchase method and funds transfer system |
US20020007302A1 (en) | 2000-03-06 | 2002-01-17 | Work Bruce V. | Method and apparatus for tracking vendor compliance with purchaser guidelines and related method for the commercial distribution of software and hardware implementing same |
US7263506B2 (en) | 2000-04-06 | 2007-08-28 | Fair Isaac Corporation | Identification and management of fraudulent credit/debit card purchases at merchant ecommerce sites |
US6839690B1 (en) | 2000-04-11 | 2005-01-04 | Pitney Bowes Inc. | System for conducting business over the internet |
JP5025875B2 (en) * | 2000-04-24 | 2012-09-12 | ビザ・インターナショナル・サービス・アソシエーション | Online Payer Authentication Service Method |
US6970853B2 (en) | 2000-06-06 | 2005-11-29 | Citibank, N.A. | Method and system for strong, convenient authentication of a web user |
US7406442B1 (en) | 2000-09-11 | 2008-07-29 | Capital One Financial Corporation | System and method for providing a credit card with multiple credit lines |
US20020069166A1 (en) | 2000-09-15 | 2002-06-06 | Moreau Lawrence R. | Method and system for facilitating buying and selling transactions |
US20020035538A1 (en) | 2000-09-15 | 2002-03-21 | Moreau Lawrence R. | Method and system for facilitating buying and selling transactions |
US7006986B1 (en) | 2000-09-25 | 2006-02-28 | Ecardless Bancorp, Ltd. | Order file processes for purchasing on the internet using verified order information |
US20050038715A1 (en) | 2000-09-25 | 2005-02-17 | Ecardless Bancorp Ltd. | Customer processing for purchasing on the internet using verified order information |
US20040236673A1 (en) | 2000-10-17 | 2004-11-25 | Eder Jeff Scott | Collaborative risk transfer system |
US7379916B1 (en) | 2000-11-03 | 2008-05-27 | Authernative, Inc. | System and method for private secure financial transactions |
US6839692B2 (en) | 2000-12-01 | 2005-01-04 | Benedor Corporation | Method and apparatus to provide secure purchase transactions over a computer network |
US20020120864A1 (en) | 2000-12-13 | 2002-08-29 | Wu Jackie Zhanhong | Automatable secure submission of confidential user information over a computer network |
US6931382B2 (en) | 2001-01-24 | 2005-08-16 | Cdck Corporation | Payment instrument authorization technique |
US20040215551A1 (en) | 2001-11-28 | 2004-10-28 | Eder Jeff S. | Value and risk management system for multi-enterprise organization |
US20020107793A1 (en) | 2001-02-06 | 2002-08-08 | Yuan-Chieh Lee | Electronic transaction system for the internet |
US7013289B2 (en) | 2001-02-21 | 2006-03-14 | Michel Horn | Global electronic commerce system |
US20020120537A1 (en) | 2001-02-28 | 2002-08-29 | Dominic Morea | Web based system and method for managing business to business online transactions |
US20020198822A1 (en) | 2001-06-21 | 2002-12-26 | Rodrigo Munoz | Method and apparatus for evaluating an application for a financial product |
AU2002327322A1 (en) | 2001-07-24 | 2003-02-17 | First Usa Bank, N.A. | Multiple account card and transaction routing |
US7366694B2 (en) | 2001-08-16 | 2008-04-29 | Mortgage Grader, Inc. | Credit/financing process |
US7707108B2 (en) | 2002-01-31 | 2010-04-27 | International Business Machines Corporation | Detection of unauthorized account transactions |
US7890393B2 (en) | 2002-02-07 | 2011-02-15 | Ebay, Inc. | Method and system for completing a transaction between a customer and a merchant |
US7707120B2 (en) | 2002-04-17 | 2010-04-27 | Visa International Service Association | Mobile account authentication service |
US7139734B2 (en) | 2002-12-04 | 2006-11-21 | Nathans Michael G | Preferred credit information data collection method |
US20040186807A1 (en) | 2003-03-21 | 2004-09-23 | Nathans Michael G. | Credit data collection method and apparatus |
US20040151292A1 (en) | 2003-01-31 | 2004-08-05 | Larsen David J. | Prepaid and postpaid subscriber telephony platform |
US20050049974A1 (en) | 2003-08-29 | 2005-03-03 | Ali Jani | Credit card payment processing system and method |
US7108174B2 (en) | 2003-09-30 | 2006-09-19 | First Data Corporation | Systems and methods for detecting corporate financial transactions |
US20060289621A1 (en) | 2003-10-14 | 2006-12-28 | Compucredit | Dynamic fee structuring in a stored valude card program |
US20050125336A1 (en) | 2003-12-09 | 2005-06-09 | Capital One Financial Corporation | Methods and systems for offering a credit card account to a consumer at a point-of-sale location |
US20050131808A1 (en) | 2003-12-10 | 2005-06-16 | Edgar Villa | Method for establishing control over credit card transactions |
AU2004316986A1 (en) | 2004-02-23 | 2005-09-15 | Pay Pal Pte Ltd. | Verification and authorization of a consumer transaction |
US8762283B2 (en) | 2004-05-03 | 2014-06-24 | Visa International Service Association | Multiple party benefit from an online authentication service |
US7870071B2 (en) | 2004-09-08 | 2011-01-11 | American Express Travel Related Services Company, Inc. | Systems, methods, and devices for combined credit card and stored value transaction accounts |
US20060106699A1 (en) | 2004-11-17 | 2006-05-18 | Boris Hitalenko | System and method for conducting secure commercial order transactions |
CA2594881C (en) | 2005-01-25 | 2013-10-15 | I4 Commerce Inc. | Computer-implemented method and system for dynamic consumer rating in a transaction |
WO2006105040A2 (en) | 2005-03-29 | 2006-10-05 | Mastercard International Incorporated | System and method for issuing prepaid debit card at point of sale |
US7527195B2 (en) | 2005-04-11 | 2009-05-05 | Bill Me Later, Inc. | Method and system for risk management in a transaction |
US20060229974A1 (en) | 2005-04-11 | 2006-10-12 | I4 Licensing Llc | Method of extending credit to at least one consumer and method of processing a transaction between a consumer and a merchant |
US8756099B2 (en) | 2005-04-11 | 2014-06-17 | Bill Me Later, Inc. | Consumer processing system and method |
US20070038485A1 (en) | 2005-07-07 | 2007-02-15 | Yeransian Luke W | Method and automated system for evaluating and trading insurance risk |
US8056114B2 (en) | 2005-08-23 | 2011-11-08 | The Boeing Company | Implementing access control policies across dissimilar access control platforms |
US20070063017A1 (en) | 2005-09-21 | 2007-03-22 | Yaofei Chen | System and method for securely making payments and deposits |
US20070073889A1 (en) | 2005-09-27 | 2007-03-29 | Morris Robert P | Methods, systems, and computer program products for verifying an identity of a service requester using presence information |
US7627525B2 (en) | 2005-10-07 | 2009-12-01 | Andrew Williams | Automated check cashing and loan processing ATM system and methodology |
US8770473B2 (en) | 2005-10-25 | 2014-07-08 | Capital One Financial Corporation | Systems and methods for providing flexible incentive rewards |
US20070094095A1 (en) | 2005-10-26 | 2007-04-26 | Kilby Brian G | Internet anti-fraud cardholder verification system |
WO2007058732A2 (en) | 2005-11-10 | 2007-05-24 | Markmonitor Inc. | B2c authentication system and methods |
US20080040261A1 (en) * | 2006-04-24 | 2008-02-14 | Robert Nix | Systems and methods for implementing financial transactions |
US20080040275A1 (en) | 2006-04-25 | 2008-02-14 | Uc Group Limited | Systems and methods for identifying potentially fraudulent financial transactions and compulsive spending behavior |
US8554669B2 (en) | 2007-01-09 | 2013-10-08 | Bill Me Later, Inc. | Method and system for offering a credit product by a credit issuer to a consumer at a point-of sale |
US8433648B2 (en) | 2007-02-26 | 2013-04-30 | Bill Me Later, Inc. | Method and system for engaging in a transaction between a consumer and a merchant |
US20080208760A1 (en) | 2007-02-26 | 2008-08-28 | 14 Commerce Inc. | Method and system for verifying an electronic transaction |
-
2007
- 2007-05-02 US US11/799,667 patent/US20080272188A1/en not_active Abandoned
-
2008
- 2008-04-28 AU AU2008201859A patent/AU2008201859B2/en active Active
- 2008-04-30 CA CA2631178A patent/CA2631178C/en active Active
- 2008-10-14 US US12/250,978 patent/US20090037290A1/en not_active Abandoned
-
2015
- 2015-08-03 US US14/817,180 patent/US10580070B2/en active Active
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080052244A1 (en) * | 1999-04-19 | 2008-02-28 | First Data Corporation | Anonymous transaction authentication |
US20090125430A1 (en) * | 1999-12-16 | 2009-05-14 | Scott Krueger | Secure networked transaction system |
US20040230536A1 (en) * | 2000-03-01 | 2004-11-18 | Passgate Corporation | Method, system and computer readable medium for web site account and e-commerce management from a central location |
US7752132B2 (en) * | 2001-02-23 | 2010-07-06 | Efunds Corporation | Electronic payment and authentication system with debit and identification data verification and electronic check capabilities |
US20040257894A1 (en) * | 2003-06-20 | 2004-12-23 | Toshiyuki Onogi | Electric-field-effect magnetoresistive devices and electronic devices using the magnetoresistive devices |
US20060020542A1 (en) * | 2004-07-21 | 2006-01-26 | Litle Thomas J | Method and system for processing financial transactions |
US20080255947A1 (en) * | 2007-04-11 | 2008-10-16 | First Data Corporation | Mobile commerce infrastructure systems and methods |
Cited By (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060229974A1 (en) * | 2005-04-11 | 2006-10-12 | I4 Licensing Llc | Method of extending credit to at least one consumer and method of processing a transaction between a consumer and a merchant |
US8639846B2 (en) | 2005-06-29 | 2014-01-28 | Visa U.S.A. Inc. | Adaptive gateway for switching transactions and data on unreliable networks using context-based rules |
US20100153435A1 (en) * | 2008-12-15 | 2010-06-17 | International Business Machines Corporation | Opening Document Stored at Multiple Database Replicas |
US8229890B2 (en) * | 2008-12-15 | 2012-07-24 | International Business Machines Corporation | Opening document stored at multiple database replicas |
US20120191648A1 (en) * | 2008-12-15 | 2012-07-26 | International Business Machines Corporation | Opening Document Stored at Multiple Database Replicas |
US8380670B2 (en) * | 2008-12-15 | 2013-02-19 | International Business Machines Corporation | Opening document stored at multiple database replicas |
US20110178901A1 (en) * | 2010-01-15 | 2011-07-21 | Imrey G Christopher | System and method for resolving transactions employing goal seeking attributes |
US9251539B2 (en) * | 2010-01-15 | 2016-02-02 | Apollo Enterprise Solutions, Ltd. | System and method for resolving transactions employing goal seeking attributes |
US8543508B2 (en) | 2010-07-09 | 2013-09-24 | Visa International Service Association | Gateway abstraction layer |
US9846905B2 (en) | 2010-07-09 | 2017-12-19 | Visa International Service Association | Gateway abstraction layer |
CN105426260A (en) * | 2015-10-30 | 2016-03-23 | 北京航天自动控制研究所 | Distributed system supported transparent interprocess communication system and method |
US20170185989A1 (en) * | 2015-12-28 | 2017-06-29 | Paypal, Inc. | Split group payments through a sharable uniform resource locator address for a group |
Also Published As
Publication number | Publication date |
---|---|
CA2631178A1 (en) | 2008-11-02 |
US20080272188A1 (en) | 2008-11-06 |
CA2631178C (en) | 2016-06-14 |
US10580070B2 (en) | 2020-03-03 |
AU2008201859B2 (en) | 2013-03-14 |
US20150339770A1 (en) | 2015-11-26 |
AU2008201859A1 (en) | 2008-11-20 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10580070B2 (en) | Distributed system for commerce | |
US7735720B2 (en) | Method and system for manual authorization | |
US7788170B2 (en) | System and method for providing extra lines of credit | |
US8315929B2 (en) | Online incremental payment method | |
US8041606B2 (en) | Online purchasing method | |
US6980970B2 (en) | Secure networked transaction system | |
JP4685812B2 (en) | Online coupon distribution method | |
US6332134B1 (en) | Financial transaction system | |
US20160086167A1 (en) | System and method for administering a value vault | |
US10169748B2 (en) | Alternative payment implementation for electronic retailers | |
US20120166311A1 (en) | Deferred payment and selective funding and payments | |
US20070022375A1 (en) | Apparatus, system, and method for an electronic payment system | |
US20130226807A1 (en) | Online funds transfer method | |
US20100174626A1 (en) | Payment system | |
US20170243178A1 (en) | Authentication data-enabled transfers | |
US20050044014A1 (en) | Public network privacy protection tool and method | |
US20030120590A1 (en) | Electronic settlement method and system |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: BILL ME LATER, INC., MARYLAND Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:KEITHLEY, THOMAS H;WHITFORD, THOMAS E;REEL/FRAME:023236/0116 Effective date: 20080308 |
|
AS | Assignment |
Owner name: PAYPAL, INC., CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:EBAY INC.;REEL/FRAME:036170/0540 Effective date: 20150717 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |
|
AS | Assignment |
Owner name: EBAY INC., CALIFORNIA Free format text: MERGER;ASSIGNOR:BILL ME LATER, INC.;REEL/FRAME:038449/0678 Effective date: 20081003 |