Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 1 down vote favorite

I am eager to know what information is checked by the online companies to confirm that the card is yours?

If a programmer has to implement this functionality, how can he access information like address of the client which is not written on the debit card? Thanks

share|improve this question
1  
Do you mean debit cards as in those similar to a checking account where banking information may be used or do you mean to include credit cards where there may be other values like a card verification number? Also, is this a point-of-sale that would have a swipe of the card or access to the chip or a purely on-line transaction with user entered data? – JB King Jan 2 at 21:17
1  
There are a great number of heuristics credit card companies and banks use to identify fraud and out of habit buying - they have more information at their disposal than the point of sales system does. They also won't tell you what they are (industry secrets, fraud identification, and the like). – MichaelT Jan 2 at 21:18
You ask for this information from the credit card holder, and then submit it to a payment processing service. The payment processing service verifies the information, not you. – Robert Harvey Jan 2 at 21:27

3 Answers

up vote 18 down vote

If a programmer has to implement this functionality, how can he access information like address of the client which is not written on the debit card? Thanks

He doesn't, He simply collects data from the user and submits that data to the CC via some API. The API returns a Status (Authorized, Captured, ect).

The API will NOT give the merchant any data about the customer hes\he\it does not already have.

share|improve this answer
up vote 2 down vote

The way these things usually works is roughly like so:

  1. Customer proceeds through checkout on your shopping site.
  2. Your site redirects to payment processor, sending the required data along with the request (your site's ID, amount, remarks, etc.).
  3. Payment processor processes payment.
  4. Payment processor redirects back to your site.
  5. Your site verifies that the payment was successful, and if so, completes the order.

Step 3 is entirely between the customer and the payment processor; your site is completely out of the loop at this point.

For step 5, I have seen three approaches.

The most solid one is that the payment processor simply passes you a transaction ID (in step 4), which you can then use to call a web service provided by the payment processor, and this call will tell you that the transaction ID does indeed match your request and was indeed successful. Because the web service is not publicly accessible, and the response contains some sort of token that uniquely identifies your order, a customer cannot replay the redirect back to your site to reuse the successful payment.

The second approach does the same, but instead of you polling the payment provider, the payment provider pushes a message to you. The problem with this approach is that you have to check payment statuses asynchronously, which in turn means the customer's order can't be completed directly after the redirect.

The third approach uses cryptography to pass the entire verification through the client. This is usually done by sending complete payment information, digitally signed by the payment processor, along with the request. The upside of this is that the extra web service call between your server and the payment processor's isn't needed, but as a downside, all the sensitive information passes through the client, which means the attack surface is larger - a malicious shopper could store the payment response, try to crack the key used to sign the message, and then produce their own fake responses on future orders without involving the real payment processor at all. This is bad, because your server will think the payment has been made, while the payment processor has absolutely no clue that anything is going on at all.

This procedure is mostly the same whether it's a debit or credit card; the difference lies in what the payment processor does, and what exactly that is depends on the card, the card issuer, the country, and a few other things.

share|improve this answer
You forgot to mention the fourth approach -- send the entire verficiation through the client in unsigned plain text. – jmoreno Jan 3 at 3:01
@jmoreno: I haven't seen this one yet, and if I came across it, I'd refuse to accept payments through this provider (or urge my client to do so). – tdammers Jan 3 at 10:24
up vote 1 down vote

When the credit card number is entered, you can check the checksum --LUHN Formula (Mod 10)--, length, and character set. Since you probably are only going to accept 2 or 3 different types of credit card, it is also common to seperately check the issuer number (the first 6 digits).

That's it. You can't do any more online - you have to send the credit card number to your merchant account supplier for verification.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.