US20180225663A1

US20180225663A1 - Methods and devices for managing composite transactions

Info

Publication number: US20180225663A1
Application number: US15/511,037
Authority: US
Inventors: Ghislain D'ALANCON
Original assignee: Heoh
Current assignee: Heoh
Priority date: 2014-09-15
Filing date: 2015-09-15
Publication date: 2018-08-09
Also published as: EP3195224A1; US10776782B2; CN107209887A; US20160125482A1; BR112017004962A2; FR3025915A1; WO2016042258A1; AU2015316635A1; MX2017003424A; FR3025915B1

Abstract

Disclosed is a method for the management of composite transactions including a main transaction and at least one additional operation in an arrangement including a device (205) for initiating a transaction, a device (215) for proposing at least one additional operation depending on the characteristics of a main transaction and a device (220) for managing additional operations, the device for proposing at least one additional operation being accessible via a plurality of separate devices for initiating a transaction and via a plurality of separate devices for managing additional operations.

Description

The present invention relates to the management of financial transactions made by debtors with creditors via bank accounts of the latter. More precisely, the invention relates to methods and devices for managing composite transactions, for example transactions comprising a payment and a donation to a particular entity, done by means of devices connected by a communications network.
Whereas traditionally donations used to be made autonomously, for example by addressing a cheque or a transfer to an entity of general interest or by giving change to a representative of an association, today there are computer applications (that is, in practice, on computers, personal assistants, smartphones or similar).
An essential characteristic of the computer-implemented mechanisms for collecting donations relates to the quality of interfaces for making donations so that a user is not inclined to discard an offer for donation due to complexity, excessive time, uncertainty as to amount, beneficiary or reliability of the procedure, etc.
While these mechanisms generally follow simple monetary rules by proposing for example rounding a sum to be paid for a purchase up to a whole number or paying a predetermined sum for each purchase, the implementation is generally complex for meeting the simplicity needs of the user and security needs of transactions. Also, there is substantial demand for traceability of donations, especially for tax reasons.
FIG. 1 schematically illustrates an environment in which a mechanism for collecting donations can be implemented, allowing a client to make a micro-donation during a purchase, for example a donation of the difference between the price to pay and this price rounded up to a whole number.
As illustrated, the environment 100 allows a client 105 having a payment card making purchases from a merchant having a computer infrastructure 110. Apart from this infrastructure, the environment 100 here comprises a computer system 115 linked to a bank of the merchant, a computer system (not shown) linked to a bank of the client and a computer system 120 linked to a bank of an organisation 125 of NGO type (acronym for Non-Governmental Organisation).
The computer infrastructure 110 of the merchant here comprises, in particular, a computerised accounting system 130, a cash register software 135 associated with a cash register operated by a checkout operator and a payment terminal 140. The computerised accounting system 130 and the cash register software 135 are connected to each other by a communications network, for example a network of Ethernet type using IP protocol (acronym of Internet Protocol).
Computer systems linked to banks are connected to each other and to the computerised accounting system 130 as well as to the payment terminal 140 by a communications network of Internet type, with data exchanges being secured, for example by encryption.
The mechanism for collecting donations is generally essentially implemented in the computerised accounting system 130 of the merchant and in the cash register software.
When a client go through checkout to make payment for his purchases (step {circumflex over (1)}), of an amount noted M, the checkout operator asks if he wants to make a donation of an amount noted D (step {circumflex over (2)}). If the client declines, the payment process continues conventionally (not shown).
On the contrary, if the client accepts to make a donation (step {circumflex over (3)}), the checkout operator presses a specific button to calculate a donation value based on the rounded up value of the amount of purchases, scans a specific barcode to obtain a similar result or inputs the amount of the donation using the cash register software (step {circumflex over (3)}′). This input is typically performed by adding a particular reference to the list of references of products bought by the client, this particular reference designating a donation and allowing, if necessary, inputting any amount by the checkout operator.
It is observed that several particular references can be used to each designate an entity to which the donation is to be made. The donation is thus integrated into the sales receipt whereof the total amount indicated, noted T, comprises the amount of real purchases (M) and the amount of the donation (D). In other words, T=M+D.
In a following step (step {circumflex over (4)}), the total amount (T) indicated on the sales receipt, the amount of real purchases (M) and the amount of the donation (D) are transmitted by the cash register software 135 to the computerised accounting system 130 of the merchant.
If payment of purchases is made by bank card (and not in cash or by cheque), the cash register software automatically transmits the amount to be paid (T) to the payment terminal 140. Alternatively, this amount is input by the checkout operator at the payment terminal 140. If it is authorised, the client validates the payment by means of his secret code.
The computer system of the bank of the merchant telecollects the cashed transactions of the merchant, typically periodically, and through a bank intermediation scheme, presents the amount of the payments (T=M or T=M+D according to whether the client has made a donation or not) to credit an account of the merchant by a corresponding amount (step {circumflex over (5)}).
At the same time, the computerised accounting system 130 of the merchant updates account journals into which the amounts of real purchases (M) and the amounts of donations (D), typically by beneficiary organisation, appear. Separate management of amounts of real purchases (M) and amounts of donations (D) is necessary for accounting reasons (linked for example to VAT, acronym for Value-Added Tax) and tax reasons (especially for calculating revenues in which the amount of donations does not have to be specified).
The account journal of donations is especially used by the merchant to periodically refund, for example every month, the total amount of donations received for the account of one or more organisations. Such payments are typically made upon order of the merchant to its bank, the latter executing the order of transaction (steps {circumflex over (6)} and {circumflex over (6)}′). The organisation or organisations then have donations paid for carrying out their missions (step {circumflex over (7)}). It is observed here that implementation of the mechanisms for collecting donations or micro-donations such as that described with reference to FIG. 1 requires substantial modifications of the used devices.
In particular, it is necessary to modify the cash register software and/or to add a software cooperating with the latter, to allow the input of at least one particular reference designating a donation and enabling the calculation of an associated amount or the input of any associated amount, so that a particular article, not subject to VAT, is added to a sales receipt.
It is also necessary to modify the computerised accounting system of the merchant to allow separate management of amounts of real purchases and amounts of donations, to enable processing of references of products assimilated into donations and not subject to VAT (these amounts do not have to form part of the calculated revenue) to manage different account journals and credit external accounts (accounts associated with organisations of NGO type) as well as to calculate the exact revenue amount.
In addition, it should be noted that the implementation of these mechanisms for collecting donations requires the involvement of checkout personnel for clients. Therefore, for example, checkout operators must beg the clients by asking them to make a donation and if so, handle initiation of the donation management process. This extra work is generally considered as unpleasant by checkout operators who feel that they are begging for donations. Also, this method may have an unpleasant psychological influence and be considered as intrusive by the client who feels trapped to the extent where a refusal can be poorly received by a checkout operator or a nearby customer when the question is asked.
Therefore, the constraints imposed by these mechanisms for collecting donations have considerable consequences.
Also, there is a risk of substantially slowing down the checkout due to the complexity of the procedure.
Finally, the modifications to be made to the cash register software and in the computerised accounting system of the merchant are very expensive (typically of the order of several million euros in terms of a chain operating nationally). It is observed here that modifications are very difficult to export from one merchant to another, thereby involving repetition of modification operations and therefore of related costs.
Finally, transfer and management of funds are of the responsibility of the merchant, without real possible controls. The traceability of donations is accordingly not assured, leading to problems such as tax exemption problems.
The invention allows solving at least one of the problems outlined previously.
The aim of the invention is a management method of a composite transaction comprising a main transaction and at least one annex operation, this method being implemented in a set comprising a device for initiating a transaction, a device for proposing at least one annex operation according to characteristics of a main transaction and an annex operations management device, said device for proposing at least one annex operation being accessible by a plurality of separate devices for initiating a transaction and by a plurality of separate annex operations management devices, this method comprising the following steps,

