It's QR-based, so customers create an account, load money onto their account, then show their QR code to vendors who scan it to charge their account. We also provide plastic cards (think: gift card) for people who don't want to use their phone but we see 80%+ of people interact completely on their phone/online. We have an app and website (same codebase, Quasar framework) and for in-person payment (entry, bar) we provide iPads with connected CC readers.
My best advice is this: your hardest challenges will not be technical in nature. The hardest part is the equipment, dealing with customers, hand-holding the festival organizers. I don't say any of that as some gross thing or bad thing, just reality. In fact, I think I've succeeded larged based on the in-person aspect (We travel to the event and are on-site for the event) and being the "I have all the answers for your festival payments"-person. Rolling with the punches is a huge part of it.
The whole thing runs on AWS Lambda with a postgres DB from Neon.tech. I'll be honest, it's incredibly over-architected, the whole thing could run a a couple (or even 1) servers as a traditional NodeJS app without issue (and with less complexity) but I used this project as learning experience and a chance to try our some technology I was interested in. Lambda is incredibly cool and I think I might have one of the best use-cases for it (incredibly spikey load: no traffic for 9 mo, tiny traffic for presales for 1-2 months, 1 month with higher sales, then 1-2 days of the event with crazy sales) but the debugging story isn't the best. SST makes it 10000x better than anything else I've tried and the developer experience is bar-none for writing lambdas but all the other crap (CloudFormation, logs, monitoring, etc) is so much overhead. If I was writing this again today I'd probably look at something like NestJS but I won't let myself re-write the code (again) without a pressing reason and if I need to spend time anywhere it's sales/marketing.
Festival-goers can just pay for their food direct as well?
Sorry, I don't understand your offering at all and the questions just sort of keep coming!
I see you combine payments, but I'm struggling to see the real-terms benefit over a tap-payment (card, watch or phone)? For a food stand, it would seem, not taking the money directly is a relatively large potential liability. Is the point to enforce a contract between vendors and the festival?
Does the festival pay the food stands [something] up front?
How's your liability insurance? Or do the festivals underwrite you for when Amazon/wifi is down and no-one can pay for their meals? (I did see you tout live updates, so transactions must be networked)
Sounds easy to abuse (show someone else's code?), have you had much fraud?
You're in USA? Did you need a banking license?
Small festivals in UK would be 4-8000 people, say; average food spend is probably £20+ per day -- are you carrying a debt to food providers for £500,000+ over a long weekend (consolidating payments)?
Fascinating.
Do you do non-food transactions too - souvenir stands, onsite shops, [festival] activities? Like some festivals include a number of tokens and you can buy activities with them at the festival.
> Festival-goers can just pay for their food direct as well?
In a word? Data. Festivals normally charge vendors a percentage of sales to be at the festival and they need a way to track sales. "Trust me bro" doesn't quite work since restaurants/vendors will lie or shave their sales numbers so they pay out less. One festival told me about a time they had a vendor steal another vendor's tickets they had collected and try to turn them in as their own. I don't think all or even most vendors are dishonest but the ones who are mess it up for everyone. So instead the festival requires all payment to go through their festival currency (1 to 1 with USD). This gives them realtime data of all vendors and they use that data to decide which vendors to invite back and how much to pay out at the end.
> I see you combine payments, but I'm struggling to see the real-terms benefit over a tap-payment (card, watch or phone)? For a food stand, it would seem, not taking the money directly is a relatively large potential liability. Is the point to enforce a contract between vendors and the festival?
Yes, the point is to enforce the contract between the two. For a lot of festivals the food price is low (think $3-5) since it's meant to be a way to sample a lot of things. The $0.30/transaction (that Stripe charges) eats into total percentage quickly at lower price points. Also this lets all vendors take payment without needing any special equipment (other than their smartphone). Yes, some/most of them have their own POS but this lets the festival and festival-goers keep all their transactions in one place. Also the vendors have access to reports as well.
> How's your liability insurance? Or do the festivals underwrite you for when Amazon/wifi is down and no-one can pay for their meals? (I did see you tout live updates, so transactions must be networked)
All our contracts state that we cannot be held liable for internet issues, we operate completely on LTE/5G and do not provide WiFi at the events (that's a huge PITA if you've ever looked into it) and very often there isn't even an ISP we could work with to provide the internet service so if we are going to rely on LTE anyways might as well have each iPad talk directly to the towers instead of through extra infrastructure we need to manage. So far this has no been an issue but we do a cellular survey of the area when we take on a new festival to check how good the signal is.
> Does the festival pay the food stands [something] up front?
No, in fact often the vendors pay a small amount to reserve the space (mostly to make them have some skin in the game and show up, the number of no-shows always surprises me a bit). Vendors in general are very hard to wrangle. You can send them all the info ahead of time multiple times, in multiple forms, etc and at least 20%+ will show up and have no idea what's going on. Thankfully we can train someone on the system in well under 5min and they rarely need follow-up help.
> Sounds easy to abuse (show someone else's code?), have you had much fraud?
This was a huge concern of mine up front but in practice it's been non-existent or at least non-reported (and trust me, I've dealt with every other type of support ticket), In fact couples/families will often just load 1 account and share the QR between them. We also offer in-system transfers which isn't used as much as I would have expected but people do it that way as well.
> You're in USA? Did you need a banking license?
Yes, thankfully no license needed. I've worked/founded startups that needed Money Transmitter Licenses and I wouldn't touch those businesses with a 10ft pole (so much insurance and each state is done differently, no thanks). No, the money never touches my accounts, I use Stripe Connect so I help the festival get their own account setup and all the money dumps directly into their Stripe account (and then their bank account). I don't handle payouts to vendors because every festival has a different formula so it's easier to just give them all the money, give them the reports, and let them sort it out.
> Small festivals in UK would be 4-8000 people, say; average food spend is probably £20+ per day -- are you carrying a debt to food providers for £500,000+ over a long weekend (consolidating payments)?
I can't share exact numbers but 4-8K customers is the range we see as well but our numbers are low because people share accounts. The average spend is about $30-40 depending on the festival. My answer to the previous question probably answered this for you but no, I don't carry the debt or deal with that, the festival does.
> Do you do non-food transactions too - souvenir stands, onsite shops, [festival] activities? Like some festivals include a number of tokens and you can buy activities with them at the festival.
Sometimes. We have special support for bars (to track stock) and you can put anyone on the system if you want. We have done entry ticketing, event ticketing (bourbon tasting for extra at the festival), and one festival ran all their T-shirts/stickers through the system as well. We support multiple ticket types so you can create a ticket type for anything you want. One festival didn't use the "festival currency" at all and instead wanted everyone to get 15 tasting tickets (we support packages/bundles as well) who bought the "Tasting package" and they redeemed those at the vendors.
> show their QR code to vendors who scan it to charge their account.
That sounds _brilliant_ -- being able to show a physical QR code card rather than dig out the phone sounds like it would help a lot with preventing damage/loss of phones.
Yep, because everything is QR-based I can provide almost the same experience for people on their phones or those who opt for a card. The card even has a URL on it you can go to to claim the card (convert to a user account in the system) or a page you can go to and see the balance without needing to create an account.
I love geeking out over my "stack" or talking about the business stuff, it's been rollercoaster and a huge learning experience for me. Really upended a ton of preconceptions I had about a number of things.
It's QR-based, so customers create an account, load money onto their account, then show their QR code to vendors who scan it to charge their account. We also provide plastic cards (think: gift card) for people who don't want to use their phone but we see 80%+ of people interact completely on their phone/online. We have an app and website (same codebase, Quasar framework) and for in-person payment (entry, bar) we provide iPads with connected CC readers.
My best advice is this: your hardest challenges will not be technical in nature. The hardest part is the equipment, dealing with customers, hand-holding the festival organizers. I don't say any of that as some gross thing or bad thing, just reality. In fact, I think I've succeeded larged based on the in-person aspect (We travel to the event and are on-site for the event) and being the "I have all the answers for your festival payments"-person. Rolling with the punches is a huge part of it.
The whole thing runs on AWS Lambda with a postgres DB from Neon.tech. I'll be honest, it's incredibly over-architected, the whole thing could run a a couple (or even 1) servers as a traditional NodeJS app without issue (and with less complexity) but I used this project as learning experience and a chance to try our some technology I was interested in. Lambda is incredibly cool and I think I might have one of the best use-cases for it (incredibly spikey load: no traffic for 9 mo, tiny traffic for presales for 1-2 months, 1 month with higher sales, then 1-2 days of the event with crazy sales) but the debugging story isn't the best. SST makes it 10000x better than anything else I've tried and the developer experience is bar-none for writing lambdas but all the other crap (CloudFormation, logs, monitoring, etc) is so much overhead. If I was writing this again today I'd probably look at something like NestJS but I won't let myself re-write the code (again) without a pressing reason and if I need to spend time anywhere it's sales/marketing.
Here is my, crappy, "marketing" website: https://grubbux.com/