Question

While developing a credit card transaction page for a website to transmit data to the payment gateway, I notice that many input options are available. The return response from the payment gateway also contains a myriad of data.

Listed below are some input fields which, I believe, are captured on most payment gateways:

• customer’s address
• customer id
• customer’s IP address
• description
• email
• first name and last name
• invoice number and PO number
• tax and tax exempt status
• transaction id

Listed below are some response fields which, I believe, would generally be returned to the website:

• overall response (accept, reject, error, hold)
• specific responses (such as address verification, card CCV
  verification, etc)
• specific description of response
• hash (unique to merchant account)
• data from the input above

I would like to find out:

1. Which data would you process internally without sending to the gateway?
2. Which data would you route through the gateway before processing?
3. Which responses would you use for further processing?
4. Which responses would you store for future reference, and why?

I believe this decision making process is what web developers would normally encounter when they set an e-commerce application. Would anyone like to share his/her knowledge?

To start the ball rolling, let me attempt

1. Which data would you process internally without sending to the gateway?

email – I would notify customers of a successful transaction by emailing directly from my web application. The payment gateway provider does not need to know my customers’ detail.

Answer 1

So in the credit card industry, there is something called PCI compliance. Look at https://www.pcisecuritystandards.org/ or some other such site for more information. There are a fair number of requirements to storing / processing credit card data yourself. The other thing you can do instead is to use a company like http://www.chargify.com who takes care of PCI compliance for you. They provide a processing module for you to reference in your web page. The data never crosses your servers until it has been processed. Then you will only be given things like customer information, a recurring payment token if you want to set up subscriptions.

EDIT:
So based on your comments, here’s what I’ve done in a couple of places. We generally will create the user record with whatever user data we want to have prior to sending the payment. We also create all of the transaction records prior to submitting the cc data – minus the final transaction result. That way if a failure occurs in your system, you haven’t touched the credit card yet. Gateways charge for refunds. Everything is waiting for a flag or two to be set. Acquire the authority to charge, get confirmation from the custumer, then complete the transaction. If for some reason the transaction fails, you have all of the information required to reset their pages… except the credit card info.

As far as transaction information, definitely store the status and the reference number. Your finance people will appreciate being able to tie out specific transactions with specific entries in the cc gateway reports. As far as additional transaction information, I’ve found that overall no one uses it again…unless you want to evaluate how often your gateway rejects cards. If it chokes on address info a lot, you might want to switch gateways.