On Thu, Apr 25, 2013 at 6:19 PM, Mauricio Tavares <raubvo...@gmail.com>wrote:
> On Thu, Apr 25, 2013 at 5:41 PM, Ted Byers <r.ted.by...@gmail.com> wrote: > > Thanks Mauricio, > > > > I'd apreciate that. I hadn't actually thought about a card reader, but > > you're right. For the POS side of it, we'd need (and really should only > > use) an encrypted card reader, to handle the credit ar and debit > > transactions. That said, though, what this thread started as involved > bar > > code reading (in POS that would identify what has been bought and look up > > the price from the DB), and of course in inventory management (both POS > and > > taking inventory) the idea is to read the products' bar codes, to > identify > > the products bought ot in stock, and then enter the quantity, and adjust > > the amount represented in the DB as being available for sale or use > > (depending on whether we're talking a contractor or a vendor). > > > For the bar code scanner, I have seen a program called > out-of-milk in the android which seems to scan bar codes rather nicely > with the onboard camera (you hold product so bar code is inside its > border. When it is successful the border goes green) and then search > for them up somehow (google? built-in db? I dunno). Most of the time > it finds the product. I take there has to be examples on making such a > reader out there. Or talk to the guy who wrote it and see if you two > can do something together. > > Can you provide contact information for this guy? I had found a rather good bar code scanner software product from S4BB, but they ignored my request for contact and information. It reads the bar codes very well, but when it has done so, it sends the data hme and the browser on my Blackberry opens with product information. And, it is cross platform, so there are versions that run on just about any smart phone. All the apps I found that read bar codes work like this, building their own database of products, manufacturers and retailers for each bar code. Thus some are more useful than others as it takes time to build such a database. I'd expact that such a database would get so large that it can not be stored on a smart phone. > > That said, a question that perhaps ought to branch off to a distinct > > thread, is "Are you aware of an encrypted card reader that a consumer > could > > We probably should do that. > > > plug into his own computer or mobile device, to transform ecommerce sales > > into card present transactions (something I am sure processing banks > would > > prefer over card not present transactions). A part of much of my work > > these days is investigation and development of fraud prevention > > technologies, and such a device would be of tremendous value, especially > if > > at a price point a consumer wouldn't think twice about buying one. > > > I just asked the programmer who usually integrate those readers. > Off the top of his head, we have used one by honeywell and another by > infinite peripherals, but those are for IOS. He did not remember which > one we played with for the android. > So, I ought to be able to get further informatin from Honeywell (a little name recognition wouldn't hurt in promoting the idea to consumers). > I wonder who makes the ones used by paypal and by squareup (I think > that's its name). > > > As I have several decades of software development experience in a variety > > of programming languages, I am sure I could develop something using a > same > > SDK, but as all my apps have been either intended for a desktop or for > > application servers, and I have yet to develop something for any mobile > > device, it would be good if I could connect to someone with mobile device > > app development experience if I have to go the route of developing > > something like that. If the programmers you know who do this sort of > thing > > hate those SDKs, I think I might prefer to hire someone to deal with it > > than take it on myself (when my budget allows me to do so). > > > Also, one of the sucky parts is that after you get it to work > you then have to certify it with your payment processor. There are > ways around that: I just talked to my boss and he said a POS (like > ofbiz!) does not deal with the card reading. Instead it tells out > software "bitch, I want to charge $19. Yay or Nay?" and the program > talks to card reader and then to the processor, and then says whether > transaction is approved or denied. POS takes that info and does what > it needs to do. This way the POS does not need to be PCI compliant; it > is out of the card-handling loop. So, it instead can focus on the > other aspects like inventory control and providing an interface that > does not make your end user want to scream. > > That is a great way to enhance the security and fraud prevention methods. I have developed my own API (in Perl) for taking ecommerce data and submitting it to a merchant's processing bank. And, I am investigating incorporating a suite of Perl packages into my API, so that I can support a great many more processing banks. I would love to be able to incorporate support for that approach also, as well as support for 3D secure transactions (when I get time). But, in the realm of ecommerce, a secure channel would have to be created between the vendor's server and the consumer's card reader, so that the card reader knows where to submit the transaction, and communicate the result back to the vendor's code that handles the response. I haven't thought about this possibilityenough to figure out how to handle that. > Now, I apologize for being a bit vague at some points; I am making a > point not to mention the name of the software we make. I am not one of > those silly monkeys who sneak into mailing lists to peddle programs, > services, and (enlargement) pills. All that matters are the concepts, > which should be applicable to whatever system you are dealing with. > > That's OK. Feel free to send such data, along with who you see as being your pronciple competitors, I am venturing into what it new ground for me, in terms of card readers and related software, so I do not yet know who the principle providers would be, and thus a little info from someone who works in the industry as to who to look at would be appreciated. Thanks Ted
