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
- 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:
- Which data would you process internally without sending to the gateway?
- Which data would you route through the gateway before processing?
- Which responses would you use for further processing?
- 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
- 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.