How to offer Mangopay as a payment method to hubs? [Split Payments]

Tags: #<Tag:0x00007f79fff70ca8> #<Tag:0x00007f79fff70af0> #<Tag:0x00007f79fff70898>

We need to offer the hubs an e-wallet option as a payment system. It’s a requirement at least in France, as lots of hubs can’t be considered as “intermediates” (they can’t collect money and pay the producers), they are considered as “service prodivers” for the producers, and legally paid by the producers to find them clients. Cf: Generating a compilation of one invoice per producer for more details.

Also, some very good points with an e-wallet solution like Mangopay:

  • it simplify the life of the hubs manager as he doesn’t have to manage payments (receive money and pay the suppliers) > time saved
  • they are much cheaper than Paypal (Mangopay starts in france for low volumes at 1,8% + 10cts and then less, while Paypal is at 3,9%+0,25cts)

So I know both Norway and France want to be able to offer Mangopay (and/or Stripe, similar products) as a payment gateway option. I saw also UK might be interested (@lin_d_hop you mentionned it somewhere I think) We would like to evaluate the work needed to be done and the time/cost estimate, to see if we can crowdfund / find volunteer, or a bit of both.

How it works: the money paid by a byer is kept on a “virtual provision account”, and given the process we encrypt in Mangopay, for exemple, when the sales is validated by the hub manager the money is dispatched in the right amount to the different producers, the hub account, and the instance account.

Here is what I see as a job:

A- Understand and connect the Mangopay API

Here is the technical document to integrate the API: https://docs.mangopay.com/

B- We need to develop some pieces of code to adapt the processes to this new option:

1- If we agree about the process (=the money is dispatched when the sale is validated, so that if adjustments, are done before the money is send everywhere) it means that we need somewhere a button (in the order cycle?) "validate delivery and send money"
2- As the commission taken by the hub and paid to the instance is managed through entreprise fees, we need to be able to tell the API the rule about the calculation for sending the money to the hub e-wallet and the instance e-wallet. Alternatively, if it’s simpler, we can keep the instance fees out of this and stay on a seperate invoicing process… In that case I guess that all entreprise fees will be dispatched to the hub e-wallet… Or if we can manage the instance as an entreprise and give the possibility to all hubs to add in their order cycle the fee from the instance, then the rule could be “the entreprise behind the entreprise fee receive the money”
For info, Mangopay will contract with the instance, not with every hub, and the invoice from Mangopay will be sent to the instance, so the instance need to be able to collect the money (either directly, or added in the invoice sent to the hub using Mangopay > invoice to hub system to adapt in that case)
3- The invoicing system must be adapted, as in that case, we need to have the good invoices sent in every direction: the client receive an aggregation of one invoice per producer, the producer receive an invoice from the hub for the business provider operation, the producer (or the hub?) receive an invoice from the instance for the use of the platform.
4- We need to change the supplier registration process, as every legal entity using a e-wallet is legaly required if they have more than 1000€ in their wallet (will be quickly reached) to be officially registered (the e-wallet is like a bank account) so we need to add some fields in the producer registration process (copy of some official paper, by-laws, etc).
5- For buyers, the threshold is 2500€ per year. When reached, the buyer is asked to upload a copy of its ID (we can customize the email sent and explain why)

C- We can have a degressive tarif based on the global volume made with Mangopay on all the OFN instances

So for example, if Norway, France and UK sign a contract with Mangopay, the rate applied will be based on the global volumes.

Complement document from a year ago (has probably changed a bit, but clear to understand): https://drive.google.com/open?id=0B_HDFsX1e_2VYmZGdWtVQ1o5WEE

@danielle, @oeoeaio, @maikel, it would be great to have your feedback and an idea of the time needed to do all th job, and an estimated budget? Then we can see with @nickwhite and maybe other smart guys if they have a bit of time to dedicate to it on a volunteer base (I know Nicolas is still on the internationalization job) or else we can see if/how we could crowdfund the job. Some hubs in France are starting to apply for funds for their project, maybe they can add a line to develop that feature they need :wink:

I talked about Mangopay here, but I know Stripe offers comparable services (but I feel Mangopay is more famous used in Europe)

