Taler pour les développeurs


GNU Taler is free software implementing an open protocol. Anybody is welcome to integrate our reference implementation into their applications. Different components of Taler are being made available under different licenses. The Affero GPLv3+ is used for the exchange, the LGPLv3+ is used for reference code demonstrating integration with merchant platforms, and licenses like GPLv3+ are used for wallets and related customer-facing software. We are open for constructive suggestions for maximizing the adoption of this payment platform.


Taler is designed to work on the Internet. To ensure that Taler payments can work with restrictive network setups, Taler uses a RESTful protocol over HTTP or HTTPS. Taler's security does not depend upon the use of HTTPS, but obviously merchants may choose to offer HTTPS for consistency and because it generally is better for privacy compared to HTTP. Taler uses JSON to encode structure data, making it easy to integrate Taler with existing Web applications. Taler's protocol is documented in detail at docs.taler.net.


Taler is currently primarily developed by a research team at Inria and GNUnet. However, contributions from anyone are welcome. Our Git repositories can be cloned using the Git and HTTP access methods against git.taler.net with the name of the respective repository. A list of repositories can be found in our GitWeb.


In addition to this website, the documented code and the API documentation. Technical papers can be found in our bibliography.


We have a mailing list for developer discussions. You can subscribe to or read the list archive at http://lists.gnu.org/mailman/listinfo/taler.

Tests de régression

We have Buildbot automation tests to detect regressions and check for portability at buildbot.taler.net.

Mesure de couverture du code

We use LCOV to analyze the code coverage of our tests, the results are available at lcov.taler.net.

Technical Presentation

Vue d'ensemble de Taler

The Taler system consists of protocols executed among a number of actors as illustrated in the illustration on the right. Typical transactions involve the following steps:

Vue d'ensemble de Taler
  1. A customer instructs his bank to transfer funds from his account to the Taler exchange (top left). In the subject of the transaction, he includes an authentication token from his electronic wallet. In Taler terminology, the customer creates a reserve at the exchange.
  2. Once the exchange has received the wire transfer, it allows the customer's electronic wallet to withdraw electronic coins. The electronic coins are digital representations of the original currency from the transfer. It is important to note that the exchange does not learn the "serial numbers" of the coins created in this process, so it cannot tell later which customer purchased what at which merchant. The use of Taler does not change the currency or the total value of the funds (except for fees which the exchange may charge for the service).
  3. Once the customer has the digital coins in his wallet, the wallet can be used to spend the coins with merchant portals that support the Taler payment system and accept the respective exchange as a business partner (bottom arrow). This creates a digital contract signed by the customer's coins and the merchant. If necessary, the customer can later use this digitally signed contract in a court of law to prove the exact terms of the contract and that he paid the respective amount. The customer does not learn the banking details of the merchant, and Taler does not require the merchant to learn the identity of the customer. Naturally, the customer can spend any fraction of his digital coins (the system takes care of customers getting change).
  4. Merchants receiving digital coins deposit the respective claims that resulted from the contract signing with the customer at the exchange to redeem the coins. The deposit step does not reveal the details of the contract between the customer and the merchant or the identity of the customer to the exchange in any way. However, the exchange does learn the identity of the merchant via the provided bank routing information. The merchant can, for example when compelled by the state for taxation, provide information linking the individual deposit to the respective contract signed by the customer. Thus, the exchange's database allows the state to enforce that merchants pay applicable taxes (and do not engage in illegal contracts).
  5. Finally, the exchange transfers funds corresponding to the digital coins redeemed by the merchants to the merchant's bank account. The exchange may combine multiple small transactions into one larger bank transfer. The merchant can query the exchange about the relationship between the bank transfers and the individual claims that were deposited.
  6. Most importantly, the exchange keeps cryptographic proofs that allow it to demonstrate that it is operating correctly to third parties. The system requires an external auditor, such as a government-appointed financial regulatory body, to frequently verify the exchange's databases and check that its bank balance matches the total value of the remaining coins in circulation.
  7. Without the auditor, the exchange operators could embezzle funds they are holding in reserve. Customers and merchants cannot cheat each other or the exchange. If any party's computers are compromised, the financial damage is limited to the respective party and proportional to the funds they have in circulation during the period of the compromise.