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.
> 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.
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.
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.
> Thanks
>
> Ted
>
>
> On Thu, Apr 25, 2013 at 4:26 PM, Mauricio Tavares <raubvo...@gmail.com>wrote:
>
>> On Thu, Apr 25, 2013 at 4:06 PM, Ted Byers <r.ted.by...@gmail.com> wrote:
>> > This is an important question.
>> >
>> > I too have potential clients who want to use their smart phones for POS,
>> as
>> > well as to take inventory (both within their warehouse and on rmote job
>> > sites). I have found bar code reader hardware that will put the barcode
>> > data into whatever field in whatever form has focus (regardless of
>> whether
>> > the applicatin is a web app, with which the user is interacting via a
>> > browser, or a dedicated app). Obviously, I want to have the user working
>> > with both the POS and inventory components via the web browser. However,
>> > all the bar code readers I have found for my blackberry are dedicated
>> apps
>> > that send the bar code data to a website, and I see the result only in
>> the
>> > bar code provider's web page (always some form of advertizing or service
>> > supporting comparison shopping). None, that I have found so far, will
>> > interact with any other app on the smart phone, regardless of whether the
>> > other app is a specialized app or a web app living in a browser. What I
>> > have to find is an app or browser plugin that will work on any mobile
>> > device that will put the bar code data directly into whatever web form is
>> > open (and so avoiding the need for these guys to spend an extra couple
>> > hundred dollars per bar code reader); either that or someone who has the
>> > ability and experience required to develop it (and who is affordable).
>> >
>> > Do you have any information what would help us?
>> >
>> A lot of the (insecure) card readers (hardware) will just act
>> like they are glorified dumb keyboards. At work that is how we would
>> test them. That said, PCI now wants you to use encrypted card readers,
>> and those usually require some kind of library to talk to them. And
>> those libraries usually suck noodles through straws... at least that
>> is what I gather talking to the programmers here who have to make them
>> work.
>>
>> If you want, I could ask my boss which card scanner that you slap to a
>> cell phone he would recommend (easy to work with, etc). We really do
>> not support them but have investigated using them before.
>>
>> My money is to find one of the ones that use the headset port with a
>> sane SDK and then see if you can port/hack that to the blackberry;
>> they usually support apple and android hardware only. Ok, maybe
>> windows, but that is a scary bag of cats.
>>
>>
>> > Thanks
>> >
>> > Ted
>> >
>> >
>> > On Thu, Apr 25, 2013 at 3:49 PM, freap <fr...@a1bodyandframe.com> wrote:
>> >
>> >> Are you expecting to run in a browser or rebuild as a dedicated
>> >> application? Android?
>> >>
>> >>
>> >> On 4/24/2013 10:39 PM, Hans Bakker wrote:
>> >>
>> >>> Good morning!
>> >>>
>> >>> we just get 2 requests in from customers who ask the question if they
>> can
>> >>> use a tablet for a POS (point of sale) or cash register for a physical
>> shop.
>> >>>
>> >>> If we could make this work using the WEbPOS from OFBiz, add local
>> storage
>> >>> and sync for product and customers and orders (to use the POS off-line
>> when
>> >>> internet goes down) and either use the camera or external barcode
>> scanner
>> >>> and a wifi network printer could do the job .
>> >>>
>> >>> This would significantly simplify and reduce the physical shop
>> investment
>> >>> for IT.
>> >>>
>> >>> Anybody interested? let me know so we could together on this subject?
>> >>>
>> >>> Regards,
>> >>> Hans
>> >>>
>> >>>
>> >>
>> >
>> >
>> > --
>> > R.E.(Ted) Byers, Ph.D.,Ed.D.
>> > t...@merchantservicecorp.com
>> > CTO
>> > Merchant Services Corp.
>> > 17665 Leslie st., unit 30
>> > Newmarket , Ontario
>> > L3Y 3E3
>>
>
>
>
> --
> R.E.(Ted) Byers, Ph.D.,Ed.D.
> t...@merchantservicecorp.com
> CTO
> Merchant Services Corp.
> 17665 Leslie st., unit 30
> Newmarket , Ontario
> L3Y 3E3