- receiving information relative to said main transaction, said information being received from said device for initiating a transaction by said device for proposing at least one annex operation;
- estimating at least one parameter of said at least one annex operation, from at least one predetermined rule, according to at least one received item of information relative to said main transaction, said estimation step being performed in said device for proposing at least one annex operation;
- in response to an indication of acceptance of said at least one annex operation received from said device for initiating a transaction, transmitting to said annex operations management device data comprising at least said at least one parameter of said at least one annex operation, said main transaction being managed independently of said steps of receiving, estimating and transmitting.

The method according to the invention offers the possibility of making donations during payment at a payment terminal without substantial modification of the cash register software and of the computer accounting systems of merchants. The costs of computer setup at merchants are therefore not significant (the same device for proposing at least one annex operation or the same management system for donation requests can be used by different merchant systems, different bank systems and/or different donation beneficiary systems).
Collecting donations is particularly rapid because of a number of operations which can be limited to a single input of acceptance type. Also, checkout operators are not being asked to collect donations.
The method for management of donations according to the invention enables simplified installation in a large number of merchants as well as control and traceability of donations.
According to a particular embodiment, the method further comprises a step of selecting said at least one rule for estimating said at least one parameter of said at least one annex operation.
According to a particular embodiment, the method further comprises a step of receiving an identifier of said device for initiating a transaction, said at least one rule for estimating said at least one parameter of said at least one annex operation being selected according to said identifier of said device for initiating a transaction.
According to a particular embodiment, the method further comprises an initial configuration step of at least one rule for estimating at least one parameter of at least one annex operation.
According to a particular embodiment, said data transmitted to said annex operations management device in response to an indication of acceptance of said at least one annex operation further comprise said information relative to said main transaction.
According to a particular embodiment, the method further comprises a step of transmitting a print command to said device for initiating a transaction, said print command aiming at printing a receipt comprising said at least one parameter of said at least one annex operation and said at least one received item of information.
A client can keep evidence of a donation made by way of printing a receipt at a payment terminal, which contains a reference. The latter allows identification of the user on a computer management system for donations especially for accessing a set of donations already made and downloading tax receipts.
According to a particular embodiment, said print command also aims at printing a reference to an identifier of a personal entity on said receipt.
According to a particular embodiment, said data comprising at least said at least one parameter of said at least one annex operation further comprise said reference.
According to a particular embodiment, the method further comprises a step of storing said at least one parameter of said at least one annex operation.
According to a particular embodiment, the method further comprises a step of generating a transaction based on at least one previously stored parameter of at least one annex operation.
According to a particular embodiment, the method further comprises a step of generating a summary of annex operations, said summary comprising at least one previously stored parameter of at least one annex operation.
According to a particular embodiment, the method further comprises a step of encrypting at least one datum transmitted between said device for initiating a transaction and said device for proposing at least one annex operation or between said device for proposing at least one annex operation and said annex operations management device.
According to a particular embodiment, the communication protocol between said device for initiating a transaction and said device for proposing at least one annex operation or between said device for proposing at least one annex operation and said annex operations management device complies with a standard of the IP type.
The invention also concerns a computer program comprising instructions adapted to carrying out each of the steps of the method described previously when said program is executed on a computer as well as a system comprising means adapted to carrying out each of the steps of the method described previously. The advantages provided by this computer program and this system are similar to those mentioned hereinabove.

