Great job @Nemael !
Thank you very much for this sharing!
So the document you mentioned is about “for configuring the fee structure of an Exchange from different points of view (Exchange operators, buyers/users, and sellers/merchants).”
Do you have a reading suggestion more theoretical about the fee structure in Taler ? Something more “economic point of vue” about fee in Taler, to understand what are the choices, what is flexible or not?
I sadly don’t have a document that is closer to what you’re requesting. It would be useful, but also it is configurable differently for every merchant, so each merchant has different choices to make in relation to their maintenance cost.
There is this FAQ that contains some more information regarding fees GNU Taler: Frequently Asked Questions
These two links do contain some advice for some of the fees, such as the expected amount and the refund system for fees, in relation to the usual maintenance cost.
I hope there is a page with more detailed “legal” information, but I couldn’t find it available, the Taler documentation is very focused on the technical side
Note: I might not understand your request, but also I don’t think I am the right person to obtain this information, because I am focused on the technical integration side from the wallet owner’s point of view.
Thank you for you answer! It’s useful, I think that if this kind of document is not easily found by someone working on technical side of integration this maybe means that the documentation on this topic is not enough user friendly…
In the faq document you suggest to read, there is indeed few information on the subject :
The Taler protocol allows any exchange to set its own fee structure, allowing operators to set fees for withdrawing, depositing, refreshing or refunding coins. Operators can also charge fees for closing reserves and for (aggregated) wire transfers to merchants. Merchants may choose to cover some of the fees customers incur. Actual transaction costs are estimated around 0.001 cent/transaction (at high transaction rates, amortized over billions of transactions, excluding migration costs). Note that this is an early estimate, details may depend on hosting and backup requirements from the regulator and could thus easily be 10x higher.”
One can not see how/why “Actual transaction costs are estimated around 0.001 cent/transaction “
Withdrawing 5 CHF creates electronic coins with denominations of 0.04 CHF, 0.16 CHF, 0.32 CHF, 0.64 CHF, 1.28 CHF, and 2.56 CHF. Paying 3.23 CHF might then use the 0.04 CHF, 0.64 CHF and 2.56 CHF coins, resulting in a total of 3.24 CHF with 0.01 CHF returned as change.
Deposit fees charged by Taler payment providers depend on the electronic coins used in the transaction. For example, the deposit fee could be higher for a $1.28 CHF coin than for a a $0.01 CHF coin. Your wallet will automatically try to select coins that minimize the fees you have to pay. Merchants can offer to pay deposit fees up to a specified limit; customers have to pay deposit fees that exceed what the merchant is willing to cover. Taler wallets inform customers about applicable deposit fees they have to pay before every transaction.”
Bon courage !
On the 9th of December 2025:
Small update today, I redid the QR Code integration in invoices, to make it more robust and look nicer
I am having an unrelated, complex issue. I keep getting already-claimed orderIDs when posting an order on Taler after resetting the testing DB, and I know why it happens, it is due to the fulfillment message or fulfillment URL repeating from a previous DB running.
but it shouldn’t happen because I setup multiple systems to go around that, and it shouldn’t happen to a regular user, but it still happens to me in my testing environment. I am thinking of adding some random text to the end of the OrderID to avoid the issue, but it’d be messy and could lead to more unpredictable issues. So I will need to take some time to think about a fix for this one.
Other than that, next step is implementing payment for event tickets.
Quick update:
I spent 2 more hours on this already-claimed orderID issue, and I implemented a uuid system for the fulfillment message and URL, and it seemed to resolve the issue I was encountering.
This UUID is only used for the fulfillment url. Without the UUID in the url, the Taler merchant could mix up two orders with the same Odoo ID, on two different Odoo instances
This is not a perfect solution, as two duplicate UUID for the same OrderID could be generated on two different Odoo instances, on the same Taler Merchant, but this is highly unlikely.
On the 10th of December 2025:
Today I implemented the flow for event tickets and registration, as well as the flow for bookings with up-front payment. Luckily, both of these flows only required minor tweaks compared to previous payment implementations!
Note: to have the proper ticket ordering system, you might need to install the Odoo events module, as well as the python module pycairo:
- 1. sudo apt install libcairo2-dev
- 2. pip install rlPyCairo
Next step: Implementation of Self-ordering at Point of Sale! This flow will require a much tighter management of the Taler QR Codes, and will need a new implementation I think. As it is one of the last main flows required, Iafter it, I will be able to tackle code bolstering, and taking care of non-flow sub-milestones.
On the 12th of December 2025:
Today was a weird day for progress. I had a false hope moment, where I thought that Odoo would manage my Taler qr code dynamically, and automatically, but I could not be further from the truth…
Instead, I will have to dabble in Javascript and Odoo’s custom framework, Owl 2.0.
This is because the pos addon for Odoo is very js-focused, so it does not go through the usual python pipelines.
After trying 4-5 different approaches, none of them which worked, I found another repository on OCA, that provides a similar service that I am trying to make, but for Cashdro. The addon is even maintained by the OCA themselves!
So tomorrow, I will set some time aside to dissect their version, and I’m crossing my fingers that I will have a strong lead after that 
Edit:
After checking the link for 15 minutes, I concluded that the link would not help me much, so back to the search I go!
On the 14th of December 2025:
Good progress!
I made the completion of the flow for point-of-sale, it is now possible to pay using Taler on an Odoo pos.
I also made an in-depth tutorial to make the pos payment work, because there are a few small hoops to jump through. I will be making other in-depth tutorials later, with screenshots included.
Also, I made the security aspect more robust. Now, only administrator users can edit Taler payment settings, and there are two layers of security.
That makes the milestone 3 technically complete!!! The milestone 2 is still waiting for unit testing integration, and that will be the next step for me
Also, the code does need more cleanup, which I will be doing before I publish the “0.2 or 0.3 update”
I am super happy with the progress, and looking forward to move to other parts of the code 
On the 18th of December 2025:
After a few days, the bulk of unit testing is now complete and ready to be used!
They test a few of the utils methods, as well as the transaction creation, and the reception process. I am annoyed that it ends up being only 4 tests, but they cover the range of transaction status possible, so there couldn’t be many more relevant tests than that.
I struggled for a full day to make Odoo run my tests, but I now have honed on hwo to make it work, and have added a section in the README file to explain how to run unit testing.
Next step is adding a few more tests, and after this I will do another 3-4 days of code and UI cleanup. After this, I will go through my current TODO items, see what I can tick off, and what I should implement. Once this is complete, I should be ready to submit the milestones 0.2 and 0.3, this is exciting!!
I am hoping to be done with this part by the 24th, so I can have the whole holiday week off for real, and come back refreshed for the next steps for the addon.
On the 19th of December 2025:
Today I added a few tests, and upped the count from 4 to 9. I will continue adding them as I think them up, but I think this is a good stopping point for now.
Now that I can confidently navigate Odoo’s testing code, I am much faster at making them (it took 1 evening to manage to run any tests, then one evening to make the first big test, and one more to make the 4 other tests, I am much more confident on making them quickly now)
I also added expiration functionality to orders created from invoice or online payment. Orders for invoices expire at the invoice due date, and orders for online payment expire after 15 minutes.
So next step is started, I am now cleaning up massive amount of unused code, making the logs much more relevant for the user, and labelling them as logs/warnings/errors.
On the 21st of December 2025:
Another few days of great progress, it is smelling like the end of milestone 2 and 3!
I completed the cleanup process, it felt great to check all the lines I did, and identify the unused ones. After this process, my confidence in the code I made rose greatly!
I tackled the huge todo list I accumulated, full of many small changes to do, and I ticked off all tasks that were possible to do at this stage of the process! It was fun to work on many small tasks, instead of one huge system for once.
Next step: making strong tutorials, with pictures, on the different flows available. That will be useful for the users to understand how to use the addon, as well as for the milestone completion request to NGI Taler.
I am not sure yet how I should present this. Should I make a very big README file, with all the info, tutorials and pictures? Or should I make a second or multiple files specifically for tutorials?
The same question will arise when I will make a French translation for the README files. Should I put the French version below the English version (It feels bad to put them in an order of importance)? Or should I create multiple README files, one for each language (The users reading the code might not find the proper READMEs)
This whole README files organization is a mess, and I will need to brainstorm more about this, as well as read what other people did online. If you have any suggestions, please let me know
I won’t be able to work this Sunday, but I think I will be able to close out the milestones 2 and 3 on Wednesday, right on time for the holidays
On the 24th of December 2025:
Great news everyone!
After a few days of making tons of tutorials and walkthrough to insert in the README file, I am now finally ready to merge the next big update for the TOPS add-on
I am putting the final touches for version 0.3 of my addon, which includes the toughest part of this project, milestones 2 and 3 (See more in the release post)
These milestones are the biggest hurdle of the project because they include the implementation of the payment system in every part of Odoo. Further milestones will build on what’s already completed, instead of starting from “scratch”.
But that also means that the add-on is usable as of this release! Because most payment possibilities with Odoo are now integrated with Taler payments.
I will take some time off with the holidays, and I will be coming back to the project on January the 2nd
Next step is going to be milestone 5, “Merchant Test Mode”, I am skipping milestone 4 (Internationalization and Accessibility) for now, because it is best to leave it for a later part of the project.
On the 12th of January 2026:
Hi all, I did not make a devlog, but I kept making good progress on the project with the new year!
I am now close to be finished with milestone 5 (Merchant test mode), which can be used to test your module install and the Taler Merchange endpoint.
I added a big tooltip to explain the purpose of test mode, and warn the users that it should not be used in production. I also added a ribbon to the payment provider, to easily identify its current status (enabled, disabled, test mode)
I also added a section in the README file to explain how to use the test mode, what to expect, and how to see that everything is working properly.
I think I won’t merge this change to the main branch yet, I will let it stew a little more, to see if I missed a something in the feature. In the meantime, I will go ahead and start the refund system implementation. I already laid the groundwork for the refund system, so this should go ok, and be completed in the coming weeks. Yay!
Oh also, I received an issue from someone on the codeberg repository! It was a bit of a surprise because that’s the first one, but I am super happy with the short discussion it generated.
On the 15th of January 2026:
I am struggling a bit on progressing the refunds milestone.
I am in the middle of making the refunds system. The code itself is 50% done, but I am having issues following Odoo’s refund flow. I followed many many tutorials, but none of them showed my specific use-case (online payments), or if they did, they were using Odoo paid add-ons (Enterprise edition), and I would like to stay within the Community edition for the users of my add-on, and because if I want to install Odoo’s paid add-ons on my own servers, I have to pay a whole year of Odoo at once.
I reached out to the OCA Community on the mailing lists to get ideas on how to proceed, and I am looking forward to a response from them
Because I cannot yet move forward with the refunds, I started tackling the “Internationalization and Accessibility” milestone.
The Internationalization will progress in four parts.
The first part is complete, I will soon reach out to the person that can translate my add-on professionally, to request for the second part (the add-on translation itself). I will make a translation tutorial as well when this is finished.
The screen reader functionality is the next part I will tackle. Because I know very little about these technologies, I am not sure what to expect. It could be very simple or as super difficult, depending on if my, and Odoo’s code allow for easy automatic reading. I will find out when I start the next part
On the 23rd of January 2026:
I made progress for internationalization and accessibility milestone!
The French translation and glossary for the main software is about 60% done. After that. I will re-take all the tutorial’s screenshot in French, and start translating the tutorials as well.
In regard to accessibility, I implemented aria-labels and other content markers, to help someone who would be navigating with a screen reader. This is mostly for the back-end (the person that installs and setups the add-on), because all the user-facing Taler-relevant information is managed by Odoo themselves, and implements the accessibility standards from Odoo - which is what I aimed for in my accessibility implementation.
I am going through “What to do for accessibility” tutorials, and I am implementing small changes that are recommended, but due to being constrained by the Odoo framework, I cannot do stuff such as re-organizing the page to make it more readable, because it would break compatibility with other payment providers, so it will be a limited implementation.
On other milestones, I am still blocked on the “refund” flow that I should follow. I did reach out to 3 Odoo knowledge sources (including Odoo themselves), but none of them could explain to me a reliable flow that I could follow to go through the refund methods for online payments. I know it exists, but I guess it is rarely used, in favor of manual refunds? I will work on this more, and hopefully reach something that works
Great to know you are bringing special attention to accessibility as this is a key Taler feature.
Wish you best luck on the refund problem, it seems a bummer….
On the 1st of February 2026:
I finally figured out the refunds, and the feature has been implemented!! That completes the technical milestones, and I am getting ready for the next release
I also made a tutorial on using the refund feature, which can be found, as always, in the README file.
I had SO MUCH trouble finding, and then making the “Refund” button appear on Odoo, due to different configuration issues. To resolve this, I had to duplicate configurations for my payment provider and my payment method to make Odoo accept my refunds. After that was fixed, I implemented the API calls. Taler’s refund system is interesting, where you have to send a refund, and a URI is sent back. I turn this URI into a QR code that I send via email to the customer, who can scan it to their Taler wallet, to receive the refund. I had expected Taler to do the refund internally, as in, run the transaction back automatically to the customer wallet, instead of the customer having to interact at all. But I imagine that due to privacy reasons, the Taler merchant does not necessarily store the wallet information, and so the customer has to complete the refund themselves. One thing is unclear to me, does the customer need to receive the refund on the same wallet as the one they used to pay for the transaction? I will have to dive deeper in the documentation for this answer.
Anyway, my add-on now implements full refunds for customers. I did not implement partial refunds, because they are out of scope of the current project, but it is possible to implement it because Taler does allow for partial refunds. This could be a future improvement.
Regarding the coming work, now that all the technical features are done, I will get started fully on the translation, making more documentation (although I currently have a pretty good base), and looking into releasing the add-on!! This is super exciting!!
The translation of the add-on itself was complete, but I just added these new features, and so we need another go at the translation 
Anyway, that is all for today, I will make a post in the Odoo category of this forum as well
Thanks for reading!
On the 18th of February 2026:
Another long gap in devlogs, but the progress has been great!
The translation of the add-on’s code is complete! Next step is translating the README file and the few more documentation files I will make before the project is complete. For that purpose, I went through the whole readme file again, added a few sections (how to contribute, how to translate, etc…) and polished it to send to my translator, for them to make a translation of this file. I make sure to re-take all the documentation’s screenshots in French, only the text is left. The file README_FR.md has been created on the repository’s main branch.
Speaking about that, upon request, and to align my code to the standard, I moved all the code in a payment_taler sub-directory, and I renamed the main branch from main to 18.0. When I will update the add-on to Odoo 19, I will make a new branch with this name, and make it the new main branch when ready. This is how most other Odoo add_ons are laid out as well.
The accessibilization of the module is complete as far as I can take it while being limited by the Odoo framework. This mostly includes screen reader guardrails and alt text.
I initially had setup email support at the address tops_support@zaclys.net, but I actually don’t think I will use it, because this forum is perfect for public support. I asked around, and it is ok if I direct support questions to this forum category odoo - TALER ICH. I am super happy to be able to do this instead of maintaining private support via email.
I knocked out a massive amount of TODO items, basically everything that could be improved in the code itself.
On the repository itself, I added a CI pipeline to run unit testing automatically, using Woodpecker (You can see a pipeline run example here: Woodpecker). I also configured the repository to have releases and packaging based on tags, and made a first dummy release to try it out.
Next step: I will start on gathering approvals to upload my module on the two add-on shops I am aiming for, the Odoo app store and OCA community shop. I will also start on some milestone-specific tasks, such as making a security report.
I’m super excited to reach this point in the project, and to start seeing a complete bundle of tons of different tasks, that I can show off to people!
Hi @Nemael, congratulations on reaching this new milestone! I would recommend splitting the documentation away from the README, and keep that one minimal and stable. This way you can envision translations without affecting the code. Since Odoo documentation, like all Python docs, follows some standard for this, you could anticipate maintenance and write a separate tops-doc package written in ReStructured text to be included as a Git submodule in your code repository. I’m unsure about the correct way to package documentation in Python packages, but probably other grantees working on Taler in:python would be more helpful.
Do you have an external contribution yet? 
Since you’re proposing to use TALER ICH for support – which is a great choice --, I would suggest you split your README Markdown into documentation topics here, as to facilitate contributions. It could provide an alternate path to splitting your docs out in another repository. 
Thank you for this response, and apologies on the long time to respond, I decided to focus on reaching the end of this first part of the project!
Splitting the documentation would make its navigation way easier. I don’t see how it would “help me envision translations without affecting the code”, however I think the current README is way too long and the information would be more relevant if cut in 2-3 separate files, and easier to read.
Regarding the standard Odoo documentation format (.rst), it is definitely needed to overhaul the documentation towards this format, and would accomplish the above-mentioned clarifications.
Regarding the python packaging, there is currently no plans on making the add-on as whole, or part of it, onto an installable python package. There were a few messages exchanged about this topic, and I think it would be very useful to package the Taler API requests methods. However, I do not have sufficient knowledge or availability to take up this part of the task, at least for the moment. I am 100% open to discuss this further!
I did receive external contributions! I already mentioned previously, but I will mention again that Jan Suhr, the CEO of Nitrokey provided me with a lot of feedback about my add-on’s structure! It was very helpful in making the add-on easier to install and ready-to-use on a real-life Odoo instance. Thank you so much for this continuous support!
I also received helpful contributions from @how, who made a PR that tightened up the REUSE-compliance of my repository, and included the licenses’ actual text in the repository. Thank you so much for your support!
Regarding using ICH for support, your idea of splitting the support needs based on the documentation topics is great, it would streamline the process. Because there are very little supporting needs right now, I will do this later. I intend on doing this splitting after the documentation is updated to the .rst format.
Thank you for this detailed improvement proposition!
