Business model configuration

Each instance of OFN will have its own business model. As we get further into this, there will be aspects of the business model that are best managed as super-admin users in configuration, and some perhaps best managed by developers turning config setting on and off.

Work is underway to have a customisable / CMS front-end so the messaging, text, blog etc are easily manageable by the instance manager. Other questions that instances / organisation might have different answers to include:

  • should Producers be able to sign-up themselves? for profiles? for shops?
  • should Hubs be able to sign-up themselves?
  • can anyone set their enterprise to whatever type they want?
  • how much should different enterprises pay, and how is this managed?
  • do we need different reports if people are trying to extract info to invoice users

The most immediate question of these is the third - how much do different users pay, and how do they pay?

An increasingly high-priority for the Australian team is to set up a payment module (for users) within ofn itself, so that we don’t have to extract user info and invoice, and so we can use the existing payment methods in the system to collect this money.

I’m outlining below a couple of possible approaches to this - hoping to stimulate discussion on which ones best lend themselves to customisation in different instances - speak now or forever hold your peace . .

As an Enterprise User, I can see how much I will / have been charged

Calculating payments

The factors likely to affect payment structures for every instance are:

  • User is Owner of one or more Enterprises (the Owner is responsible for payment}
  • ‘#’ of enterprises a User owns
  • Enterprise ‘Types’ of those Enterprises e.g. are they selling products online or not, their own or also others
  • Turnover in a given period

I think we need a basic structure to reveal this, with ability for the ‘rules’ to be configured at an instance level. So the view could be something like the sketch below, with the circled numbers being customisable at instance level - see sketch

The ‘rules’ are then set at each instance. So for Australia,

  1. Monthly cost is 2% of turnover capped at $50. Only complete months are payable
  2. We want an additional payment structure which is an optional extra service package e.g. extra $50 a month
  3. How do customers pay. Easiest way to do this for Aus at the moment is to put a link to a pin payments form and they just enter credit card. I suspect we could pretty easily send it through to any payment method in the system (e.g. paypal)

Where does this form go?

Option 1: My Account

As a logged in User, I already have an Account page, which currently only shows my previous orders. We could we start the process of turning this into a User Dashboard - separate this into multiple tabs so that we have My Orders, My Shops, . . and one for My Enterprises

The intention is to eventually turn this page into a Customer Dashboard, with more social elements (e.g. ability to follow Producers, Hubs etc) . . so I suspect it might be confusing to start managing ‘enterprise-side’ functions here

Option 2: Enterprises tab

Pros: quite a lot of the required info is already here, but this page is pretty clunky, and perhaps even increasingly obsolete, so we’d probably just be making a mess

Option 3: Enterprise Type Selector Dashboard?

We’re about to give this an overhaul (including working out how to make visible to multi-enterprise owner), would this be the best place to access account and payment info?

currently can’t even see it if you have more than one enterprise, will update this when i have a screen shot


  • could something like this work for your proposed business model?
  • anything obvious we should tweak to make it more easily adaptable?

@NickWeir @lin_d_hop @CynthiaReynolds @MyriamBoure @lawrence

Thanks @openfoodnetwork for that reflexion and opening the discussion :smile: Here are my comments!
Globally I think the reflexion is logical and fits pretty well our need as well. But I have some questions/comments.

For the service package, we are thinking in Scandinavia to charge a fixed amount per month on top of the 2% commission, only for the “hubs” (either selling own or any), if the entreprise is not a member of Altifrem (the non-profit that drive the project here). The problem is: how do we know in the system if the hub is a member or not? Can we have that info somewhere in the hub properties, that we can manually change (until we can connect OFN to a CRM ;-)) so that the “service package” can be calculated? Is it what you mean by “the instance will be able to configure the rules”?

3 comments on that:

1- e-wallet systems don’t require hubs to pay the instance
I’m investigating about Mangopay right now. The service they provide enable the “owner” of the platform (for example Altifrem for OFN Scandinavia) to “map” the circulation of money so that the money can be directly sent without the hub having to do manual payments. That is the system used by Farmdrop by the way. For example: a buyer pay for 100 of products (20 to producer 1, 80 to producer 2) + 10 for the hub (admin fee) + on top of that, 2% of the total due to OFN (could be integrated in the hub, so that would be 12,2 for the hub, but I don’t see why this shouldn’t be transparent also). So the amount the buyer pay is 112,20. When he pays (regular interface), the money goes through his e-wallet, to the e-wallet of the hub, who just have to validate when the order has been delivered (or can change if a product has been missing so that the amount concretly taken is adapted, so no need for vouchers). When he validates, the amounts are automatically redirected to the e-wallets of the entreprises who should get the money: 20 to producer 1, 80 to producer 2, 10 to the hub, 2,2 to OFN instance. And each one transfer the money from the e-wallet to their bank account when they want. Of course, we need anyway to send them the invoice but there is somewhere a “contract” that tells that they are paying a 2% commission, so we don’t need them to validate the invoice each time, no? With that solution, no need to ask the hubs to pay, the money is distributed directly from the final buyer payments, following the rules we have agreed on.
Of course a hub can choose another payment system for his operations… in which case we need to have another option for them to pay. I don’t know if Mangopay proposes the same “payment form” as Pin payment does… but anyway there are various options for that.
In any case, even if a hub has chosen Mangopay, with what you propose, he can have in his dashboard the infos, even if he doesn’t have to pay online because it’s already paid… we just won’t have the “Pay now” in that case.
I am still investigating about that option, but it seems pretty promising. I know them through OuiShare, they work with lots of P2P marketplaces. And they take only a 2% commission for non-profit, so all the hubs could benefit of this tarif as it’s for the whole platform (through paypal it’s more around 5% if the hub is not non-profit)

