-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Free Digital Funding Chez Betty Account (Venmo?) #348
Comments
My hunch is it will be difficult to reduce or eliminate the fees because that is an established business model for how these services work. But it would of course be good to be proven wrong 😀. From a logistics point of view, I think Betty is pretty flexible, but we want something where our code is not touching any credit card/account info (we just get a callback telling us what happened). Lastly, we at one point supported Bitcoin (and the code might still be around) but very few (<5) people ever used it. |
This is a stretch but I'm wondering if we could just set up a personal Venmo account for Betty, and have it deposit payments to a users account based on maybe including UMID in the payment description? Might be a bit of a grey area Venmo ToS wise, and we would need to have a little fun with automating things. |
That's definitely and very explicitly against the Venmo ToS (at least when
we last looked into it) -- not really an option for us.
I believe that Venmo was purchased by Braintree which was purchased by
PayPal. While the dedicated Venmo business API was shut down, you can use
Braintree payments to accept Venmo transactions, but they come with very
similar fees.
…-Pat
On Mon, Feb 10, 2020 at 8:19 AM Gregory Young ***@***.***> wrote:
This is a stretch but I'm wondering if we could just set up a personal
Venmo account for Chez, and have it deposit payments to a users account
based on maybe including UMID in the payment description?
Might be a bit of a grey area Venmo ToS wise, and we would need to have a
little *fun* with automating things.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#348?email_source=notifications&email_token=AACS3XQ6FEPE5JX6W7Y7QM3RCF475A5CNFSM4KSQU2Z2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELJD6UQ#issuecomment-584204114>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACS3XWLV6X37LVYX5DLDKLRCF475ANCNFSM4KSQU2ZQ>
.
|
I'm obviously not very educated on the logistics here, I'm just trying to gather information on logistics so I can kick off some better educated research. Can we discuss the logistics more specifically? Is Betty technically a business? I'm getting the vibe that Betty is a more efficient means of bulk purchasing and reimbursing amongst our community. It sounds like a personal cash-like digital service like Venmo or Cash App would be a good fit for the reimbursement aspect. Discussing the ~3% standard fee, in addition to paying for access to the network we are also paying for various services and protections offered to merchants and consumers in a typical commercial environment. I don't think these services and protections are appropriate to the cooperative model of Betty. I'm wondering if there might be a digital payment model that is a better fit for Betty, (I may be wrong) but I am assuming we don't need and aren't taking advantage of most of the services we're paying for in that fee to use networks like Visa/MC. By reducing the cost for these convenient digital deposits, we might be able to significantly reduce debt and increase usage. Anecdotal, only times I have ever gone into debt (or gotten a low balance) with Betty was difficulty to deposit funds. Edit: There is also obviously a non-zero cost to collecting cash deposits. Even if we can just lower the cost of digital payments to be closer to the cost of collecting cash, then maybe we could bake it into the small general markup. |
Betty is technically a business, though the underlying objective of economizing bulk purchasing is one of the original goals. To operate strictly under a reimbursement model would require restructuring as a cooperative, which has a lot more legal & logistical overhead. We looked into the co-op model early on, and it's basically a non-starter. I think Betty would be happy to switch to a digital payment mechanism with lower transaction fees, I just don't know of any that exist (for business use). [As I understand it, most of what transaction fees cover is the de-risking of lines of credit; i.e. you get money immediately and how that money is collected from the paying individual is now Visa/Amex/etc's problem -- Betty certainly derives that benefit in full] Regarding 'hiding' the digital overhead in the general markup: I think there's actually some value in showing people how the financial ecosystem operates :) |
@ppannuto, thank you for the information and perspective. I'm going to mess around with some things and report back to this issue, if any other members want to chime in with ideas that would be great.
This is true, but does Betty need this type of benefit? I did some light googling and it looks like there may be some processors that charge significantly less fees for debit cards vs. credit cards. Obviously we should keep credit cards as an option, but some might prefer using debit cards to avoid the fees.
Agreed entirely, but we might already be misleading users as we're 'hiding' the overhead of cash deposits. This obviously encourages users to deposit cash over paying digitally, and I always end up in a loop of "oh I have a low balance I'll just fill my account next time I have cash on me" until I go deep into negative. Also when Betty gets busy it's awkward to fill the cash dispenser with a line behind you (I hope most will just do it another time as to not hold people up). An alternate in the interest of transparency might be deducting a fee from cash deposits, as I am assuming there is some comparable overhead for cash deposits, and then markups could be able to go down and everyone wins. I'm mainly just going off of personal experience right now though, do we have usage statistics that might support or dissent my claims? I realize we're mostly computing students and can figure the system out no matter how complicated, but a little bit of good user experience can go a long way. After further reflection, I'm wondering if this might be a UX issue more so than a logistics issue. |
The biggest barrier to change is simply that Betty is a volunteer run
operation. Currently Stripe is implemented, works, and has required
literally zero maintenance or additional time in the last four years. Happy
to add new payment methods if there's enough benefit to justify the one-off
cost of implementation -- but the reality is that anything with sustained
maintenance overhead is unlikely (yes, cash currently has this, but cash
also has a system that is working; again, not impossible, just really needs
to justify the change).
As Betty is all volunteer, there's no fiscal overhead to cash deposits.
Regarding lines, we have previously discussed adding a second terminal,
it's simply that no one has had the time to make this happen.
YTD, deposits have been roughly 1/3 cash, 2/3 credit card.
…On Mon, Feb 10, 2020 at 3:38 PM Greg Young ***@***.***> wrote:
@ppannuto <https://github.com/ppannuto>, thank you for the information
and perspective. I'm going to mess around with some things and report back
to this issue, if any other members want to chime in with ideas that would
be great.
most of what transaction fees cover is the de-risking of lines of credit
... Betty certainly derives that benefit in full
This is true, but does Betty need this type of benefit? I did some light
*googling* and it looks like there may be some processors that charge
significantly less fees for debit cards vs. credit cards. Obviously we
should keep credit cards as an option, but some might prefer using debit
cards to avoid the fees.
Regarding 'hiding' the digital overhead in the general markup: I think
there's actually some value in showing people how the financial ecosystem
operates :)
Agreed entirely, but we might already be misleading users as we're
'hiding' the overhead of cash deposits. This obviously encourages users to
deposit cash over paying digitally, and I always end up in a loop of "oh I
have a low balance I'll just fill my account next time I have cash on me"
until I go deep into negative. Also when Betty gets busy it's awkward to
fill the cash dispenser with a line behind you (I hope most will just do it
another time as to not hold people up). An alternate in the interest of
transparency might be deducting a fee from cash deposits, as I am assuming
there is some comparable overhead for cash deposits, and then markups could
be able to go down and everyone wins.
I'm mainly just going off of personal experience right now though, do we
have usage statistics that might support or dissent my claims?
I realize we're mostly computing students and can figure the system out no
matter how complicated, but a little bit of good user experience can go a
long way. After further reflection, I'm wondering if this might be a UX
issue more so than a logistics issue.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#348?email_source=notifications&email_token=AACS3XQA6AJSA6NH6OZGG6LRCHQOFA5CNFSM4KSQU2Z2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELKWYEY#issuecomment-584412179>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACS3XULHY3M54BEHCYBLFTRCHQOFANCNFSM4KSQU2ZQ>
.
|
Stripe is nice but the fees aren't great. It might be more efficient if we set up a way to fund accounts using Venmo, or some other free digital wallet system?
Venmo is definitely the most popular, it looks like they shut down their API though. They seem to have some options for businesses, maybe we could contact for more information? I'm assuming at that point there would be some fees but it might be less than Stripe.
I'm an undergrad here, I'm willing to do some research into other platforms and potentially do some work into implementing. I'm interested in knowing what logistical barriers there would be to setting something like this up, and what the community thinks.
Potential Options:
Open to more options, especially ones with a public API!
The text was updated successfully, but these errors were encountered: