If you are using POS in the USA, how do you accept Credit Card payment?

ERPNext
1

Ok, it has been a while since I looked into this and there is not much new in the forum that I could find on the topic.

In my past clients where I had to setup a storefront cashier station, I used the POS module and made the clients get a separate credit card machine from their bank and only enter the totals into the POS payment screen if the credit card transaction was validated by the bank machine.

I know that others have been working on a better way to do this and I wanted to see how other people are handling their credit card sales.

Are you using a service like Stripe, Square, or other similar processing service?

Do you have some service “connector” or “service integration” with ERPNext POS?

Do your cashiers like what you are using?

Please, if you have a POS running is a store environment, share with us what you are doing about credit card payments. Ultimately I am trying to identify a new and better way to setup small stores here in the USA and this credit card payment issue has been a stumbling block.

Thank you,

BKM

2 Likes
2

Hi @bkm,

I cannot offer info regarding ERPNext. But I can speak a little about other ERP systems, POS, and credit card processing.

The simplest (not necessarily best) method is what you already described. Get a standalone credit card machine. Set that down beside your POS. And you’re in business. You don’t have to be concerned about the how’s and why’s of its operation. Certainly there are big drawbacks. Your POS/ERP is entirely unaware of what’s happening. Is the amount on the CC machine the same as the Sales Order? Was an amount even recorded at all? What about split payments, or authorization delays? There is no information sharing whatsoever.

Now, if you want your POS/ERP to participate in the CC processing, or even handle the entire transaction? You’ve got 2 things to figure out.

  1. PCI Compliance. PCI Compliance Guide Frequently Asked Questions | PCI DSS FAQs

You need to read it, understand it, and make sure you’re doing the right thing. It’s not rocket science. But it is a lot of reading, thinking, and writing. You have to document everything.

Are you accepting/storing actual CC data (name,number,pin,dates)? Or are you dealing only with tokens? Makes a difference. If you’re going to store CC info, it needs to be encrypted, protected. You need to meet certain expectations for both physical security (where is the hard drive), network security (firewall), etc.

Many years back, I discovered our Accounts Receivable manager was allowing reps to store Customer CC data as free-text notes in the ERP. Any person who had access to the Customer screen? Well, they could just click on the “Notes” button, and see the entire credit card. I threw a fit. I wrote SQL scripts to identify every last one of those notes, and wiped them out. And stopped that practice.

Compliance is boring. But you don’t want your company on the front page of the Wall Street Journal tomorrow.

  1. Credit Card Processors/Payment Gateways

This is where the technical stuff happens. And it can get extremely technical. I spent the better part of 2011-2013 helping an eCommerce client build this from scratch. They needed their ERP to bridge the shopping cart with the Credit Card processor. It wasn’t POS like you’re asking about. But the concepts are largely the same.

There are some common codes shared in the industry. But also, each provider can have a different API. I worked with CyberSource, PayPal Payflow, and later a 3rd company that I’m struggling to find their name.

Handling all this required quite a bit of code changes to the ERP. There are tons of digital handshakes. You need to recognize the Processor’s codes, parse the results correctly, and send information back to them. We had to add new SQL tables, new lists of values, new classes for creating XML files, and then transmitting over the web.

Differently spelled names, addresses, and phone numbers can (and will) mess you up. When credit card validation fails (and it will), you need to be ready to handle it. I ended up writing a combination of Logs and Workbenches to help with this. So that without help from IT, my client could see failures, make corrections, and re-transmit messages. You don’t want to be doing this stuff manually, or talking on the phone with credit card companies or processors.

The huge difference with POS is time. With eCommerce shopping carts, we had some flexibility. There was time to debug, and fix a problem, before the customer was even aware something went wrong. But when they’re standing right in front of you? Speed and time is critical. For that reason, the brick & mortar retail customers I’ve had? They never brought the ERP into play. They stuck with those separate machines, talking over telephone lines. Because it was simple, and the customer wasn’t stuck waiting because of “technical difficulties”.

Perhaps things are easier now, with Stripe or Square? I’m not sure. Then again, I’m often disappointed when I discover where that where I think technology should be in 2019, is not where it’s at.

One of my clients recently switched ERP systems. Previously, they could scan barcoded Invoices/Tickets into their ERP. All auto-magically. We’d built that feature together in 2009. Now fast forward to 2019, and their new ERP cannot do this. :roll_eyes:

Anyhow, hope some of my rambling was helpful!

2 Likes
3

Yup!!

The reason for the thread on the forum is to see exactly what is being worked on now and what may already exist.

It turns out there is an existing system called “Braintree” that is in most of the world but not yet working in the US. It has it’s own drop in payment screen and a supposed working connection to ERPNext POS.

I am still hoping that someone has another working interface that is available in the US. I can always go back to the separate CC machine, but was holding out hope for something a little better integrated.

BKM

4

I am building an e-commerce store and I have implemented Stripe and works without any problem so far. But I am building the Store from scratch with webviews in www folder. I am not using built-in POS. Stripe’s documentation is very good.

But I believe your case is different from mine.

5

We help clients with PCI DSS certification requirements. I can tell you that if the client does not have high budget just for certification it’s not worth going up this alley. Plus there is the half yearly testing requirements which adds further cost.

Coding ERPNext is an additional cost.

1 Like
6

Yes, I understand all of that. I understand also that it makes no sense for the ERPNext developers to attempt to support any direct involvement in the CC processing arena.

That was not my purpose for this thread.

My purpose for this thread was to find out what others in the USA were doing about credit card sales in their ERPNext POS usage in the hope that I could duplicate a working process.

You folks have turned this into a discussion about the minute details of credti card processing and that was never the intent here. This thread has devolved into discussions that were NOT part of the original questions.

I give up!

BKM

7

I apologize if I derailed your thread, @bkm. You’re correct; you didn’t ask for a technical dissertation on credit card processing.

To answer your question plainly:
All my customers use standalone credit card machines, that plug into the wall with telephone lines. :slight_smile:

1 Like
8

I have been looking for a way to connect a CC Payment terminal to ERPNext POS
I found this and it looks interesting. A REST-API based integration

https://www.handpoint.com/docs/device/REST-API/

They also have a JavaScriptSDK that works in a browser.

https://www.handpoint.com/docs/device/JavaScript/

Has anyone tried this before?

thanks

9

Here’s something similar that integrates Stripe Terminal: