burnedfaceless
asked on
Temporary database to store information from a form
There is a very good chance the company I work for will use Dwolla to accept payments.
Here's the thing we don't have a mySQL database so the girls at the office would be contingent upon information from my form (account number, name, address, bill amount.
So I would have to store this to a database, then go offsite to Dwolla, they send us back and I email the customer a receipt and the girls at the office payment information from the information I have stored on the database.
Should this be temporary? I can see problems arising when two customers check out at once.
I could just set a column to customer ID number than write the changing information (bill amount, etc.)
Or it could be temporary. Ideas?
Here's the thing we don't have a mySQL database so the girls at the office would be contingent upon information from my form (account number, name, address, bill amount.
So I would have to store this to a database, then go offsite to Dwolla, they send us back and I email the customer a receipt and the girls at the office payment information from the information I have stored on the database.
Should this be temporary? I can see problems arising when two customers check out at once.
I could just set a column to customer ID number than write the changing information (bill amount, etc.)
Or it could be temporary. Ideas?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
elvin66 is right about not using a temporary intermediate storage approach. This is a financial transaction, and the first rule of any financial transaction is that you must always have a complete and permanent audit trail from initiation all the way through the final processing.
Generating a row in a database for the transaction gives a starting point and it can be update through the process by adding additional information, so that every row contains the information to step through and duplicate all activity that was part of the transaction. That make it possible to correct errors, adjust problems, and defend processing integrity in a legal setting.
It will not take much longer to do it right instead of hacking out a "temporary" solution that will likely become the basis of the whole system over time.
Cd&
Generating a row in a database for the transaction gives a starting point and it can be update through the process by adding additional information, so that every row contains the information to step through and duplicate all activity that was part of the transaction. That make it possible to correct errors, adjust problems, and defend processing integrity in a legal setting.
It will not take much longer to do it right instead of hacking out a "temporary" solution that will likely become the basis of the whole system over time.
Cd&
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Perfect explanation.
ASKER
What I'll do after your suggestions is first time - enter customer ID, then info. Then when they pay again I will have them enter their customer ID and ask is this you or something. Maybe just open the form with all of the information.
Thanks for the points. I suggest that you may want to ask the marketing department what information to ask for and in what order. There is some science about this, and asking a client to remember a customer ID is one of the sure ways to send them out the door forever.
ASKER