| Electronics > Projects, Designs, and Technical Stuff |
| Embedded Payment Module |
| << < (3/4) > >> |
| firehopper:
have you looked into square readers? |
| rbm:
--- Quote from: JVR on October 22, 2018, 09:07:13 pm ---I'm designing a new product, and having the ability to do contactless payments will add significant value to the product. With all of the other aspects (loads of mechanical bits) I wont have time to try and get the system L2 certified by EMVCo, as such, I want a COTS module that I can integrate, that I can give an IP port to, and I can send it transaction queries for it to manage. --- End quote --- Let me see if I understand it properly. I think you are designing a device that needs to accept and process face-to-face card present transactions. You want the device to accept EMV "dip" and contactless "tap" but not magstripe "swipe". You'd like your device to control the card reader device, putting it into an accept mode and wait for a payment completion message back from the processor / acquirer. You want the EMV reader to do all the rest of the work such as setting up the connection to the transaction switch, formatting the proper ISO 8583 transaction message and interacting with the acquirer's transaction environment. Is that correct? You're solving only part of your problem, if I have understood properly. The reader will need to have a correctly working payment application built into it to do all the human and machine interactions required to complete either a debit or credit transaction. You would be advised to select a device that is PCI PTS certified, and preferably SRED-enabled (how will you handle manually keyed transactions or processes reversals / chargebacks). Your payment application will also need to be PCI PA-DSS certified, because you will find that many acquirers will not be capable or willing to allow your device to connect to their merchant networks unless it is compliant. Even so, you'll also have to pass their unique certification processes that ensures your device is capable of correctly interacting with the transaction switch and supports all messaging. Even if you could do all this work, you'll have to figure out who will inject keys into your device and how those keys are going to be managed throughout the life of the device. You may also need to support point-to-point encryption if demanded. This is much more than a COTS piece of hardware needed to solve this problem, assuming that I understood it properly. |
| JVR:
--- Quote from: firehopper on October 24, 2018, 11:21:31 pm ---have you looked into square readers? --- End quote --- I've looked at them, its one of the options I'm looking at, even though it forces the use of a smartphone. --- Quote from: rbm on October 25, 2018, 03:29:10 am --- --- Quote from: JVR on October 22, 2018, 09:07:13 pm ---I'm designing a new product, and having the ability to do contactless payments will add significant value to the product. With all of the other aspects (loads of mechanical bits) I wont have time to try and get the system L2 certified by EMVCo, as such, I want a COTS module that I can integrate, that I can give an IP port to, and I can send it transaction queries for it to manage. --- End quote --- Let me see if I understand it properly. I think you are designing a device that needs to accept and process face-to-face card present transactions. You want the device to accept EMV "dip" and contactless "tap" but not magstripe "swipe". You'd like your device to control the card reader device, putting it into an accept mode and wait for a payment completion message back from the processor / acquirer. You want the EMV reader to do all the rest of the work such as setting up the connection to the transaction switch, formatting the proper ISO 8583 transaction message and interacting with the acquirer's transaction environment. Is that correct? You're solving only part of your problem, if I have understood properly. The reader will need to have a correctly working payment application built into it to do all the human and machine interactions required to complete either a debit or credit transaction. You would be advised to select a device that is PCI PTS certified, and preferably SRED-enabled (how will you handle manually keyed transactions or processes reversals / chargebacks). Your payment application will also need to be PCI PA-DSS certified, because you will find that many acquirers will not be capable or willing to allow your device to connect to their merchant networks unless it is compliant. Even so, you'll also have to pass their unique certification processes that ensures your device is capable of correctly interacting with the transaction switch and supports all messaging. Even if you could do all this work, you'll have to figure out who will inject keys into your device and how those keys are going to be managed throughout the life of the device. You may also need to support point-to-point encryption if demanded. This is much more than a COTS piece of hardware needed to solve this problem, assuming that I understood it properly. --- End quote --- :wtf: Thanks for the info-overload, I'll go do some reading on the certification and the process. But this does make me think that this is not a viable feature for a phase 1 product. Rather something to be added in time when we have more dev time. |
| jbb:
I had a look at PCI SRED, which turns out to be part of PCI PTS. It can be found - for free! - at pcisecuritystandards In summary: abandon all hope all ye who enter here. It involves: - detailed hardware review - Differential Power Analysis attacks - hardware attacks with drills, mills etc. up to an *electron microscope* (I suspect that they do these on paper) - detailed code review & testing - a whole section called Open Protocols about network connections, including vulnerability disclosures - a whole lot of policy and procedures documents which could be nasty I suspect it would take anything form 6 months to 2 years to get through that. |
| rbm:
Closer to the 2 year estimate since the assessment has to be performed by a Qualified PIN Transaction Security assessor (PTS-QSA), in their lab using their people and processes. Then, the final report of validation (if compliant) needs to be reviewed and accepted by the PCI Security Standards Council, before being listed on their web site. That costs both time and money. And that's just the PCI PTS portion; The same goes for the PA-QSA listing. It's a lot. that's why there are just a few companies which produce merchant-ready point of sale terminals - Verifone, Ingenico, Stripe, NBS, to name a few. |
| Navigation |
| Message Index |
| Next page |
| Previous page |