Ping @CynthiaReynolds, @sigmundpetersen and @LucieB

Hiya @MyriamBoure, nice work on summarising what needs to be done :smiley:

@RohanM, given you were involved implementing stripe would be keen to hear your thoughts on this. Will it be as easy as implementing stripe was, or will a gateway need to be built?

@Myriam, I won’t be able to let you know about an estimation until @RohanM has given us a little insight about the complexity of implementation. If it’s as easy as Stripe then it shouldn’t be too hard to provide an estimate. If it requires the development of the gateway as well then it will be a far more complex beast to develop (and therefore estimate).

Have you already implemented support for Stripe?

Mangopay does have a gem so the payment gateway itself shouldn’t be too hard.

The difference with this task as Myriam outlines is that the idea is to directly pay producers, automating the step in which the hubs process invoices and manually pay suppliers. The complexity of this will be the payment rules and mappings, ensuring that it is configurable and the right money is directed to the right places in all cases (even when products aren’t delivered after being ordered or the weight changes, correctly allocating taxes and fees etc etc). The mind does boggle.

The other complexity is that to enable these marketplace payments all producers for a hub will need to be registered with Mangopay, and from experience of EU regs on payment providers there can be all sorts of hurdles in the way of this that pop up at the most random times based on someone changing their mind in Brussels.

I would love to see this implemented, as would a number of local food projects I have spoken to… but I think it’ll be a sizeable piece of work.

@sigmundpetersen I think what Danni was thinking of was Pin Payments, not Stripe. However, as Lynne pointed out, adding another payment gateway is straightforward, and can often be done with maybe half a day’s work.

The tricky part is when we look at distributing the money, for the reasons that Lynne mentioned. Would it be possible (meet legal requirements) to distribute the money manually at first?

1 Like

@RohanM no it’s not, that’s actually why we want to implement it, to avoid to distribute the money manually :slight_smile: And also it’s not legally possible and that’s why we need that tool, the hub cannot be considered as a middleman in lots of cases in France, but should be considered as a business provider for producers, the money can’t transit through the hub… So we need to “map” the flows of money, but I don’t know how this is done technically and if it’s complex or not, I suggested some ideas for the processes above… So the purpose here is to detail the job needed to be done so that we have an estimate of costs/time and see how we can co-finance that with the instances interested… but having a look at the way the mapping is technically done through the API might be needed :wink: And I guess we need to agree on the process for those e-wallet types of payments (cf my proposal)

@lin_d_hop, the way I see it is that we tell the Mangopay system that when client X buy to producer Y, the item_price (the first line in the price breakdown) goes to the e-wallet of the producer, the fees goes to the hub e-wallet. And the money flow from the client e-wallet to the others when the hub manager “validates” the sales, after all adjustments have been made. So if some products have not been delivered, some money will remain on the e-wallet on the client, that he can use for the next round, or be paid back. That would be the easiest process for me, keep out the instance paiment with a seperate invoicing process. But we need also the producers to put some official papers when they register, as you say, but as far as I understood it’s only some registration papers… Should we ask that to all the producers? Or just add the fields in the producer profils, and it’s the hub manager role to ensure the producers put their official stuff online if (s)he wants to use Mangopay? And then we map those fields in the Mangopay API… For this I guess we need to see how the API works :wink: Maybe if the hub chooses that as a payment method, an email should be sent to all the producers connected to the hub to ask them to create their Mangopay account (I guess it’s in the API…) but do we need to develop a piece of code for that to happen that way? Is it how we want it to work?

I don’t think we should force anything on anyone, but we should offer e-wallet solutions to those who want. If the Customer (C) wants to use Mangopay (MP) he chooses this at checkout, and if the Producer (P) wants to receive payments through MP it registers its MP account in the admin interface. The system calculates the rest.

Those Cs in the OC that haven’t registered MP need to be invoiced manually (the invoices should preferably be precalculated by the backend and be possible to send directly to the C by mail through the interface). If the P hasn’t registered MP it needs to invoice the Hub manually so this will be an incentive for Ps to register an MP account. The Hub of course needs to temporarily cover the mismatch in totals between C and P totals in its e-wallet.

