Is there a protocol which point-of-sale machine use to talk to a credit card machine? What is the recommended software/hardware platform to prototype a point of sale system?
There are several protocols available, here are some of then: First there is OPI, Open Payment Initiative, specified by Wincor Nixdorf. It is in wide use. Then there is the german ZVT protocol or the Swiss VEZ protocol. It really depends in which region you plan to use it, the protocols I listed definitel are in widespread use in Europe.
It would be easier to get the sdk of your payment gateway and integrate it into you software. I have hooked ip VeriFone, Clover and Priority machines. Each vendor has multiple APIs in different languages.
Related
I have a couple of questions concerning BLE beacons:
1) Are beacons based on nRF51822 chip the best solution? Or are there any other chips better than nRF51822? I want to take up BLE beacon development and struggling to find the right hardware for these needs. As a novice developer I want the beacon to be as cheap as possible in order not to waste money in case of a failure.
2) Is it possible to buy pure Eddystone beacon (not iBeacon)? The reason for choosing Eddystone is that Eddystone is capable of broadcasting URLs that are essential for me.
The second question stems from my failed attempts to find a pure Eddystone beacon on Chinese electronics sites like alibaba.com or aliexpress.com where the only firmware available is iBeacon. But iBeacon is not an option because it can't broadcast URL the way Eddystone does.
Apart from the above questions It would be great if someone wrote a quick guide for taking up BLE development with Eddystone and covered basic topics like: chip to use, beacon model, best website to buy beacons at, etc.
Thanks in advance,
Pavel
1) I've worked with Estimote beacons and Chinese beacons from Amazon and in my opinion, they do not differ in terms of accuracy too much. Especially for prototyping, I'd buy cheaper ones to test if your use case can be satisfied with BLE beacons. If it is too inaccurate with Chinese beacons, chances are that it won't work with more expensive ones either.
2) Why do you need the URL broadcast? If the app is going to use the url, it would have to be connected to the internet. Therefore, you can just query the beacon's IDs to a web service to get back an URL and use that. Personally, I think this is a better approach as you can configure the web service from anywhere to change the url for beacons where as if you want to change the URL of the Eddystone, you have to go to the beacon to configure it.
The nRF51822 is a common implementation, is flexible, well understood and can be very inexpensive. Be aware though that development costs, add on circuitry for power and/or peripherals, and packaging can easily eclipse the Bluetooth chip when you get to production cost savings.
If you want to buy an off the shelf beacon, most models supporting Eddystone also support iBeacon, simply because supporting both adds no additional hardware cost. Newer Radius Networks and Estimote beacons all support both. And, yes, cheaper generic Chinese suppliers often have bulk manufactured inventory from before Eddystone existed at only support iBeacon.
I have a bunch of generic beacons from China that I'd like to upgrade to Eddystone. How do I go about doing this?
Some beacon hardware vendors like Estimote and Kontakt.io now support Eddystone™ too. You are able to easily change the broadcasting scheme of your beacon to iBeacon or Eddystone protocol. In the below video by Pushmote URL, you can see how to change Estimote beacons' broadcasting scheme to Eddystone™ protocol:
https://www.youtube.com/watch?v=gX0AlAOB6NU
As it's possible with Estimote and Kontakt.io beacons, it might be possible with yours too. Contact with your hardware manufacturer to see the possibilities.
I am quoting it from here
Generally the "transmit these bytes" instructions are carried out in
firmware on the beacon and can't be controlled in real-time via
software. Many beacon manufacturers have updated their provisioning
applications to allow their devices to broadcast Eddystone frames. For
generic beacons (maybe you mean raw BLE chips? or Arduino/R-Pi sets?)
you'll need to set the bytes to Tx manually since there's no generic
provisioning app (or not that I'm aware of).
Thanks to Michael Ashbridge (aka) mashbridge
Unfortunately, you probably can't. Generic beacons typically don't offer firmware upgrades, and few if any generic vendors offer Eddystone support.
Full disclosure: I am Chief Engineer at Radius Networks, which sells beacons with Eddystone support.
I study the construction of mobile networks and began to study MVAS. But could not find a specific iinformation what protocols are used in the VAS or MVAS.
I understood that main protocol using SMS - it SMPP.
It would be great if someone made a list of the protocols used, or links where I could read more information about the protocols used.
There is such a list; it is published by 3GPP in specification TS 23.039.
3GPP (earlier ETSI) specified the GSM, UMTS and LTE systems, with standard protocols for most of the interfaces. They did not specify any standard protocol between Short Message Service Centres and external messaging servers though.
Instead, this was left open, and each SMSC developer specified their own protocol. An early and successful SMSC developer was an Irish company called Aldiscon, which was later taken over by Logica. They developed the Short Message Peer-to-Peer protocol (SMPP), and published it as an open standard, which is the reason why it's so widely used today.
Could somebody tell me what does mean 'DCS' in IP telephony communication standards?
I have looked at the internet and found that DCS is a distributed control system, but I think it's not relevant information when we talk about IP telephony communication standards.
A DCS is probably a Digital Cross Connect System in the context you have seen it, although it also seems to be a popular set of letters to include in product names, so check that it is not simply this you are seeing.
A digital cross connect is a 'box' or device that allows you switch between digital circuits - e.g. connect an incoming digital 'trunk' to an outgoing digital 'trunk' or phone 'line'.
You are correct that 'pure' IP telephony does not generally have to use cross connects as it is packet switched rather than circuit switched, but in the real world most IP telephony systems have to interface with or connect to older digital circuit networks and equipment.
For this reason you may see devices which act as a gateway between IP telephony networks and circuit switched digital networks - these boxes are often called Media Gateways.
See more about DSC at: http://en.wikipedia.org/wiki/Digital_cross_connect_system
I'm doing a grad-school software engineering project and I'm looking for the protocol that governs communications between ATMs and bank networks.
I've been googling for quite a while now, and though I'm finding all sorts of interesting information about ATMs, I'm surprised to find that there seems to be no industry standard for high-level communications.
I'm not talking about 3DES or low-level transmission protocols, but something along the lines of an Interface Control Document; something that governs the sequence of events for various transactions: verify credentials, withdrawal, check balance, etc.
Any ideas? Does anything like this even exist?
I can't believe that after all this time the banks and ATM manufacturers are still just making this up as they go.
A shorter question: if I wanted to go into the ATM software manufacturing business, where would I start looking for standards?
Well, there are lots of interbank networks. I would guess that each of them communicate differently. The stickers on the ATM (Cirrus, STAR, Pulse, etc...) identify which network the machine participates in. I do believe, though, that the "structure" of the message is dictated by an ISO standard. Cirrus is a Mastercard owned network and PLUS is a Visa owned network... I'd scour their sites to see if they publish any API details.
Edit, by request:
Have a look at the following ISOs 15022, 20022, 9362 and 4217 -- http://en.wikipedia.org/wiki/Category:Financial_routing_standards
ISO 8583 is dominant.
Also, take a look at EMV.
The ATM to bank link can be proprietary or standard. It is only upstream where inter-organisation wire level interoperability is needed, that standards become always necessary.
ISO 15022 definitely doesn't cover ATM to bank. So far, it covers further upstream. And is now superseded by ISO 20022 - "originally named ISO 15022 2nd edition".
ISO 20022 covers the total scope of financial services, and acts as a super forum for ISO financial services protocols.
There are two basic protocols, ISO8563 and IFX (a financial XML subset) but many banks us protocols supplied by the vendor, because these include Device driver protocols that drive the ATM 'States', There is also a reporting protocol where the ATM reports its cash and usage statii.