Credit Card Processing/POS Application



  • All,

    This morning I went to get my hair cut. As I paid the barber (the same one I've been going to for 10+ years), I recalled a time when I only had my debit card and no cash and had to run to the ATM after a hair appointment, as they still do not have the ability to accept plastic. I was considering how I could make a pretty penny by offering to develop a simple POS application for them to use to book appointments and accept credit cards using something simple (like a VeriFone Omni 3750 reader).

    Those of you that have experience developing these kinds of things - how does this work? Say I have a computer and a reader like the one mentioned above - great. What now? How does this information get transmitted, how are payments processed, how should it be stored, would I need to worry about PCI compliance, etc? Note I'm not looking for any code here, just a kind of architectural overview from someone who's worked with this stuff before.



  • To embbed your app in a POS is complicated. The POS only runs applications signed by someone with a key you need to get from the manufacturer. I don't what it takes get one, but there aren't many companies with these keys around here. You're more likely to run your app in a PC, and use a PINPAD connected in the USB port to read cards. You'll need PCI compilance and a contract with a bank for doing that.

    The common scenario for smaller softwarehouses in my country is to contract a company to make the automation-software to banking integration.



  • @fbmac said:

    You're more likely to run your app in a PC, and use a PINPAD connected in the USB port to read cards. You'll need PCI compilance and a contract with a bank for doing that.

    Yeah, that's what I was getting at - some desktop PC running MyApp with a reader connected to it.


  • Notification Spam Recipient

    Speaking from the posterior here, but you need to establish a line of trust with your vendor. I'm assuming some kind of code signing will be required and communications libraries et al.
    Or, you could use an established third party (like Square, or the other providers I can't think of right now) and hook into their services, which should be massively simpler.



  • @rc4 said:

    would I need to worry about PCI compliance

    You want to explicitly choose products and services that remove you from the scope of PCI compliance. There is no practical way to make your barber meet the requirements of PCI without putting him out of business.

    Look for credit card solutions that convert card numbers into tokens, or that completely offload the processing of credit card data to their service. If you write any code that has an actual credit card number stored in a variable, then you are doing it wrong.



  • A better (and far safer) bet would be to get him signed up for some sort of micropayment by phone thing, IMO

    @Jaime said:

    If you write any code that has an actual credit card number stored in a variable, then you are doing it wrong

    QFT

    @Jaime said:

    If you write any code that has an actual credit card number stored in a variable, then you are doing it wrong.

    BFT



  • @Jaime said:

    If you write any code that has an actual credit card number stored in a variable, then you are doing it wrong.

    Of course not! I would just base64 encode it and reverse it! 🚎

    @Jaime said:

    completely offload the processing of credit card data to their service

    I figured I'd be looking for something like this. Where can I find services like this and how does one interface with them?



  • @rc4 said:

    Where can I find services like this and how does one interface with them?

    My experience is from big corporations. We used XiPay, and we paid about $20K for the consulting services to get it set up. That's in addition to our development work.



  • From what I can tell (since this is purely brick and mortar) - I would need a merchant account from something like http://paylinedata.com/ and then just a POS system that I can connect to the internet.

    Well, that's simple. Too simple, almost...



  • Too simple. If you then write an application with a text box for a card number (or card scanner), then you write the line of code that hands the number to the paylinedata provided software, you are responsible for all of the things that PCI says and the network you install the software on is responsible too. These things are too onerous for the same company that paid the $20K consulting fee to even consider attempting.



  • Forget me handling credit cards with my application. Shouldn't that mostly be handled by the credit card machine, which connects to the payment processor (I guess using the details Payline would give me, for example)? If so, I wouldn't need to handle anything at all with my app.


  • ♿ (Parody)

    @tufty said:

    A better (and far safer) bet would be to get him signed up for some sort of micropayment by phone thing, IMO

    This is super easy to use with a phone:

    We got some this year for Cub Scout popcorn sales. It's awesome. Might be more complicated for them having to deal with, e.g., tips, but pretty much anyone can get up and running with it.

    Obviously, this is just payments.



  • I know about square, and I might go with that if I did do this. I was wondering how other types of credit card machines work/handle things/whatever.



  • @rc4 said:

    Forget me handling credit cards with my application. Shouldn't that mostly be handled by the credit card machine, which connects to the payment processor (I guess using the details Payline would give me, for example)? If so, I wouldn't need to handle anything at all with my app.

    That looks like one of the solutions I was referring to above. Make sure to ask them this question (wording is important): "Does your product/service remove my system from the scope of PCI requirements?". It looks like it might. This is from their site:

    Three-Step Redirect API

    •The Three Step Redirect is the preferred API for customized web-based payment processing. Using this integration method significantly reduces a merchant's PCI footprint without sacrificing end-user look and feel. This method is required when using Verified by Visa/Mastercard SecureCode (Payer Authentication).

    Direct Post API

    •The Direct Post method is the simplest integration method for both web-based and non web-based payment applications, however, merchants using this integration method should have passed a PCI vulnerability scan before use.

    Mobile API

    •The Mobile API supports iOS and Android based devices. These SDKs include a mobile card reader library which simplifies integrations for applications requiring encrypted mobile card readers. Additionally, an end-to-end encryption library is included, allowing merchants to send both swiped and keyed-in payment information without ever touching any sensitive data.


    The first looks like it might get you out of scope of PCI, but it sounds like web site integration. The second definitely doesn't get you out of scope of PCI. The third sounds promising.



  • The one you linked looks like the ones that connect direct with the bank using GPRS, you dont connect those with a PC. You would use a "PIN Pad" http://www.1nps.com/shop/product-category/pin-pads/ for that.

    The PIN Pad will answer you with encrypted data, but PCI regulation will want you to put more layers of encryption over it, and your application to be compliant.

    In my country, solutions like Square are simpler, but take a larger % of your transaction, as compared to what we call "TEF" here, but I don't know how to translate that, or if you even have it there. In what country are you doing this?



  • @fbmac said:

    The one you linked looks like the ones that connect direct with the bank using GPRS, you dont connect those with a PC.

    Yeah, that's what I realized later. I think I'd like to avoid PCI stuff if possible, but keep the terminal like that (at least that was the terminal I had in mind all along).

    @fbmac said:

    In what country are you doing this?

    United States.


  • Discourse touched me in a no-no place

    @boomzilla said:

    We got some this year for Cub Scout popcorn sales. It's awesome. Might be more complicated for them having to deal with, e.g., tips, but pretty much anyone can get up and running with it.

    A local restaurant has something that I believe is from Square that's actually a pretty nice turnkey system. It comes with an ipad and a credit card reader; the worker punches in all the relevant info, then you swipe your card, and you have a place to sign with a stylus, and buttons for 10/15/20/other% tips.


  • ♿ (Parody)

    Yeah, their app has stuff you can set up as a "cash register," but I didn't look into it too closely. Mostly other people used it.


  • Discourse touched me in a no-no place

    @boomzilla said:

    I didn't look into it too closely.

    Not compatible with your :belt_onion:?


  • Discourse touched me in a no-no place

    @boomzilla said:

    Yeah, their app has stuff you can set up as a "cash register," but I didn't look into it too closely.

    As a customer of someone using it that way I can reiterate it's a pretty nice-to-use system.



  • The stuff we did waaaaaay back was a micropayment by SMS deal. You generate a url with a unique one-time token, in the form of a QR code, client scans the token with their phone, hits the URL, clicks a couple times, receives a premium rate SMS as payment, your site gets payment token so you know the payment has been received.

    Should have made millions. It was made for anonymous micropayments to porn sites. Guys running the company had "christian morals", went bust trying to sell it for print media paywalls.

    This was in - ummm - 2003 for the mockup, which was in PERL, and about 2005 for the real version, which used Ruby on Rails (with a heavily customised server and butchered ruby).

    The square stuff looks pretty damn good, though.


  • Discourse touched me in a no-no place

    Yeah, this is what I was thinking of:

    Again I saw it in a burger joint, but if it's a generic "cash register" software it seems like setting it up to work for a barbershop instead should be pretty easy.


  • ♿ (Parody)

    @loopback0 said:

    @boomzilla said:
    I didn't look into it too closely.

    Not compatible with your :belt_onion:?

    My job was more about wrangling Cub Scouts and handling the cash.


  • ♿ (Parody)

    @FrostCat said:

    Yeah, this is what I was thinking of:

    Yeah, that looks really nice for a shop.


  • Notification Spam Recipient

    @FrostCat said:

    Yeah, this is what I was thinking of:

    Yup. Note that the $99 tagline does not include an iPad 4th generation (required, not included) that you would need to set up along with the system.



  • @boomzilla said:

    My job was more about wrangling Cub Scouts and handling the cash.

    Paging Operation Yewtree. Operation Yewtree to aisle 5. Code pink.


  • Discourse touched me in a no-no place

    @Tsaukpaetra said:

    Yup. Note that the $99 tagline does not include an iPad 4th generation (required, not included) that you would need to set up along with the system.

    I did not notice that but it seems entirely reasonable given the cost of an iPad.


Log in to reply