What is your workflow? How many terminals do you have? How do you deal with a busy bar where everyone is paying for 1 drink at a time via CC?
Personally I think if integration is done via DLL then it will feel like an extension of samba, with depending on how itās setup could maybe used specific to the API used to create it.
On the other hand having integration as part of samba allows for variety of different client and bank API customisation.
1 Like
Too bad itās windows. Can you share the reasoning behind doing it in windows rather than a client-server model and writing in php or ruby? DLLs seem so yesterday to me.
They have 4 terminals. If you have a bar with single drinks, open a tab and hold customers credit card until they are drinking.
That doesnāt work. 1) people donāt like you to hold cards, 2) People want to pay for 1 drink at a time so they donāt have to flag down an overmatched bartender to pay when they want to leave. Also people waiting for a table donāt want to have to wait to cash out when their table is ready. You have the family being shown to their table while Dad waits for a bartender to run his card. Itās a disaster scenario.
This is the only real point there in my opinionā¦ and is a very fair point as it has become frond upon to even handle a persons card at all, most machines are configured in such a way you put the amount in and allow customer to put own card in etc to remove the part where anyone else has possession of the card.
All three of these would suggest under staffing, if people are having to wait to get served to pay they will be waiting whether you have integrated card terminal or not to get their drinks in the first placeā¦
The difference in time between an integrated and separate machine is not that huge, there are only two more steps in the process in that you have to type the amount in the machine and then press credit card as payment method.
While selecting payment method would not be completely replaced as you would still need to press a button or two to initiate the card transaction on an integrated machine.
The main reason places have integrated card machines is not a speed thing but to reduce USER ERROR.
The only time saving on integrated card processing is typing in the amount on the machine.
There are disadvantages to integrated solutions.
The first one being that you will likely require additional pin pads/cc machines so as to have one per till.
Where with separate they can be shared which I know is a common thing for hospitality where the preference would be more tills.
The verdict is that SambaPOS currently DOES NOT have an integrated card solution. This is something that is being worked on and would expect if a custom device setup isnāt put together for V5 I would expect that V6 will almost certainly end up having the ability in one way or another.
Yes many people would like to have an integrated solution and it is being worked on and would be a valuable feature.
The question as to if its a deal breaker in using Samba is just that. If you you think you need it now you might need to look at alternative solution.
This topic is in V4 category and can say with certainty that V4 will not have this functionality.
V5 solution is being worked on and sounds like between paulin and shavan they are making great progress.
2 Likes
Itās not understaffing. Should I have a bartender for each customer? Itās 3 deep on a saturday night. 90% of the time it doesnāt matter, but how much $$$ do I lose on Fri and Sat night because of a slower workflow?
Iām trying to determine if itās a deal breaker. The solution doesnāt have to be fully integrated. But there needs to be something where a card can be swiped and a token saved, so that you donāt need the card again to put the charge through. So then you can
- Swipe to run a tab, and just put it through when they want to cash out. or
- Just Swipe without having to key anything in manually
Are any SambaPOS developers in the US? Did someone really ask how many of the 100 POS solutions have integrated payments? Like all of them? Like someone said, itās where they make their money. Itās a math problem; you can buy an Aloha system for $25K and get any processor you want, or pay $1000 and use the higher fee service.
I did, I have dabbled in 3-4 softwareās in last few years and only one offered this as an expensive extra option.
The developer is emre, he is not US based but a couple of the forum regulars are US based.
Is this a legitimate option?
I am not US based but here in UK any 'over the counter sales require the use of Chip and Pin or Contactless if under Ā£20.
The issue with your suggestion is the idea of storing card details. Im no PCI pro but this would be a big issue in getting approved. Storing card details electronically is one of the main PCI flags resulting is huge amounts of paperwork.
This paperwork would be on the user not the software developer as allot of it relates to security and networking to protect the data.
If you were content with sorting your own PCI compliance and were happy to store card details electronically yourself you could probably achieve an integration with scripting in V5 IF you can find a payment processor which accepts the transfer of card details like that but think thats where you will struggle.
Look at most websites, they often use paypal, sagepay , autherizenet etc through either a new window or embedded frame as the requirements for self hosted card processing are complex and expensive.
Again not sure how it works in US as believe you guys are still heavily using swipe for cc processing rather than chip and pin but the only viable solution here in UK is to use a provided card machine connected to your POS terminal and the POS DOES NOT have any contact with card details. It merely tells the terminal the amount and waits for the terminal to respond with approval etc.
This I believe is what is being worked on and is the type of integration you see in any place with it in UK even big companies like Tesco etc have a separate card machine which is connected to the till, the till itself doesnāt see or handle the card details
I donāt think or havenāt seen the impression of anyone looking to make SambaPOS actually process the card details itself.
Just to follow upā¦ Not all of them, like I said have seen many without the option.
And FYI its not where they make their money, they might make some but think yourll find most money is earnt through support rather than a tiny commission of card processing.
I have looked into this and some offer a basic referral reward and others offer a small commission and that commission would be a % of there commission so like 1% of 2% which on Ā£1,000,000 anaual card turnover would be like Ā£200, while is a nice bonus for little effort the real revenue for them will be support on the EPOS system.
1 Like
Nobody in the US would pay for a restaurant pos system without it. Clover, Square, shopkeep, lavu, toast, touchbistro, vend, zing, revel, bindo, ambur, breadcrumb shopify. Thereās a million of them.
This is how itās done with the Aloha System. Very customer friendly. The most used in big restaurants in the US. Old, clunky, looks like a bad college project from the 90s, but they get $20K+ for it.
Its all done with secure tokens. Thereās no card info stored. You run the card, it contacts the processor and verifies the details, and returns a token that can be used for some period of time. So the POS only stores the token. Then when you settle you just send the token with the amount to charge. To integrate you need to get a PCI compliant SDK. Otherwise youād have to get your code certified, which is cumbersome and expensive.
Itās the same way online processors like Stripe.com do it. The difference is that stripe uses a secure form (all of the code is JS so nothing is stored on your server).
This is what I thought you might say and may well be possible through v5 with a bit of work,
A friend is developing a system with a ācard vaultā provider like you describe for his subscription website, cant remember the name of the company but they act as a card vault.
You would obviously need one of the PCI compliant card vault services along with a gateway and merchant account which is not something I have at my disposal for testing.
I would have a look at the scripting capabilities in V5 as it is most likely possible although the PCI SKD side is something iām not so familiar with.
Scripting the submitting of card details to the āvaultā and saving the ātokenā as a customer entity data field.
This however is something that would be a āuser developmentā, one of the main principles of SambaPOS is that you are not forced in to a particular method rather than emre hard-coding an integration to a specific provider he would prefer to add the abilities for us to do our own integration to a provider of our own choosing.
1 Like
A card vault isnt the issue, really. You still have to read the card info with a card reader. So the code that transfers the card info from the reader to the ācard vaultā has to be PCI compliant. Iām not sure how hardened it has to be. You canāt allow some 3rd rate programmer the ability to edit the JS and suck out the CC info. So the local module that handles the card info has to be certified, or youāre not in PCI compliance.
Chip readers arenāt required in the US, because there are 5 million terminals and you canāt force everyone to buy something that is only marginally better. We fought a war long ago to escape that kind of authoritarianism. 
Plus chip readers slow everything down. Better to just get beaten once in a while.
Theyāre also very tight about man in the middle scenarios. With an HTTPS form itās fairly easy. What you want is the terminal to act as the vault. Card reader on PC, sends info to terminal (on your local net somewhere). So you can either swipe the terminal, or have your POS talk to the terminal via ethernet.
I thought they were in the process of switching? Obviously its not an over night thing. I know customers at hotel from US have generally started having a pin vs many years ago when you had to swipe and sign.
Thatās understandable and get that but I was under the impression this worked through āframeworksā if thatās the right expression, thats they have a hook/call code to process the card detail.
I am sure my friends signup form is self hosted with SSL which is ok as it doesnāt hold the card details locally but guess thats what your saying in ref HTTPS forms.
You have a link to one of these? Havenāt seen such a thing myself but never look to be honest.
Hey Guys - sorry I missed the conversation.
The above is all what I have at my disposal. The integration needs to be 2-fold:
- Terminal Integration (Direct Bank connection);
- Bank-End processor Integration (PCI Complaint Store).
All the stuff talked about with PCI Compliance is all relevant and @Danial I agree I would like to plan for a 3 deep busy bar āPay Passā AND āAloha System. Very customer friendlyā type facilities.
What we really need to a āframeworkā to built integrations with as whatever I do may not be applicable in the US or UK. Maybe if I ever get this to work I can public a general āsend & responseā framework that Emre may pick up on 
1 Like
Hey all!
Iām headed to bed, but I stumbled across this and was hoping to put my 2 cents in.
1: As far as PCI compliance goes, generally thatās on the establishment running the software. As far as modules go, all that really needs to happen is some vendor-agnostic coding which will allow various banks/vendors modules to āplug inā to Samba. Itās actually not very hard (if you know that sort of stuff).
2: Creating a module yourself with the necessary security and compatibility to satisfy various clearinghouses in compliance with Federal law (in the US) is RIDICULOUSLY hard and complicatedā¦so much so that most vendors and banks wonāt even consider letting you process. Better to focus on basic handles for popular APIās such as XCharge, Wells Fargo, FirstData, ETC. Many of these vendors will happily and freely provide their APIās for testing purposes if you ask!
I have Samba v5 running at a bar and restaurant with both Windows tablets and traditional POS systems, with the DB on an old school Dell Server running 2003 with SQL 2008 Standard. Itās been running since August and it ROCKSā¦however the lack of integration during busy times is more than a minor annoyance (but given how great Samba is, we deal). I own an IT consulting firm and plan on marketing Samba v5 to local establishments once I figure out a reasonably simple workaround.
I would be pleased to assist you all in this process in any way I can. Thanks for reading my long winded rant!!! I will reply to you all tomorrow.
3 Likes
19 Hours is up. The delay is your faultā¦
Itās optional. Whatās changed is that if you DONT have a chip reader, the vendor is responsible for bad charges and not the CC company. So thatās the incentive. Itās a math problem again. How much does it cost me vs how much does it cost me. If it slows the business down, you eat the bad CC charges.
Iām guessing. I donāt know if thatās allowed, or exactly how the SDKās work. but Iād think a device that canāt be read would be suitable. The terminals already talk TCP/IP, so why wouldnāt you be able to send the card info from multiple POS systems? That way youād only need 1 terminal per business. Why would you need a hard wire from each terminal? Heck, I donāt care, give me a terminal with a card reader that I can glue on the side of the POS screen. You donāt even need to run the CC info through the PC. Just send the total, wait for a light, and swipe the card. As long as I donāt have to have some server with wet hands keying stuff in.
Doing one from scratch would be folly; but writing a card reader interface that talks to a terminal is the way to integrate it well enough to eliminate the deal-breaker of no CC integration; if thatās a deal breaker.
The issue with a build-your-own POS is not the issue of writing an API. Itās a matter of securing the data from the card reader to some API.
For the record, Iād rather deal with a band of thieves than First Data, if thatās not redundant.
Or course everything is made more difficult on a Windows Platform. C++, DLLs, Mickey Mouse APIS. Itās too painful to contemplate.
But is that not what the ācard vaultā sites do?
I cant remember the company my firend was looking to use but they are linked to pretty much every gateway provider.
His form is java based pon secure server which securly gives card number to the vault.
Nothing is recorded locally other than the token and then to process the charge you post the toden and amount to the vault which handels it though the gateway setup.
You still need to talk to the card vault. It doesnāt solve the problem. the problem is the human readable card info that gets scanned by the card reader. The processors are all "card vaultsā. Why would I need an intermediary?
The old āstoring cards on your serverā is 1995 PCI compliance. Now itās much more complicated. Itās end to end, man in the middle protection.
If youāre not scanning cards, you can just use HTTPS forms. But when you scan a card you have the card info to the API issue. Who has access to that info? How easy or difficult is it to hack?
Iām not sure how the chip readers work, or if anyone has a chip reader for POS systems. This is all crap in reality. the CC card companies make so much money that the CC losses are nothing. A tiny cost of doing business.
I have a chip and pin reader for intergrating. Is a dev unit but have not had much time to dive into it too deeply plus I have only had 1 of maybe 50 clients ever ask about it.
It is a stand alone terminal in its own rights but you feed an amount in from POS and it returns a string of responses as it processes, ie enter pin, processing, aprived.
This is probably the only viable solution in the UK given chip and pin is required for over the counter transactions.
The card info when swiping the card is just the elctronic data of the information on the card, number, exp and holder name etc. There is nothing on the card MSR which isnt on the card face.
So, actually, a mag swipe is basically a keyboard; no matter what you do, the info off
of the mag reader is transmitted plaintext to the computer. Itās been that way for many years.
The payment module detects the swipe, hiding the input, then encrypts the info before transmitting. All of the compliance stuff is on the payment vendor. There is no practical method or need to secure the info from the card reader to the API.
Client-side, the PCI compliance is the establishments (e.g. bar or restaurant) responsibility; like having a properly configured firewall, necessary access controls, and AV/AM.
While I understand you may have frustrations with them, the reality is that they are the largest CC clearinghouse in the US, and making the modifications necessary to allow Samba to communicate with their software might be the quickest way to open the door to other vendors.
Has @emre or anyone else been in contact with these vendors? Iād be happy to make contact with some US based offices and make some inquiries if needed.