Jump to content

Archived

This topic is now archived and is closed to further replies.

hadoob024

Payment Handling Code Question

Recommended Posts

OK.  I have a real estate listing site where searches are for free, but we charge the customer to list their property.  Here's how I'm setting up my site:

Add Listing p.1 - Customer enters listing type (to determine how much to charge customer).  Form action sends control to Add Listing p.2.

Add Listing p.2 - Customer enters payment info on a form on our site.  The action of the form sends the information to the merchant account payment gateway.  The return value of this determines whether or not the payment went through.

If payment goes through, we send control to:
Add Listing p.3. - Customer enters in listing info.  The action of the form sends control to Add Listing p.4, which basically is a confirmation that the info was added to the db and that the payment went through.


Basically, I want to know is how can I prevent anyone from accessing Add Listing p.3 without getting a 'yes' confirmation from the payment gateway?  Like I don't want someone to try and access Add Listing p.3 by directly entering the URL, thus bypassing the payment part.  Any thoughts?

Share this post


Link to post
Share on other sites
There are several ways that I can think of. You could set a $_SESSION variable in the form before that one and check to see if it exists. You could also check the referer. If the referer dosn't match the previous page then you could direct them to the first page.

Nether of those are fool proof but they should do what you want..

Good luck,
Tom

Share this post


Link to post
Share on other sites
hmmm... yeah, i was thinking of going the SESSION route, but with SESSION hijacking couldn't that be a problem?

Share this post


Link to post
Share on other sites
there are a few things to aid in avoiding session hijacking.  i usually store the user's IP at login in the session and check it continuously against this value.  if someone hijacks, the IPs differ and they're booted.  in my opinion, the chances that someone's IP changes on them in the short while they're browsing the site (or even in one continuous internet session) is minimal.

i would suggest requiring BOTH the listing information and payment info in one place.  they submit, and if the payment fails don't store the information.  if it does, store it and they're done.  that way there is no third form to hard link to.  not sure how feasible this is with your merchant gateway, but it's worth a shot.

finally, another option is to enter the listing info first and store it as inactive.  let the user then pay for it to be shown, and it is active.  while people could theoretically enter info and not pay for it, it will not be displayed until they've paid for it.

regardless of your choice of solution, i think it's silly to have them enter their listing info AFTER they've paid.  there are too many possibilities for errors and unhappy clients.  what if they pay, get to the listing addition page, and their connection craps out or they close the page, etc.?  unhappy customer demanding a refund; while they may have been willing to list their property with you before, good luck retaining their business after.  just a thought.

Share this post


Link to post
Share on other sites
OK.  Cool.  But if I have them enter payment info and the listing info on the same page, the form action sends them to the merchant account gateway, and when they get sent back, won't I have lost my form information for the listing itself?

Also, I was thinking about doing the payment info first because there seems like there could be more issues with paying than just entering form info.  Because once the listing form info is sent, I send myself an email saying that the following listing info was submitted.  I then send myself an email once the info actually gets added to the db.  That way I know that for a successful addition, I'll get 2 emails.  Doesn't this seem like it will handle the situations you talk about?  If I did it the other way, what do I do with the listing information while I'm waiting to find out whether the payment went through successfully?  Thanks!

Share this post


Link to post
Share on other sites
most payment processors (this is in my paypal experience) will be able to inform you immediately whether the payment was successful, assuming payment was by way of credit card.  also, most processors that allow you to communicate with their gateway also allow you to send some information back and forth with the payment info, so that you can attach it to an identifier for that user's listing info.

i just think that the way you are doing it leads to a lot more admin work on your end than necessary, given the number of fully automated options.  that being said, don't neglect to add a manual system in just in case the automation fails, but you shouldn't need to rely on it.

Share this post


Link to post
Share on other sites
Cool.  Thanks for the advice.  Yeah, I think I'll wait until I get through the docs for the payment gateway before making my final decision.  If they allow for pass-thru variables, then maybe I can have both listing and payment info on 1 page.  Otherwise, I'm guessing I'll have to split it up.

Share this post


Link to post
Share on other sites
You can also add a true/false field in the lkisting table. Any payment processor would be able to pass at LEAST one variable-then you just have script set it to true when it comes back:)

Share this post


Link to post
Share on other sites
oh yeah!  that's a good idea...  i'll probably go with it after reading through the docs.  from the way they've setup other stuff, it seems like they've encountered all these kinds of issues before and cater to them pretty nicely.  but if they don't, then that seems like a good way to protect myself for issues of just one of the transactions going through, and not the other.  thanks!

Share this post


Link to post
Share on other sites

×

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.