I have a friend who runs Zuldi Co has probably spent month and months (and thousands of dollars) looking for a solution like this. He sells point of sale ordering systems so waiters and waitresses can take orders and accept payment at bars/restaurants/casinos etc.
Most likely Zuldi probably wants to keep their own user experience, inventory, CRM etc. Using Square doesn't allow them to keep control of their brand.
> While other companies like Square and PayPal have provided businesses with the ability to collect payments with mobile credit card readers, businesses are reliant on the provider’s apps to process those payments. CardFlight provides its clients with card readers, and also gives them an SDK to build payment processing into their own branded apps.
All signs point to no. Square wants to be a prominent brand in the eyes of SMBs and consumers (e.g. Square Register, Square Wallet.) They don't seem interested in offering APIs or other white-label tools that help app developers feature their own brands and experiences. Seems like Cardflight clients can integrate payments into their own app experience, rather than having to push CardFlight's, Square's or anyone else's brand.
They provide an API for integrating credit card readers into Point of Sale Systems (POS) like e.g a grocery store checkout system or a mobile app to take payments when the card is present.
Besides user convenience compared to entering the credit card information manually the transaction fees for card-present transactions are much lower due to reduced transaction-risk.
Say you are a small retail chain that accepts credit card payments at the cash register, and you want to make things more efficient (Apple-store style) by also accepting payments via portable devices that your employees carry around.
You have a couple of options:
a. Invest in proprietary portable payment devices (what Apple does)
b. Sign up for a service like Square and invest in iPods or iPhones
Primary problems with (a) are cost and possibly an outdated interface. Problem with (b) is the payments are not tied into your existing infrastructure, and you have to live with Square's 2.75% fee, which may be higher than what you've already negotiated with your card providers.
With CardFlight, you get a card reader like Square's, but you can use their SDKs to collect and send payments into your existing card infrastructure. Square is ideal for independent coffee shops and the like, but if you're a small business with a few locations, something like this is probably the better solution.
tyvm, exactly the explanation I was looking for. So, to be clear, the responsibility would still be on you to use their SDK to create a custom app that would interface with the CardFlight card reader, correct?
We're still experimenting with different pricing models to figure out what makes the most sense for our clients. We typically pass the hardware expense through at cost and charge an all-inclusive monthly or annual fee per deployed device for the SDK, payment gateway, unlimited transactions, unlimited support, etc.
One upside of using CardFlight is that clients can shop around and pick whichever processor they want for the lowest rates, easiest integration, best service, or whatever reason they wish, while using the CardFlight SDK for an easy technical integration. Our clients/developers can even work with multiple processors in parallel, or switch processors down the track without having to rebuild their back end.
Not really germane to the topic, but I really dislike people that pitch their company as, "<existing company> for <demographic>." I get it lets you easily convey what you do since it's really just an improve version of an existing thing. Let your product stand on it's own. Sell what it does and why it's better. Not, "Like this existing thing, but fit into this subset?"
been following these guys for a while - wish we had this in the early days of our app when we did more on-the-ground sales to customers within our app.
15 comments
[ 1540 ms ] story [ 867 ms ] threadDoes Square have any future intent to allow this?
Besides user convenience compared to entering the credit card information manually the transaction fees for card-present transactions are much lower due to reduced transaction-risk.
You have a couple of options: a. Invest in proprietary portable payment devices (what Apple does) b. Sign up for a service like Square and invest in iPods or iPhones
Primary problems with (a) are cost and possibly an outdated interface. Problem with (b) is the payments are not tied into your existing infrastructure, and you have to live with Square's 2.75% fee, which may be higher than what you've already negotiated with your card providers.
With CardFlight, you get a card reader like Square's, but you can use their SDKs to collect and send payments into your existing card infrastructure. Square is ideal for independent coffee shops and the like, but if you're a small business with a few locations, something like this is probably the better solution.
We're still experimenting with different pricing models to figure out what makes the most sense for our clients. We typically pass the hardware expense through at cost and charge an all-inclusive monthly or annual fee per deployed device for the SDK, payment gateway, unlimited transactions, unlimited support, etc.
One upside of using CardFlight is that clients can shop around and pick whichever processor they want for the lowest rates, easiest integration, best service, or whatever reason they wish, while using the CardFlight SDK for an easy technical integration. Our clients/developers can even work with multiple processors in parallel, or switch processors down the track without having to rebuild their back end.