[committee] EFTPOS / Payment gateway options for UCC
Felix von Perger
frekk at ucc.asn.au
Tue May 15 20:29:12 AWST 2018
Hi Frames,
Putting UCC bank details on a poster would be a perfectly suitable
solution and would be very easy to implement - that solves any actual
problems we might potentially have.
As for technical failures, well, it is an experiment for that purpose,
and we will have to see how it works out in practise. If you could get
your hands on a device to test cheaply or for free, it would no doubt be
useful and I'd be happy to play around with it even if it never became
widely used in the club.
Considering that the primary concern is the cost, secondly the effort
required by committee to activate the account, having a free device
would solve at least half of the problem.
Being able to take card is indeed cool. Although, having thought more
about it myself, taking online payments is actually more useful and
would allow people to manage their dispense credit and memberships
online themselves. (Part of my longer term goal to eliminate paper
membership forms altogether, muahahaha!).
Anyway, if you could borrow a device for testing then that would be great.
Kind regards,
[FVP]
On 15/05/18 16:23, Frames wrote:
>
> @Felix:
> Where were your thoughts on my point from before:
>
> Why don't we just stick our BSB and Account number on a poster , and
> people can open their banking app/website,
> and do a transfer witnessed by a door member, with their user ID in
> the transaction description.
> Then the door member can add money on dispense, including the "via
> bank transfer" in the description.
> And then when it comes to doing checking,
> the treasurer can just grep our bank statement, grep the coke logs,
> and diff them.
>
> I mean it is a couple of extra steps over the ideal system, but it
> isn't many.
> And it is free.
> and it basically has no technical failures compared to my experience
> of PayPal here.
>
> But anyway having a system that takes a card is cool.
> And adventures in payment APIs is a good educational experience.
>
> I might be able to borrow a paypal here to use for testing and setting
> up a system.
> That we could jeep for at least 6 months. Possibly with an option to
> buy it for cheap if it works out.
> Do you want me to look into that?
>
> Kind Regards
> Frames
>
>
>
>
> On 15/05/2018 4:06 PM, Felix von Perger wrote:
>> An update on the pricings and information after doing more research
>> and talking to Mint payments for an hour yesterday.
>>
>> With regards to app integration, my main concern was whether it could
>> be integrated seamlessly enough into another app that you do not need
>> any user interaction (in other words, a setup with a raspberry pi
>> wouldn't necessarily require a touchscreen nor direct user input). In
>> this case it seems like Square would be non-ideal.
>>
>> Essentially, Mint can't offer us any cheaper rates than the following:
>>
>> * Card reader is $300 to buy the device, no monthly fees thereafter
>> o For every paypass (NFC/contactless) transaction, a flat rate
>> of 1% applies
>> o For every EFTPOS (card + PIN and select "savings"), a fixed
>> price of 16.5c per transaction applies
>> * For online payments via their web payment gateway (ie. can be
>> integrated into the website)
>> o Costs $30/month to use
>> o 25c per online transaction, irrespective of payment method
>> * APIs
>> o It is possible to seamlessly integrate the card reader API
>> into a separate app (ie. to avoid having to see/touch their
>> app when doing payments, good for dispense integration)
>> o Web integration (online payments) is possible with a secure
>> hosted payments page
>> o No card details need to be stored by us
>>
>> Supposing that the card reader is too expensive for this experiment,
>> Paypal and Square offer more affordable solutions in the short term.
>>
>> Square (see pricing here <https://squareup.com/au#section-b>):
>>
>> * Card reader costs $59
>> o 1.9% on all card transactions involving the card reader (as
>> far as I can tell)
>> o Main downside to this is that the card reader has no keypad;
>> for card+PIN transactions, you must enter the PIN code on the
>> Android/iOS device rather than on the card reader
>> o Theoretically most people who have cards also have paypass so
>> it might not be necessary
>> * Online payments, virtual terminal & manually entered card details
>> in POS app
>> o 2.2% flat rate
>> * APIs
>> o Card reader integration available (can write custom POS apps;
>> again dispense integration)
>> + However note that one must still enter PIN codes on the
>> app, which is not ideal
>> + Anyone have experience
>> o Web integration possible using Square APIs (no out of the box
>> solutions available from Square, it seems, so we must write
>> that ourselves)
>> o Unknown about card details, presumably we don't touch them
>>
>> Paypal's pricing structure
>> <https://www.paypal.com/au/webapps/mpp/paypal-seller-fees> is similar:
>>
>> * Paypal Here card reader costs $100 outright, no monthly fees
>> o 1.95% flat rate on all transactions
>> o Card reader has buttons, don't need to enter anything on app
>> * Online payments (presumably applies for both payments with a
>> paypal account and card payments)
>> o 2.6% flat rate + 30c per transaction
>> * APIs
>> o Can write custom POS apps to use card reader
>> o Web integration available using all kinds of existing
>> frontends that redirect to a hosted payment gateway; we can
>> also write our own frontend if we want.
>>
>> [FVP]
>>
>>
>>
>> _______________________________________________
>> List Archives:http://lists.ucc.gu.uwa.edu.au/pipermail/committee
>
>
>
> _______________________________________________
> List Archives: http://lists.ucc.gu.uwa.edu.au/pipermail/committee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ucc.gu.uwa.edu.au/pipermail/committee/attachments/20180515/89fa2408/attachment-0001.htm
More information about the committee
mailing list