2- Is the fee taken by the OFN instance tranparent for the final buyer?
I ask myself this question when reading your explanation: the commission the OFN Instance takes is not transparent for the final buyer if we invoice “afterward” the hubs… couldn’t this be integrated directly in the check-out? If I understand well, it is integrated today on the fees of the hub (the hub has to calculate its margin and take into account he will have to give 2% to OFN) but it’s not really transparent then, no? Shouldn’t this be a default configuration and apply to all the orders? Just an open reflexion… we ask everyone to be transparent, so I guess we should be too :slight_smile:

3- Why not keeping the same process as for invoicing by hubs?
Also, another question… why this invoicing shouldn’t be considered the same way as the invoices for hubs? Because the Instance needs to do its accounting also, and it’s easier to generate the invoice in the module connected to the accounting so that its automated. Why not just having, at the end of each months, a report for the Instance, with, for each owner, and for each entreprise, the total turnover, if there is a service package associated to the owner/the hub, etc. And we can import this csv and make the invoice through the accounting system? I agree that this doesn’t prevent us to offer an interface for the hubs to pay the amount online to make their life easier, it is more a complement to what you propose.


I’m looking forward to your answers on my comments, and I’ll keep investigating to see as quickly as possible how we would like to operate for Scandinavia on this aspect,but I think what you propose could work for us… if we can export a CSV to send the invoice to the hub, and if we can desactivate the “pay now” depending on the payment method used by the hub.

re. location of this new page, @oeoeaio and I reckon it needs a new page ‘Enterprise Account’ which we can then use for various things, including landing page for newly registered enterprise (selecting types for multiple enterprises etc). See spec here

okey dokey

2-service / member thingo
yes this seems quite a reasonable thing to do. I guess the difference would be how they paid for this membership, or whether you just had ability to turn on/off and set cost to zero or something

yep i get how these things work and for plenty of people that might be what they want, and also for others it might not. I agree we should definitely have an option for this down the track, think there are some complicating factors, but we can start with something that is headed in the right direction. agree with your point about transparency of payment to ofn, and also trying to keep to our core design principle of flexibility to local enterprise e.g. we didn’t want to make them all pay one way, or have the money come through us etc when we set out, which is why this wasn’t the way it was done to start with. But agree it would be good to have it as an option for those that want it

Complicating factors

  • Farmdrop and most other marketplaces have a very simple and set payment structure that is the same for each ‘enterprise’ i.e. the calculation of who pays what to whom can be set at ‘instance’ level and it’s one size fits all. OFN lets people do all sorts of different things, so there’s not one simple calculator to hook up to the mangopay (or other) api. So basically whichever way we do it, we need to build the OFN calculator that works out who’s getting paid what and send this information to whatever payment gateway is going to move the money.
  • for instance level we need to do this as described above, so that people can change how the calculator works to fit their business model
  • for enterprise level it’s even trickier, because each enterprise chooses how they want their fees to work and who gets what
  • There is nothing to stop a Hub putting the 2% (or whatever) OFN fee as a fee into their transactions and collecting from customers. We could work out some way to build this ‘special’ fee so it’s available to everyone, and then ofn could use it . . but this would be tricky to use as the main ‘instance’ calculator as again it is customisable by rules e.g. for aus model would we need to detect and stop charging once the Hub has hit $50 for the month (hard / annoying).
  • Very shortly the sites will be clear about what the payment structure is for Hubs/Producers etc, so it’s not hidden, and then I guess the assumption is that this is built into Hub admin costs

So there’s two issues here

  • calculating and paying for use of OFN by enterprises
  • splitting payments between producers, hubs etc (so Hubs don’t have to manually pay), potentially including payment to instance if that is part of the local instance’s model

As always, complexity increases by factors of flexibility :smile: Usually we find if we sit with it, wallow in it, and take a few sensible steps the complexity starts to fall out into simpler patterns . . so my proposed steps are this

  1. Build basic interface for management / viewing of this (see
    Enterprise Index Rebuild)
  2. Work out the instance level calculator that has enough flexibility to at least spit out the right numbers for what enterprises owe OFN (starting point above)
  3. Build report to spit out info in csv for importing into accounting package
  4. We will have a look at pin payments api, to see if we can set up auto-billing, holding enterprise credit card accounts etc. If we can do this, I suspect it will not be a huge deal to send to mangopay api instead
  5. Look at how something similar can be done as a payment method, configured by Hub, to split the transaction when it happens (e.g. in Checkout)

just a note for later re. relevant pin payments doc for marketplace set-up -

I love this mindset, very agile&lean :smile:
I understand the issues you mention, and I guess the “first small step method” is the best one, so we’ll see on the move, and the steps you mentioned makes sense.
About Mangopay, I don’t think OFN is holding any credit card accounts… check this out with PIN, but I think that’s the interest of it, they are using “e-wallets”, no bank accounts. I will also ask Mangopay on my side and share the infos with you.
The interest with this kind of system is that Mangopay (or equivalent) is a cheap and convenient payment solution offered by OFN to the hubs, not by an external actor like Paypal. It’s an “internal” payment system, but without using bank accounts, we use e-wallets instead, and Mangopay is the banking institution guaranteeing those e-wallets and the connections with the real bank accounts).
But as you say, let’s take it step by step, and also have things to clarify to see if we can really use Mangopay among other payment systems on our platform.

I have some thoughts on this.
1.We can use Tags for Enterprises who payed their monthly fee… Way to make it transparent and stimulate not force.
2.Fee can be collected also as % on orders and we grant Tags as “size of emterprise”. (than we can lower %) Is that easier to implement?
3. On checkout there we can ask people to give bit to all sorts of charities. Also to OFN or exact project of it.