1

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.

Brian Tompsett - 汤莱恩
  • 5,753
  • 72
  • 57
  • 129
Question Overflow
  • 10,925
  • 18
  • 72
  • 110

1 Answers1

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.

Kris Robison
  • 698
  • 7
  • 13
  • Yes, I understand there is this PCI compliance requirement. One way to avoid such issue totally is to let the payment gateway host the payment form. What I am asking is assuming that I want to host the payment form. I am aware that storing the full card number and CCV is a no-no. Anyway that is not what my question is about. – Question Overflow Oct 29 '11 at 16:11
  • I was thinking about your answer and wondering how to approach the situation. Do you think I should store all transactions that generate an error, together with the error code and transaction id on a separate table for troubleshooting? In case there is a charge back from customer, how do you handle? Thanks. – Question Overflow Oct 31 '11 at 09:59
  • You could move failed transactions to a separate table. It is certainly useful in the beginning. If you do, I would consider doing that as an offline batch task. For chargebacks, I've created an internal use page that allows an internal person, usually an authorized finance person, to issue the chargeback through the system. That way the counter transaction gets created and still allows you to do any revenue recognition processing that you require. – Kris Robison Oct 31 '11 at 17:56
  • Sorry, I do not quite understand the part on chargebacks. Let's say a customer dispute a certain transaction. The finance dept gets informed by the bank, how do you ascertain whether such claim is valid based on the data you have? And when the chargeback is approved, what happens to the particular row in the transaction table? Do you have an automated way to deal with this? – Question Overflow Nov 01 '11 at 04:33
  • When a customer disputes a charge, the best you can do is validate that the system processed the charge on a particular date and was validated via address and ccv methods. Providing your team a screen to find the data via reference number is helpful. At that point, we proided an interface that allowed authorized users to approve a chargeback. the system would create a new transaction that removed the balance and referenced the original transaction. it would also perform the chargeback and store the new reference number with the new transaction. – Kris Robison Nov 01 '11 at 05:27
  • Let's say the CCV filter is enabled and the transaction is approved based on a match. Is there any recourse for the merchant to dispute the validity of such a chargeback? – Question Overflow Nov 01 '11 at 07:46