Abstract:
A card payment system includes a purchases assistance system linking online merchants of goods or services, including digital goods, with the operator of the card issuance system. Merchants can use the purchases assistance system to seek help from the Issuer for resolving disputes related to purchases of digital goods of which the provisioning may have failed, to trade better commercial terms from the Issuer in exchange for providing details of products purchased by cardholders, to verify the balance of debit cards and request a reservation of funds from the Issuer to lower their financial risks prior to certain types of transactions, or to signal to the Issuer special loyalty rewards associated with specific purchases.

Description:
PRIORITY CLAIM/RELATED APPLICATION 
       [0001]    This application claims priority under 35 USC 119(e) to U.S. Provisional Patent Application Ser. No. 60/795,769 filed on Apr. 28, 2006 and entitled “Assistance Method and Apparatus for Online Purchases of Goods or Services Conducted With Payment Card Systems”, the entirely of which is incorporated herein by reference. 
     
     FIELD 
       [0002]    A payment system and in particular a card payment systems are provided that are fitted with a method and apparatus for the online purchase of goods or services. 
       BACKGROUND 
       [0003]    Card payment systems are commonplace, allowing users to make payments using a credit or debit card. While credit card charges accumulate debt that the cardholder needs to settle periodically, debit card charges draw money from the funds available in an account. The terms “charge card” or “payment card” will be used herein below to relate to both credit and debit cards. 
         [0004]    A charge card is associated with an account that is established with and managed by a card issuer. The card issuer is an entity that manages payments on behalf of the cardholder, and can be a bank, credit card company, telephone company, workplace, school, etc. The charge card is accepted by participating merchants, who sign with a transaction acquirer, which can be the same or other than the card issuer. In a typical transaction, the merchant calculates the payment amount, the cardholder submits his card for payment, the card adequacy to pay is verified by a process called “authorization”, the payment particulars are recorded by the merchant&#39;s POS (Point Of Service), and then, either in real time or as part of an end-of-day procedure, the transaction records are sent from the merchant to his transaction acquirer for settlement. The transaction is finalized when the transaction acquirer settles with the card issuer (if the issuer is another entity), and funds are transferred to the merchant&#39;s account on the one hand, and are charged to the cardholder&#39;s account on the other hand. Often the amount transferred to the merchant&#39;s account is slightly smaller than the one charged to the cardholder&#39;s account, the difference being a fee collected by the issuer, transaction acquirer and/or an interchange network between the transaction acquirer and the issuer. 
         [0005]    The charge card is a means for a cardholder to identify his account and authorize transactions therewith. It can have the well-known form factor of a plastic card with embossment and magnetic stripe; it also can be a contact or contact-less smart card having a variety of form factors such as plastic card or a key fob; it also can even be just a record of account details used for performing electronic transactions over the Internet or a cellular network. 
         [0006]      FIG. 1  is a schematic block diagram that describes a typical card payment system  100 . A payment card  104  related to user account  120  makes a payment transaction  108  in the amount of X dollars with a merchant POS  112 . The merchant POS  112  contacts merchant&#39;s acquirer  35  for making an authorization  116 . The acquirer contacts in turn a card interchange network  25  to obtain the authorization from an issuer  15  via a protocol  355 . If the transaction is successfully authorized, the cardholder receives his merchandise or service from the merchant (not shown). The transaction is ultimately completed when the funds transfer  138  of X dollars minus a fee (MF) charged to the merchant is received through settlement network  40  by merchant account  160  associated with POS  112 . 
         [0007]    Of a special interest are merchants who sell items of small monetary value, for which the fees MF charged by ordinary acquirers of card transactions represent a prohibitively high percentage of the items price.  FIG. 2  shows the typical structure of a fee  200  charged to merchants for card payment processing, where the merchant fee MF is comprised of a fixed amount  210  to which a percentage amount  220  of the purchase amount is added. Typical fees  200  are devised to represent an acceptable overall percentage of most common card transactions, for example 2.5% or less. However, when the price of the good or service being sold is small, the fee incurred by the merchant accepting the card as a payment instrument can be in excess of 10% of the value of the transaction because the fixed factor  210  becomes preponderant, thus making card payments non viable for small-ticket low-margin commerce. For example, it is customary that fixed factor  210  be in the vicinity of $0.25, thus representing 25% of a $1 transaction. It should be noted that the fee MF charged to the merchant is intended to cover all the service costs incurred by the participants of charge back-end system  130  of  FIG. 1 , i.e. the acquirer, interchange network and issuer, and not just the acquirer. 
         [0008]    Costs incurred by merchants for ordinary card transactions are even higher for online merchants which sell goods and services over an Internet storefront, because the transactions are deemed to be “card-non-present-transactions”, which are typically riskier than “card-present-transactions” at a physical retail Point Of Service. During a card-present-transaction, the merchant is given the opportunity to verify by itself a number of credentials about the card holder, such as that the matching of the signature at the back of the card against the card-holder&#39;s signature on a paper receipt, or the matching of the name printed on the face of the card against a requested card-holder proof-of-identity. Such verifications by the merchant are not available during an online purchase, thus increasing the risk that the card involved may not be legitimate or may have been stolen. Hence, transaction acquirers typically charge merchants a higher fee for such card-non-present-transactions, by increasing the percentage amount  220 , and sometimes the fixed amount  210  as well. 
         [0009]      FIG. 3  is a schematic block diagram that describes a typical card-non-present payment system  300 . A personal computer  105  is used to browse and select a desirable good or service from a merchant&#39;s web storefront server  311 , where the personal computer and the merchant server communicate remotely with each other via a known Internet protocol  306 . Once the desired good or service is selected, a payment card  104  on the personal computer side makes a payment transaction  308  with a merchant POS  312  via the merchant storefront  311 . The merchant POS  312  contacts a charge back-end system  130  for making an authorization  116  which is considered a card-non-present authorization. If the transaction is successfully authorized, the cardholder receives his merchandise or service from the merchant (not shown). Online merchants of small-value digital items like digital music, ring-tones for Mobile Phones or casual video games for Personal Computers or Game Consoles or Mobile Phones are thus doubly impacted by card fees: once because the fees amount to a naturally high percentage of the price of their wares, and a second time because they sell through card-non-present transactions which have a higher fee associated with them. 
         [0010]    Some of the most sophisticated online merchants of digital goods implement methods and processes to alleviate the onerous fee structure of typical card payment systems by attempting the aggregation of a multiplicity of small-amount transactions within a given period of time (e.g. a few days).  FIG. 4  illustrates a typical aggregation system  400  where a series of consecutive small-amount transactions are lumped together “behind the scenes” by a merchant POS  412  into a single larger-value transaction, which is then processed by an ordinary charge back-end system. In this way, the fee is incurred on the cumulative value of the plurality of small transactions, and in particular the fixed factor  210  of  FIG. 2  is incurred only once. 
         [0011]    Besides being financially impacted by the current cost structure of card payment systems, online merchants of digital items are also encumbered by high failure rates in the telecommunication-based fulfillment of the goods they sell. Digital items are typically sent from a merchants&#39; computer-based server and storage system to the purchaser via shared and public telecommunication links such as phone lines, broadband cables, or wireless cells reaching a purchaser&#39;s device such as a personal computer, set-top box, game console or mobile phone.  FIG. 5  is a schematic block diagram that describes a typical digital goods delivery system  500 . A digital item is downloaded through the public Internet  309  via a communication protocol  307  from the Merchant&#39;s  110  to the Personal Computer  105  of the purchaser. All elements involved in the delivery of the digital goods, i.e. the merchant&#39;s server system sending the goods, the purchaser&#39;s device receiving the goods and the telecommunication system transporting the goods, are prone to technical failures, resulting in the unsuccessful fulfillment of the purchased digital goods. Examples of such failures include interruptions of the telecommunication links, corruption of the data during transfer due to noise or interferences, erroneous labeling of item references on the merchant server, lack of available memory space in the purchaser&#39;s device. The failure rates are much higher than during the fulfillment process of physical goods such as the delivery of a cinema ticket, the bagging and transporting of groceries, or the selection of a book from a store shelf. Therefore, merchants of digital goods are often confronted with complaints from customers having failed to properly receive the digital goods already selected, ordered and purchased by the customer. 
         [0012]    Some of the most sophisticated online merchants of digital goods implement methods and processes to reduce the risk of fulfillment failures by implementing disruption-tolerant end-to-end communication protocols between their download servers and the purchasers&#39; devices. Such resilient protocols typically allow purchasers to recover from an interruption, but they tend to be limited to high-end programmable devices like personal computers, and require a certain degree of technical sophistication from the purchaser. 
         [0013]    These typical systems and methods, however, have limitations and drawbacks. First, the merchants implementing an aggregation method to reduce their fees incur a risk of not being paid as long as the cumulative amount of transactions has not reached the threshold for triggering an authorization request to the charge back-end system. This is particularly true when the payers are teenagers equipped with prepaid or debit cards rather than adults with a credit card. Teen prepaid or debit cards usually carry a small balance and transactions on such cards are only authorized on the basis of the balance amount and not the estimated credit-worthiness of the holder. Therefore, the merchants run a higher risk to see the transactions being declined when the aggregated amounts to be obtained from such cards are presented to the payment network. This holds true even if an authorization request was performed prior to the user starting to make purchases, as, in the mean time, the balance on the prepaid or debit card may have decreased through purchases elsewhere, below the value of the aggregated amount submitted to the network. 
         [0014]    A second drawback is that the issuers of payment cards are usually the first entity called by purchasers if a transaction listed on their card statement is in dispute. If the problem relative to a digital good purchase is due to a fulfillment problem, then the card issuer is powerless because he is unaware of the fulfillment process and possible shortcomings or improvements of that process, and needs to refer the cardholder back to the merchant. Furthermore, if the transaction in dispute is one of a series of transactions having been aggregated by the merchant for cost-optimization purposes, then the cardholder and the issuer cannot even determine which part of the aggregated transaction may be at fault. 
       SUMMARY 
       [0015]    A method and apparatus for improving the online card payment of goods, including digital goods is provided. The system lowers the financial risks incurred by merchants who attempt to aggregate small-amount transactions before requesting a card payment authorization, including in those cases where the card is a prepaid debit card with an expected low balance. The system also allows the card issuer to investigate potential digital content fulfillment failures when a cardholder disputes such a transaction, including in those cases where the incriminated transaction is part of an aggregation by the merchant of successive small-amount transactions. The system also permits merchants to negotiate financially advantageous transaction processing prices with the card issuers by selectively providing to such issuers commercially-useful details about the purchased products or services which would not otherwise be available through the processing protocols of the prior art, in exchange for a discount on interchange fees. The system does not require any modification to the existing protocols used by merchants, acquirers, payment networks and issuers. 
     
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0016]      FIG. 1  is a simplified block diagram describing a typical card payment system; 
           [0017]      FIG. 2  is a description of a typical merchant fee structure; 
           [0018]      FIG. 3  is a simplified block diagram describing a typical card-non-present online transaction architecture; 
           [0019]      FIG. 4  is a simplified block diagram describing a typical transaction aggregation system implemented by a merchant; 
           [0020]      FIG. 5  is a simplified block diagram describing the typical download path of digital product being purchased online; 
           [0021]      FIG. 6  is a simplified block diagram of a purchases assistance system; 
           [0022]      FIG. 7  is a simplified diagram showing more details of an issuer purchase assistant of the purchases assistance system shown in  FIG. 6 ; 
           [0023]      FIG. 8  is a simplified diagram showing more details of a merchant purchase assistant of the purchases assistance system shown in  FIG. 6 ; 
           [0024]      FIG. 9  is a simplified diagram illustrating another embodiment of the purchase assistance system operating in batch mode; 
           [0025]      FIG. 10  is a simplified diagram illustrating another embodiment of the purchase assistance system operating in a real-time mode; 
           [0026]      FIG. 11  is a flowchart illustrating how a merchant uses the purchase assistance system to deliver data representing the details of purchase transactions, including product identification; 
           [0027]      FIG. 12  is a flowchart illustrating how a merchant uses the purchase assistance system to obtain data representing balance checks and funds reservation; 
           [0028]      FIG. 13  is a flowchart illustrating how a merchant uses the purchase assistance system to exchange data with an issuance system  130 ; 
           [0029]      FIG. 14  is a flowchart illustrating how the issuing system uses the purchase assistance system to provision new or updated card information into the wallet of co-branding merchants; and 
           [0030]      FIG. 15  is a flowchart illustrating how a merchant uses the purchase assistance system to delegate online user authentication to an issuer. 
       
    
    
     DETAILED DESCRIPTION  
       [0031]    A purchase assistance system  450  between one or more merchants  310  of products or services selling, among other things, small-value items, and one or more charge card account issuance systems  120  is provided as shown in  FIG. 6 . The overall system may include a merchant domain  30 , an interchange domain  20 , and an issuer domain  10 . Card payments made at a merchant  310  are authorized via a typical protocol  45  between an acquirer  35  and an issuer  15  via an interchange network  25 . The protocol may be ISO 8583 that is independent of the presence or the absence of purchase assistance system  450  since the purchase assistance system  450  does not require the protocols of the typical charge card system to be altered in order to be used with the purchase assistance system. 
         [0032]    The purchases assistance (PA) system  450  may include a merchant purchase assistant unit  350  associated with each merchant  310  and an issuer purchase assistant unit  150  associated with each issuer  130  wherein the units  350 ,  150  each have a plurality of lines of computer code, executed by a computing device associated with the merchant and issuer, respectively, that perform the functions and operations of each of these units as described in more detail below. The merchant purchase unit  350  links the merchant to the same issuer  15 , but through a data exchange helper protocol  250  running in parallel with protocol  45 , between merchant purchase unit  350  and the issuer purchase unit  150 . The data exchange helper protocol  250  does not carry payment authorization transactions, which are solely conducted via protocol  45 , such as ISO 8583. Instead, data exchange helper protocol  250  handles a series of optional assistance features related to the purchases of goods or services including digital goods. Thus, the dedicated data exchange helper protocol  250  allows the merchant purchase assistant  350  and the issuer purchase assistant unit  150  to communicate with each other either in batch mode at regular intervals or in real-time asynchronous mode. The data exchange helper protocol  250  never carries payment authorizations. With reference to Table 1, the data exchange helper protocol  250  can carry a combination of one or more of the following: card holder identification data elements; purchase transaction data elements; reward program transaction data elements; card balance and reservation request data; administrative commands; card identification data elements; and/or card-holder authentication request commands. 
         [0033]    The card-holder identification data elements allow the issuance system  120  to determine which card-holder is carrying out purchase transactions that may require assistance through the Purchase assistance system  450 . The purchase transaction data elements including product genre or product identification such as, by way of example, title, track name, level name, chapter name, etc. that can be further used by the Issuer to identify unambiguously digital purchases that may be at fault during a failed fulfillment or erroneous charge, or to warehouse for later commercial analysis, if the merchant agrees to such exploitation of these data elements, for example in exchange for a discount on the interchange rate. The reward program transaction data elements allow, by way of example, a particular transaction to be rewarded with a number of loyalty points different from what the default rules for the loyalty program would otherwise allocate. The data elements representing the card balance and reservation-request amount allow the merchant  310  to verify the amount of funds available from a card-holder and to request that a portion of such amount be reserved for its use, prior to the merchant attempting to aggregate transactions for fee optimization purposes. The various administrative commands allow the merchant purchase unit  350  and the Issuer purchase unit  150  to inform each other of various operational states, enter into specific modes of operations and otherwise stay synchronized. The card identification data elements allow a merchant  310  to provision in its online wallet system those cards that can subsequently benefit from the Purchase Assistance because they are issued by an Issuer equipped with Issuer Purchase Assistance  150 . Such feature can be found, by way of example, in the typical Amazon.com system where Visa Amazon cards get provisioned automatically inside the Amazon storefront&#39;s wallets once issued. The card-holder authentication request commands allow the merchant  310  to delegate to the issuance system  120  the online authentication of the card-holders and thus reduce the risk of later transaction repudiation by such card-holders. Such feature can be found, by way of example, in the typical Verified-by-Visa and MasterCard Securecode systems. 
         [0034]    The assistance features provided by the PA system  450  is described with reference to  FIG. 7  which depicts schematically the internal modules of the issuer purchase unit  150  (“IPA”). The unit  150  may include a data exchange helper protocol handler  151  that receives and sends information from and to the data exchange helper protocol  250 , parses, dispatches and receives relevant data to and from the other modules of the Issuer PA. A module  152  is a data repository that stores the details of purchase transactions sent by the merchant  310 . A module  153  handles the real-time verification of accounts balances and the reservation of funds in such accounts by communicating with a card processing platform  140  shown in  FIG. 6 . A module  154  also communicates with the card processing platform  140  and handles the provisioning of new or updated card account information back to merchant  310 . A module  155  is in charge of resolving different user-identification syntax conventions used respectively by merchant  310  and the card processing platform  140 , so that each party can keep using its own proprietary name space while enabling the Issuer PA to unambiguously handle individual users. By way of example, the issuer system  130  can identify its cardholders with Payment Application User Identifiers data elements or “PA_ID&#39;s”, managed by the module  155 . A module  156  handles the management of reward events requested by merchant  310  and destined to card processing platform  140 . A module  157  handles the synchronization of the reporting of purchase transactions coming from the merchant  310  with the reporting of transactions handled by card processing platform  140 . A module  158  passes relevant data elements about purchase transactions to a Customer Relation Management system, in particular to assist with possible disputes on such transactions. A module  159  handles user online authentication request from the Merchant  310  wishing to delegate such authentication to the Issuer. In an exemplary implementation, each module described above may be implemented as one or more lines of computer code on a computing device of the merchant that implement the functions and operations of the module as described herein. 
         [0035]    Symmetrically,  FIG. 8  depicts the internal modules of merchant purchase unit  350  (“MPA”). In an exemplary implementation, each module described above may be implemented as one or more lines of computer code on a computing device of the merchant that implement the functions and operations of the module as described herein. A data exchange helper protocol handler  351  sends and receives information to and from the data exchange helper protocol  250 , collects, parses and dispatches relevant data elements from and to the other modules of the Merchant purchase. A module  353  receives requests for the real-time verification of accounts balances and the reservation of funds in such accounts from merchant storefront  311 . A module  354  also communicates with merchant storefront  311 , and handles the provisioning of new or updated card account information received from the Issuer. A module  355  is in charge of resolving different naming convention used respectively by merchant  310  and the card processing platform  140 , so that each party can keep using its own proprietary name space while enabling the Merchant purchase unit to unambiguously handle individual users. By way of example, merchant  310  can identify its customers with its own Merchant Application User Identifiers data elements or “MA_ID&#39;s” managed by the module  355 . A module  356  handles the management of reward events requested by storefront  311  and destined to card processing platform  140 . A module  357  provides the details of purchase transactions coming from the merchant storefront  311  and destined to Issuer PA  150 . A module  359  handles user online authentication requests from the merchant storefront  311  and delegates such authentication to the Issuer via data exchange helper protocol  250  and the Issuer PA  150 . 
         [0036]    With reference to  FIG. 9 , in one embodiment of the system, the Merchant purchase unit  350  and the Issuer PA  150  can operate only in batch mode, i.e. at regular intervals agreed upon between the merchant  310  and the issuer system  130 , for example every 24 hours at the end of the business day. In such an implementation, modules  353  and  153  for handling balance inquiry and reservation of funds, and modules  159  and  359  for handling delegated user authentication, are not present because a merchant  310  cannot request the issuer  130  to authenticate a cardholder on its behalf nor to verify a card balance and reserve funds. The provisioning of new cards into the merchant&#39;s wallet system through modules  154 ,  155 ,  354  and  355  is done synchronously at agreed upon intervals, with the consequence that a new card issued to a new consumer will not appear inside the merchant&#39;s system until for example the next business day. The delivery of transactions details and special rewards requests is also done synchronously at agreed upon intervals, with the consequence that purchase details and associated loyalty rewards will not appear inside the cardholder&#39;s account until for example the next business day. While such batch-mode implementation has the limitations described above, it has the benefit of being easier to deploy for merchants, as it places no real-time constraints on the merchants&#39; systems. 
         [0037]    Alternatively, in another embodiment of the system shown in  FIG. 10 , the Merchant purchase unit  350  and the Issuer PA  150  can operate in real-time, i.e. whenever the need arises for the merchant and the issuer to communicate. In such an implementation, all modules can be present as needed. In particular, the merchant  310  can request the issuer  130  to authenticate a cardholder on its behalf and to verify a card balance and reserve funds before attempting an aggregation of subsequent transactions. 
         [0038]    A first assistance function of the purchase assistance system is to enable merchants  310  to obtain better customer support from the issuer  130  for purchases of goods carried out by cardholders at the merchant&#39;s online storefront. Since disputes relative to purchases of digital goods often arise out of a delivery failure of such goods rather than a faulty payment transaction, it is beneficial for the issuer  130  who is likely to be the first responder to cardholder inquiries about disputable transactions, to have the details of which exact digital product was purchased by whom, instead of just knowing the monetary amounts spent by cardholders for what may amount to a succession of separate downloads of digital content all aggregated into in financial transaction. Using the Purchase Assistant and in particular modules  152 ,  155  and  157  inside the Issuer PA  150  and modules  355  and  357  inside the Merchant purchase unit  350 , the merchant  310  can send to issuer  130  the detailed data elements representing previous transactions relative to purchase by the multiplicity of holders of cards issued by Issuer  130 . This is illustrated in the flowchart of  FIG. 11 . Such sending of transactions details need not be done in real-time, and can be carried out at agreed upon intervals between the merchant and the issuer. 
         [0039]    A second function of the purchase assistance system is to enable merchants  310  to obtain cheaper merchant fees for purchases of low-priced goods carried out by cardholders at the merchant&#39;s online storefront. One way of achieving lower fees is for issuer  130  to refund part or all of its share of the interchange fees to merchants  310  in exchange for obtaining from merchants  310  data elements detailing which products were purchased by whom. Product details relative to goods typically yield interesting personality traits information such as behavior, lifestyle and areas of interest about their purchasers. Such personality traits information can subsequently be used by issuer  130  in an anonymous manner to create cardholder profiles and categories and assist other merchants than merchants  310  to create product offers to cardholders as a function of their profile. Since such assistance to other merchants can be monetized by issuer  130 , it can afford to give up part or all of the interchange fees received from merchants  310 . Using the Purchase Assistant and in particular modules  152 ,  155  and  157  inside the Issuer PA  150  and modules  355  and  357  inside the Merchant purchase unit  350 , the merchant  310  can send to issuer  130  the details of previous transactions relative to purchase by the multiplicity of holders of cards issued by issuer  130 . This is illustrated in the flowchart of  FIG. 11 . Such sending of transactions details need not be done in real-time, and can be carried out at agreed upon intervals between the Merchant and the Issuer. 
         [0040]    A third function of the purchase assistance system is to enable merchants  310  to reduce the financial risk of aggregating small transactions before requesting an amalgamated payment authorization through the card interchange networks of the background art, in particular when the card presented by a purchaser is a debit card rather than a credit card. Using the Purchase Assistant and in particular modules  153  and  155  inside the Issuer PA  150  and modules  353  and  355  inside the Merchant purchase unit  350 , the merchant  310  can send to issuer  130  a request to obtain the current remaining balance in the payment card of a particular named user for whom merchant  310  would like to start an aggregation cycle. Merchant  310  can also optionally request that a certain amount of funds inside the user&#39;s card balance be pre-reserved for its use during a certain period of time. This is illustrated in the flowchart of  FIG. 12 . Such balance checks and funds reservation requests need to be done in real-time. 
         [0041]    A fourth function of the purchase assistance system is to enable merchants  310  to grant special awards to purchasers for certain transactions, where the special awards supersede the default rules that the loyalty program may otherwise allocate. By way of example, the purchase of a given item during a certain period of time may be awarded double the number of loyalty points than usual. Using the Purchase Assistant and in particular modules  155  and  156  inside the Issuer PA  150  and modules  355  and  356  inside the Merchant purchase unit  350 , the merchant  310  can send to issuer  130  a request to grant a number of loyalty points to a particular named user and for a particular transaction for which merchant  310  would like to provide an exceptional reward. This is illustrated in the flowchart of  FIG. 13 . Such sending of loyalty points grant requests need not be done in real-time, and can be carried out at agreed upon intervals between the Merchant and the Issuer. 
         [0042]    A fifth function of the purchase assistance system (that may also be provided by typical systems), is to enable merchants  310  to collaborate more efficiently with the issuer  130  to issue co-branded payment cards, which are cards bearing some distinctive logo or graphics of merchant  310  and carrying some cardholder benefits when used for purchases at such merchant, such as, by way of example, the earning of loyalty points which can be later redeemed against free or discounted goods or services. To make such co-branded cards easier to select and to use when cardholders visit the merchant&#39;s online store, it is customary in the background art for merchants to implement a wallet system, which is a secure repository of the cardholder&#39;s card details, avoiding the need for the cardholder to repeatedly input its card details before a purchase. While populating such merchant wallet system with the details of a new card can always be done manually by the cardholder during his or her first visit to the online store of the merchant, it would be advantageous to enable the automatic provisioning of co-branded cards into the wallet system as soon as the issuer has validly issued such a card to a cardholder. Using the Purchase Assistant and in particular module  154  inside the Issuer PA  150  and module  354  inside the Merchant purchase unit  350 , the issuer  130  can send to merchant  310  the required cardholder and card details information via the data exchange helper protocol  250  if the merchant is suitably equipped with a wallet system. This is illustrated in the flowchart of  FIG. 14 . Such sending of card provisioning requests need not be done in real-time, and can be carried out at agreed upon intervals between the Merchant and the Issuer. 
         [0043]    A sixth function of the purchase assistance system (that may also be provided by typical systems ) is to enable merchants  310  to reduce the risk of transactions repudiations by delegating back to the issuer  130  the task of authenticating online users. Using the Purchase Assistant and in particular modules  155  and  159  inside the Issuer PA  150  and modules  355  and  359  inside the Merchant purchase unit  350 , the merchant  310  can send to issuer  130  a request to authenticate a particular named user with whom the merchant  310  is about to carry out a transaction. This is illustrated in the flowchart of  FIG. 15 . Such delegated user authentication needs to be done in real-time. 
         [0044]    While the foregoing has been with reference to particular embodiments of the system and method, it will be appreciated by those skilled in the art that changes in this embodiment may be made without departing from the principles and spirit of the system and method, the scope of which is defined by the appended claims.