Gossamer Forum
Home : Products : Gossamer Links : Discussions :

LSQL as pay per "link" classifieds

Quote Reply
LSQL as pay per "link" classifieds
Hey folks,

I have been tinkering with LSQL for like 9 months now... I understand how the globals, templates and category pages work. I'm planning on running our entire site using LSQL, but I have a few modifications that I just can't wrap my head around:

In most categories, memebrs will not be able to add or modify "links". LSQL will be delivering full length articles in most categories.

I'd like to have a category for "classifieds" and one for "personals" where folks can add a "link" if they pay a fee. So, in other words, the only way to add a link would be to first go to a cart and pay for the link.

I can understand that the "add a link" would point to a cart with an item and price, and you'd end up in the cart check out. But then what, how would it work? Would they get an email with a code allowing them to upload a "link"? what would stop them from using that code to add whatever amount of links they'd like to add? Obviously, I'd amend the add.html and modify.html pages to reflect those two categories fields.

I guess first I am asking a general question: How should I approach this idea? What should I look out for?

Then, more detailed questions follow: Can I get away with using one copy on LSQL and using seperate template sets? It seems to me, if the price is sent over to the cart, then it is just a matter of tracking the payment "certificate" or whatever and having them plug that into the LSQL add/modify form.... is that right thinking?

I am not concerned about keeping the member's email info private (for the personals). I'll also be using the vBulletin plugin, so they can use the private messaging system there.

I hope you'll share your collective wisdom with me on this.... Smile

Last edited by:

Evoir: Jan 24, 2002, 12:44 AM
Quote Reply
Re: [Evoir] LSQL as pay per "link" classifieds In reply to
Actually, you'd probably want to attack this in a slightly different way.

Your shopping cart needs a way to let Links know there was a successful transaction. This could be writing the response code to a file, or passing back a reply from a secured server - or something else.

But, when your user goes to add.cgi they are prompted to enter their data, and upgrade their link. If they choose an upgrade, they are sent to the shopping cart. The shopping cart handles the transaction, and if successful, should "flag" that user, or more likely that link record, as being "paid."

This goes back to having the the Link exist (LinkID) before going through the shopping system.

Let the user enter their data, and create an entry. But mark it "unpaid." Once a user goes through the shopping cart, the system flags that link as "paid". It then goes through the validation process (or can be automatically validated ie: isValidated=Yes).

The point here is to get your LinkID _first_ then use that to mark the shopping cart transaction, so you know what the transaction was for (if something fails) and the shopping cart knows what link to credit.

If you use a system of "user credits" then you'd do the same thing, but update the Users_credits with what they purchased, then go through your other system.

The user_credits system is more flexible for something like classifieds, and logos, or downloads. It's a bit harder to implement, but it allows a "user" to have a balance, not a "link", and it means you should always know where the shopping cart transaction was going since you should at least have a USERNAME.

Just remember, the web is fallible. Connections don't complete, a person may lose their connection, or their browser crashes before they get a confirmation. You need to make sure there are discrete steps to your process, so that you can recover any "damaged" or incomplete transaction gracefully.

And, remember the words of great wisdom - "Trust No One."


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.