Credit card readers - what am I missing here?
-
After a bit of a falling out with Square over a botched update with their Android app (that just rubs salt in the wound that is their adamant refusal to support Windows devices), I looked into what would be involved in removing the app from my workflow. Supposedly there are ways to read "audio" signals from the microphone jack into the details needed to charge a card. Most of the code I've found for this is beyond byzantine but that's not what I have a question about. That question revolves around encryption, which supposedly has been built into the readers for a few years now.
My question is...wouldn't I just get encrypted garbage that I couldn't plug into a merchant gateway API? Or do merchant gateways accept encrypted garbage as part of PCI compliance rules? Because as it stands right now, it looks like the real reason Square added encryption was so somebody like me couldn't throw their garbage unsupported app away and roll their own. Or am I missing some key detail here?
-
@Zenith said in Credit card readers - what am I missing here?:
Because as it stands right now, it looks like the real reason Square added encryption was so somebody like me couldn't throw their garbage unsupported app away and roll their own. Or am I missing some key detail here?
They probably did that to prevent rogue Android apps from also listening to what the card reader is sending to the Square app, and meanwhile syphoning off valuable creditcard numbers to Western Bumfuckistan.
-
The mag stripe itself is not encrypted; it's just data encoded into magnetic fields. If you're getting analog data, then you've got to convert the raw magnetic field into digital data as the user swipes the magnetic stripe past the magnetic head in the reader (hopefully at a consistent speed). The code to do that is probably going to be pretty byzantine.
Card readers will typically encrypt the data; this is to make sure that it cannot be sniffed by anything. You might find this useful...
https://idtechproducts.com/how-to-decrypt-credit-card-data-part-i/
https://idtechproducts.com/how-to-decrypt-credit-card-data-part-ii/
https://idtechproducts.com/how-to-parse-magstripe-credit-card-data/
-
A merchant services account is going to have a particular whitelisted set of hardware, and a bootleg square reader ain't gonna be one of them.
-
@Weng The reason this idea came back up was because I saw BluePay had an API (with C# examples even) for me to POST raw details via HTTPS. Square only has the app (that's locked to Android/iOS and no longer works), a remote loaded JavaScript form (that never worked in IE, drops browser support like nobody's business, and can't be styled to fit your site), and an API that could do many useless things but couldn't charge a card. It's really easy for me to put more features into my Windows program but I'm stuck with what seems like endlessly broken Android tutorials/tools so all I could manage out of Square was to send an invoice.
-
If you are developing for windows on desktop computers, there used to be serial port (or USB -> serial) card readers that were supported by OPOS that would basically make the card reader act like a keyboard. Of course, it was 12 years ago since I worked with OPOS and point of sale hardware/software.
-
@Zenith I'm pretty sure everything you're talking about here, even if you could get it to work, would be terrible for PCI compliance and probably get the shit sued out of you if someone ever found out.
Just fair warning...
-
So I'll ask the dumb question - what's special about your situation vs everybody else using Square?
-
@mikehurley said in Credit card readers - what am I missing here?:
So I'll ask the dumb question - what's special about your situation vs everybody else using Square?
Well...
- I want to integrate card processing into a Windows app because...
- I don't want to rebuy my phone/tablet every other year because...
- I don't turn enough sales via EFT to justify it because...
- Android development is such a clusterfuck that I can't display anything but what's on the table unless I can use Windows.
- I want to support non-Chrome browsers. Don't ask me why they've fucked up three textboxes so bad that it won't work on any other browser. Having to embed an alien form introduces so many timing issues anyway that I just don't want to plaster a "best viewed in Creepscape Chromium" sticker across my site too.
I'd settle for using their own storefront but they still don't support calculated shipping in 2019. They keep bombarding me with spam about all these "amazing" new services they're developing but none of it is actually useful. All I want is a way to process EFT without being put on a forced obsolescence treadmill turned up to 11.
-
@Zenith said in Credit card readers - what am I missing here?:
Android development is such a clusterfuck that I can't display anything but what's on the table unless I can use Windows.
While I'm not disputing the clusterfuckiness of Android, lots of developers seem to be producing code that targets it anyway; after all, it's very available and where the customers are. Maybe part of the problem is that you're too dependent on doing things in one way (which works with tooling for Windows) in your mind?
-
@dkf said in Credit card readers - what am I missing here?:
clusterfuckiness
E_NO_REPRO
You must type it too much.
-
@dkf Just take databases. Android has no database drivers. That means to write a database driven app (like a store catalog would be), I have to write a second one, a website in PHP, and a JSON layer between them. Why can't I just have one app? Because, according to StackOverflow, "you don't need that." Fuck you SO, I'll tell you what I need, and it's a standalone app.
Look, I'm willing to put up with Java and single page app nonsense...how much more inside out am I expected to turn? I already have the rest of my workflow developed in Windows so there are limits to what I'll put up with.
-
@Zenith said in Credit card readers - what am I missing here?:
@dkf Just take databases. Android has no database drivers. That means to write a database driven app (like a store catalog would be), I have to write a second one, a website in PHP, and a JSON layer between them. Why can't I just have one app?
You need some layer doing authorization that sits in front of the database, keeping User X from viewing or manipulating User Y's data, or from making unexpected changes to the data. (e.g. creating an order record without actually paying for anything)
In your case, it sounds like you aren't releasing this APK, so maybe direct database access would be okay for you. For 99.9999% of Android apps, that's not the case.
-
@Unperverted-Vixen Most Android apps seem to be dumb terminals linked to a website. As apps on this tablet have arbitrarily fallen out of support (Square, eBay, YouTube, e-mail, banking, etc), I've had to resort to using Chrome. Why even download apps (forget about buying them) when they have such a limited shelf life?
It's really a self fulfilling prophecy though. When you don't provide tools like database drivers, it's no surprise that 99.99% of apps don't use those tools. Because of this, Android is absolutely useless to me as a custom development environment. I would sooner buy and lug around a laptop with Windows 10 than another tablet.
-
@Zenith said in Credit card readers - what am I missing here?:
As apps on this tablet have arbitrarily fallen out of support (Square, eBay, YouTube, e-mail, banking, etc), I've had to resort to using Chrome. Why even download apps (forget about buying them) when they have such a limited shelf life?
How old is this tablet?!
I've got an Android tablet that's coming up to 6 years old and eBay, Youtube etc are all still available. I can't comment on Square as I don't use it.
-
@loopback0 said in Credit card readers - what am I missing here?:
@Zenith said in Credit card readers - what am I missing here?:
As apps on this tablet have arbitrarily fallen out of support (Square, eBay, YouTube, e-mail, banking, etc), I've had to resort to using Chrome. Why even download apps (forget about buying them) when they have such a limited shelf life?
How old is this tablet?!
I've got an Android tablet that's coming up to 6 years old and eBay, Youtube etc are all still available. I can't comment on Square as I don't use it.
I'm guessing something below 5.0
So either super ancient, or something newer that's really crap and came with 4.4 (or earlier)
-
@loopback0 It's a Motorola Xoom that I bought in 2012. It was rendered useless by late 2016 or early 2017.
I'm afraid to even try updating apps anymore because the Android app store doesn't check for compatibility, doesn't allow side-by-side installation, and doesn't let you downgrade. That's what fucked me last time I tried to update the Square app. The version it downloaded suffered random restarts. All Square would do was go "hur dur, you's be needing a new tablet cuz we's won't even gibs you an older version of the app LOL." I had to hop back through a few older APKs on the Android version of oldversion.com to find one that was old enough to work on the tablet but new enough to pass the arbitrary version check in the API.
That worked for awhile and then suddenly stopped too. So I've been limping along on a 2014 Samsung Galaxy Active phone. That only updated to Android 5 so it's not going to work much longer either.
It's really a pain in the ass to spend $400 for a new tablet or $600 for a new phone just to run a few charges. Made that mistake when I bought the Xoom. I also don't like that so many of these devices don't have replaceable batteries anymore so they're broken garbage within 2 years. I've been looking at the newer Samsung Galaxy Active tablet but it ships with Android 6 or 7 with 9 being out so who knows how long that would last.
Meanwhile, Windows 7 runs both SQL 2000 and the latest Chrome.
I mean, it's a simple app...read a 50 year old card format from a 19th century headphone jack and POST text over the 25 year old HTTPS protocol...why the hell do the system requirements keep changing?
Incidentally, I've seen a whole lot fewer card readers on the dealer room floor over the last few years. They were everywhere when I got started with this in 2012. Now it's cash or bust.
-
@Zenith said in Credit card readers - what am I missing here?:
It's really a pain in the ass to spend $400 for a new tablet or $600 for a new phone just to run a few charges.
Sure, but there may be a reason card payment processors don't want to support their app on a version of an OS that's not received security updates in years.
@Zenith said in Credit card readers - what am I missing here?:
I also don't like that so many of these devices don't have replaceable batteries anymore so they're broken garbage within 2 years.
This isn't true. As I said, I have a Nexus 7 from 2013 with a "non-replaceable" battery and it's still fine.
@Zenith said in Credit card readers - what am I missing here?:
I've been looking at the newer Samsung Galaxy Active tablet but it ships with Android 6 or 7 with 9 being out so who knows how long that would last.
The Galaxy Tab A6 is cheaper and while it does ship with 7 there's an update to 8.1 available as soon as you turn it on.
@Zenith said in Credit card readers - what am I missing here?:
Meanwhile, Windows 7 runs both SQL 2000 and the latest Chrome.
It does but no-one should be running old software like SQL 2000 anywhere near something taking card payments.
@Zenith said in Credit card readers - what am I missing here?:
why the hell do the system requirements keep changing?
Security. Plus supporting an infinite number of devices going back an infinite number of years is a pain.
-
@Unperverted-Vixen said in Credit card readers - what am I missing here?:
You need some layer doing authorization that sits in front of the database
We've got some homegrown at work which uses the DB auth layer for user auth, and PL/SQL to implement data modification. Direct table access is read-only. There's web frontend, but it's a java shim calling PL/SQL to generate HTML.
It works much better than you'd expect.
-
@PleegWat I guess you’re right, the authorization layer could be done in stored procs like that. As described you still get data leakage between users, but table access could be dropped in favor of read sprocs.
I would argue that they qualify as the separate layer I described, though. Yes, they’re technically in the database, but without direct table access it doesn’t act like you have database access.
Sounds painful to maintain and test, though. And does it allow self-signup of new users (like an app would), or is this a system where the logins are manually created?
-
@Unperverted-Vixen Since this is internal, access is centrally provisioned (I do think it's automated). I do believe row level read access restrictions are a thing despite apparent direct table access but don't ask me how it works.
-
@Zenith said in Credit card readers - what am I missing here?:
I bought in 2012. It was rendered useless by late 2016 or early 2017.
Sounds like you got more than your money's worth out of it then
@Zenith said in Credit card readers - what am I missing here?:
hur dur, you's be needing a new tablet cuz we's won't even gibs you an older version of the app LOL.
I'm pretty sure they can't do that. If there's an exploit or something, and someone's CC number gets yanked, they're partially liable.
-
@Zenith said in Credit card readers - what am I missing here?:
Android app store doesn't check for compatibility
Also, yes it does. If Square's app compatibility listings are wrong, that's on them.
@Zenith said in Credit card readers - what am I missing here?:
The version it downloaded suffered random restarts.
That sounds like your device just didn't have enough processing power to run the new version. (probably RAM, sounds like an OOM kill, but it might be killing it for other reasons too)
-
@Zenith said in Credit card readers - what am I missing here?:
Just take databases. Android has no database drivers. That means to write a database driven app (like a store catalog would be), I have to write a second one, a website in PHP, and a JSON layer between them. Why can't I just have one app? Because, according to StackOverflow, "you don't need that." Fuck you SO, I'll tell you what I need, and it's a standalone app.
I'm trying to understand why shipping the app with SQLite isn't enough (and that's pretty trivial to build and include, with no licensing issues either, so that's what everyone does for an on-device DB). Most Android devices are single user, and on those that aren't, apps are installed for single user at a time and can't access each other's storage. Anything where you need fancy auth capabilities doesn't actually belong on the mobile device in the first place.
-
@sloosecannon That's crazy though. The device has 1GB and an OS that was designed for hardware specs of that period. I can even run Firefox on it. The phone, where it works, only has 2GB and I can keep 200 Chrome tabs open on it, plus Square, plus the stupid Samsung voice app that keeps opening by itself, and so on.
The restart isn't after it's been running awhile either. Every window it opens has a chance of triggering the restart. Sometimes I can go back and forth before it triggers. Even if you bypass everything and just go straight to a raw $1 charge, the swipe triggers it. Keyed entries don't work either because, again, if you make it that far, that's where it restarts.
Square is just sloppy. I can't imagine paying their $1K asking price for a POS terminal. Who knows when that'll break for no reason. At least I can still use the tablet for something else.
@dkf said in Credit card readers - what am I missing here?:
I'm trying to understand why shipping the app with SQLite isn't enough (and that's pretty trivial to build and include, with no licensing issues either, so that's what everyone does for an on-device DB). Most Android devices are single user, and on those that aren't, apps are installed for single user at a time and can't access each other's storage. Anything where you need fancy auth capabilities doesn't actually belong on the mobile device in the first place.
What happens if you need to interact with anything outside of that device? In my scenario, I have a database in MSSQL on a server and my storefront runs on MySQL (not by choice, believe me). I might want to pull an updated catalog or export updates from the sales floor. I can't access either of them from the tablet due to the driver situation. Nope, I've got to write two websites, one in PHP (because Linux has so many choices) and another in ASP (because fuck PHP if I have another option).
Again, it sounds like I'm being told the lack of even a generic ODBC driver isn't a problem because I don't need to do what I need to do. That's exactly the attitude that makes Linux on the desktop a running joke year after year. Like nobody learned from Microsoft making things easier to use and compatible with competitors they went on to destroy.
May as well just stick with a notepad and cash only.
-
@Zenith said in Credit card readers - what am I missing here?:
What happens if you need to interact with anything outside of that device? In my scenario, I have a database in MSSQL on a server and my storefront runs on MySQL (not by choice, believe me). I might want to pull an updated catalog or export updates from the sales floor. I can't access either of them from the tablet due to the driver situation. Nope, I've got to write two websites, one in PHP (because Linux has so many choices) and another in ASP (because fuck PHP if I have another option).
I think this is usually done via REST or some other form of web service/API for most Android apps.
-
@sloosecannon said in Credit card readers - what am I missing here?:
Sounds like you got more than your money's worth out of it then
Not really. 2015 and 2016 were serious downturns; revenue halved twice. I didn't find out about the botched update until I was at a show trying to run a charge. Developers wonder why people don't jump at software updates. Here Square directly notified me of it, I trusted them and the Google Play store controls, and these restarts were the result. Sales have recovered (I think...still working my way through 2018 taxes) but they're all in cash now. I'd like a good API that'll work online so I can get out faster but it's such a fight.
-
@Zenith When it comes to "mobile devices" such as phones and tablets, the average expected lifespan of them is ~2 years. After that, they're usually considered "out of support" for nearly everything. Some app developers may keep some backwards compatibility in their apps for another year or so, but more than that is usually gonna be "Sorry, your shit's too old, get newer stuff".
I have a Nexus 7 from 2013 I can't install most apps on nowadays because it won't update past Android 6.0.1. This is expected. It's basically just a Netflix remote now, when I remember to plug the damn thing in and am not just using it as a coaster.
-
@Zenith said in Credit card readers - what am I missing here?:
I can keep 200 Chrome tabs open
That's an illusion, it actually only keeps at most five open, the rest are hibernated and reloaded on demand.
-
@Zenith said in Credit card readers - what am I missing here?:
Nope, I've got to write two websites, one in PHP (because Linux has so many choices) and another in ASP (because fuck PHP if I have another option).
But, why tho? Will not your one site (in your preferred language, natch) suffice?
I'm confused why you think PHP is some magic requirement here.
-
@Zenith said in Credit card readers - what am I missing here?:
Again, it sounds like I'm being told the lack of even a generic ODBC driver isn't a problem because I don't need to do what I need to do. That's exactly the attitude that makes Linux on the desktop a running joke year after year. Like nobody learned from Microsoft making things easier to use and compatible with competitors they went on to destroy.
And here I was given alien faces when I mentioned we were using ODBC to connect our game servers to the database. Get with the times, I guess?
-
@Zenith said in Credit card readers - what am I missing here?:
Again, it sounds like I'm being told the lack of even a generic ODBC driver isn't a problem because I don't need to do what I need to do.
That's exactly what you're being told.
Android is a generalized consumer-oriented mobile device operating system. A cell phone has no business directly talking to a database server.
That's not your use case, sure, but it's the use case the device and operating system were designed for. Don't be surprised that it's maybe a little harder than you might expect to get it to work outside of the use case it was designed for.
-
@e4tmyl33t That's why I've been trying to find a Windows solution. As long as I have Visual Studio and access to hardware, I have some control. I don't like to be forced into throwing stuff away just because a 3rd party feels like I should rebuy it. SaaS makes me want to vomit.
@Tsaukpaetra said in Credit card readers - what am I missing here?:
@Zenith said in Credit card readers - what am I missing here?:
Nope, I've got to write two websites, one in PHP (because Linux has so many choices) and another in ASP (because fuck PHP if I have another option).
But, why tho? Will not your one site (in your preferred language, natch) suffice?
I'm confused why you think PHP is some magic requirement here.
Because 95% of shared hosting is Linux hosting? And all those plans support is PHP and MySQL?
From my POV, everything is Windows. The stores, the schools, the jobs, all Windows. Linux is something they argue about on Slashdot and pack on disposable devices via Android. It drives me nuts that Windows crashed and burned on mobile. I already don't like using PHP through a cPanel interface. It's the most ass-backwards way to do anything. I never feel like I fight Visual Studio and MSSQL like I have to fight the web and Eclipse and Android and MySQL.
(There are two sites because the original backend was MSSQL. The PHP site was completed right before Google pulled the plug on Checkout so I only had test inventory transferred. That really frustrated me so I put stuff on eBay while I figured out what to do. In the meantime I developed alot of C#/WinForms tools for the original backend. When eBay started to peter out I went looking at the Square API to see how I could integrate it with the PHP site. Having to host a form introduces timing and compatibility issues, which I was struggling with when they started requiring an SSL certificate for the sandbox, which I didn't want to pay for until I was sure the integration worked, which I couldn't because I no longer had any testing access.)
-
@Zenith Then maybe one of these is more up your street?
-
@e4tmyl33t Possibly. That or BluePay if I can get some time to work with their SDK. I really only started the thread to see if I understood what was going to come out of the reader. Sort of spiraled into why I really dislike Android though.
-
@Zenith said in Credit card readers - what am I missing here?:
Because 95% of shared hosting is Linux hosting? And all those plans support is PHP and MySQL?
FUCKING HELL YOU TOLD US YOU WERE DOING INTERNAL DEVELOPMENT!
Fuck you I'm not even going to try and help with snarky comments anymore when you're
.
-
@Tsaukpaetra It IS internal development. The website and PHP only became involved once I figured out the Android tablet had absolutely no way to connect to the MSSQL database. What I wanted was to do this:
- Have the tablet read the catalog from MSSQL.
- Go on location, sell stuff, and record sales (this is where the Square reader originally came in).
- Come home and export sales from the tablet to MSSQL.
That's when people said "nononono, you need to write a website and a JSON layer in addition to the Android app. You don't need an ODBC driver, it's not more work to write the app twice, and more dependencies are even more betterer."
THIS thread was a question about if I'd be able to use whatever came out of the card reader if I put my 95% done WINDOWS program on a laptop with an audio jack and used it instead of some kludged together Android/PHP abomination.
Jesus Christ, I'll keep printing my inventory out on paper, crossing stuff out as it sells, and manually transcribing to MSSQL. There's "Android just isn't going to work for your use case" and then there's "you're moving the goal posts because you're not doing web services for everything so you're wrong."
-
@e4tmyl33t said in Credit card readers - what am I missing here?:
I have a Nexus 7 from 2013 I can't install most apps on nowadays because it won't update past Android 6.0.1.
Installing LineageOS takes it to 7.something and I've not found an app I couldn't install on that yet.
-
@Zenith said in Credit card readers - what am I missing here?:
I'll keep printing my inventory out on paper, crossing stuff out as it sells, and manually transcribing to MSSQL.
I haven't followed this topic that closely, but sometimes a paper solution is the simplest if it's a small system. Also, see signature.
-
@Zenith said in Credit card readers - what am I missing here?:
@Tsaukpaetra It IS internal development. The website and PHP only became involved once I figured out the Android tablet had absolutely no way to connect to the MSSQL database. What I wanted was to do this:
- Have the tablet read the catalog from MSSQL.
- Go on location, sell stuff, and record sales (this is where the Square reader originally came in).
- Come home and export sales from the tablet to MSSQL.
That's when people said "nononono, you need to write a website and a JSON layer in addition to the Android app. You don't need an ODBC driver, it's not more work to write the app twice, and more dependencies are even more betterer."
THIS thread was a question about if I'd be able to use whatever came out of the card reader if I put my 95% done WINDOWS program on a laptop with an audio jack and used it instead of some kludged together Android/PHP abomination.
Jesus Christ, I'll keep printing my inventory out on paper, crossing stuff out as it sells, and manually transcribing to MSSQL. There's "Android just isn't going to work for your use case" and then there's "you're moving the goal posts because you're not doing web services for everything so you're wrong."
There's nothing wrong with your point, but if you do things the 'conventional' way for whatever platform it's just easier. Even if that doesn't exactly fit the way you want to work.
I develop for Android and I've never really even thought of the lack of anything DB related. SQLite locally and then sync via a web service whenever connectivity is available. Admittedly none of my apps have a lot of data, but it doesn't sound like you do either.
-
@Zenith said in Credit card readers - what am I missing here?:
It IS internal development.
@Zenith said in Credit card readers - what am I missing here?:
Because 95% of shared hosting is Linux hosting?
This does not tell me internal development. This tells me "I'm going to be putting this on the public web and want Linux hosting out on the cloud".
@Zenith said in Credit card readers - what am I missing here?:
Have the tablet read the catalog from MSSQL.
If you really wanted to do this, there's a library called FreeTDS, which is effectively open-source SQL Server Client for non-windows. But yes, just like any development project, this will pull in dependencies such as UnixODBC. Just like building a Windows app you'll pull dependencies (even if they're "built-in").
@Zenith said in Credit card readers - what am I missing here?:
Go on location, sell stuff, and record sales (this is where the Square reader originally came in).
Hmm, methinks Square doesn't support this kind of interaction. I may be wrong.
@Zenith said in Credit card readers - what am I missing here?:
Come home and export sales from the tablet to MSSQL.
I'm hesitant to say, but it seems your intentions are good, but implementation is dodgy. If you're going to be on the Internet with Square to do the transaction anyways, why not send it off to be recorded live on the database? Through, I don't know, an API?
@Zenith said in Credit card readers - what am I missing here?:
That's when people said "nononono, you need to write a website and a JSON layer in addition to the Android app. You don't need an ODBC driver, it's not more work to write the app twice, and more dependencies are even more betterer."
You're already writing the app twice, or did you think you were going to be able to take your homebrew Windows application and shove it onto Android somehow? I'm really struggling to see what you were thinking here.
@Zenith said in Credit card readers - what am I missing here?:
THIS thread was a question about if I'd be able to use whatever came out of the card reader if I put my 95% done WINDOWS program on a laptop with an audio jack and used it instead of some kludged together Android/PHP abomination.
Oh. Well the answer is: No. Thread closed, edit the title to
[Resolved]?
Look, if it was that easy to do every chinese reseller would have done it already. And how many knock-off Square apps do you see?@Zenith said in Credit card readers - what am I missing here?:
Jesus Christ, I'll keep printing my inventory out on paper, crossing stuff out as it sells, and manually transcribing to MSSQL. There's "Android just isn't going to work for your use case" and then there's "you're moving the goal posts because you're not doing web services for everything so you're wrong."
You made it harder for yourself to start with. Also, you misinterpret what I said, but that's fine.
Also, if you were looking for inventory management, natch Square has that too.
Inventory Management Software | Square
Square Inventory Management software gives your business a suite of tools, including inventory tracking, daily stock alerts, and more. Get started for free.
So not only are you
, you're stacking on complicators gloves for no apparent benefit.
-
@loopback0 said in Credit card readers - what am I missing here?:
@e4tmyl33t said in Credit card readers - what am I missing here?:
I have a Nexus 7 from 2013 I can't install most apps on nowadays because it won't update past Android 6.0.1.
Installing LineageOS takes it to 7.something and I've not found an app I couldn't install on that yet.
Eh. I don't particularly care all that much about it anymore. For actual tablet-things I just use my Surface Pro 3. I just remember it exists every now and again. Eventually I'll bin the thing because either the battery'll be too shot or because I deem it "too old and needs to be put out of its misery".
-
@Tsaukpaetra said in Credit card readers - what am I missing here?:
Hmm, methinks Square doesn't support this kind of interaction. I may be wrong.
It can, or at least it could, cache them, with the caveat that if you explicitly logged out or powered down the device, those charges disappeared. At any rate, there's less of a power drain if I just use the wi-fi to sporadically run cards than keep transferring data back and forth over the network like an online catalog would do. Also, I don't know how many convention centers you've been in, but the reception is not always very good.
@Tsaukpaetra said in Credit card readers - what am I missing here?:
You're already writing the app twice, or did you think you were going to be able to take your homebrew Windows application and shove it onto Android somehow? I'm really struggling to see what you were thinking here.
Originally, I was going to write the app in Android. That was hard and got even harder when it looked like I couldn't separate the Square reader "driver" from the Square POS app. Would've been nice if they had a black box function like WaitForSwipeAndReturnTrueOrFalse() or something. So then I thought maybe I could use the reader, or something like it, from Windows, where I had everything but the card processing already written. So the Android app was really a 2nd copy and the website Android needed to do anything with it was the 3rd. Not interested in that much of a headache.
@Tsaukpaetra said in Credit card readers - what am I missing here?:
Also, if you were looking for inventory management, natch Square has that too.
Only the most bare bones implementation. Item description, item price, item counter. That's it. May as well use a spreadsheet or paper at that point.
The custom solution I developed in T-SQL can automatically distribute costs like shipping across an entire order, calculate break-even prices for multiple venues with differing fee structures, perform bulk editing, generate a printed catalog, generate eBay listings, tell me at any given point in time whether I'm running a profit or a loss, and do my schedule C with a single stored procedure.
What I can't understand is how any online marketplace can get away with not offering calculated shipping or, in the case of anybody but Square, a second payment processor in 2019. I absolutely wouldn't use eBay or develop my own site if they didn't insist on making me choose between losing money on west coast orders and overcharging on east coast orders. But it's really a different subject aside from falling under the "missing features that shouldn't be missing" umbrella.
-
@Zenith said in Credit card readers - what am I missing here?:
@Tsaukpaetra said in Credit card readers - what am I missing here?:
Hmm, methinks Square doesn't support this kind of interaction. I may be wrong.
It can, or at least it could, cache them, with the caveat that if you explicitly logged out or powered down the device, those charges disappeared. At any rate, there's less of a power drain if I just use the wi-fi to sporadically run cards than keep transferring data back and forth over the network like an online catalog would do. Also, I don't know how many convention centers you've been in, but the reception is not always very good.
Yes, I'm IT head of BABSCon, a convention in California going on six years (I think?). If the convention isn't getting you priority wifi, that's on them. And even so, it's not so much more difficult to send the transaction at the time you're "sporadically turning on wifi to run cards" versus not. Unless you're saying you literally transfer the whole damn catalog for each and every interaction with it? Then that would be
and I feel sorry on your behalf.For comparison, the con's registration site is completely HTML+Javascript (yes there's a PHP+MySQL backend for the API) and we run absolutely fine on speeds that make Dial-up tilt its head.
Also, you're looking at the wrong power-saving if you think WiFi is your biggest drain.
@Tsaukpaetra said in Credit card readers - what am I missing here?:
You're already writing the app twice, or did you think you were going to be able to take your homebrew Windows application and shove it onto Android somehow? I'm really struggling to see what you were thinking here.
Originally, I was going to write the app in Android. That was hard and got even harder when it looked like I couldn't separate the Square reader "driver" from the Square POS app. Would've been nice if they had a black box function like WaitForSwipeAndReturnTrueOrFalse() or something. So then I thought maybe I could use the reader, or something like it, from Windows, where I had everything but the card processing already written. So the Android app was really a 2nd copy and the website Android needed to do anything with it was the 3rd. Not interested in that much of a headache.
Yeah, personally I would have searched Square's dev docs (if they exist) to know if there was a "black box function" in the first place. Saving yourself the energy during research phase instead of starting and then trashing days (or months) of effort was probably the smartest thing you (I assume) have done.
In your shoes I would have looked for a card processor that supported such functionality (though undoubtedly that would involve quite a bit more headache with regulations and compliance).
Effectively you took two arbitrary products and tried to mash them together, instead of taking one product and finding another that could be integrated.@Tsaukpaetra said in Credit card readers - what am I missing here?:
Also, if you were looking for inventory management, natch Square has that too.
Only the most bare bones implementation. Item description, item price, item counter. That's it. May as well use a spreadsheet or paper at that point.
Beggars can't be choosers. Who held you at gunpoint and said you absolutely needed to use Square?
The custom solution I developed in T-SQL can automatically distribute costs like shipping across an entire order, calculate break-even prices for multiple venues with differing fee structures, perform bulk editing, generate a printed catalog, generate eBay listings, tell me at any given point in time whether I'm running a profit or a loss, and do my schedule C with a single stored procedure.
And I'm sure you're very happy with what you've done, but that's completely irrelevant to the discussion. I have wrote a custom solution to handle players, their inventory, character data, login credentials, in-game payments, trades, and more, but I'm not going to whine about how Android won't let me connect directly to the database. Indeed, I wouldn't want it to connect directly to the database (or any game client, for that matter), which is why it's behind a connection broker API endpoint where I can control access and (coincidentally) have a common interface for any possible app I want to make, whether it's Windows, HTML, Linux, Android, or even Mac.
What I can't understand is how any online marketplace can get away with not offering calculated shipping or, in the case of anybody but Square, a second payment processor in 2019. I absolutely wouldn't use eBay or develop my own site if they didn't insist on making me choose between losing money on west coast orders and overcharging on east coast orders. But it's really a different subject aside from falling under the "missing features that shouldn't be missing" umbrella.
So you're telling me Square is literally the only online payment processor at all? I'm really confused what you're saying here, because that's demonstrably untrue with the most cursory google searches.
-
@Tsaukpaetra said in Credit card readers - what am I missing here?:
So you're telling me Square is literally the only online payment processor at all? I'm really confused what you're saying here, because that's demonstrably untrue with the most cursory google searches.
No, it's the one I have a reader for. OK, technically, I have an old Intuit GoPayment reader too but I think they shut that down. For APIs, I had struggled through Google Checkout's Swiss cheese documentation only for them to pull that out from under me. They had this great feature where API calls wouldn't just fail, they'd ping pong around with increasing intervals. Days later I'd have these retries cluttering up my test database while I was trying to debug current transactions. Not fun.
Anyway, that was before I had a Square reader. I didn't really have time to fuck around with PayPal directly so I opened an eBay account instead (and a few others that ended up being time wasters - looking at you Bonanza). So fast forward a few years to when the Square reader started causing problems by restarting randomly. I looked into the API and didn't like it. I looked into Stripe and didn't pursue it. I guess I could figure out PayPal if I wanted to. Problem is, it's hooked up to eBay and might be difficult to separate out sales channels. I know Square and Stripe don't have the ability to hook up more than one bank account. It occurs to me this maybe matters less to people that aren't declaring this on their income taxes.
Also, talk about
, how can you not tell the difference between a static library or local DLL and an external internet site with another custom API layer? I don't want to sound like a lazy hipster going "buuuuuut maaaaaaaintenance" but I really don't want to maintain a website that's not generating sales on its own outside of playing telephone for tablet crippleware. Again, I don't like being forced into Chrome and I don't see any reason to require an SSL certificate for sandbox testing.@Tsaukpaetra said in Credit card readers - what am I missing here?:
Indeed, I wouldn't want it to connect directly to the database (or any game client, for that matter), which is why it's behind a connection broker API endpoint where I can control access and (coincidentally) have a common interface for any possible app I want to make, whether it's Windows, HTML, Linux, Android, or even Mac.
You're acting like ODBC isn't a common interface.
It's not whining to want ODBC support. Look, I know the Android developers don't want to provide it. That doesn't mean it's not a feature that others would like to have and might even expect from a non-toy OS. Not every request you don't like is whining. Developers need to get over that mindset.
The major leagues of whining are really people that never shut up about how evil and stupid Microsoft is. For 20 years starting in 1993, I never had any of the problems other supposedly computer-savvy people complained about. Oh it's so hard to install anything without a package manager. Oh it's so hard to use IE to download Netscape. Oh it's so hard to look up Win32 documentation on MSDN. I haven't seen a Windows PC blue screen in 15 years but to hear some people talk it happens a hundreds times a day every day and twice as often on Sundays.
The best thing about Windows is the development tools. I never feel helpless if I have Visual Studio. On an Android device, I always feel helpless and I don't like it.
-
@Zenith said in Credit card readers - what am I missing here?:
I haven't seen a Windows PC blue screen in 15 years but to hear some people talk it happens a hundreds times a day every day and twice as often on Sundays.
Oh. Ooooohhhhhh!!!! I understand clearly now! You're in @pie_flavor's dimension!
Nevermind everything I said, you're in a whole
newdifferent world I have no experience with. Good day, sir.
-
@Tsaukpaetra there's a reason I call them @Tsaukpaetraisms.
-
@Zenith said in Credit card readers - what am I missing here?:
You're acting like ODBC isn't a common interface.
For a mobile oriented OS? No, it's really not. In fact, using a persistent connection like that is strongly discouraged - the OS will actively fight it, especially if your app isn't active for battery life and data saving reasons.
As a matter of fact, ODBC does not seem to be readily available for either iOS or WinPhone, probably for exactly the same reasons.
If you want a system that can keep a persistent connection to a database, you're looking at a job for an OS that's designed for that kind of use, not for an OS that's designed for mobile use. Not that you can't do that on Android - in fact, the kind of app you're talking about is extremely simple to create, even counting the time required to make a tiny API in front of the database. You just can't use it like you're wanting to.
-
@sloosecannon said in Credit card readers - what am I missing here?:
If you want a system that can keep a persistent connection to a database, you're looking at a job for an OS that's designed for that kind of use, not for an OS that's designed for mobile use. Not that you can't do that on Android - in fact, the kind of app you're talking about is extremely simple to create, even counting the time required to make a tiny API in front of the database. You just can't use it like you're wanting to.
He's probably spent more time arguing here than it would take to do the glue service to mediate between the mobile device and the DB.
-
@dkf No, it just kept me from getting as far with my taxes as I would've liked. My software is good but it still relies on manual entry of items and sales. Couple that with acute procrastination and, well, yeah.
I bailed on the Android app long ago. Android Studio just kept Gradling forever instead of compiling.
Credit Card Terminal for Windows - Inner Fence
