Note: Descriptions are shown in the official language in which they were submitted.
j CA 02217739 1997-10-08
ELECTRONIC PAYMENT MET~OD FOR PnR~A~F.-RFT.ATFn TRAN~ACTIONS OVER A
COMPUTER N~l~UKK
The present invention concerns an electronic payment method enabling
5 transactions to be carried out relating to the purchase of "goods" offered by
suppliers by means of on-line services via a public co~ ulei telec~.l....l...ir~tinn
nGlwulh to which are ~ttache(l suppliers' seners and clients' stations. Here, "public
colll~lllel teleco.l....l..)ir~tion nGlwolhl' is intenflP~ to mean a network to which
persons or co...p~.-ies can freely connect themselves so long as they have an
lû address, for example the "Tlll~ t". "Goods" is intPn-lP(l to mean products orservices, which are delivered outside the network after the transaction has beenconcluded, as well as non-m~tçri~l goods, such as information, which can be
delivered via the co~ ulGr network.
Various electronic payment methods have been proposed, and some are
15 already operational.
Several methods are based on a new form of currency. They involve an
electronic reprçsçnt~ti~>n~ sometimes called a "token", which can be purely
embodied in software or can be partly physical, for example a "smart card". T~hese
methods neces~il;.~e circulation of the ~;UllGllCy on the colllpulGr network, which
20 plcselll~ difficult security problems regarding the creation of false CU11G11~;Y.
Other known electronic payment methods ~ece~ le a direct relation with
a bank or a banking network. These are typified by methods used in the credit
card ll~,Lw~Jl~; such as well-hnown methods ~ltili7.ing point-of-sale tçnnin~l~
linked to a bank card circuit as well as methods employing electronic cheques
25 using an electronic signature to ~lthpnficate the purchaser. This is a form of
engagement letter issued by a purchaser, returned to the seller and accepted andrecognised by a bank.
There are certain inconveniences associated with methods which
n~c~s~ilalt;, at one time or another during a transaction, a relationship with a30 traditional banking system and the effecting of a transaction in such a system.
R~nkin~ system transactions have a real cost which becomes prohibitive when the
amount of the purchase is very low, for example, an amount based on a query to adata base. And computer nGLwolhs are well adapted to the sale of low-priced
goods, in particular informational goods, since the delivery can be carried out
35 through the network itself. Moreover, access to a banking network or a bank card
network must have high levels of security, which, in practical terms, excludes the
_
~ CA 02217739 1997-10-08
-
possibility of access through a public co~ ult;r llelwolh, sueh as the ~r..~ , to
which potential purchasers can connect themselves.
An object of the invention is to provide a method which avoids the
problems of the known methods - in particular, a method p~....;lli..g a simple and
5 reliable way of accomplishing transactions relating to the purchase of goods on a
CO~ e~ lwolh, without the need to circulate electronic cullcncy~ for goods of
high price req 1irinp~ ~llt~ riC~tion from a traditional banking system, as well as for
goods of low to very-low price.
The object is achieved by a method of the type defined at the begi..~ of
10 the present ~esc~iption and COlll~ lg, according to the invention, the steps of:
-creation, by the server of a supplier connected to the llt;lwulh, of a
tr~n~ction authorisation request or "payment ticket", conceming a pulcllase
envisaged between the supplier and a customer, and ~;o...~,. ;~;.1~ information
relating to the supplier, the customer, the purchased object and the price;
-~ c~ si~n of the payment ticket via the colllpuler network to a payment
server which is distinct from the customer station and the supplier server,
-automatic verifir~tion by the payment server of whether the payment of
the price is authorised for the customer involved, the v~rifir~tion being effected,
according to the level of the price to be paid, either by interrogation of an ~Ccol~nt
20 of the customer, held by the payment server and int~.n~led for payment of smaller
sums, or by interrogation on a banking network, inflepen-lent of the colllpul~
network, for payment of higher sums;
-if the verification is positive, creation by the payment server of a
transaction authorisation or voucher including at least part of the payment ticket
25 inforrn~tion; and
sion of the voucher to the supplier server via the colll~ult;
network, to authorise the conclusion of the purchase.
Thus, the procedure according to the invention is nott;~o,lhy in that it
nrc~csil~e~ neither the creation of electronic currency nor the circ~ tion of
30 electronic currency over the colllpul~l network.
The control of the transactions is effected by a payment server which alone
can access a banking network or a bank card nelwolk, and which m~n~ges non-
bank c~-.ctomer accounts from which small sum transactions can be effected.
The payment server also manages non-bank supplier accounts used for
35 small sum ~ cl ;ons. In this way, when a voucher is tr~ncmittecl after
verification by interrogation of a customer account held by the payment server, the
CA 02217739 1997-10-08
amount of the purchase is debited from the customer account and credited to the
account of the co~.r~ d supplier and held by the payment sener, a procedure
which does not produce high procescinp~ costs.
Each customer has available his own identity to enable use of the payment
5 method. He must also have available a real bank account, plGfGl~bly one which
can be operated by means of traditional bank cards. The verification by the
payment server can include a preliminary phase of validating the identity of thecustomer from the CO11lG11lS of the payment ticket. The identity validation precedes
access to the customer account (if the sum of the ~u~ ce is low) or access to the
10 bank network (if the amount involved in the yul~;llase is higher). The paylllclll
server preferably includes means, for example a data base, for storing the
relationship between the customer identities used for tr~nc~ctions on the Co~ ulGi
network and the bank identities (bank account or credit card numbers) used for
transactions on the bank ~lGlwu~h. In that way, the circulation of banking i~ientiti~c
15 on the Co...yulG. ~elwc ~h can be avoided.
An implementation of the invention will now be described, as a non-
limitin~ example, with reference to the accompd~ying drawings, in which:
-Figure 1 is a general sc-h~m~tic view of an electronic ydylllG..l system
accol~lh.g to the invention;
-Figure 2 is a lepl~s~ ion in the form of a block sr~ c ~ grAm of a
payment server of the system of Figure 1;
-Figure 3 illustrates the progression of operations relating to a purchase
using the system of Figure 1; and
Figures 4A to 4C are flow charts showing srhem~tically the operations
carried out by the payment server.
Figure 1 lGylGse~ sr-hrln~tically a co,,lyulel telec(l.-.. ication nGlwo-h
10 to which are connected supplier servers 20, customer stations 30 and at leastone payment server 40.
The COI11YUlG1 llelwolh 10 is an open or public network, for example the
30 network known as the "r..le~ t". The supplier servers 20 are units such as those
currently used for on-line services connrctecl to the rnt~rnet, for example, units
o,~ i.ce~l around UNIX-based multi-processor m~rhines. The customer st~ti~mc
30 are basically microcomp.lle.~ which are provided with means for connecting tothe Tnternrt network 10, for example, in the form of a "Web" interface. The
35 supplier servers 20 and the customer stations 30 may use, for example, known
CA 02217739 1997-10-08
software protocols commonly known ~ the "World Wide Web" ("WWW")
employing the HITP protocol.
The payment server 40, shown in more detail in Figure 2, comprises front
and rear units l~s~e.;lively 41 and 42 both connected to the Tnt--rnet 10. The front
5 unit 41 has an ar hitcçt--re similar to that of a standard server conn~cte~l to a
network such as the rntçrn~t The rear unit 42 in~ltlcles a proc~ssing unit 43
co~ .i"i"g one or more processors, a data base 44 cn,,~ information relatingto the suppliers and customers subscribing to the payment system, a tr~n~ction
register 45, an intc.rf~re unit 46 for connectin~ with a banhing ll~lw~Jlh or with a
10 bank card network 50, and a communication bus 47 or similar other link enabling
connection between the dirr~G~lL con~tituçnt parts of the unit. A secure connection
48 enables bi-directional communication between the front unit 41 and the
plocessi~g unit 43. Colll,,,unication with the network 10 is controlled by the front
unit 41 while m~n~gement of the data base 44 as well as the control of the
15 col~ tion with the banking ll~ilwulh are assured by the rear unit 42.
The data base 44 colll~i"s information relating to the customers and to the
suppliers who have subscribed to the payment system. For each customer, the database 44 CO~t~illS the system identity ("CId") ~ ign~rl when the customer initially
subscribes to the system, a customer account or electronic wallet ("PME") for
20 payment of small sums, a banking identity such ~ an account number of a real
account or a credit card number, possibly as well as the customer's own access
p~~wo,.l or "key". For each supplier, the data base 44 colll~ s the system identity
of the supplier/merchant ("MId"), which is a~.~igne(1 when the supplier initially
subscribes to the system, a supplier account, or electronic cash register (' l ~ ) for
25 receipt of small sums and a banking identity such as a bank account number.
Figure 3 shows schematically the dirrt;~t;lll stages of a transaction relating
to the purchase of goods by a subscribing customer from a subscribing supplier. It
can be a case of m~tçrizll goods, for which delivery to the customer will take place
after conclusion of the tr~n~action, or non-m~tçri~l goods (such ~ information)
30 which can be provided to the customer over the co",pult;r network as soon as
electronic payment has been effected.
(1) Consultation by the customer
After connl-cting to the Internet 10, a customer can consult the catalogue or
"window" of any supplier on-line by ~ccç~ing the supplier's server 20 and
35 viewing the supplier's wares on the screen of the customer station 30. On
pl~sç.~ tion of the customer's system identity CId, the supplier's server 20 can
CA 02217739 1997-10-08
present to the customer particular ~ l conditions (for example a discount)
applicable tQ the potential tr~n~ction.
(2) Purchase demand
Once the customer has chosen a commodity (object) O, his choice is
5 ~ to the supplier's server in the fomm of a message col.l;.i"il~ an identity
OId of the commodity and the identity CId of the customer. When nr~s~ry, for
example, for the eventual delivery of the commodity chosen, the supplier's server
can request supplementary i~r(J~ lion such as an address arld ~lGr~ ;id deliverytime. This may co~ .liently be done through use of an electronic fomm sent over
10 the network to be filled in by the customer.
When the purchase envisaged represents a large sum or is subjected to legal
conditions, a prelimin~ry ~l~thPntication of the customer may be desired. As will
be seen in detail in the following, the ~nthrntication of a customer is effected by
the payment server 40. Also, the ~uthelttication clem~n~l coming from a supplier is
15 advantageously issued in the fomm of a payment ticket of no value which is
h...~ l to the payment server over the colll~ l network via the ~;u~rlolllel
station and, in the case of ~osilive ~ttthl~ntication~ provokes the retum of a voucher
from the payment server to the supplier server, always by way of the customer
station. The procedure for the establisl.llle.l~ of a payment ticket and for the20 lr~lll ip of a voucher are described in greater detail in the following.
The pulcllase d~-nn tn~l issued by the customer can relate to a single
commodity or to several goods to be provided as a group "basket purchase".
(3) Development of the payment demand
In response to a pulcllase deTn tn-l, the supplier server develops a payment
dcnn~ntl~ which can include the following infommation:
-Identity of the supplier ("MId");
-Description of the commodity ordered, or, in the case of grouped
purchases, each of the goods in the basket;
-Type of tr~n~ction (single or basket);
-Identity of the customer ("CId");
-Identity of the commodity or collection of goods of the basket ("OId");
-Price of the commodity ("Oid");
-Value Added Tax, VAT, (if applicable),
-Date and time of the issue of the payment ticket (hour and date ~lall.pillg
by the supplier server);
-Period of validity of the payment ticket; and
CA 02217739 1997-10-08
-Serial number in the sales register of the supplier (particularly in the case
when the l.~ l;on has inrlllderl a preli...i~-,..y ~thl-ntication stage).
The combination of the above infonn~til-n is coded as a series of bytes
which are ~~ hled in the hidden ch~nnel of a payment ticket (or URL of an order
S of a commodity, URL being the initials of "Uniform Resource Locator" used in
WWW software with the HITP protocol), as follows:
URL http:<SP>cdesc . ;l,lion of the ordeD,
where SP is the ~..I~...~t address of the payment server. The payment ticket is
addressed to the customer station. It is completed by two logical "anchors" which
10 enable the customer either to cancel or to confirm.
(4) Sending the payment order
The payment order is ~ d to the payment server simply by
validation by the customer of the URL of the payment order. As will be
appre~ te~l, the payment ticket only passes in transit through the customer station.
(5) Issue of the voucher
Upon reception of a payment order, the payment server 40 ~lec~es the
payment order, ~uth~nticates the customer and invçstig;~tes whether the pdyllltllt
can be ~uthori~e~l before rGllll..i..g either a voucher or a payment refusal. The
c~lol~cl ~llth~ntir~ti~n and payment ~lth~ri~tion operations will be described in
greater detail with reference to Figure 4.
When the verification process does not permit authorisation of payment, an
explanatory refusal notification (referring, for example, to insufficient funds in the
account, to the passing of a limit authorised for the customer, etc.) is sent to the
customer by the payment server. When the veri~lcation does permit ~lthori~tion
of payment, the information cont~inecl in the payment ticket is completed with aseAal number in the llallsa~;lion register 45, a time stamp, a validity time limit
(typically some tens of seconds) and the seal of the payment server co~ l;--g
certification information. The combination of this information, possibly after
being digitally signed through use of a private key portion of a public key/private
key encly~lion system belonging to the payment server (which ensures the validity
and the integrity of the payment authorisation) is encoded in a series of bytes
which cn- -~ the hidden ch~nn~l of a voucher or delivery URL:
URL http:<M><description of the voucheD,
where M is the rntçrn~t address of the supplier.
(6) Delivery request
CA 02217739 1997-10-08
The voucher is ~ cl to the supplier server via the customer station.
This can be efl~ected auloll~tir~lly by the software installed in the r~-st-)mer station
using the re-routing possibility of the URL-s, well-known to those skilled in the art
to which the invention pertains. The supplier server decodes and verifies the
5 lGc~ivt;d voucher before ~llfhori~in~ delivery of the commodity. This veriffcation
includes using the private key of the payment server, v~liryhlg that the validity
time limit has not passed and co~p.~ the co..~r~ of the voucher w*h the
payllle.~l cleSn~n-l
(7) Delivery of the commodity
When the voucher has been validated by the supplier server, this server can
effect delivery directly to the customer station, in the case where the commodity
being purchased is inform~tion, or address to the customer station a document
permitting the collection of the commodity and, notably, specifying the place ofdelivery and the name of the recipient.
It will be noted that, in the case of a grouped or basket purchase, the
supplier server creates an object with allocation of a unique identity, a list of the
U~Ls of each of the goods contained in the basket. It is this object which is
indicated in the URL commodity order and which enables the details of the
purchased goods to be recorded in the tr~n~ctinn register of the payment server.Figures 4A to 4C show the operations carried out by the payment server 40
in response to the reception of a payment order.
In the front unit 41(Figure 4A), the payment order is decoded (stage 61)
and its validity is e~minrd (test 62) notably from the point of view of the validity
period. If the result of the cx;....i~ ion is negative, a refusal notification is sent to
25 the customer station (stage 63). If the result of the ~i....;..~tion is positive,
customer authentication follows (stage 64). The details of this operation are
described further with reference to Figure 4C. If the authentication is negative (test
65), a refusal notification is sent to the customer (stage 63). If the a~lthrntication
produces a positive result, the payment order (possibly limited to the ~;u~lome~30 identity CId, the supplier identity MId and the price) is tr~n~mittecl via the
col"",u"ication stage 68 to the rear unit 42 of the payment server shown in Figure
2 (stage 66). The col~lec~ion 48, as mentioned above, is a secure connection
p~ c;lllillg access to the rear unit by persons connected to the network 10.
The front unit 41 then waits for the rear unit to clete, . . . i . .~ whether or not to
35 authorise the payment (stage 67). If the payment is not authorised, (test 68), a
refusal notification is sent to the customer station (stage 63). If the payment is
CA 02217739 1997-10-08
authorised, a voucher is ~p~llcd (stage 69) usirlg the information recorded in stage
62. The voucher is saved in a memory of the front unit 41 (stage 70) and is sent to
the supplier server via the customer station (stage 71).
~ the rear unit 42 (Figure 4B) of the payment server, a newly received and
5 ~uth~nticated payment order is ~mine~l to ~ "~ whether this order should
be ~uth(>ri~ed from the customer account PME or through the banking ~lc;lwolh. In
this respect, the price is colllpdlGd with a ~ ... threshold (test 72). Thisthreshold is, for example, some tens of French francs.
If the threshold is exceeded, a request for effecting the payment operation is
10 sent to the banking network (stage 73) using the banking identity co,,c;spollding to
the customer identity CId as obtained from consultation of the data base 44. Thepositive or negative response from the banking network (stage 74), when received,
is l.~...c...il~e-l to the front unit 41 (stage 75).
If the threshold is not exceeded, the payment can be effected from the PME
15 customer account.
In this event, the customer ~Ccount iS ~x;tlll i..ed to ~let~-- .. . i..~. whether it has
sufficient funds (test 76). If it does not, a refusal of payment authorisation is sent
from the rear to the front unit (stage 75). If it does, the price is debited from the
PME customer account, the TCE supplier account collc;s~onding to the identity
MId is credited with the same sum (stage 77), the transaction is inscribed in the
transaction register 45 (stage 78), and the payment authorisation - in other words,
a positive response - is lldnslllilled to the front unit 41 with the indication of the
serial number of the inscription in the tr~n~ction register (stage 75).
The authentication procedure in the payment server (Figure 4C~, at the
stage 64 of Figure 4A, comprises sending to the customer station, preferably in
secure (encrypted) form, a ~leln~n-l for an access key, or pdS~WOld (stage 641).Upon reception, in secure form, of the access key (stage 64), a COlll~dliSOll iSeffected between corresponding information contained in the data base 44 (test
643). If the col"palison is negative, and a lll~illlUlll number of ~In~ucc~ssf~ll
dlk;lll~l~ has not been reached (test 644), the process returns to stage 641. If this
mi.x;.~,.. number has been reached, the failure to authorise is noted, and an alert
is produced (stage 645) and a negative response is sent to the customer station
(stage 646). The alert can comprise cancellation of the PME account or
surveillance of this account in order to detect new usage ~ ;",~ f the test at
step 643 is positive, the ~uthent;cation is recorded (stage 647) and a positive
response is provided (stage 648).
CA 02217739 1997-10-08
Dirr~ilG~ nr~1ing tç~hni~ e.s for p~....;ll;..~ secure ~ m of
numeric information in a colll~ulel network are well known, notably for the
request and sçn~lin~ of access keys.
The authentication procedure disclosed herein permits a prel i . . . ; . .. . y
S ~lth~ntication of a customer to be effected when necessary before the
establishment of a payment deln~n~l by the supplier's server. For this
~lth--ntir~tion, it is ~nfficient to create a payment ticket in which the price
indicated is zero, as indicated above.
The recording of the voucher in the front unit permits the cnctomer~ and the
suppliers to carry out controls and, possibly, to obtain copies of these. The
ccol~lillg of tr~n~ctions in the rear unit enables records of the transactions to be
conserved for possible use when needed later, for example, in the case of a dispute
arising belwt;till a customer and a supplier.
The balance in the customer accounts PME m~n~ge~d by the payment
server is limited in size and, according to the pl~;rt;llt;d embodiment of the
invention, these accounts do not receive interest payments (the payment system
being separate from the b~nkin~ world). Replenishment by a customer of his PME
~c~ount can be effected from his bank account, by placing an order with his
banking establishment.
The supplier accounts TCE m:~n~g~o~l by the payment server are ~c~oci~ted
with real bank accounts of the suppliers, into which they are, for example, emptied
daily.
Although there has been described above one way of putting into effect the
method according to the invention in an Internet ellvho~ lent and with WWW
software using the HITP protocol, a person skilled in the art will readily
appreciate that the method can be put into effect with a network other than Internet
or further with supplier servers and customer station software which does not use
the HITP protocol of WWW. Furthermore, secure ~thrntication methods using
a~dldllls such as smart card readers or voiceprint recognition means can be
foreseen in the place of access keys. These and other variations which will occur
to those skilled in the art are within the spirit and scope of the present invention.