![]() |
|
#1
|
|||
|
|||
|
Has anyone here before worked with POS and credit card authorization systems. I'm looking for some kind of an SDK which will be able to charge and verify the cards with the bank, and not only checksums of the card. If you have useful information, please post it here.
Thank you. |
|
#2
|
|||
|
|||
|
Knowing the capitalist approaches, I'd say you have to make a deal with some bank for that.....
ION T |
|
#3
|
|||
|
|||
|
hmm,,
quite difficult (read: 'impossible') to do that ! NR 1: which country are you in ? NR 2: which cards do you want to accept ? the the solution would be as follows: Figure out the main credit card authority for your country (in Netherlands, this would be 'InterPay' for example, but could be Eurocard/Mastercard in whole of europe). Step 2: get some harware "card-reader" (shouldn'd be hard to get) Step 3: write the software that will encode all information to be sent over PSTN/telephone lines to authority. Usually this is Triple-DES encoding or likewise. Step 4: send your software/hardware in to the authority for evaluation/certification. In the unlikely event that your SW/HW will be certified, you can start selling/distributing your stuff. Good luck (you'll need it) ! Eddy-B Please click |
|
#4
|
|||
|
|||
|
I'm in the US. I can read barcode scanners and card readers without any problem. These things actually require little programming. I want to accept all credit cards (MasterCard, Discover, AMEX, Visa, Diners Club). My understanding is that it depends on the processor who needs to be setup for the proper credit card authorization and not the software. The software has to only get the number from the credit card, and send it to the merchant/processor. I can get the number, but how do I send it. That's why I was asking about some kind of an SDK for that.
BTW, I found ICVerify (icverify.com). Has anyone worked with it? Thanks. Luke |
|
#5
|
|||
|
|||
|
I was just trying to help you - you see, my job is (in the netherlands, europe) install and service payment terminals for debet & credit cards.
that's why i know a lot about these kinds of things (as it works here of course, and it might be completely different in the US). Because of all the security around credit & debet cards, any information that will be sent on regular telephone lines MUST be encoded. That's why i mentioned that usualy they asking for the latest (most secure) encoding system. For years now they've been using Triple-DES encoding. Until 1998 the standard was (single) DES encoding. Now, for the enocing your will need some kind of software (pc controlled, or a simple piece of hardware that will do this - which usually includes some kind of EPROM including the nessecary software) Normaly the authority (AMEX, Diner's whatever...) will want to test your software/hardware combination before they allow you to market or use it. This is of course to prevent fraud (not that I don't trust you, but they (=credit card companies) know better: trust NO ONE).. anyway: triple-DES encoding is not so hard to find. Even perl or PHP can do it. So you won't have any problems finding pascal or c source for that. But what you DO need tio find out about first, is WHAT encoding do the 'authorities' want. As you pointed out, getting the information from the card is easy. Sending it won't be a problem either (just need to knwo WHERE to send it). But getting the autorization code back depends not only on the card(holder) but also on the "manufactorer" of the equipement. If they don't double-check this, just about anybody can send card-info and get auth.codes. So that is basicly the thing here in Europe, but you'd really have to check there, to see what all the credit card companies tell you... Good luck ! Eddy-B Please click |
|
#6
|
|||
|
|||
|
Hi, did you ever find a solution to integrate Icverify with Delphi?
Im working on a project and way over-due... Please advise Mike Quote:
|
![]() |
| Thread Tools | |
| Display Modes | |
|
|