validate part of URL
Moderator: General Moderators
validate part of URL
Hi all,
Once the customer pays through PayPal, he has to press the 'Return to Merchant' button (or something like 'Return to Company ABC').. where I have his results showing ..and all this shows up in the return URL something like this.....
[url="http://www.companyABC.com/Untitled-2.ph ... BC.....etc"]
How can I put in a code that says if the the URL has the 'merchant_return_link=Return+to+CompanyABC, then allow user to see the page=process5.php if not, page=Dismiss.php ....
I'm thinking the only way to validate if the customer came from that 'paid' page, because it's really the last page of te PayPal process, technically the customer finalized his pay..
Thanks
Once the customer pays through PayPal, he has to press the 'Return to Merchant' button (or something like 'Return to Company ABC').. where I have his results showing ..and all this shows up in the return URL something like this.....
[url="http://www.companyABC.com/Untitled-2.ph ... BC.....etc"]
How can I put in a code that says if the the URL has the 'merchant_return_link=Return+to+CompanyABC, then allow user to see the page=process5.php if not, page=Dismiss.php ....
I'm thinking the only way to validate if the customer came from that 'paid' page, because it's really the last page of te PayPal process, technically the customer finalized his pay..
Thanks
Re: validate part of URL
You can use the $_SERVER['HTTP_REFERER'] variable in PHP to compare with the URL that you expect it to be coming from. You can determine the exact URL by sending a transaction to PayPal and having a line in your return script that (temporarily) reports to you that value. Once you know what to compare it with, you can eliminate that line and instead make the comparison.
Re: validate part of URL
You might find it more reliable in the long run to use Paypal's IPN service https://www.paypal.com/ipn
You can process the ipn notification with php, validate their purchase, send them a login/password to access your files via email...or just email them a link which you can move the location of from time to time without having to generate new buy now buttons.
You can process the ipn notification with php, validate their purchase, send them a login/password to access your files via email...or just email them a link which you can move the location of from time to time without having to generate new buy now buttons.
Re: validate part of URL
The issue there is that you usually want to confirm the transaction to the visitor on your own web site immediately. What some of us have found to be a good solution is use both. Use the Return page for immediate confirmation, then the IPN for your internal accounting. There should be an extremely low risk to using HTTP_REFERER in this situation, since PayPal sends that information when transferring to the merchant's Return URL.Eric! wrote:You might find it more reliable in the long run to use Paypal's IPN service https://www.paypal.com/ipn
You can process the ipn notification with php, validate their purchase, send them a login/password to access your files via email...or just email them a link which you can move the location of from time to time without having to generate new buy now buttons.
Re: validate part of URL
I tried the $_SERVER and it didn't work because PayPal sends it through https and my site is using http, these 2 woun't communicate together and don't recognize eachother... that's unless I get an SSL certificate and then it should work... I had just realized that I was asking to match against PayPal, but 'merchant_link...' is on the same premmisses and that woun't work either..
Re: validate part of URL
It appears that you're correct, I just tested it myself. I am surprised, I expected it to be available. Sorry.podarum wrote:I tried the $_SERVER and it didn't work because PayPal sends it through https and my site is using http, these 2 woun't communicate together and don't recognize eachother... that's unless I get an SSL certificate and then it should work... I had just realized that I was asking to match against PayPal, but 'merchant_link...' is on the same premmisses and that woun't work either..
Re: validate part of URL
I wonder if I can use the advanced variables for the 'Buy Now' button, and see if PayPal creates some sort of session id that I can pass through to my site and verify that the user came from PayPal and paid... you know what I mean? I just don't know how to integrate the advanced variables and what they are..
Re: validate part of URL
I've looked into doing that too, but as of a year ago they wouldn't let you pass dynamic info through their gateway.
The IPN is almost instant. One trick I've used is to use their transction id passed via ipn as a sort of password. They buy, then can login with the transction id. The only problem is Paypal also generates a receipt number and users tend to confuse these from time to time.
Edit: relying on users clicking return to merchant is also problematic as about 1 in 20 people pay then bail out of paypal, then they send you some complaint that they didn't get what they paid for yada yada.... This is particularly bad with people over 50, because they often don't get the return to merchant concept.
Also as you're finding it's hard to keep people from sharing the link with others after they paid.
The IPN is almost instant. One trick I've used is to use their transction id passed via ipn as a sort of password. They buy, then can login with the transction id. The only problem is Paypal also generates a receipt number and users tend to confuse these from time to time.
Edit: relying on users clicking return to merchant is also problematic as about 1 in 20 people pay then bail out of paypal, then they send you some complaint that they didn't get what they paid for yada yada.... This is particularly bad with people over 50, because they often don't get the return to merchant concept.
Also as you're finding it's hard to keep people from sharing the link with others after they paid.
Re: validate part of URL
Maybe I'm missing the point of some of this. It's true that a few customers will neglect to click the "Return" button, although I think you can set a parameter to automatically return, if that's your concern (but now that I'm looking for the documentation on this, I can't find it!). And it's true that the IPN is nearly instantaneous, but the problem is that it doesn't return to a page that the customer will see (unless you require them to login to another page, which seems clumsy in the extreme, to me). That's why I use the Return page as the normal confirmation to the customer, but then use the IPN to update my database and send confirmation email to the customer (as well as the staff, for fulfillment). Then, even if the customer bails out and never returns to our site, they will get an email confirmation from the IPN transaction.
I'd say the important thing is to be very clear about what it is you are trying to achieve and what exploits you are trying to protect against. Personally, I don't quite see why it's important to verify that the Return data is genuine, since I won't be using it for anything besides a courtesy notification to the customer. Fulfillment and our database maintenance is all done from the IPN, which has built-in verification that it's coming directly from PayPal. But no doubt in a different business situation there would be other factors that don't apply in my application.
It probably doesn't matter, but my application is for attendance registration for events at a very active nonprofit organization.
I'd say the important thing is to be very clear about what it is you are trying to achieve and what exploits you are trying to protect against. Personally, I don't quite see why it's important to verify that the Return data is genuine, since I won't be using it for anything besides a courtesy notification to the customer. Fulfillment and our database maintenance is all done from the IPN, which has built-in verification that it's coming directly from PayPal. But no doubt in a different business situation there would be other factors that don't apply in my application.
It probably doesn't matter, but my application is for attendance registration for events at a very active nonprofit organization.
Re: validate part of URL
I see what you're saying.. my issue is that I allow users to see a page with calculated statistics from a form they fill out before hitting PayPal... if I use IPN my only concern is if I can pass form variables such as (credit score, number of delinquencies, etc.) in IPN variables... the user can only see this calculated statistics page if he paid with PayPal... but you can see how I have to pass all this data from page to page and also not allow anyone to just simply type in the URL and get them withouy paying.
I might just make a really long ass URL address and hope that users can't dechipher it...sort of like dsimlskd4u30jimfosmsei......blablablabla.php
I might just make a really long ass URL address and hope that users can't dechipher it...sort of like dsimlskd4u30jimfosmsei......blablablabla.php
Re: validate part of URL
That's the beauty of using both the Return page AND IPN! There's no way (as far as I know) of spoofing the IPN transaction, because you repeat the data back to PayPal and only then will they send a confirmation, and it's only THEN that I record the transaction in our database and send a confirmation email to the customer and notify the office staff that someone has registered. That seems to me to be just about foolproof. What I use the Return page for is just to give the customer a "warm and fuzzy" feeling that the transaction has gone through. If somebody went to the trouble of hacking into that page, the only problem it would cause would be a bad feeling on the part of the customer, which could no doubt be explained if it ever came to that. There's no incentive for someone to hack that page.
Your other point I meant to comment on earlier. You can actually send quite a bit of your own special data in the custom variable, which will be repeated back in both the Return transaction and the IPN transaction. I do that, because our registrations are rather complex, carrying the number of registrants in the party and even the number of children in 4 separate age groups, as well as other information for some events! I just concatenate a string of delimited data and explode it when it comes back. I also code similar data into variables that I don't use, such as invoice (PayPal doesn't require an invoice number, but there's a pretty long field reserved for it, so I just use it for my own purposes.)
Your other point I meant to comment on earlier. You can actually send quite a bit of your own special data in the custom variable, which will be repeated back in both the Return transaction and the IPN transaction. I do that, because our registrations are rather complex, carrying the number of registrants in the party and even the number of children in 4 separate age groups, as well as other information for some events! I just concatenate a string of delimited data and explode it when it comes back. I also code similar data into variables that I don't use, such as invoice (PayPal doesn't require an invoice number, but there's a pretty long field reserved for it, so I just use it for my own purposes.)
Re: validate part of URL
Looks like about 7 months ago they starting allowing you to pass dynamic info along with the buy now buttons. Here's an discussion on how.
http://www.pdncommunity.com/pdn/board/m ... ing&page=2
I don't think you can force them to return, they have to hit a button, unless they've changed that too.
http://www.pdncommunity.com/pdn/board/m ... ing&page=2
I don't think you can force them to return, they have to hit a button, unless they've changed that too.
I'm just poining out that for applications where you need to restrict URL access the return to vendor option is difficult to secure and it is prone to confuse users.califdon wrote:Maybe I'm missing the point of some of this.
Re: validate part of URL
Oh, I agree. I'm pretty sure that I read in one of their documentation documents that you can set a flag in your profile so that the user is returned to your Return URL immediately upon completion of the payment, rather than displaying PayPal's confirmation with a button to return. But now that I tried to find the reference, I can't seem to find it again.Eric! wrote:I'm just pointing out that for applications where you need to restrict URL access the return to vendor option is difficult to secure and it is prone to confuse users.
Thanks for the link to a discussion of the use of the several custom variables they allow. That would have saved me some time figuring it out for myself if I'd had it 3 months ago. But that's exactly what I do: pack my data in a long delimited string and send it as custom and I also use invoice similarly, since both of those standard variables permit fairly long strings. I became confused by the on1 and similar variables, so I haven't used them.
Part of the challenge of integrating PayPal is the wide variety of different mechanisms you can choose to use. It's almost like too much of a good thing! But it has been serving the purpose quite well and hasn't been that difficult, once I figured out what most of the terminology means.