Patent Publication Number: US-2003225691-A1

Title: Method and device for processing an electronic transaction

Description:
[0001] The present invention relates to a method and a device for processing an electronic transaction between a client device and a server device.  
       [0002] More particularly, the invention relates to a method of processing an electronic transaction between a client device and a server device, in which method a third party device is used which serves as intermediary for payment of said transaction.  
       [0003] For example, an intermediary payment device may be used to centralize the processing of the electronic payments implemented during electronic transactions between devices within a distributed computer network.  
       [0004] According to this architecture, the client device makes a payment to the intermediary device, this intermediary device making a payment to a server device at the end of the transaction.  
       [0005] This architecture is particularly advantageous for a server device making few transactions, since it does not directly bear the cost of the processing of the payment by the client device.  
       [0006] A method for carrying out payments using a payment intermediary is know from the document U.S. Pat. No. 6,311,170.  
       [0007] A payment system in accordance with the state of the art and comprising a payment intermediary will now be described with reference to FIG. 1.  
       [0008] More particularly, FIG. 1 represents a client device C, a server device S and an intermediary device P, and the exchange of messages between these different devices during an electronic transaction between the client C and the server S.  
       [0009] In the example described in FIG. 1, it is assumed that the client device C wishes to obtain an image I from the server S, but the mechanism implemented would be equivalent for another type of transaction.  
       [0010] The image I is charged for, but, as described previously, the payment is not carried out directly by the client C in favor of the server S.  
       [0011] On the contrary, the intermediary device P serves as intermediary for payment between the client C and the server S.  
       [0012] Prior to any purchase from the server device P, the client device C transmits a request RTA for transaction authorization to the intermediary device P, this request comprising:  
       [0013] the address S of the server device S;  
       [0014] the identifier I of the image I to be obtained;  
       [0015] a payment sum PS; and  
       [0016] an electronic coin P j (C, P) belonging to the set of electronic coins usable by the client C to make a payment to the intermediary device P.  
       [0017] By this request RTA for transaction authorization, the client device C notifies the intermediary device P:  
       [0018] that it must reply positively to a request from the server device S for the authorization for the delivery of the image I to the client device C; and  
       [0019] that it accepts to pay the payment sum PS to obtain that image I.  
       [0020] After sending the request RTA for transaction authorization, the client device C sends the server device S a request RTI for transaction initiation, this request comprising the identifier I of the image I to be obtained.  
       [0021] On receiving the request RTI for transaction initiation, the server device S sends the intermediary device a request RAD for authorization to deliver the image I to the client device C.  
       [0022] This request RAD for authorization to deliver comprises:  
       [0023] the identifier I of the image I requested by the client device C; and  
       [0024] the payment sum PS I  requested by the server device S to supply the image I to the client device C.  
       [0025] On reception of this request RAD for authorization to deliver, the intermediary device P verifies whether it has received a request RTA for transaction authorization from the client device C to obtain the image I.  
       [0026] If so, the intermediary device P sends a transaction validity message TVM to the server device S, this transaction validity message TVM comprising a coin P k (P, S) belonging to the set of electronic coins usable by the intermediary device P to pay the server device S to settle the sum PS I .  
       [0027] On reception of the transaction validity message TVM, the server S verifies the validity of the payment received from the intermediary device P at the preceding step, and transmits the image I to the client device C when this payment is validated.  
       [0028] The mechanism described in FIG. 1 nevertheless poses a problem when the transaction is not carried out after the payment by the client device C to the intermediary device P. This may be the case if the server device S has broken down or, more generally, is not available, or if the user of the client device C decides not to go through with the transaction, for example.  
       [0029] The present invention enables this problem to be solved by enabling the transaction to be cancelled by the intermediary device S.  
       [0030] The present invention relates more particularly to a method of processing an electronic transaction between a client device and a server device in a communication network. This method is implemented within an intermediary device of the communication network and it comprises the following steps:  
       [0031] receiving a request for transaction authorization from the client device, this authorization request comprising a first payment sum;  
       [0032] detecting a failure of the transaction between the server device and the client device; and  
       [0033] sending a message for canceling the transaction to the client device when the failure is detected, this message for canceling the transaction comprising a sum for reimbursement by the intermediary device in favor of the client device.  
       [0034] Thus, if the intermediary device detects that the transaction is not being correctly made, it sends a message of cancellation of the transaction to the client device. This may in particular occur when the server device is not available, or if the network is overloaded.  
       [0035] This canceling message is accompanied by a reimbursement by the intermediary device in favor of the client device.  
       [0036] In a preferred embodiment, the reimbursement sum is at most equal to the payment sum paid by the client device in favor of the intermediary device.  
       [0037] According to a first feature, the detection step comprises a step of receiving a request for cancellation from the client device (C).  
       [0038] According to this first feature, the user of the client device may deliberately cancel the transaction, by sending a cancellation request to the intermediary device which, on reception of this request, notes the cancellation of the transaction.  
       [0039] Preferentially, the failure of the transaction is detected when a period at least equal to a predetermined period has passed between the reception of the request for transaction authorization and the reception of the cancellation request.  
       [0040] In a particular embodiment, the detection step comprises an attempt to set up a communication with the server device.  
       [0041] Thus, if the server device is not reachable, for example, when the server device is down, or when the communication network is overloaded, the intermediary device detects the failure of the transaction and reimburses the client device.  
       [0042] According to a preferred feature of this embodiment, the failure of the transaction is detected when the attempt to set up communication fails for a period at least equal to a predetermined period.  
       [0043] This feature makes it possible to avoid the cancellation of the transaction in case of a temporary difficulty to reach the server device, for example in case of transient congestion of the communication network.  
       [0044] According to another preferred embodiment, the method further comprises, prior to the detection step, a step of receiving, from the server device, a request for authorization to deliver comprising a second payment sum.  
       [0045] In this preferred embodiment, the failure of the transaction is detected if the second payment sum is greater than the first payment sum.  
       [0046] Thus, the intermediary device checks that the sum received by the server device for making the transaction, is less than the first payment sum paid by the client device in favor of the intermediary device.  
       [0047] In a complementary manner, the invention relates to a device for processing an electronic transaction between a client device and a server device in a communication network. This processing device may be incorporated in an intermediary device of the communication network and comprises:  
       [0048] means for receiving a request for transaction authorization from the client device, the authorization request comprising a first payment sum;  
       [0049] means for detecting a failure of this transaction between the server device and the client device;  
       [0050] means for sending a message of cancellation of that transaction to the client device when the failure is detected, this message of cancellation of the transaction comprising a sum for reimbursement by the intermediary device in favor of the client device.  
       [0051] The invention also relates to an intermediary device comprising means adapted to implement a processing method as briefly described above.  
       [0052] The invention also relates to an intermediary device comprising a processing device as described briefly above.  
       [0053] The invention also relates to an electronic transaction system in a communications network comprising an intermediary device as briefly described above.  
       [0054] The invention also relates to an information carrier readable by a computer system, possibly wholly or partly removable, in particular a CD-ROM or magnetic medium, such as a hard disk or a diskette, or a transmissible medium, such as an electrical or optical signal, and comprising instructions of a computer program enabling the implementation of a processing method as briefly described above, when this program is loaded and run by a computer system.  
       [0055] The invention also relates to a computer program stored on an information carrier, said program comprising instructions enabling the implementation of a processing method as briefly described above when this program is loaded and executed by a computer system.  
       [0056] Since the particular advantages and features of the processing devices, intermediary devices, electronic transaction system, information carrier and of the computer program are the same as those set out above concerning the processing method according to the invention, they will not be repeated here. 
     
    
    
     [0057] Other features and advantages of the present invention will appear more clearly on reading the description of the specific embodiments which follow, this description being given solely by way of non-limiting example and made with reference to the accompanying drawings in which:  
     [0058]FIG. 1, already described, represents a payment system comprising a payment intermediary in accordance with the state of the art;  
     [0059]FIG. 2 represents, in the form of a flowchart, the main steps implemented by a client device during a transaction, in accordance with the present invention;  
     [0060]FIG. 3 represents, in the form of a flowchart, the processing of a request for transaction initiation by a server device in accordance with the present invention;  
     [0061]FIG. 4 represents, in the form of a flowchart, the processing of a request for transaction authorization by an intermediary device in accordance with the present invention;  
     [0062]FIG. 5 represents, in the form of a flowchart, the processing of a request RAD for authorization to deliver by an intermediary device in accordance with the present invention;  
     [0063]FIG. 6 represents, in the form of a flowchart, the main steps of processing a cancellation request, in accordance with the present invention;  
     [0064]FIG. 7 is an overall representation of the exchange of messages and requests between an intermediary payment device and a server device during an electronic transaction, in accordance with the present invention; and  
     [0065]FIG. 8 is a diagram of an intermediary payment device adapted to implement a processing method according to the present invention, in a preferred embodiment. 
    
    
     [0066]FIG. 2 represents the main steps S 200  to S 250  implemented by a client device C during a transaction in accordance with the present invention.  
     [0067] In the preferred embodiment described here, the payments are made by means of the PayWord system that Rivest and Shamir have proposed.  
     [0068] A description of this system can be consulted at the Internet address http:/theory.Ics.mit.edu/˜rivest/RivestShamir-mpay.ps.  
     [0069] Generally, this system consists in recursively generating, from a random number P n  and a hash function h, a series of electronic coins P n , P n-1 , . . . , P 0  by the formula P n-1 =h(P n ).  
     [0070] This hash function has the particularity of not being reversible, such that it is impossible in practice to find the previous number P n  from a number P n-1 .  
     [0071] The end P 0  of the chain thus obtained is known as the root coin and makes it possible to verify the authenticity of the other coins.  
     [0072] In the description that follows the notation P(M, N) will be adopted to designate the series of coins used by a device M to make a payment to a device N.  
     [0073] For example, according to this notation, the series of electronic coins P(C, P) is a series of coins used by the client device C to make a payment to an intermediary device P.  
     [0074] During the first step S 200  the client device C sends a request RTA for transaction authorization to the intermediary device P.  
     [0075] As already described, this request RTA for transaction authorization comprises:  
     [0076] the address S of the server device S;  
     [0077] the identifier I of the image I to be obtained;  
     [0078] a payment sum PS; and  
     [0079] an electronic coin P j  (C, P) belonging to the set of electronic coins P(C, P) usable by the client to make a payment to the intermediary device P.  
     [0080] In the embodiment based on the payment system PayWord, this electronic coin P j (C, P) is such that all the coins of index strictly less than j of the set of coins P(C, P) have already been validated for earlier payments by the intermediary device P.  
     [0081] Step S 200  is followed by a step S 205  during which the client device C sends a request RTI for transaction initiation to the server device S.  
     [0082] This request RTI for transaction initiation comprises the identifier I of the image to be obtained.  
     [0083] Step S 205  is followed by a test S 210  during which the client device C verifies if it has received the image I from the server device S in reply to the request RTI for transaction initiation sent at step S 205 .  
     [0084] If this is the case, the result of the test S 210  is positive. This test then terminates the procedure implemented by the client device C to perform a transaction with the server device S according to the invention.  
     [0085] On the other hand, if the client device C has not received the image I from the server device S the result of test S 210  is negative.  
     [0086] This test is then followed by a test S 220  during which the client device C verifies whether, since the transmission of the request RTI for transaction initiation, the period TR_MAX has run out.  
     [0087] This constant TR_MAX is stored in a register of a non-volatile ROM memory of the client device C.  
     [0088] If this is the case, the result of the test S 220  is positive. This test is then followed by a step S 230  during which the client device C sends a cancellation request CR to the intermediary device P.  
     [0089] The processing of the cancellation request CR by the intermediary device P will be described later with reference to FIG. 6.  
     [0090] Whatever the case, following the transmission of the cancellation request CR to the intermediary device P, the client device awaits a response to the cancellation request CR sent to the intermediary device P at step S 230 . This response may be:  
     [0091] either a reimbursement (cancellation accepted);  
     [0092] or a notification of rejection of the cancellation request CR.  
     [0093] Step S 230  is followed by a test S 235  during which the client device C verifies whether the cancellation request CR has been accepted by the intermediary device P.  
     [0094] If this is not the case, the result of the test S 235  is negative. This test is then followed by the test S 210  already described.  
     [0095] Returning to test S 220 , it the period TR_MAX has not run out since the sending of the request RTI for transaction initiation, the result of this test is negative.  
     [0096] This test is then followed by a test S 225  during which the client device C verifies whether the user of the client device C has explicitly requested an interruption of the transaction.  
     [0097] If this is the case, the result of the test S 225  is positive. This test is then followed by step S 230  of sending the cancellation request CR to the intermediary device P already described.  
     [0098] On the other hand, if the user of the client device C has not explicitly interrupted the transaction, the result of test S 225  is negative. This test is then followed by the test S 210  already described.  
     [0099] Steps S 210 , S 220 , S 225 , S 230 , and S 235  thus constitute a loop whose execution terminates:  
     [0100] either when the result of test S 210  is positive, which occurs when the client device C has received the image I in response to the request RTI for transaction initiation sent at step S 205 ;  
     [0101] or because the maximum period TR_MAX has gun out since the sending of the request RTI for transaction initiation;  
     [0102] or by deliberate interruption of the transaction by the user.  
     [0103] In these last two cases, and as already described with reference to step S 230 , a cancellation request CR is sent to the intermediary device P.  
     [0104] When the intermediary device P sends a response to the cancellation request CR representing the acceptance of that cancellation, the result of test S 235  is positive.  
     [0105] This test is then followed by a test S 240  during which the client device C verifies whether the reimbursement received from the intermediary device P is valid.  
     [0106] In the preferred embodiment described here, this reimbursement is carried out by means of electronic coins P(P, C) in accordance with the payment system PayWord.  
     [0107] If the reimbursement is valid, the result of the test S 240  is positive. This test is then followed by a step S 245  during which the client device C pays the reimbursement into its account.  
     [0108] On the other hand, if the reimbursement is not valid, the result of test S 240  is negative. This test is then followed by a step S 250  of notifying an error to the user of client device C.  
     [0109] Whatever the case, steps S 245  and S 250  terminate the transaction procedure in accordance with the present invention.  
     [0110]FIG. 3 represents the main steps S 300  to S 350  of processing a request RTI for transaction initiation by a server device S, in accordance with the present invention;  
     [0111] During the first step S 300 , the server device S receives a request RTI for transaction initiation from the client device C to obtain an image I.  
     [0112] On reception of that request RTI for transaction initiation, the server device S sends, during a step S 310 , a request RAD for authorization to deliver to the intermediary device P.  
     [0113] As already described, this request RAD for authorization to deliver comprises the identifier I of the image I requested and the payment sum PS I  requested by the server device S to supply the image I to the client device C.  
     [0114] That step S 310  is followed by a step S 320  during which the server device S receives a transaction validation message TVM, this message comprising an item of information according to which authorization to deliver the image I is granted or not by the intermediary device P.  
     [0115] The sending of this transaction validation message TVM will be described later with reference to FIG. 5.  
     [0116] Step S 320  is followed by a test S 330  during which the server device S verifies whether that authorization has been granted.  
     [0117] If this is the case, the result of the test S 330  is positive. This test is then followed by a step S 340  during which the server device S transmits the image I to the client device C.  
     [0118] On the other hand, if the authorization is not granted by the intermediary device P, the result of the test S 330  is negative.  
     [0119] This test is then followed by a step S 350  of notifying a transaction error to the client device C.  
     [0120] Steps S 340  and S 340  terminate the procedure of processing a request RTI for transaction initiation according to the present invention.  
     [0121]FIG. 4 represents the main steps S 400  to S 450  of procedure for processing a request RTA for transaction authorization by an intermediary device P in accordance with the present invention;  
     [0122] During the first step S 400 , the intermediary device P receives the request RTA for transaction authorization from the client device C.  
     [0123] The sending of this request RTA for transaction authorization has already been described with reference to step S 200  of FIG. 2.  
     [0124] This step S 400  of receiving a request RTA for transaction authorization is followed by a step S 410  during which the intermediary device P verifies the validity of the payment associated with the request RTA for transaction authorization.  
     [0125] This verification is performed, in the preferred embodiment described here, by verifying whether the electronic coin P j (C, P) contained in the request RTA for transaction authorization enables a payment of sum PS to be made, this sum being also included in the request RTA for transaction authorization.  
     [0126] If the payment is valid, the result of the test S 410  is positive. This test is then followed by a step S 420  during which the intermediary device P pays into its own account the payment sum PS contained in the request RTA for transaction authorization.  
     [0127] Step S 420  is followed by a step S 440  during which the intermediary device P stores an item of information A(C, S) according to which the client device C authorizes the intermediary device P to reply positively to a request RAD for authorization to deliver from the server device S to deliver the image I and for a payment sum PS.  
     [0128] In the embodiment described here, the item of information A(C, S) explicitly comprises the payment sum PS and the identifier I of the image I to obtain.  
     [0129] On the other hand, if the payment associated with the request RTA for transaction authorization is not validated, the result of test S 410  is negative. This test is then followed by a step S 450  during which the intermediary device P notifies the client device P of an error.  
     [0130] Whatever the case, the steps S 440  and S 450  terminate the procedure of processing a request RTA for transaction authorization according to the present invention.  
     [0131]FIG. 5 represents the main steps S 500  to S 580  of a procedure for processing, by the intermediary device P, of a request RAD for authorization to deliver from the server device S.  
     [0132] During a first step S 500 , the intermediary device P receives a request RAD for authorization to deliver sent by the server device S at step S 310  as described earlier with reference to FIG. 3.  
     [0133] Step S 500  of receiving a request RAD for authorization to deliver is followed by a step S 510  during which the intermediary device P verifies whether it has received an authorization from the client device C for the delivery of an image I to the server device S, by comparing the identifier I read in the request RAD for authorization to deliver with the image identifier stored in the item of information A(C, S) during step S 440  already described.  
     [0134] In practice, this test consists of reading whether the register of the non-volatile memory A(C, S) has been updated in accordance with step S 440  described earlier.  
     [0135] If such an authorization has not been given, the result of test S 510  is negative. This test is then followed by a step S 550  during which the intermediary device P notifies the server device S that the client has not authorized the intermediary device P to accept that transaction.  
     [0136] On the other hand, if such an authorization has been given, the result of test S 510  is positive.  
     [0137] This test is then followed by a test S 520  during which the intermediary device P verifies whether the payment sum PS stored in the item of information A(C, S) at step S 440  on reception of the request RTA for transaction authorization is greater than or equal to the payment sum PS I  included in the request RAD for authorization to deliver received at step S 500 .  
     [0138] If this is not the case, it means that the server device S demands a sum PS I  greater than the sum PS paid by the client device C in favor of the intermediary device P. In this case, the result of the test S 520  is negative.  
     [0139] This test is then followed by a step S 570  during which the intermediary device P cancels the authorization received from the client device C at step S 400 .  
     [0140] In practice, this amounts to storing the value  0  in the register A(C, S).  
     [0141] Step S 570  of canceling the authorization is followed by a step S 580  during which the intermediary device P reimburses the client device C by means of electronic coins P(P, C).  
     [0142] In practice, this reimbursement is carried out by the sending of a message TC of transaction cancellation to the client device C.  
     [0143] In the preferred embodiment described here, the reimbursement sum is less than the payment sum PS received in the request RTA for transaction authorization received at step S 400  already described.  
     [0144] Step S 580  is followed by the previously described notification step S 550 .  
     [0145] On the other hand, if the sum PS I  demanded by the server device S is less than or equal to the sum PS that the client has paid for the transaction, the result of test S 520  is positive.  
     [0146] This test is then followed by a step S 530  during which the intermediary device P stores in memory the fact that the authorization for the transaction has been given to the server device S.  
     [0147] In practice, this amounts to storing the value  0  in the register A(C, S).  
     [0148] This memorization step S 530  is followed by a step S 540  of the payment by the intermediary device P of the sum PS I  to the server device S, by means of electronic coins P(P, S).  
     [0149] Step S 540  of payment of the server device S is followed by a step S 560  during which the intermediary device P sends the server device S a transaction validation message TVM, this message TVM comprising an item of information representing the acceptance of the transaction.  
     [0150] The steps S 550  of notifying the server S, and S 560  of sending the server S the transaction validation message TVM terminate the procedure of processing a request RAD for authorization to deliver according to the invention.  
     [0151]FIG. 6 represents the main steps S 600  to S 640  of processing a request CR for cancellation by the intermediary device P.  
     [0152] During the first step S 600 , the intermediary device P receives the cancellation requests CR sent by the client device at step S 230  already described.  
     [0153] This cancellation request CR is sent either when the period TR_MAX has run since the sending of the request RTI for transaction initiation, this request having remained without any response (result of test S 220  positive), or deliberate interruption by the user (result of test S 225  positive).  
     [0154] Step S 600  is followed by a test S 610  during which the intermediary device verifies whether that cancellation is acceptable.  
     [0155] In a first variant embodiment, a cancellation request is acceptable if a predetermined period has passed since the reception of the request RTA for transaction authorization, in accordance with step S 400  just described.  
     [0156] In a second variant embodiment, that cancellation request CR is acceptable if the server device S cannot be reached, in the case of a breakdown or a network problem for example.  
     [0157] In this variant embodiment, during the test S 610  of verifying the acceptability of the cancellation, the intermediary device P carries out an attempt at connection with the server device S to verify whether it actually is unreachable.  
     [0158] Whatever the case, when the intermediary device P considers that the cancellation request CR is acceptable, the result of the test S 610  is positive.  
     [0159] In that case, test S 610  is followed by a step S 620  during which the intermediary device P cancels the authorization received from the client device C at step S 400 , then by a step S 630  for reimbursing the client device C.  
     [0160] In the preferred embodiment described here, steps S 620  and S 630  are similar to steps E 570  and E 580  already described with reference to FIG. 5.  
     [0161] Authorization cancellation step S 620  is followed by a step S 630  during which the intermediary P reimburses the client device C by means of electronic coins P(P, C) for a sum less than or equal to the payment sum PS received in the request RTA for transaction authorization at step S 400  already described.  
     [0162] In a preferred embodiment, the reimbursement sum is strictly less than the payment sum PS received in the authorization request RTA, the difference between these sums being used to remunerate the intermediary device P.  
     [0163] On the other hand, if the intermediary device P considers that the cancellation request CR received at step  5600  is not acceptable, the result of test S 610  is negative. This test is then followed by a step S 640  of notifying the client device C of the rejection of the cancellation request CR.  
     [0164] Whatever the case, the steps S 630  of reimbursement and S 640  of rejection notification terminate the procedure of processing a cancellation request CR according to the present invention.  
     [0165]FIG. 7 is an overall representation of the exchange of messages and requests between a client device C, server device S, and an intermediary device P during an electronic transaction between the client C and the server S, in accordance with the present invention.  
     [0166]FIG. 8 is a diagram of an intermediary payment device adapted to implement a processing method according to the present invention, in a preferred embodiment.  
     [0167] This intermediary device may in particular be constituted by a computer.  
     [0168] In the example embodiment described here, the intermediary payment device comprises a communication card  807  to connect the intermediary device to a communication network, a keyboard  810 , and a screen  809 , connected to an input/output port  803  of a processing card  801 .  
     [0169] The processing card  801  comprises, connected together by an address and data bus  802 :  
     [0170] a central processing unit  800 ;  
     [0171] a random access memory RAM  804 ;  
     [0172] a read only memory ROM  805 ;  
     [0173] a non-volatile memory FLASH  806  and  
     [0174] the input/output port  803 .  
     [0175] Each of the elements illustrated in FIG. 8 is well known to a person skilled in the art of microcomputers and, more generally, of information processing systems. These common elements are therefore not described here.  
     [0176] The random access memory  804  comprises in particular:  
     [0177] A register REQUEST for storing any type of request received from the client device or from the server device, that is to say in particular, a request RTA for transaction authorization, a request RAD for authorization to deliver, and a cancellation request CR.  
     [0178] a register MESSAGE to store, prior to them being sent, the messages destined for the client device and for the server device and in particular the messages of transaction validity TVM and of transaction cancellation TC.  
     [0179] The non-volatile memory FLASH  806  comprises registers to store, in accordance with the payment system PayWord, the root coin P 0  and the last coin P j  validly received for the series of coins P(C, P), P(P, C) and P(P, S), respectively used for:  
     [0180] the payments made by the client device C in favor of the intermediary device P;  
     [0181] the reimbursements made by the intermediary device P in favor of the client device C in case of cancellation of the transaction, and  
     [0182] the payments made by the intermediary device P in favor of the server device S in case of cancellation of the transaction.  
     [0183] The non-volatile memory FLASH  806  also comprises a register A(C, S) for storing the information A(C, S) according to which the client device C authorizes the intermediary device P to reply positively to a request RAD for authorization to deliver coming from the server device S.  
     [0184] The read only memory  805  is adapted to store the operating program of the central processing unit  800 . It comprises in particular a register “Program” to store the instructions of a program implementing a processing method according to the invention, as described earlier with reference to the flow diagram of FIGS.  2  to  6 .  
     [0185] The processing device comprises conventional communication means known to the person skilled in the art, adapted to communicate, by means of requests and messages with other devices of the communication network.  
     [0186] These communication means are in particular constituted by the communication card  807  and portions of computer code stored in the read-only memory ROM  805  implementing the conventional protocol layers such as TCP/IP.  
     [0187] Whatever the case, these communication means constitute receiving means adapted to receive a request RTA for transaction authorization, a request RAD for authorization to deliver and a cancellation request CR as described earlier, as well as means for sending a transaction cancellation message TC to the client device C when the failure is detected.  
     [0188] The communication means are in particular adapted to recognize the type of a request received and to extract from it the different fields.  
     [0189] The processing device comprises means for detecting a failure of the transaction between the server device S and the client device C. In the preferred embodiment described here, these detection means cooperate with a clock, not shown here, and are adapted to calculate a period that has passed between the reception of a request for transaction authorization and the reception of a cancellation request CR.  
     [0190] These detection means comprise means for setting up a communication with the server device S. In the preferred embodiment, the means for setting up the communication use the services of protocol layers defined above, for example the function PING known to the person skilled in the art.  
     [0191] More particularly, the means for setting up a communication are adapted to attempt to set up a communication with the server for a predetermined period, and to generate a signal if the communication cannot be set up during the said period.  
     [0192] The detection means are also adapted to detect the failure of the transaction if the second payment sum read in the request RAD for authorization to deliver is greater than the first payment sum PS read in the request RTA for transaction authorization.