I once talked with PayPal TR people and asked how can we use that API. They said it is designed for website usage (by customer). If multiple payments processed from same IP address (by venue) it will ban account due to security reasons. I don’t know if it is still the case. That was about 2 years ago.
Just to clarify. When we talking about API’s and API integration, i know about integration but i dont quite understand what file an API is that we can link/integrate into another software. Can you elaborate on this?it might help make me understand the process and how i can make it work for integrating an eftpos terminal into samba. Ive so far managed to get the eftpos terminal to login, do settlements and other things, but now im trying to figure out what steps do i need to take to integrate it into samba
API is ‘application program interface’ its not a file but more of a term that there is the ability to communicate between programs/software.
I am part way through an integration with a hotel booking system, have a look at the thread, it might help you understand;
That works with JSON, you make a request to their rest url giving details of request and it returns data based on your request.
It does yes. I will call to be sure. That API is straight forward it would be easy to use with just a standard card reader. Integration would be easy. Ensuring PCI compliance might be little more work though.
That’s always going to be the hardest part I think.
Had to work on PCI compliance for the hotel…
Their main issue was storing card numbers for security on bookings, spend long time on phone with TrustWave and my understanding for their situation was if the network the office ran on was completely separated from public wifi and you did the network checks they expected you to do (checking for unauth devices on network etc and loging firewall settings & changes on modem etc it was acceptable)
Believe storing card details to be the biggest concern.
As for processing as the card details are not stored it should be less of an issue but the above issues would obviously want to be applied also.
As processing is not handled by us (popper efpos machines on landline rather than network) that part of the compliance questionnaire was not needed but if network can be shown to be secure and your communication with paypal api is secure/encripted etc then it should be ok…
How would samba handle the values from the reader? Presumably they would be local to the terminal within the script into request and not put into database…
The request url is https and paypal arent going to allow insecure connections…
TBH I think the compliance questionnaires are made to be overly techy to scare less tech savy people to have 3rd parties in to sort it out.
Well given that paypal is only going to accept sufficiently secured requests I would say if you can show duediligence on securing the local network and the software’s use of the card details is done properly it should be ok.
To contribute to this great idea, I am looking at :-:
A merchant installs your order-entry app, and the PayPal Here app, on a device. Then, a merchant can:
Use your app to assemble an order
Use your app to send the order, as an invoice, to launch the PayPal Here app
Use the PayPal Here app to adjust the amounts as necessary, or add items, and then accept payment with a credit card, PayPal, cash, an invoice or a check
Thus, during the Order and Payment Flow:
Your app sends an order to the PayPal Here app (using the API)
The order details are pre-populated within the PayPal Here app
The merchant uses the PayPal Here app to accept a payment
After the payment is successful, the merchant is returned to your app
I like the idea and is a solution but seems allot of steps in the process vs the old fashioned way of ringing in on till and having independent PDQ machine where you punch in the price take the payment and then put the payment in to pos.
Would love to have a go at having a PDQ machine connected to the PC so samba tells PDQ machine the amount and responds with payment received but the issue with that is PDQ machines will generally be locked down pretty tight for security/PCI.
Am not sure what the level of integration big shops like tesco have would imagine its as above and that the pc/pos has no direct contact with the card details.
Was having a look at PayPal Here the other day but seems to me much more that its paypals offering for small businesses who would look to use it as a basic POS in the way that you setup products on the app. In which case I would expect they would be less open to intergration with other POS but thats just a guess.
Have you considered integrating with Stripe? https://stripe.com/docs/stripe.js
I dont know about integration with a card reader but I would be an affordable option where card transactions are minimal. (no monthly fees, Terminal lease, merchant accounts etc…)
Commission seems reasonable but 7 day to receive seems excessive, anyway.
ecomerse is allot different to over the counter sales, think you increase your chances of charge-back/challenges if not very careful for over the counter.
Not sure how it is in other countries but in UK all cards are chip and pin, which is why I would look to have a normal card terminal which allows sale total and processed feedback to EPOS which I expect is what most systems use.
The Latest Systems
The latest POS systems often have a virtual terminal inside their software. Most merchant processors can be used with these terminals and the price for the POS includes everything you need to take a sale.
Some POS machines have a terminal which runs alongside your POS software and the two systems can talk to each other. This does of course run the risk that future upgrades could make the two systems incompatible.
Alternatively, there are virtual terminals whereby the POS system accesses a payment gateway and processes payments on the merchant processor’s servers.
This will only work if you have an internet connection of some kind so is not best suited to areas that suffer from lost connectivity.
However, the key decision for most merchants is not whether to integrate their POS system with their card terminal but what approach they will take when doing so.
Virtual terminal is the term i was looking for. Having a virtual terminal on your own system I expect would be a tall order for a small business given PCI/security requirments which is why a seperate terminal which can comunicate with the POS is most likely a common choise for smaller business wanting PDQ integration.
It primarily removes the user involvement with the PDQ terminal and reduces human error.
If/when I look at this kind of integration that will be thr route I will be going down.
That is the method I most often see with medium sized business like garage chains and franchises.
With smaller ones sticking to the independent PDQ machine route.