Other advantages, aims and characteristics of the present invention will emerge from the following detailed description, given by way of non-limiting example, with respect to the appended drawings, in which:

FIG. 1 schematically illustrates an environment in which a mechanism for collecting donations can be implemented, allowing a client to make a micro-donation during purchase, for example a donation of the difference between the price to pay and this price rounded up to a whole number;

FIG. 2 schematically illustrates an environment in which a particular embodiment of the invention as well as some steps of an exemplary method according to the invention may be implemented;

FIG. 3 schematically illustrates a payment terminal element comprising a screen on which several choices of donations are proposed to a user;

FIG. 4 schematically illustrates a standard payment example by payment card in an infrastructure comprising a payment card, a payment terminal as well as banking computer systems linked to the debtor and creditor; and

FIG. 5 illustrates an example of an information-processing device adapted to implement, at least partially, an embodiment of the invention.

According to a particular embodiment of the invention, a management mechanism of composite transactions computer-implemented, for example a mechanism for collecting donations, calls on several devices including a set of third-party devices in order to isolate at least partially specific elements of the management of composite transactions.
A composite transaction here comprises a main transaction and at least one annex operation. The latter typically concerns amounts and beneficiaries different from those of the main transaction. It is recalled that a transaction is a commercial operation aiming, for the party forming the subject of a particular embodiment of the invention, at a transfer of a monetary sum between a debtor and a creditor.
By way of illustration, a composite transaction can comprise a payment of a purchase (main transaction) combined with a donation (annex operation).
According to a particular embodiment, the management of donations is essentially entrusted to two separate servers, one handling the management of donation requests, called computer management system for donation requests or more and generally device for proposing at least one annex operation, and the other the management of the donations themselves, called computer management system for donations or more and generally annex operations management device.
FIG. 2 schematically illustrates an environment in which a particular embodiment of the invention as well as some steps of an exemplary method according to the invention can be implemented.
The environment 200 here comprises a set including a cash register software 202, a payment terminal 205 (more generally called a device for initiating a transaction), a computerised accounting system 210, a computer management system for donation requests 215 and a computer management system for donations 220. As illustrated, the cash register software 202, the payment terminal 205 and the computerised accounting system 210 belong to the merchant 225.
The cash register software 202 and the payment terminal 205 as well as the cash register software 202 and the computerised accounting system 210 are connected by a private or public communications network, for example an Ethernet network or the Internet network.
The payment terminal 205 is here also connected to the computer management system for donation requests 215, for example an Ethernet network or the Internet network, allowing an exchange of data in real time.
The computer management system for donation requests 215 and the computer management system for donations 220 are here accessible via a public communications network, for example the Internet network, in order to be accessible by computer systems of different merchants and different users (i.e. clients).
The communication protocols between these different devices are preferably selected from among standard protocols, for example IP and X.25 protocols.
It is observed that if the computer management system for donation requests 215 and the computer management system for donations 220 are typically separate servers, the management of donation requests and management of donations can be undertaken by two applications implemented on the same server, or even by the same application.
The environment 200 further comprises a bank intermediation network 230, for example the bank intermediation network of MasterCard, Visa, GIE Carte Bancaire, SWIFT, STET or Target 2 (MasterCard, Visa, GIE Carte Bancaire, SWIFT, STET and Target 2 are trademarks), as well as computer systems for management of bank accounts 235 to 250 associated respectively with a client, with the merchant having the cash register software 202, the payment terminal 205 and the computerised accounting system 210, with a third party in charge of managing donations and with a donation beneficiary organisation.
According to a particular embodiment, the data exchanged between the cash register software 202, the payment terminal 205, the computerised accounting system 210, the computer management system for donation requests 215, the computer management system for donations 220, the bank intermediation network 230 and the computer systems for management of bank accounts and transactions 235 to 250 are transmitted in the form of messages encrypted by means of standard algorithms, for example algorithms based on the use of private keys and public keys, notably algorithms of RSA type (Ronald Rivest, Adi Shamir and Leonard Adleman), by packets. Alternatively, only some exchanges are encrypted according to their nature and/or according to the source and/or destination devices.
As shown in FIG. 2, the aim of an initial step (step {circumflex over (0)}) is to configure the computer management system for donation requests 215. Such configuration comprises especially the definition of one or more rules associated with one or more payment terminals, typically all the payment terminals of the same merchant, defining a modality for calculating an amount of donations and associating a donation with a recipient, for example an organisation of NGO type.
These rules are typically applied according to received parameters, for example according to a received value (e.g. amount of a transaction), and/or an identifier of the device from which these data are received (i.e. sender of the message comprising these data). An example of such rules is illustrated the attached appendix in the form of a table (table 1). As illustrated, each line of the table corresponds to a rule. Each rule is here defined by an identifier (column 1), an identifier of a payment terminal or a group of payment terminals (column 2), a method for calculating donations (column 3) and an identifier of a beneficiary or a group of beneficiaries (column 4).
Of course, other information can be used in the definition of rules.
When a group of beneficiaries is designated, the distribution of a donation between the latter can be predetermined or left to the appreciation of a user (can especially select a sole beneficiary in the group).
Thus, for example, the rule having the identifier 2 applies to the payment terminal or group of payment terminals having the identifier G53391, the beneficiaries being for a first half of a donation a beneficiary having the identifier 1 and for the second half of the donation a beneficiary having the identifier 2. The amount of the donation is determined here as a function of the amount of purchases (0.5%) or on a flat-rate basis (5 €), the lesser value being retained.
The setting of these rules may be done via a protected access to the computer management system for donation requests 215. By way of illustration, a merchant can access, by means of an identifier of a payment terminal or a group of payment terminals and of a password, to all the rules associated with this identifier, i.e. to a subset of stored rules. Access to rules allows adding, modifying or deleting rules. Access can be done from any computer (or equivalent) connected to the computer management system for donation requests 215 via a communications network such as the Internet and via a portal of web type.
When a client is in front of a payment terminal to pay for purchases and after the amount M of purchases has been determined, for example by a checkout operator or automatically and obtained by the payment terminal (step {circumflex over (1)}), manually or automatically, a communications link or a communications session is set up between the payment terminal 205 and the computer management system for donation requests 215. According to a particular embodiment, the communications link is set up automatically after input, obtaining or validation of the amount M of purchases. For this purpose, the payment terminal comprises an address of the computer management system for donation requests 215, for example a URL link (acronym for Uniform Resource Locator) associated with an access command called up as soon as an amount is input, obtained or validated.
As described previously, the computer management system for donation requests 215 can be accessed from different payment terminals managed by different merchants, i.e. by different payment terminals having no links between them.
Following setting up the communications link between the payment terminal 205 and the computer management system for donation requests 215, the amount M of purchases and an identifier of the payment terminal and of the transaction are transmitted by the payment terminal 205 to the computer management system for donation requests 215 (step {circumflex over (2)}).
Alternatively, the amount M of purchases as well as the identifier of the payment terminal are transmitted in the form of a message to a predetermined address or to an address determined dynamically, for example by means of a mechanism of DNS type (acronym for Domain Name System).
In response, the computer management system for donation requests 215 determines the applicable rule or rules for calculating donations, notably as a function of the identifier received from the payment terminal, and calculates one or more donation values. This value or these values are then transmitted to the payment terminal, each value being associated with a beneficiary denoted b (step {circumflex over (2)}′).
The value or values of donations as well as the corresponding beneficiaries are preferably displayed on a screen of the payment terminal to let the client validate a donation proposition, select and validate one donation proposition from among several, freely input a donation amount or pay for the purchases without making a donation.
Advantageously, selection or refusal of a donation is done by a single press on a key of the payment terminal (or of a device connected to the latter).
It is observed here that at least some of the actions conducted by a payment terminal can be deported, for example in a device of smartphone type or a web site, to let a user view and/or validate choices on his own device.
FIG. 3 schematically illustrates a payment terminal element comprising a screen on which several choices of donations are proposed to a user. The payment terminal element 300 here comprises a set 305 of keys touches and a screen 310.
As shown, the screen displays a message offering a user the possibility of making a donation of 0.54 € to the Red Cross or to the Restos du Coeur (the Red Cross and the Restos du Coeur are trademarks) or of paying for his purchases without making a donation. As indicated by reference numerals 315, 320 and 325, respectively, pressure on the key 1, referenced 330, effects payment of a donation of 0.54 € to the Red Cross, pressure on the key 2, referenced 335, effects payment of a donation of 0.54 € to the Restos du Coeur and pressure on the key A, referenced 340, effects payment for purchases without making a donation.
After having validated or refused a donation, the user validates his purchases (step {circumflex over (3)}) for a total amount T corresponding to the amount of his purchases to which is added the amount of the donation (T=M+D) or corresponding only to the amount of purchases (T=M). Typically, when payment of purchases is made by means of a portable electronic entity such as a bank card, validation of purchases is completed by input of a confidential code associated with the used card or by any other biotechnical means (e.g. digital fingerprints). Alternatively, for example if the payment is made by transfer or by means of an electronic wallet, the confidential code can be a code associated with an identifier previously obtained from the user.
Taking out the amount T from the bank account of the user and crediting an equivalent amount to the bank account of the merchant is advantageously carried out conventionally as described in reference to FIG. 4 (step {circumflex over (4)}).
At the same time as payment or, preferably, following receipt of payment authorisation, the payment terminal 205 sends, where necessary, an indication of acceptance of donation to the computer management system for donation requests 215, typically in the form of a message comprising the value or values of the donation and the selected beneficiary or beneficiaries (step {circumflex over (5)}).
In response, the computer management system for donation requests 215 preferably returns a print command for a receipt containing the detail of the operation, that is, the total payment made and its distribution between payment of purchases and donation made (step {circumflex over (5)}′). On receipt of this command, the payment terminal prints this receipt which is given to the user.
According to a particular embodiment, the print command of a receipt is transmitted with a card reference (Rc) associated with the payment card used, this card reference preferably being determined by the payment terminal from an identifier or a card number (for example by applying a hash function to the card number).
It is observed here that, according to a particular embodiment, a personal identifier (IDp) is given to each user during signup on the computer management system for donations 220 (signup comprising typically creating a user profile). The card reference supplied on the receipt can be used for this signup which can be completed, for example, via a web interface. To prevent fraud, creating a profile can be subject to providing additional information, for example, apart from providing the card reference, the user can be requested to give the last six digits of the payment card number (from which a card reference could be generated which will be compared to that received for validation).
A password is advantageously linked to the personal identifier to secure access to data relative to this donor.
When a donor signs up on the computer management system for donations 220, a profile is created. It comprises especially the card reference, and other payment card references which can be associated with this profile.
In addition to access to his profile, the personal identifier lets a donor connect to the donation management system 220, for example via a web page, and get information relative to the history of donations made, download the tax receipts for the cumulative amounts of donations on all his cards or receive information originating from associations benefiting from his generosity.
The personal identifiers and the associated profile are preferably known only for the computer management system for donations 220 (i.e., they are not known by the payment terminal 205 or by the computer management system for donation requests 215).
To allow the computer management system for donations 220 to manage donations, the payment terminal sends the computer management system for donation requests 215 a reference of the payment card used with indication of acceptance of donation. With this card reference, the computer management system for donations 220 can retrieve a personal identifier previously created (the computer management system for donations 220 stores the links between a personal identifier and one or more card references, for example in a table). If no personal identifier is found, the data relative to the donation are stored to be processed later, after creation of a user profile associated with the corresponding card reference.
Following acceptance of a donation, the computer management system for donation requests 215 stores the amount of purchases M as well as the amount of the donation D made in a donations journal. For each transaction completed, the latter comprises a transaction reference, an identifier from a payment terminal or group of payment terminals payment card, a reference Rc, an amount M of purchases, an amount of donation(s) made and the associated beneficiary or beneficiaries (given that the amount of a donation can be distributed among several beneficiaries).
An example of a donations journal of a computer management system for donation requests is illustrated in the appendix attached (table 2). By way of illustration, the line of the journal specifying the transaction identified by reference 2 corresponds to a transaction completed from a payment terminal or group of payment terminals identified by reference G53391 for the donor having used a card having reference 023, the amount of purchases made being 87.45 € and the amount of the donation 0.44 € being distributed in equal parts among the beneficiaries identified by references 1 and 2.
In addition to a transaction identifier, an identifier from a payment terminal or a group of payment terminals, a payment card reference Rc, an amount M of purchases, an amount of donation(s) made and the associated beneficiary or beneficiaries, the donations journal can optionally (not shown) comprise the amount T of the payment, representing the total amount M of purchases and amount of donation(s) made and paid.
The donations journal is sent periodically, for example every hour or every night, to the computer management system for donations 220 (step {circumflex over (6)}) where it is stored. After transmission to the computer management system for donations, the donations journal stored in the computer management system for donations 220 is reinitialised (however, a copy is preferably kept).
The computer management system for donations 220 then analyses the donations journal to extract those parts concerning a particular computerised accounting system, for example the computerised accounting system 210, that is, the computerised accounting system associated with a payment terminal or a group of payment terminals. The parts extracted concerning a particular computerised accounting system are here transmitted to the latter to allow it to carry out accounting reconciliation (step {circumflex over (7)}).
Periodically, for example every week or every month, the computer management system for donations 220 calculates, for a particular computerised accounting system, the sum of donations made by clients at payment terminals linked to the latter, denoted ΣD. This calculation is made from the purchase journal by totalling those donations associated with the same payment terminal or the same group of payment terminals. A request for debiting or payment of this amount is sent to this computerised accounting system to credit this amount from a bank account associated with the computer management system for donations (step {circumflex over (8)}).
The debiting or payment of this sum of donations from a bank account associated with a computerised accounting system and crediting an equivalent amount from the bank account associated with the computer management system for donations is advantageously conducted conventionally similarly to a payment method of a supplier.
In a following step, the computer management system for donations 220 calculates for each beneficiary the sum of donations to be reversed. Again, this calculation is effected from the donations journal, accumulating the donations associated with the same beneficiary.
The donations journal stored in the computer management system for donations 220 is preferably updated following transfer of donations. But, a history is kept to enable traceability of donations and setting up tax slips where necessary.
Thus, for example, the computer management system for donations 220 calculates for a particular user, for some or for all users, the sum of donations paid during a given period, typically a fiscal year. Again, this calculation is effected from the donations journal, by accumulating the donations associated with the same user.
The management of composite transactions and in particular donations backed by purchases requires creation of third-party computer systems which can be used by merchants and clients, as well as the development of particular interfaces giving access to these computer systems.
Thus, for example, executing the solution described in reference to FIG. 2 requires setting up a computer management system for donation requests and a computer management system for donations as well as creating interfaces. Of the latter and to execute the solution described in reference to FIG. 2, the following interfaces are set up:

- secure data exchange interface, in real time, between software of a payment terminal and software of the computer management system for donation requests;
- secure data exchange interface between software of the computer management system for donation requests and software of the computer management system for donations,
- parameterising interface of the computer management system for donation requests (typically by means of a merchant computer system for configuring rules of donation requests via a web page);
- query interface of the computer management system for donations (typically by means of a user computer system for parameterising his identity, registering his cards, modifying his profile and/or accessing donation slips via a web page); and
- a standard exchange interface between the donations management system and the computerised accounting system of the merchant.

According to a particular embodiment, data exchange interfaces are based on the usual communication protocols and utilise standard encryption algorithms. Therefore, by way of illustration, when computer systems are connected to each other via a network of Internet type, these exchanges can use the IP protocol combined with data encryption by private keys and public keys of RSA type.
FIG. 4 schematically illustrates a standard example of payment by payment card in an infrastructure comprising a payment card, a payment terminal as well as banking computer systems linked to the debtor and the creditor. Such a payment plan is also known under the name of payment model by bank card everywhere.
This payment plan or a similar plan can especially be used for money transfers between an account of a card carrier and an account of a merchant, as specified in reference to FIG. 2.
This payment plan can be used, as for classic plans used for cheques, transfers and debiting, for money transfers between the accounts of a merchant (referenced 240 in FIG. 2), a donations manager (reference 245 on the FIG. 2) and a beneficiary association (referenced 250 in FIG. 2).
As illustrated, a client provided with a payment card 400, for example a card of Visa type (Visa is a brand), here settles a purchase from a merchant using a payment terminal 405. The payment card is associated with a bank account 410 (client account) managed by a computer system 415 of a bank (typically the bank which issued the bank card or for the account from which the bank card has been issued). In the same way, the payment terminal 405 is associated with a bank account 420 (merchant account) managed by a computer system 425 of a bank.
To make a purchase transaction, a client presents his payment card to merchant a payment terminal to which the amount has been sent manually or automatically (step {circumflex over (1)}). After validation of the purchase by the client, for example by inputting a confidential code or PIN code (acronym for Personal Identification Number), the payment terminal typically makes an authorisation request which is transmitted to the computer system 415 of the bank of the card carrier via the computer system 425 of the bank of the merchant and a bank intermediation network 435 (step {circumflex over (2)} and {circumflex over (3)}).
The message is advantageously encrypted and comprises the identifiers of the client and of the merchant as well as the amount to be transferred.
After authentication and verification, especially of the identity of the client and that of the merchant as well as of the balance of the debtor account, a transfer acceptance message, preferably encrypted, is sent by the computer system 415 of the bank of the client to the computer system 425 of the bank of the merchant (step {circumflex over (4)}).
After having received a transfer acceptance message, a credit message is sent by the computer system of the bank of the merchant to the address of the computer system of the bank managing the bank account with which the payment card being used is associated (step {circumflex over (5)}), here the computer system 415, via the bank intermediation network 435. This message is preferably encrypted.
It is observed here that requests from bank intermediations can be accumulated and performed later on (as specified previously, the bank intermediation network 435 can be for example the bank intermediation network of MasterCard, Visa, GIE Carte Bancaire, SWIFT, STET or Target 2).
The merchant account 420 is credited with the sum transferred (step {circumflex over (6)}) while the account 410 of the client is debited by the same sum (step {circumflex over (7)}), typically on a deferred way.
Encryption used for exchanges of data is for example encryption using a public key and a private key, for example encryption of RSA type.
FIG. 5 illustrates an example of a device which can be used to at least partially implement an embodiment, especially the steps described in reference to FIGS. 2 and 4. The device 500 is for example a server, a computer or a personal assistant.
The device 500 preferably comprises a communications bus 502 to which the following are connected:

