Back in India too I am trying to think through the legal/tax issues of setting up a hub.
To begin with, we are targetting a more informal space, and if we ask the hub managers, along with coordination between producers and consumers, also to manage tax & business organisation registration etc, would be a difficult to get them started.
So as @MyriamBoure says, “service provider” category fits fine and might navigate through the legal/tax issues for small sized hubs.
But as some other people said, not sure how fair would be it to push producers to register for certain payment gateway services.
Also in India, I dont see Mangopay still being on the verge of launching.
Stripe has just decided to launch and would take sometime to come up, but meanwhile we can go around by using some other country registration, if that is the only hurdle.
There are some local players like Payumoney which is widely used in India, and has this feature and also Citrus .
I am at this point not sure of financial commitment, but will try my best to pool in support in terms of resources for development & testing.
@Kirsten Ok, I didn’t get a very precise answer from Mangopay but the guy told me that we need to have “host” in Europe to sign the contract with Mangopay, but then the payment gateway supports multiple currencies and cash-in/cash-out in multiple countries…
So it seems that any other country could use Mangopay through one instance based in Europe who would agree to be the “host” for the Mangopay contract.
For example if UK would play that role, Mangopay would sign the contract only with OFN UK, and the other instances would “buy” the payment gateway service through OFN UK… I’m not sure what it implies in term of paperwork on the part of the host. And I’m a bit surprised that for example OFN Australia could use a payment system that has not been approved in Australia. I’m also afraid it’s bureaucracy we would like to avoid, to have those kind of global host for payement solutions…
If that doesn’t work we still have the Stripe option, which seems to be more “international”, but I don’t know any company using their marketplace solution (In France they all use Mangopay), and I had a feedback from a developer saying that Stripe integration was a mess, but maybe we should have someone more technical look at it? @fraschelo any feedback about the Stripe marketplace solution on your side?
@sreeharsha it seems the payment systems you mentioned only work for India 
But I guess the important here is to make sure that the logic of those payment mapping solutions / marketplace solutions have similar logics so that the work done in adaptating the processes can fit different payment solutions?
Update from Mangopay: “It’s possible for an Australia enity for example to use the host contract based in Europe, but you need to consider the currencies we support for the moment, and unfortunately the AUD is not yet supported.”…
@MyriamBoure as you mentioned I think if the backend process of OFN is in sync with the process of distributing the amount to multiple producers/sellers, we can figure out the integration with a local or international partner.
I an sure, not everyone will stick to one payment gateway for various reasons as discussed above.
@MyriamBoure
Since were talking payment gateways, what are your thoughts on moving forward with stripe? Do we need to do Mangopay as well? UK have some budget for stripe and potentially marketplace payments so would be great to be on the same page.
@lin_d_hop sorry for the delay in my answer, I was disconnected for some days 
I answered directly in the other discussion. If Stripe Connect provides the same features than Mangopay and is available in France, that’s fine to me to start with (I think the rates are pretty similar) and I agree that it’s a better option to start with as it’s more international. I couldn’t see clearly how the Stripe e-wallet and flow mapping works in comparision with Mangopay, I guess there are also some legal constraints as they use e-wallet (like we have to ask suppliers official registration document for the creation of their e-wallet… that’s how it works in Mangopay, I guess there is something similar in Stripe)…
@lin_d_hop Given the latest answer from @oeoeaio (Integrating Stripe into OFN) It doesn’t seem that Stripe answers the requirement… Stripe doesn’t do the multi-vendor marketplace job So we will need to find fundings for the Mangopay job. @oeoeaio @lin_d_hop do you think we can have a more precise quotation for the Mangopay job? So that I can see where I can find money for that in France:-)
Do you think the job list I started above is exhaustive, in terms of impacts on processes?
is it maybe a problem that doing a quote for the mangopay job is in fact ‘a job’ as it will require quite a bit of thinking?! @oeoeaio do you think it would be half day or more like a day to do it properly? any idea?
Hi @Kirsten, @danielle, @oeoeaio
I would suspect actually speccing this work would take a lot longer, closer to 2 or 3 days.
Checking with the UK management team, but I’m hoping UK can pay for this specification work.
@oeoeaio could you quote for how long you would feel comfortable with for the spec of this functionality?
Thanks,
Lynne
Will check with @oeoeaio this week and get back to you @lin_d_hop. With this and multilingual switching and all the standing orders work (and the couple of PRs I think we’re still working through) we’re pretty full up. Going to chat with the team tomorrow and get a clearer view on when we can get all this quoting into the pipe and done as well as delivering the rest. Stay tuned.
Hi gang, @MyriamBoure, @lin_d_hop, @danielle. Apologies for being off the radar a bit.
Also pinging @stveep, as implementing the gateway is likely to have similarities with the work done for Stripe.
I think @MyriamBoure’s breakdown of the tasks at the top of this thread is pretty good.
Part A is the implementation of the basic Mangopay payment gateway. This will be similar to the work required to set up Stripe in a lot of ways. I am unsure yet as to whether Mangopay offers an equivalent of Stripe Connect (ie. allowing the instance to create payments on behalf of enterprises through a single API key). Scoping this part of the work (ie. understanding the capabilities of the API, and how we will need to implement it) is likely to take a similar amount of time to Stripe, so perhaps 3 days.
Part B represents the work required to allow payments to be split and distributed to the appropriate places. B1, B2 and B3 are the changes that need to be made in the OFN to allow this to happen. I can’t think of anything else that will be required as yet, but maybe something else will come out of the scoping process. I would like to allow 2 days for scoping to cover any unforeseen requirements for this feature.
B4, B5 feel like things that should be handled outside of the OFN, ie. enterprise users need to be responsible for ensuring they comply with Mangopay’s requirements before attempting to use it through OFN. Is this reasonable?
Just so that I am clear @MyriamBoure, are you saying that C (discounted rate across instances) is something that will be possible, or that it’s something we should try to investigate?
Thank you @oeoeaio for taking the time to give a first look at the Mangopay case
For B4 at B5, I’m not sure that can be done outside the scope of OFN, I think we need to understand better how the API work to be able to answer that. Mangopay has a legal requirement for those “official document” (they have banking authorisation so need to comply with according law) and I guess they would have implemented their rule in some automated process… So maybe a user who has bought for 2500€ won’t be able to pay anymore until he has uploaded the given document. I guess it’s the same for registration process for supplier, I think the API make it compulsory for a producer to have uploaded some document for his e-wallet to be activated. So my first bet is “that is within the scope”… but you will see in work A I guess!
If you want I can call my contact at Mangopay and ask for this specific information.
I can also ask more precisely about the discount rate, the guy told me about it, the rate depends on volumes, so if we have only one account for the whole OFN sub-accounts, we benefit for volume discount. This is likely to happen only when we have enough transaction though, and in that case we need to have one OFN instance who is the “host” of the mangopay contract (I guess payments though can be done via each instance, so I guess it’s just a “legal host”)
I will ask those two questions anyway and try to come back to you with a more precise answer.
@oeoeaio I got an answer from Mangopay:
Bonjour Myriam,
Merci pour ton message. Ce sont donc des bonnes nouvelles !Pour répondre à tes questions :
1/ Legal documents:
The ideal is to automatize our process and the upload of the documents for our users. Nevertheless, it is possible to upload the legal documents from the dashboard (example here : https://dashboard.sandbox.mangopay.com/).
2/ Prices:
The commission/price that we will negotiate together will be valid for the whole OFN network. You can choose if you want to sign one contract with one entity, or if we sign a contract with each OFN entity. The important thing to know is that if you have various ClientId then there will be various environments, various access to the dashboard, etc.
That sounds pretty cool, it seems flexible
I can put the person who will work on the integration in touch with my contact at Mangopay if needed… is it you @oeoeaio who is going to coordinate that?
When we decide to move forward someone need to manage the negotiation about the price/rate of commission. I’ll be happy to facilitate that, maybe alongside with someone from UK for example? @lin_d_hop @NickWeir
Hi @MyriamBoure
I noticed you put this on cobudget. I was wondering which project exactly you have budgeted for there? Is that for the estimate? Estimate of estimate? Payment gateway integration without any of the bespoke UI functionality required? Or the full implementation as per a spec based on the conversations above.
Sorry, I’m confused… help
Hi @lin_d_hop! Ahah, I put that as an example to play with Cobudget, but it was nothing real, I had no idea of the amount, so I just archived it, so that we can do it properly with a consistent amount, and real contributions
Sorry for the confusion
I’d like to explore in a bit more detail how this feature might look to the users. I’m very interested in reflections, corrections, comments and the like
I’m going to refer to it as Mangopay, but of course if we choose another payment gateway with suitable functionality then the name is interchangable.
For the customer:
-
The user will have Mangopay available as a payment method. Ideally this would be the ONLY payment method. Unfortunately for established hubs this might not be possible (users become used to their buying patterns ie paying a cheque on collection). This might be a blocker for some hubs, but I imagine also a blocker for implementation. Potential workaround It might be that to enable taking cash/cheques the system will need to process payment from the Hub account to mangopay. This sounds risky, but might just be necessary for established hubs, a payment method that is only allowed for customers tagged as such. Essentially it is no more dangerous than what hubs currently do (proceed to order from producers despite not having received payment).
-
The users card details will be remembered such that they don’t need to be entered each week.
-
Their payment comes out instantly.
-
Corrections and adjustments for undelivered produce etc are refunded. How does OFN handle this? In this case does mangopay keep the overpayment in the users e-wallet? Or refund? Or does the API allow us to specify. I feel the easiest will be a refund to the customers account with no credit stored anywhere, if mangopay facilitates this.
For a producer enterprise supplying a hub:
-
In the Enterprise Details menu bar a new menu item ‘Payment Details’ is added to the list.
-
Producers enter their bank details into the fields here to such that Mangopay payments will be made to this account.
-
If Mangopay is enabled and producers have not entered their bank details, payments defer to the Hubs bank account. I suspect this will be necessary to enhance the utility of this system as some producers in established hubs have specific payment methods.
-
Producers receive payment after the sorting of produce and the hub has processed all received items.
For Hub managers:
- Setting up Mangopay for Hubs
-
Communication of what users are enabling by using the Mangopay payment method will be very important. We will need a process to ensure this is understood or potentially a way to limit Mangopay as a payment method to specific users.
-
There needs to be a transparent overview of where all the money automatically goes, including Mangopay fees, instance fees, which producers are having payments made to their account directly and which producers are having payments made to the Hub bank account (in the case producers want cash, for example).
-
Enterprises need to meet the legal requirements of Mangopay, ID and registration as detailed in the description of this issue by @MyriamBoure.
-
Enteprises receive an invoice from the instance for their payment.
- Processing Orders
- Upon receipt of produce hub managers will process produce received. This will need to be reflected in the software and my feeling is that it will be important to distinguish ‘Qty Ordered’ from ‘Qty Supplied’. The payment to the producer will be based on the ‘Qty Supplied’.
- Once all produce has been marked as received hubs can pay the hubs. This could be as simple as a button with pop-up confirmation.
- Handling Customer Complaints
- Inevitably some customers will complain that something was not right, something not delivered etc. We need to be able to manage this refund to the user after the producer has been paid.
- Reporting
- Enterprises will need to easily be able to see if any payments failed, how much went where, etc etc
For Instances:
-
Mangopay can automatically deduct the Instance fee and have this automatically paid to the instance account. This means that integration will couple with implementation of specific business models. This needs to be thought through as we already have a vast combination and still there are more being explored.
-
Instances need to have a good understanding of the legal implications, responsibilities and the capacity to fix payments if they are incorrect. Who will be fundamentally responsible for incorrect payments if a bug makes it to production on an instance?
In the global context:
- This will create additional testing pressure as Mangopay functionality will need to be well tested in affecting changes. In particular changes to tax, adjustments and business models will need to be sure to flow through correctly.
@lin_d_hop as I had comments and it was hard to comment on the Discourse discussion, I opened a google doc and copied your text, and add comments and suggestions in it: https://docs.google.com/document/d/1LNl8KS0AO-FqaGbjlf5E3o_RXMENWoxHGNGOhe3mVWU/edit?usp=sharing
I suggest everyone use the “suggesting mode” to make suggestions and comment, and you curate the document (accept suggestions, modify the spec, etc.) so that we can have some “dynamic co-construction” on it… anyway, as you want, for me it was just simpler like that 
Cheers!
I have added my comments and suggestions to the google doc including a suggestion that we set up a hangout with one or more people who are managing Food Assemblies and ask them how it works in practice. I could probably get Elaine from Agergavenny Food Assembly to help.
I will ask @Oliver if he would like to chip in on this discussion
Here is the link to the worldwide pricing. https://www.mangopay.com/en_UK/pricing/pricing-worldwide/
It seems that Euro countries will have it easier than us, as they have free ‘cash out’ unlike the UK and Norway.
I am not sure how we will mange the cash-out part, as it will vary depending on the frequency a producer/hub/instance wants to withdraw funds from their e-wallet.
The fees look attractive but the implementation complicated.
Does the cashing out fee apply to each payment that goes to a supplier? Or will they all set up their own Mangopay e-wallet? (as if they would!)
If the money goes through the instance than this will be a big turnover which may or may not be an issue depending on the country. For example it may force them to become VAT registered when they wouldn’t otherwise need to. Conversely, it may help the hub if their turnover is no much lower.
The old Stroudco software required us to confirm what items had actually been supplied by the producers and in that sense it already distinguished between qty ordered and qty supplied but it was just an additional admin hassle. Granted, OFN could use this feature better but I’m not keen to go back to it.
If we do it, we certainly need to be able adjust the amount due to a supplier before they get paid.