Reading a credit / debit card from an App

skyripper · 22 Oct 2019 at 16:59

Anyone know any open source or cheap solutions for reading the numbers off a credit / debit card that we can use with an SDK or HTML5 ?

We're a recruitment company, and as part of getting people paid we need to know their sortcode and account number. Now for what is just 6 + 8 digits, this information generates far too much manual work -> keying errors, calls to our helpdesk etc, frustrated workers when their payment doesnt arrive on payday.

We have an app on both iOS and Android, and it would be nice for us to be able to say "Point the app at your bankcard... 5..4..3..2..1.. aha, we've read your sort code as 123456 and acc number as 09876543, would you like us to use these?"

I've seen this before in some apps for registering payment details, but can't remember what the apps were.

We don't want any payment facilities or contactless stuff, this is literally read the numbers, and put them into a existing form / XML / whatever. Rather than people typing them in.

skyripper · 22 Oct 2019 at 17:10

Well we're playing around with the Amazon AWS facility for OCR'ing stuff, but I've just added a brand new card to my Google Pay by putting my card on the desk, clicking "Add Card", a window to view the camera pops up.. and then Google Pay snaps it and does it.
So wondered if anyone has any knowledge of a API or SDK for doing that.

(It would be amazing to do it by reading the card itself using NFC but I'd happily take plain OCR'ing the numbers for now)

skyripper · 22 Oct 2019 at 18:46

We'd definitely still need to have manual fields for when we can't read the numbers but you'd be surprised how often what is typed in isn't right

skyripper · 23 Oct 2019 at 20:57

jsmoke said:
How many people are you talking about, can they not write their details on a piece of paper?

That's not exactly the approach we're looking for. We're already looking to replace the last of our remaining paper based timesheets, forms etc, there's a scanning cost, storage of those images, data entry and validation for paper based information. A very labour intensive process.

We process upto 40,000 timesheets a week, and if only 10% of those are new people, that's 4000 forms to process.

A duff timesheet is annoying, while a duff bank account entered means Bob the brickie doesn't get paid on time and gets the hump. Hence the need to capture the info as quickly, easily and accurately as possible.

Pretty much all working professionals have a smartphone so we're looking for how to improve our App.

skyripper · 23 Oct 2019 at 21:18

We're a FTSE 250 listed-company providing both Temp and Perm recruitment to clients. We're part of a group of companies who operate around the globe.

In simple terms we find people for jobs and find jobs for people. That's the recruitment or front-office operation.

We pay those people and then bill the company they're working for. So we provide both payroll and invoicing on top of that. That's the back-office operation.

skyripper · 23 Oct 2019 at 21:23

If OCR can't read it, we will have them type it in on the App. We're just looking to see if we can make the data entry easier - to add a new card to Google Pay is point and click.

skyripper · 24 Oct 2019 at 12:06

jsmoke said:
How about a dedicated secured PC that everyone has to log their details in once a week?

I'm loving this idea of 4000 people queued up every week to shuffle up to a secure PC to use one at a time.

Reminds me of benefit day.

@AHarvey - we certainly could take a pic and store it for manual input, thats not that different from our paper form based process. I wouldn't however be comfortable storing pictures of our workers bank cards. We already hold more than people realise - identify documents, qualifications and certs, proof of residency or eligibility to work.

If we can't use our existing OCR setups (which are actually pretty damn good accuracy for fixed layout forms - they're cloud based systems, not on device mind you) and NFC reading is a non-starter (can't imagine trying to support that over the phone to a helpdesk) we'll probably just stick with the current "Fill in these two fields.. kk.. thx.."

@balanceballs and @AHarvey - will throw those two references to APIs or existing SDKs to our Devs for them to check. Thank you

@morbid42 - it is simpler to pay someone to type the details in. We've already minimized the cost by moving this process to our offshore organisation. However I disagree that its cheaper. We hit accuracy rates above 90% on other OCR, and we can already validate "Is this a real sortcode + accnum" via other web services, so if we can tie the two together (and trigger it from an photo pinged from an App), then we already eliminate the manual work and delay.

@Lakeland - then hopefully our users will work out they can't use that card and have to type it in the old fashioned way

skyripper · 24 Oct 2019 at 20:39

Idea binned. We're stickingn with the type it in solution.

skyripper · 25 Oct 2019 at 10:16

touch said:
I've noticed that when sending money via online banking it does a check on the sort code you type in and shows the name of the associated bank. That would be a way to verify the sort code but it wont help with the account number. I dont know if it's a service you could use or if the info is only available for financial institutions.

Those things we already check using a webservice call to PostCode Anywhere. There are a range of companies offering that kind of verification service, just depends on usage and how sophisticated you need the checks to be.

I think we're going to play about with Amazon's TEXTRACT service anyhow, we've had some reasonable results with paper forms for a proof of concept.