- a central processing unit or microprocessor 504 (CPU);
- a read-only memory 506 (ROM) that may comprise the operating system and programs such as “Prog”;
- a random access memory or memory cache 508 (RAM) comprising registers adapted to record variables and parameters created and modified during implementation of the abovementioned programs;
- a removable support reader 510 of storage 512 such as a memory card or a disc, for example a DVD disc; and
- a graphics card 514 connected to a screen 516.

Optionally, the device 500 may also comprise the following elements:

- a hard drive 520 that may comprise the abovementioned “Prog” programs and data processed or to be processed according to the invention;
- a keyboard 522 and a mouse 524 or any other pointing device such as an optical pen, a touch screen or a remote control allowing the user to interact with the programs according to the invention, in particular for initiating a money transfer, configuring rules for donation requests, following one or more donation lists and obtaining a tax receipt; and
- a communications interface 526 connected to a distributed communications network 528, for example the Internet network, the interface being capable of transmitting and receiving data.

The communication bus allows communication and interoperability between the different elements included in the device 500 or connected to it.
The representation of the bus is not restrictive and, notably, the central unit is likely to communicate instructions to any element of the device 500 directly or by means of another element of the device 500.
The executable code of each program enabling the programmable apparatus to implement the method according to the invention can be stored, for example, on the hard drive 520 or in read-only memory 506.
According to a variant, the executable code of programs could be received by means of the communications network 528, via the interface 526, to be stored identically to that described previously.
More generally, the program or the programs could be loaded into one of the storage means of the device 500 before being executed.
The central unit 504 will control and direct execution of the instructions or portions of software code of the program or programs according to the invention, instructions which are stored on the hard drive 520 or in the read-only memory 506 or else in the other abovementioned storage elements. During powering up, the program or programs which are stored in non-volatile memory, for example the hard drive 520 or the read-only memory 506, are transferred to the main memory 508 which contains the executable code of the program or programs according to the invention, as well as registers for storing the variables and parameters necessary to carry out the invention.
Naturally, to satisfy specific needs, a person skilled in the field of the invention may apply modifications to the preceding description. The present invention is not limited to the embodiments described, and other variants and combinations of characteristics are possible.
The present invention has been described and illustrated in the present detailed description in reference to the attached figures. However, the present invention is not limited to the embodiments presented. Other variants and embodiments can be deduced and executed by the person competent in the field of the invention on reading the present description and attached figures.
In the claims, the term “comprise” does not exclude other elements or other steps. The indefinite article “a” does not exclude the plural. A single processor or several other units can be used to execute the invention. The different characteristics presented and/or claimed can be combined advantageously. Their presence in the description or in different dependent claims does not in fact exclude the possibility of combining them. The reference signs cannot be understood as limiting the scope of the invention.

