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 hesheit does not already have.

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.

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.