advice on pay sites wanted please

[vosgien]

Hi
Does anyone have any experience of pay sites, or perhaps can advise me anyway.
I am building a site where the user will register a name and password, once accepted a bona fide payment processor will open and he makes a payment befor being sent to a log in page. So far so good. It has occured to me that once the url becomes known it will be possible to register and then call the url and log in without making a payment. I am not certain which is the accepted way: to get user to make a payment before OR after registering. Or is thier another way

nyone any ideas/advice/experiance

Cheers

Vosgien

[fgf]

saams e commerce programming with asp has a lot of stuff about e commerce strategies as well as the asp. reasonable overiew of security and payment methods.

Put asp or php script on each page that checks for a session variable being set. Set the variable when the user logs in. if session variable not present bounce user to login or register page. Use ssl to reduce (although not eliminate) hacking and session hijacking etc. as long as people only hack to gain access rather than destroy you haven't lost anything cos they were never gonna pay anyway. You just want to keep the amount small.

fgf

[vosgien]

Hi fgf,
thanks for that, I am currently on a steep learning curve with php, haven't got as far as sessions yet, but as I have found the things that I have done (thus far) fairly straightforward, I do not envisage any probs with that.
I do not know anything about ssl, are you able to point me in the direction of any good sites/tutes etc etc - that would be more than helpful .

Thanks again

Vosgien

[fgf]

got what i know about secure socket layer out that book mostly. I do know it is not 100% secure and you can compromise is at the scripting level by really dumb coding. However it is basically all there is so comercial companied use it. I think you have to know what your going to do if you do get hacked.

Short version of SSL you buy a certificate (from some one like verisign), client browser verifies with certificate provider and this sets up an encryption protocol (all in the browser you don't have to know anything about that except...)
You set your secure pages to https:// instead of http:// and they get rsa encrpted to a level depending on the certificate you bought. Certificates are sold in different strengths 40 bit encrypt. 128 encrypt etc and last for a period of time (a year say) .

beyond that your on your own(or at leeast there isn't much else i can tell you)

fgf

[vosgien]

Hi again,
I have given some thought to your post, and I cannot see it working the way that I need it to. As I said, I am pretty new to this back end stuff, so please bear with me whilst I talk thru' an idea, perhaps you can let me know if it will work ( or not ) - just by looking at the logic. One of the (many) good things about these forums, is you very often solve problems just by typing them out, anyways, try not to laugh ( too much ).

The original plan was to have my payment processor ( 1st American in this case) send the url with the paymont reciept, (via email), however, it may be better, if when the user makes his payment, he clicks a button and the site opens at the login page, the button action ( in the payment processor ) will have a getURL command along with a variable, the variable is posted to the swf using either php or a simple text file whiich in turn will post to the swf, so then if a user accesses the site from a url, the variable will not exist and he will be bounced back to the registration page, if the variable does exist he will be allowed to continue - now, does that make any sense at all ???
To set the variable when the user logsOn does not guarantee that he/she has paid !

Anyway, if you can give some thought to that for me, or anyone else that is following this thread.
Also, does anyone have any advice/experience of online payment processors, I have done considerable research into this, was originally going to go with PayPal, but decided they were too expensive.

Cheers

Vosgien

[fgf]

noooooo!!! (in fear and surprise)

You have to keep your secure variables and page redirection stuff sever side. anything you send to the client can concievable be read from the http headers.

I'd do like I said before but add a test for payment in the logon and fail the log if no payment recieved.

You need to look at sessions (or db workarounds for sessions) to see how to handle variable.

fgf

[vosgien]

Hi,
Well, it seems the theory wasn't so bad, but the practice could have been a disater, thank heavens for these forums.
I have since discovered that my chosen payment processor will send server side variable when a user has paid, so your original suggestion holds good, now all I have to do ( lol!!) is work out how to script that in php
I must say that since starting on this route, I feel very comfortable with php and can follow it a lot easier than I did AS when I started on that, perhaps understanding one code language makes it easier when you take on another.
Anyway, just really a note to say thanks for you input, it has been more than helpful, but I think further Q's about how to set this up properly will have to be posted in the backend scripts forum !

thanks again

Vosgien