Appendix

TABLE 1

ID rule	ID TPE	RULE	ID beneficiaries

0	543291	Rounded up	1
1	1294G3	Fixed price of 1€ per transaction	1 (0.40€), 3 (0.60€)
2	G53391	Minimum between 0.5% of the	1 (50%), 2 (50%)
		transaction and 5€
. . .	. . .	. . .	. . .
n	491503	Rounded up	1

TABLE 2

ID trans.	ID TPE	Rc	M	D, b

0	543291	407	425.66€	1: 0.34€
1	543291	212	35.14€	1: 0.86€
2	G53391	023	87.45€	1: 0.22€, 2: 0.22€
. . .	. . .	. . .	. . .	. . .
p	1294G3	865	118.00€	1: 0.40€, 3: 0.60€

Claims

1. A method for management of a composite transaction comprising a main transaction and at least one annex operation, this method being carried out in a set comprising a device (205) for initiating a transaction, a device (215) for proposing at least one annex operation according to characteristics of a main transaction and an annex operations management device (220), said device for proposing at least one annex operation being accessible by a plurality of separate devices for initiating a transaction and by a plurality of separate management devices of annex operations, the method comprising the following steps,

receiving information relative to said main transaction, said information being received from said device for initiating a transaction by said device for proposing at least one annex operation;

