Well Hi there 
I've just implemented two different payment providers (swedish) in a big PHP/MySQL project that's nearing completion now.
One is the "internet wallet type" where the user loads his wallet with cash from a creditcard, then calls upon the wallet when he want's to buy something.
The other one is something of a payment switchboard that gives the end user the 4 major creditcards and swedens 4 biggest internet banks.
The implementation is differerent for both of them but they follow the same principle.
They give you specs on exactly how to create the calls to their application and in which format you will recieve their answers.
For all of these except the wallet there is one common denominator., The domain must have a valid certificate, and no it's not enough with a certificate that you (the server) creates by itself, it has to be a certificate that can be validated without any boxes popping up asking if you want to trust this or not. the thing is that it's the code that recieves these without user input so it will most probably stop your application from processing the answer. Also, you will never, ever get a user to submit creditcard info on an unencrypted page.
My first recommendation would be to research the paymentproviders available to you/the customer to see what solutions they can offer. An external paymentprovider is without a doubt the fastest and easiest way to get this up and running.
If you have a choice, pick one that provides an interface on their server for the input of creditcard info, that means less stuff for you to create.
The providers that I had to work with did it differently:
The "wallet" gave me instructions to create an url in a special format, pass that through SSL (we used CURL for that) to initiate the payment, then we should pop a window with their site, also with a special url. Then the customer did his stuff there, some info was swapped that we should react to and when it was done a response came to our script from the wallet and we responded with "OK", then if they got our response it was done and we could act on the completed transaction.
The switchboard was simpler to implement, here they provided us with two different ways, one for the banks and one for the creditcards (still in the form of differently composed urls).
For the bank we simply called our script with info on which bank, then that script popped a window that first landed at the switchboard, they convert the call to the proper format for that specific bank then they redirected to the bank. As the transaction is approved by the user/bank the window redirects to the switchboard which in turn redirected to an url of ours with standard formatted url with transaction-id status and so on, that we could act on and tell the user that all is ok.
For the creditcards we had to build the page to collect the info from the client (certificate required!), then construct the url and pass it on, from there it worked the same way as with the banks. The format of the answer from the switchboard is the same from all the payment options.
For validation of the passed and encrypted data an hash-string is created from selected parts of the url together with a secret key (some 20 chars long) that is encrypted with md5, calculation of the validation has to be done both as you send and recieve to ensure correct validation.
It sounds like a lot, but we got good specs and example code from the providers so it was appr a weeks work to get all of these payment options up and running.
As you see, creating this by oneself is not an option, at least not in my opinion.
Good luck and I hope it comes through for you!
/Dan
{cell 260}
-{ a vibration is a movement that doesn't know which way to go }-
posted 08-20-2003 18:59