Also I think the instance manager could have e-wallets where the platform fee goes automatically in the same validation operation.

I cannot see why Hubs in France can’t operate as businesses legally and handle the money flow. Either way it receives transaction fees, why is this OK and not the other @MyriamBoure ? :slight_smile:

@sigmundpetersen technically it is not possible that a hub offers Mangopay + another payment system as an option. Either the paiments are mapped and distributed automatically, either they are not, and for the hub manager, it’s even more complicated if he has to manage two different systems on one sale, in that case he shouldn’t offer Mangopay (and anyway technically it’s not possible). A hub manager who choose to use Mangopay either wants to simplify his life (not manage money transactions at all) or can’t legally be a middleman (then he can’t offer another paiment system).

Please read my original post, I put the link about the reasons why we need that in France, and that’s also why you need it in Norway I guess from what I understood (difference between a business intermediate, you buy and sell, and a business provider, the producer pays you to find clients) :wink: It’s just that in France there are thousands of alternatives models already operating, they told us from the beginning they can’t collecte the money and pay the producer (legally) so we NEED Mangopay or we won’t do anything in France…

I don’t know where @MyriamBoure has gone with this, but it might be worth seeing if we can both make Paypal’s adaptive payments system work. It does split payments but might need some rejiggering for the accounting methods outlined as included as part of MangoPay. If it were implemented in the core branch it would work everywhere Paypal Business accounts work. And it would work across international borders I think? (E.g. Norway/France/Germany/Spain/etc.)

https://developer.paypal.com/docs/marketplace-split-payments/

None of us loves Paypal, but I think it could help a lot of people get started a lot faster…

@eric here is what I found on Paypal adaptive payment system:
It seems there is a limit in the numbers of receivers, 6 (parallel paymentsà or 9 (secondary paiments, where the hub is the middleman)
https://developer.paypal.com/docs/classic/adaptive-payments/integration-guide/APIntro/
I don’t manage to find the pricing, did you?

For Europe, Mangopay is definitely the reference, and very cheap (1,8%).
And I think Stripe is pretty cheap as well and used by lots of marketplaces: https://stripe.com/connect

I’m not on the technical side so I can’t tell, but Paypal appears to me as pretty expensive and not the best user experience… What do you think @nickwhite? Maybe we can ask Cecile her opinion? (a French Ruby dev specialised in marketplaces ;-)) I’ll ping her on Slack :slight_smile:

I just got a confirmation from Cecile, for her Paypal is “horrible to integrate”. For her MangoPay is without any doubt the cheapest solution for the moment, she has installed it a few times. Unfortunately she has no time to dedicate to OFN at the moment but she can give advices and support to whoever would work on it. She has not worked with Stripe Connect.

Your company must be based in EU zone.
Regarding the PAYINS (Cash-in payments), your users can pay from anywhere in the world as long as the country is not black listed.
Regarding the PAYOUTS (Cash-out payments), we cover the SEPA, the UK, the US and the Canadian zones.

I’m wondering if we couldn’t use a European entity to support the Mangopay account as all payins and payouts can be done in other countries… As all those payment solutions get discounts fees with volumes, maybe that makes sense?
I had an email exchange with people from Strip and they also recommended that as well to benefit from degressive rates… but I’m wondering if that is not against the “subsidiarity principle”, that every country should have it’s own tools… but we can also cooperate when it makes sense… don’t know!

@eric what do you think regarding the limit of receivers with Paypal’s adaptative? Tell us also if you find the pricing…

Limiting to 6 or 9 recipients seems like a problem. And PayPal tends to be as expensive as the market will bear.

Balanced, Stripe and Braintree might all be better options here, but international PayPal still seems a very promising avenue for getting anyone anywhere started on OFN out of the box. That would be a pretty massive move forward.

This is definitely something that has been requested and would open us up to new users here, particularly farmers markets wanting to offer an online option but not wanting to take on a ‘hub’ role. I remember talking to the pin payments guy about it a while ago and it sounded quite doable, but as @lin_d_hop says, it’s the interface for enabling people to configure as they need that will be critical.