estimating at least one parameter of said at least one annex operation, from at least one predetermined rule, according to at least one received item of information relative to said main transaction, said estimation step being performed at said device for proposing at least one annex operation;

in response to an indication of acceptance of said at least one annex operation received from said device for initiating a transaction, transmitting to said annex operations management device data comprising at least said at least one parameter of said at least one annex operation,

said main transaction being managed independently of said steps of receiving, estimating and transmitting.

2. The method according to claim 1 further comprising a step of selecting said at least one rule for estimating said at least one parameter of said at least one annex operation.

3. The method according to claim 2 further comprising a step of receiving an identifier of said device for initiating a transaction, said at least one rule for estimating said at least one parameter of said at least one annex operation being selected according to said identifier of said device for initiating a transaction.

4. The method according to claim 1 further comprising an initial configuration step of at least one rule for estimating at least one parameter of at least one annex operation.

5. The method according to claim 1 according to which said data transmitted to said annex operations management device in response to an indication of acceptance of said at least one annex operation further comprise said information relative to said main transaction.

6. The method according to claim 1 further comprising a step of transmitting a print command to said device for initiating a transaction, said print command aiming at printing a receipt comprising said at least one parameter of said at least one annex operation and said at least one received item of information.

7. The method according to claim 6 wherein said print command further aims at printing a reference to an identifier of a personal entity on said receipt.

