Openes of Wallet for other transaction engines

[lucode]

Hi,

Me and other would highly appreciate if the Wallet and the Marketplace would have an open design to implement payment gateways and clients for other transaction engines. The favorite ones are Ripple and Opentransactions.

If possible the payment gateway model of odoo itself should be enhanced with crypto and community currencies plugins: https://github.com/odoo/odoo/tree/8.0/addons/payment Then payments could be get done for the odoo shop and the marketplace.

Also the Wallet should have a design that splits the module for the wallet itself and the different clients for other transaction engines. To distinguish between the modules for the wallet and the odoo build in transaction engine, it would be helpful to find a name for this. Something as OCE (Odoo Community Exchange) could fit. Then we would have client modules for OCE, OT and Ripple for instance.

                    - OCE Client
    account_wallet  - OT Client
                    - Ripple Client

    OCE transaction engine

[YannickB]

Hello lucode,

Yes indeed, integration of the marketplace with the payment module of Odoo is a concern for everyone but we are not sure how we'll do it.

Let remind here the different mode we have : -Internal currency (external currency set to off). The money is managed inside the system, by Odoo itself, if you have a balance of 0 at the start and someone pay you 200COM, you have 200COM on your balance in the end.

-External currency(external currency set to on), the transaction is done outside of the system. Let's say Fred send you 200€, here is your balance at each state : Initial fred available 0€, reserved 0€ lucode available 0€, reserved 0€ Accepted fred available -200€, reserved 200€ lucode available 0€, reserved 0€ Paid fred available -200€, reserved 0€ lucode available 200€, reserved 0€ (At this stage, this mean Fred must give 200€ to the community, and lucode must be given 200€ by the community) Payment confirmed (You click the button, confirming Fred gave you the 200€ by any means) fred available 0€, reserved 0€ lucode available 0€, reserved 0€ (Everything return to 0, Fred gave the money and the community doesn't have debt regarding you anymore. Keep in mind that the balance are always saw from the point of view of the community hosting the system)

-Now an official currency but managed inside the system. For example € with external currency set to off and with bottom limit set to 0 (which mean you can't have a negative balance) Initial fred available 0€, reserved 0€ lucode available 0€, reserved 0€ In this point, fred can't make any transaction, if he try to make a proposition it can't be accepted because the balance is checked before the accepted state. So let's say he buy 500€ credit through Paypal : fred available 500€, reserved 0€ lucode available 0€, reserved 0€ Accepted fred available 300€, reserved 200€ lucode available 0€, reserved 0€ Paid fred available 300€, reserved 0€ lucode available 200€, reserved 0€ There is no payment confirmed state, this state is only used when there is an external currency. So in the end you have 200€ available in your account, and you can ask the community to send you the money on your personal account. I didn't show here the bank fees, for the sake of simplification.

All described here is how account_wallet and marketplace works. Also one more information, to compute balance I check the balance of some accounting account, like 411 in France for € and a specific account I created for COM. All of this is fully configurable.

Now how can we improve it : -For the third case I described, the most simple is to install ecommerce module and create a product to buy credits before you can publish a proposition. The invoice will feed the 411 account of the user and so his balance will increase. Later, we can imagine a more powerful integration, with calling payment through paypal/ogone/etc... either before we publish the proposition (advance payment, you have still control on your money but it's now on the bank account of the community) or pay it only when you click on pay button.

-For cryptocurrency, the question is : does the money go through the bank account of the community. If yes, it's the same case than third. If not and we want to directly make a transaction between the two user, it's the second case but we'll probably want to automate the transaction when we click on confirm payment. My only concern here is the fact we'll probably need to store the cryptocurrency credentials of the user on the platform and I don't really like it.

I'm not an expert with cryptocurrency, but I think it's a good starting point.

[lucode]

Hi Yannick,

I suppose that you somehow misinterpreted my proposal. What you describe is a very delicate thing, that is called intertrading or clearing. Indeed if you like to perform transactions between different currency system or transaction engines it gets complicated. But this was not the point of my proposal. I just would like to keep the wallet of the Vertical-Community open, so that it will possible to ad other transaction engine to the wallet and the marketplace. But they all work independent and parallel as we have it with different payment channels in a webshop or in a Banking Software client, where I can manage different bank account from one single application. The following scheme gives an an idea how the architecture of the different modules could be arranged.

In a later stage intertrading could be added to such a system, but not in the odoo part of the whole framework, but in a transaction engine as Ripple for example. For this an Identity Server is a must, because in such a decentralised network you have to have keep track of the identities or you will have a heavy risk of massive abuse. The odoo accounting is only connected to the the other transaction engine in case that I run my odoo for a webshop for example. Then of course I wan't to have a Ripple or whatever account in my accounting system and if a customers pays with Ripple I want to track this in accounting balance. You have to think this framework strictly from a kind of client-server architecture point of view. You have different transaction engine and you clients to have a GUI to get access to this engines. Clients can be webclients, mobile clients, clients for users or special ones for the admins. Besides this we need tiny clients for payment purpose only, as payment gateways for shops and marketplaces.

Best regards Lucas

[florent-valeureux]

Hi Lucas,

Your suggestion sounds really powerfull and I assume that Yannick was aiming also the same goal. In your thinking account_wallet should be able to be filled by multiple transaction engines clients. Meaning that they the wallet have a multiple balance one for each engine. Am I correct ?

I understood that today you can already have multiple balance for multiple currencies in the wallet. And so far they are all used by OCE. But Yannick write about a deeper integration of other "payment" engine. This means to me that during an transaction payment engine will bypass the OCE.

If we extend this process to certified transaction engine then I think this next step will filled your expectation ?

[lucode]

Hi Florent, You are right. If the integration of other transaction engine would be parallel as I suggest, then OCE would bypass OCE. That means the wallet and the marketplace could also be used without the odoo internal currency OCE. What would end in an extremely versatile and powerful framework for many organisations and communities. Welcome to Happy Valley, you could say! P.S. I added the missing picture from the mail in my previous comment!

[lucode]

[florent-valeureux]

Wouah Lucas, thank you for the diagram. It is amazing and I think we should do it. I need some moment on my side to discuss with people involved around us. But as in a first row it will be major step for the repo.

[YannickB]

Hello Lucas,

I think we are already on a flexible enough base and everything, from the transaction engine to the Cyclos/Ripple/etc API can already communicate between them.

This base is the accounting itself. To compute the balance for each member for a specific currency, I simply take the balance for this member of the account "availability" defined in the currency configuration.

This way, any feature which create an account move can modify the balance of a member. A transaction in account_wallet simply take an amount from the availabily account from a member to move it in the availabily account of another member.

We plan soon to create a specific product for the native ecommerce module which will be linked to this availabily account. This way when you buy this product on the ecommerce through paypal for exemple, it will automatically credit your availability balance. I can do it very easily because I just have to create the good account move and the ecommerce module can do it with very simple configuration.

For your need it will be same. Just create your currency in the system, cyclos, ripple, etc... and create a connector which at the transaction will create the account move needed to update the balance of the member.

What do you think?

[lucode]

From this perspective you are possibly right, but I can't really imagine how cryptocurrencies, for example, would really fit in the existent framework. But I can understand now the concept a bit better and I think it is a very good start. It would be necessary to have asap a proof of concept for Ripple or OT to really get a picture how it could be done. I will try to challenge some people from the crypto scene to take over such a task.

[YannickB]

Great! We're looking forward to it, we know we have a great potential and synergies with cryptocurrencies but we don't know exactly how yet. Feedback and ideas from crypto passionnates will be really interesting I think.