Search My Merchant Account Blog

Search this Blog:

Credit Card Testing Numbers

Saturday, April 12, 2008

When you complete a credit card transaction on an electronic payment gateway, chances are very good you will be charged for the transaction.  The transaction is going through a transaction provider and to a card association (Visa / MasterCard / Discover / American Express).  The card association charges a fee to access their environment.  To overcome this, LinkPoint created staging servers. Through this staging server, a web developer can mimic a transaction to verify the transaction and response.

Since credit card numbers are developed using the Lunh's method or mod-10 algorithm, not just any number that meets these requirements can be sent.  These test credit card numbers can be used on your live LinkPoint account.  If you use these credit card numbers on your live (production) LinkPoint account, your account will be charged accordingly.  If these numbers are used on a testing (staging) server, no fees will be collected.

Card Type	Card Number	Exp Date	Amount	Number of Digits
Visa	4005550000000019	current mm/yy	$1.00	16 digits
MasterCard	5424180279791765	current mm/yy	$1.00	16 digits
Discover	6011000993010978	current mm/yy	$1.00	16 digits
American Express (Corporate)	372700997251009	current mm/yy	$1.00	15 digits

If the numbers above are used on your production (live) account, you will receive an approved response.

If you need to receive a declined transaction on your live LinkPoint account, use these numbers:

Card Type	Card Number	Expiration Date	Number of Digits
Visa	4111111111111111	any mm/yy	16 digits
Visa	4012888888881881	any mm/yy	16 digits
MasterCard	5215521552155215	any mm/yy	16 digits
MasterCard	5105105105105100	any mm/yy	16 digits
American Express (Corporate)	378282246310005	any mm/yy	15 digits
American Express	371449635398431	any mm/yy	15 digits
Discover	6011111111111117	any mm/yy	16 digits
Discover	6011000990139424	any mm/yy	16 digits
JCB	3530111333300000	any mm/yy	16 digits
JCB	3566002020360505	any mm/yy	16 digits

Keep in mind that if you use your live LinkPoint account for any transaction, you will be charged.  The test store from LinkPoint comes with the LinkPoint Basic / HTML, LinkPoint API, and LinkPoint Virtual terminal.  You will be able to mimic LinkPoint transactions in a testing environment with be assessed any fees.

The LinkPoint Gateway

The LinkPoint Gateway is one of the larger electronic payment gateways in the United States.  It was one of the first Internet payment gateways to offer a staging server for web developers.  For some of its competitors, it was years before they offered a testing environment.

After First Data completely owned 100% of Cardservice International, the LinkPoint gateway was the largest electronic payment gateway using First Data's platforms.  The LinkPoint payment gateway was still being branded as YourPay through some of First Data's partner channels.  And LinkPoint basically consumed the SurePay electronic payment gateway through mergers and acquisitions.

You might still hear YourPay being used today, but the LinkPoint gateway can also be called Integrated Internet Payments (IIP).

The Security of Your Customers

Wednesday, March 19, 2008

So I know in the past, we have always talked about credit card security, PCI Compliance, etc.  But I would also like to remind you about your customer's usernames and passwords.  How are these being stored?  A lot of shopping carts will store this information in plain text.  If the passwords are being stored in plain text and you have a server compromised, your users' information might be readily available for the hackers. 

Most shopping will store the information in a database like Microsoft Access, mysql, or MSSQL.  You should be able to view the databases somehow, either though phpMyAdmin, Microsoft Access, or Microsoft SQL Server 2000 Desktop Engine (something similar).  How you access this information is usually established when you choose a web hosting provider.  Some will allow you to access the information also via an Open Database Connectivity (ODBC).

When you are viewing these tables and records, look for the table that stores your user's information, especially the password table.  Are the passwords encrypted?  If not, you should consider getting another shopping cart or contact the vendor for assistance to enable secure passwords.

A lot of consumers use the same password for everything.  While this is a great risk to them, it is the quickest way for consumers to get to their information.   This is the reason you want to protect them as much as possible.

Your Shopping Cart Password

First and foremost, your administrator password should be changed immediately when you start to add your items.  Don't wait until you are going live - you have too much on you mind by then.  Your password should contain letters, numbers and maybe a couple of extra characters like %, !, *, {, etc.  The harder it is for you to remember, the better. 

Did you know that by changing your password from the vendor-supplied password, you have already met one of the requirements for PCI DSS?

Password Strength and Security

When new customers are signing up, your website should ask them for a unique password.  And explain to them why your company is asking for this information.  Password checker is also a great website to have them check their password strength. 

And when asking users to create an account, their session should be in a secure.  This will help to protect them when they are entering their username and password.  Even if you use a third party processor or have one of the electronic payment gateway's web page handle the transaction, if you are asking for a password, the page should be secure.

Payment Application Best Practices from Visa

Tuesday, March 11, 2008

High profile breaches of cardholder data have garnered a lot of attention in the media.  Most of us have read or heard about the 40 million cards that were compromised at CardSystems, or the 100 million cards compromised at TJX.  As a result of these breaches, the payment industry developed the Payment Card Industry (PCI) Data Security Standard (DSS).  However, complying with the PCI DSS can be complicated and expensive, especially for smaller merchants.  Although we may not read about it in the press, breaches at smaller merchants occur every day because the payment hardware and software they use is not compliant with PCI DSS. 

In an effort to make compliance with the PCI DSS a little easier for merchants who use payment application software, Visa developed the Payment Application Best Practices (PABP).  The PABP applies to software applications that store, process, or transmit cardholder data as part of authorization or settlement.  It does not apply to software developed in-house by merchants since that would be covered under the merchant’s normal PCI DSS compliance. 

Software vendors are required to have their payment applications certified as PABP compliant by a Qualified Application Security Professional that is employed by a Qualified Payment Application Security Company.  Once compliant, Visa will include the software vendor and product version in a list of validated payment applications for one year.  Software vendors must re-validate their payment applications each year to remain on the list. 

The PABP mandates are designed to eliminate the use of non-secure/vulnerable payment applications from the Visa system.  They require that members ensure that merchants do not use applications that retain prohibited data elements and use payment applications that adhere to Visa’s PABP.  If you are using a payment application from a software vendor that is not PABP compliant then you will not be able to comply with the PCI DSS.

As of January 1, 2008 new merchants are not allowed to establish a merchant account using a non-compliant payment application.  Existing merchants should check with their agent or ISO to make sure their payment application is on the list of PABP compliant applications.