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
3-payment
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 
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
- Build basic interface for management / viewing of this (see
Enterprise Index Rebuild) - 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)
- Build report to spit out info in csv for importing into accounting package
- 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
- 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)