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.
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.
- 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
- 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)
- is this a case of creating a new ‘payment method’ with additional fields? e.g. ‘up to X’, ‘customerID’, ‘auth token’ etc?