Payment Methods for Standing / Repeating Orders

Software improvement 5-Done
1

Continuing discussion from Standing / Repeating Orders

When a Customer sets up a standing order they need a way for payments to be processed against those orders.

For the MVP, we are proposing to create a customer account that they can have a balance in that is drawn down against the orders. (@oeoeaio @danielle - is this specced somewhere?)

However, we think that a full implementation should allow for customers to set a credit card that is debited as the orders go through (fairly standard practice in bigger hubs), particularly as the ‘wallet’ system may be problematic for users with less money. We need to spike this, as not clear how best handled or how difficult it is.

Considerations:

  • OFN currently doesn’t (and ideally will never) store credit card details
  • different OFN’s and different Enterprises will have different preferred payment gateways
  • currently, Paypal is the closest to a ‘universal’ gateway - if we get this working with paypal, every instance can use it, and then people can adapt to preferred local gateways
  • customer should not have to logon, go to the site or do anything to make a payment happen. They should be able to set it up and have it happen as part of the auto-order processing
  • proposed design for standing orders allows for changes to orders within the order cycle, so the required payment for a particular order might regularly vary from the original standing order
  • also discussed changing prices on products (particularly ‘extras’ e.g. not set boxes), and agreed that these price changes should be passed on to the customer, so is likely the cost of a standing order would change from week to week even if the customer made no changes. As the customer will be able to modify order before it’s actually processed, suggested a standard ‘disclaimer’ in notification email that customers should check and remove any items that are too expensive for them that week (for example)

Here are some options for how this might ideally work, for @maikel to then consider whether / how could be implemented, first with PayPal and poss. also consider the other Aus supported gateway (Pin Payments)

Option 1: Pre-authorised flexible payment

  • Customer sets an authorisation for OFN / Hub to send payments through
    • Ideally allow for any amount, and this amount is just debited when the orders are finalised
  • BUT most likely there would be security considerations / barriers to this
  • Customer sets an amount to be automatically debited for orders e.g. ‘up to’ $65. If is above that amount, then they have to actually login to authorise payment?

Option 2: Pre-authorised set payment

  • Again, Customer sets their ‘up to’ amount, but is different from above in that that EXACT amount gets debited with every order.
  • If order is less than that this week, total amount is processed and surplus goes into customer ‘account / wallet’ in OFN, for use against next order
  • If order is greater than that this week
  • check account and draw from account AND paypal to pay for order
  • if is enough, no worries
  • if insufficient
    • have a set ‘tolerance’ to allow the order to go through but a manual step likely needed to deal with account owing before next week (e.g. notification and account top-up)
    • OR notification to customer that they need to log in and authorise to go through

Option 3: Subscription

  • Customer sets a weekly / monthly subscription payment e.g. $50 per week
  • This goes through regardless of order and tops up the customer account
  • Orders are then processed against customer account
  • Would want some kind of warning if customer account went under or over by too much

Functional Questions:

  • NB. Note that the ‘account/wallet’ operation is probably important alongside this, should be specced in parallel
  • Assume Customer has an account with each Hub / Producer and can only debit / credit within that account. There is no ‘global’ OFN account that they can store money in and spend from. Are their paypal / credit card details stored against enterprise or ‘instance’ e.g. if they have signed in to authorise one Hub, do they keep having to do so? (think so)
  • OR an instance has a payment gateway against which credit card details are stored, users ‘authorise’ this and OFN can then apply to enterprises? Think this would make each OFN instance more vulnerable but may be smoother for customer
  • If we do this using Paypal, does it mean that every Enterprise needs a paypal account? (no, they can use ‘account/wallet’ system instead, but can’t store credit card details)

Tech questions:

  • is this a case of creating a new ‘payment method’ with additional fields? e.g. ‘up to X’, ‘customerID’, ‘auth token’ etc?
1 Like
2

Thanks @Kirsten this sounds great. I have an opinion on how this would best work for Stroudco but I am deliberately becoming a lot more marginal in the Stroudco decision-making process as @Oliver is doing such a fantastic job of running Stroudco so I will be very happy for him to have a separate opinion and you should give his opinion more weight than mine if they differ!! So with that lengthy proviso…here is my opinion:

I think that Stroudco would ideally like to offer shoppers both a variation on option 1 (above) as well as option 3.

The variation is that if there are security barriers to debiting any amount then instead of the shopper having to log in if their basket exceeds the limit they have set, that we invoice them for the difference. Oliver has set up Quickbooks Online to send all Stroudco shoppers an online invoice which seems to be working well.

About 20? Stroudco shopper pay in a regular standing order to top up their Stroudco account and the Quickbooks invoice shows how much of this balance there is remaining or how much needs to be paid if this balance has run out.

It would be great if we could use GoCardless instead of Quickbooks

Thanks @maikel for taking this on - it will definitely help improve Stroudco’s turnover

3

Stroudco would do this entirely outside OFN, so not much useful feedback to add from our side. I can imagine the different ways hubs handle money must vary considerably. It sounds complex to develop and potentially much less work for the user to take the money “manually”.

4

The veggie box schemes I used in the past had invoices coming with the box. You could do a normal bank transfer after you received the box or pay cash if you picked it up from the store. That are the low tech solutions.

1 Like
5

@Kirsten can we close this wishlist as it seems the feature candidate has been implemented? If some other need is not cover we can open a new wishlist proposal.

6

I think this is supeseded by subs and can be closed