Pin payments obviously no good outside aus, so not worth doing. but i think mangopay not available in australia, and not sure about outside EU? is it available in the USA and Canada for example @MyriamBoure? I guess ideally we’d come up with some kind of interface that enabled rule-setting, that could then be plugged into the site admin’s chosen gateway - but suspect that might be way too complex.

anyway, definitely a project in itself, and possibly a good one for a sample ‘project-based fundraiser’ because it’s easily defineable, something we know lots of people want and a big jump in functionality

NB. implementing this could be done to enable the site admin, or potentially user, to automatically allocate fee (e.g. 2%) to OFN and get around the whole invoicing thing

@Kirsten here is what I found in there website:

Your company must be based in EU zone.
Regarding the PAYINS (Cash-in payments), your users can pay from anywhere in the world as long as the country is not black listed.
Regarding the PAYOUTS (Cash-out payments), we cover the SEPA, the UK, the US and the Canadian zones.

So it seems they are not in Australia.

It seems Stripe Connect may be a solution that could work for every countries… https://stripe.com/connect
If you look from stripe.com/au you will see the australian prices…
It’s pretty cheap and seems to be pretty adaptable everywhere.
I will contact them to see how that could work for the OFN.
I know for Europe Mangopay is definitely the best choice, but let’s see if we can have some further mutualisation possible on this project if we look at Stripe :wink:

Hi again here!
Do you think we could have an estimate on the work needed to implement Mangopay @RohanM ? Maybe that could be funded on cobudget as this seems to be something needed by various local communities… and the work on adapting the process will be useful for other multivendor payment gateway so it can benefit communities who won’t use Mangopay as well. If it’s easier we can find someone who has already integrated Mangopay to work on it when we have a budget (depending if it’s better to have someone who knows very well the OFN code or someone who knows very well Mangopay ;-))
Thanks!

@MyriamBoure
Hiya!
Why did you change from Stripe back to Mangopay?

Do you have any budget to contribute toward this? The UX design will be expensive. UK would like this feature and are willing to contribute some toward it. I would say we are looking somewhere in the $10,000s area to properly implement and spec (I really just pulled this figure out of thin air so don’t give any weight to it).

I am wondering how much other regions have to contribute toward this, and thus how close this is to getting to the development pipeline. Do you have any thoughts and ideas? I know you need this. How much do others need it?

Also, thorough specification of this feature will be a big task in itself, costing 1000sAUD. Do you have the budget to properly specify so that we can then look at crowdfunding the implementation?

1 Like

Hi @lin_d_hop!
In France for the moment we don’t have any budget, the project grows in a pretty organic way, but we are setting up an entity now and will work on fund raising in the next months. I think OFN has really an amazing potential in France given the interest we receive and the first partnership proposals. So yes this is something that we really need in France, but for the moment we have no budget and I can’t tell when it will come. I think Norway might also want to contribute to this feature, @CynthiaReynolds and @sigmundpetersen I let you answer for Norway.
I think Italy also need it? @fraschelo am I right? I don’t know though if you already have a budget to contribute with…
Basically all European instances would need this Mangopay integration…
Stripe could work but it seems more complicated to integrate, and Mangopay is really the “standard” in France now for marketplaces, while Stripe is not so common…

@MyriamBoure if mangopay is such a strong leader in eu, it might be worth contacting them to see if they have any plans to go outside europe and explain how this is holding us back from using?

This is big . . I think we need to make sure that we’re thinking about this use case alongside the payment in standing orders (which we’re working on in shorter term) to make sure that we’re setting up a pathway / gateway that works for both

@oeoeaio @danielle just making sure you’ve seen this thread as is relevant to discussion next week

1 Like

I just asked them, will tell you when I have a feedback…

Of course @MyriamBoure!

Here in Italy we have exactly the same legal issues as France, hubs can’t be considered as “intermediates”, they should be considered as “business provider” only.

I’ve ask to a friend-developer about Mangopay. He told me that it could be a good payment technology, even if it’s not so common (in Italy at least). It also has “gem”, not bad!

If it’s useful I could ask him to estimate the work needed to implement Mangopay. Let me know.

We haven’t a budget yet, I’m waiting for LAG’s Call for proposal (Local Action Group) but it’s taking longer than I expected.