Embedded Payment Module

[JVR]

Hi Gents and ladies,

Ive been scouring the web, to no avail, I am in need of a embeddable module that can handle EMV payment transactions.

I seem to remember finding something a while back, but for the life of me I can't find them again. Basically the project requires a secure module that the host can transmit a transaction amount to, and the module takes care of the comms with the backend of the provider. Having NFC would be a plus.

Does anyone here know of something that can do this? Even I'd it's just close, it might help my Google-fu

Sent from my SM-G950F using Tapatalk

[Lord of nothing]

Hmm what do you want to do?

[jmelson]

Hi Gents and ladies,

Ive been scouring the web, to no avail, I am in need of a embeddable module that can handle EMV payment transactions.

I seem to remember finding something a while back, but for the life of me I can't find them again. Basically the project requires a secure module that the host can transmit a transaction amount to, and the module takes care of the comms with the backend of the provider. Having NFC would be a plus.

Does anyone here know of something that can do this? Even I'd it's just close, it might help my Google-fu

Well, first you need a payment processor.  They will create a merchant account for you, and will have a variety of API interfaces that you can connect to,
with a key that they provide.  I use Cayan (who set up my merchant account) and Authorize.net (who provide the online payment processing).
Select a provider of this service, and see what types of API they can provide.  They often have sample scripts at can be downloaded and integrated into the rest of your system.

Jon

[JVR]

Hmm what do you want to do?

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.

I've found the below manufacturers, so will be getting in touch with them soon:

https://www.magtekeurope.com/products/standard-and-secure-card-readers/

https://www.otiglobal.com/emv_cashless_readers/interno/

https://idtechproducts.com/products/oem-payments/vp3300-oem/

http://www.abc-smartcard.com/solutions/contactless-module/

I'm still doing a lot of reading, so any pointers from someone that has done this before will be a big help. Note that there is no smartphone connected to the design as planned, the main CPU will be a ARM powered Linux SoC though.

Info is hard to come by, as most searches return either smartphone or web based systems in the results.

[jbb]

You need to work with a payment company of some kind; the hardware is only the tip of the iceberg.

Try to find a single source: one company to provide you with hardware, certifications (MANY are required) and payment switching. DON’T try to deploy your own; I understand the paperwork is horrifying.

Interface is quite likely to be RS233 or USB. Some have Ethernet.

Suggested search keyword is “unattended”.

[Lord of nothing]

What I know from the Austrian Payment Provider the rules and regulation are huge. 
I will have some payment System for my Social Club to but after a short conclusion I decide to use what ever the offer me.  Its insane what the require.
I personally would talk to an Payment Provider and find a solution who work and is 100% safe. Please keep in Mind if something happened with the Payment you can get sued and if you are lucky you can sleep in the Jail and after on the Street...

[jmelson]

What I know from the Austrian Payment Provider the rules and regulation are huge. 
I will have some payment System for my Social Club to but after a short conclusion I decide to use what ever the offer me.  Its insane what the require.
I personally would talk to an Payment Provider and find a solution who work and is 100% safe. Please keep in Mind if something happened with the Payment you can get sued and if you are lucky you can sleep in the Jail and after on the Street...

Well, really, there are truly MILLIONS of small businesses, boutique and mom and pop online stores that have some form of card payment.  There are many online store software packages (osC (open source Commerce) is just one of many) that can be downloaded or set up on a hosting site.  Some do the whole thing for you, including the payment processor, others offer a choice of several processors that you can contract with separately.  But, MILLIONS of people are doing this - online businesses are a BIG thing, now.  Yes, you DO have to take care of security, and keep an eye out for hacking.  For that reason, I have set up my own store so that I never see the credit card info.  When either PayPal or Authorize.net is chosen by the customer, my store diverts the customer to that payment processor's site to fill in the card #, etc. and then returns a receipt to my store if the payment went through.  This relieves me of a lot of special protections I need to put on my site to safeguard the cardholder info.

But, nobody is going to jail because their site got hacked.  You COULD be liable for fines, however.

Jon

[Lord of nothing]

Well, really, there are truly MILLIONS of small businesses, boutique and mom and pop online stores that have some form of card payment.

With handcrafted Modules?

[matseng]

Have a look at the "Verifone Unattended" line of products...  http://www.bevertec.mn/products/29.html

[JVR]

There are many online store software packages (osC (open source Commerce) is just one of many) that can be downloaded or set up on a hosting site.

You are missing the point though, I need this in hardware, for a webstore this is trivial to set up.

Have a look at the "Verifone Unattended" line of products...  http://www.bevertec.mn/products/29.html

Thanks for the link, but as with most of the others I am looking at, they are all relatively "huge". I need something that can be ergonomically integrated into a arm-mounted device, so the smallest form factor possible. I think I really need to go and think about if this feature is worth it, and if it might not be easier to do this via a smartphone.

[firehopper]

have you looked into square readers?

[rbm]

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.

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]

have you looked into square readers?

I've looked at them, its one of the options I'm looking at, even though it forces the use of a smartphone.

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.

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.

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.

[Geoff_S]

I came across this today in a marketing email from ST.  Not sure if it really helps, but sounded vaguely like it might...
"Dual DDA Boosted product (ST31G + Ivory +STS3922) Secure SIP product for optimized wearable"
https://www.st.com/en/secure-mcus/stpay-boost.html