Prepaying for snacks/cans etc?

Some recent thoughts on how to get can/snack payments from those people that don’t carry cash (not looking at any @theorbtwo in particular…)


Why not just use a simple card reader like the PayPal one or stripe? Punch in how much it was, get charged, and bang job done

Not overengineered enough? :stuck_out_tongue: Also wouldn’t someone have to operate the phone app end of it?

I stayed at a hotel which had an honour system. You would go into the pantry and write down what you were taking. Put your name and room number on the paper and put it into a box. The box was then collected and added to your bill.
This could be done in the space with “invoices” being posted at the end of each month for people to pay. Failure to pay would mean blocked access to the space.

My idea:

You pre-pay using bank transfer or PayPal with a specific reference that ties your payment to a petty cash field in the database.

In the space is a box with some buttons and a screen. You press the buttons to set a price on screen, then tap your fob. The box queries the database like the door controller does, but reduces the petty cash field of the token’s database entry by the specific amount.

I don’t think it needs to be any more complicated. It doesn’t require any ongoing maintenance, or adding barcodes into memory along with prices. The onus is on the user either way, so we might as well go with the simplest solution.

I’m happy to build the box and possibly programme it if required - I’m not bad with an Arduino but I’ve not touched web/database stuff before. The backend stuff will probably need Jess to handle, but (cliche alert) it’s pretty simple database stuff right? :sweat_smile:

This can also handle minibar, consumables and even PAYG space usage maybe?

1 Like

It could, but personally I’d prefer people pay in advance… else they could disappear and not pay… or we’d have to make a fairly small cap on it…

quite a bit easier to have it be a Pi (from the software side anyway) else you have to manually parse API responses

I could do that, never done any pi programming!

1 Like

Yer i think joe has hit the nail on the head. All how personly i would like a barcode scaner on it. Its more work to set up but less work to use. As thay (as i under stand it) just fier some text back. So maybe not that hard to impment compaited to a ui. (all thow i dont know much about programing) the bar code dose have the advantages of being idiot proof for end user

Yer pre pay is definitely ideal.

All so pay as you go member ship would all so be good but with a few checks and stuff

How about, I do the storage/API part, Joe/others do the user interface/hardware end? :wink:

(You could use python… runs away)

In addition to Joe’s suggestion, we might want

  • Some buttons to select what you are paying for before entering the amount - food, machine time, materials, other.
  • Some way to check your balance on the machine - press the “balance check” button then tap your fob.

On the hardware side, if we’re doing Arduino / embedded, I wouldn’t follow the door hardware pattern of Arudino + ESP because it makes the software more complicated, an ESP alone can do it all (though there was a good reason for the door being that way at the time). However something with ethernet might be nicer to avoid wifi problems - which could be Raspberry Pi, or arduino+eth shield, or … Whoever does the hardware should probably choose what they are comfortable with / want to use - so long as it isn’t too esoteric :slight_smile:

Question / point - how long would it take from “topping up” online to money being usable in the space? I’m guessing this wouldn’t be immediate (bank transfer delays, time for makerspace systems to sync with bank account, etc). People using the system probably need their expectations set on this :slight_smile: So eg, people don’t come to the space, use their phone to top up, then expect to be able to use their makerspace card to pay immediately.

Oh, and it would be nice to have set buttons, or barcode scanner, for standard priced stuff, in addition to being able to key in amounts for ease of use.

1 Like

Good point Rob. Currently the bank transactions -> database job runs nightly, I could run it more often, tho payments still take time to make it across. Paypal would be quicker, if we integrate that. Update (tho paypal users would cause transaction fees)

I should probably make a start on this…

Meanwhile, anyone object to us spending £19 to get a SumUp card reader (there’s an offer somewhere, else its £29) … to use for larger payments in the space? Eg initial membership, guest fees, bookings etc.