8. The method according to claim 7 according to which said data comprising at least said at least one parameter of said at least one annex operation further comprise said reference.

9. The method according to claim 1 further comprising a step of storing of said at least one parameter of said at least one annex operation.

10. The method according to claim 9 further comprising a step of generating a transaction based on at least one previously stored parameter of at least one annex operation.

11. The method according to claim 9 further comprising a step of generating a summary of annex operations, said summary comprising at least one previously stored parameter of at least one annex operation.

12. The method according to claim 1 further comprising a step of encrypting at least one datum transmitted between said device for initiating a transaction and said device for proposing at least one annex operation or between said device for proposing at least one annex operation and said annex operations management device.

13. The method according to claim 1 according to which the communication protocol between said device for initiating a transaction and said device for proposing at least one annex operation or between said device for proposing at least one annex operation and said annex operations management device complies with a standard of IP type.

14. A computer program comprising instructions adapted to carrying out each of the steps of the method according to claim 1 when said program is executed on a computer.

15. A system comprising means adapted to carrying out each of the steps of the method according to claim 1.

16. The method according to claim 2 further comprising an initial configuration step of at least one rule for estimating at least one parameter of at least one annex operation.

17. The method according to claim 3 further comprising an initial configuration step of at least one rule for estimating at least one parameter of at least one annex operation.

18. The method according to claim 2 according to which said data transmitted to said annex operations management device in response to an indication of acceptance of said at least one annex operation further comprise said information relative to said main transaction.

19. The method according to claim 3 according to which said data transmitted to said annex operations management device in response to an indication of acceptance of said at least one annex operation further comprise said information relative to said main transaction.

20. The method according to claim 4 according to which said data transmitted to said annex operations management device in response to an indication of acceptance of said at least one annex operation further comprise said information relative to said main transaction.