Using Ipn In Paypal - A "Beyond Reasonable Doubt" Alternative?

[chop]

On page 150 of Larry's e-commerce book starts a discussion of "Using IPN" with regard to Paypal. I now have a need for updating a user in my MySql database who just paid his fee via Paypal by marking that user as "paid". The point, as I read it, is to get Paypal to "talk" directly to the database of the Merchant (me) to signal that a transaction of payment has actually been completed.

 

I was a bit blown away at how complicated this is (or seems to me) and decided at least try and think of a simpler way of handling it, albeit maybe less secure. I was looking for a reasonable trade-off.

 

I decided that I would send the user to a "thank you" page upon clicking the button that actually completes the transaction on the Paypal side. Paypal will do this for me. Because the amount paid is already set in the button, I can be sure that the user has paid the required amount.

 

The "thankYou.php" page (on my server) will then update the DB and mark the user as having paid his dues for that year and that will be that. EXCEPT that the "thankYou.php" appears in the browser window. If the user were to see that he could simply type in the full URL for that page and bypass the Paypal payment page, getting credit for it anyway.

 

So, my next solution was to change "thankYou.php" to something like "iwi429en298fn.php" and put in a redirect to a new "thankYou.php" that just says "Thank You for your payment" and that's all. This means that "iwi429en298fn.php" records the payment to the DB but its name doesn't stay in the browser window long enough to even be noticed. All one actually sees is "thankYou.php" that comes afterwards.

 

I know this isn't the professional way to do it and wouldn't even try if the group of people involved in this organization only numbers about 110 and are a group of fine artists that are, in general, not likely to ever try to beat this system even if someone told them how. - I suppose a savvy and sneaky person might think to look in the browser history- In addition, there are always the Paypal receipts that are sent to seller and buyer to fall back on if there is a question. The payment is also only $25/year which limits possible damages.

 

So my real question is: Is this a valid way of handling this given the circumstances or are there risks that I am not thinking of? Am I just being lazy in not wanting to do it the "right way" or does this seem to you like this really might be a "reasonable trade-off".

 

Very interested n your opinion.

[Larry]

Yeah, I don't really understand what's so bad about the IPN approach that makes you want to put all this effort into some kludge-y solution. The IPN already provides a reliable way to have PayPal communicate transactions with your site.

[abigail]

Larry's right (of course). You must wait for IPN so that you know if the charge went through. Maybe card was declined. You can put 'ordered' in your database and later when you get IPN then update ordered to 'paid'.

You can send email to your customer when you do the IPN. So tell them to watch for email. It might be right away. Similar to activating email when they register--they must wait for email.

Another thing to consider, most people using PayPal are already used to having to wait for confirmation.

Or if you want to trust them, go ahead and enroll them and if the IPN comes through with a problem then you can un-enroll them later.

[chop]

I can understand that the IPN is the "correct" way but I wanted to find out if, for my one-time use in the described situation above, if there would be an easier alternative that would suffice because it gets more complicated. Beyond the IPN programming, there is the certificate issue: understanding it and expense. This is why I at least had to pose the question. I really don't have any experience in ssl certificates or did I want to pay $85 for a private certificate.

 

I would probably risk my "kludge-y" version if it weren't for the fact that (as stated in 'e-commerce') it is up to the customer to click on the final button that returns the buyer from PayPal to the original website -where the DB update occurs. I agree it shouldn't be the buyers responsibility to click on that button to be credited for the purchase after the payment has been made. Thanks for your comments

 

FYI: You can get a PayPal IPN Guide (pdf) here:

https://cms.paypal.com/cms_content/en_US/files/developer/IPNGuide.pdf

 

"That which doesn't kill us makes us stronger" - nietzsche

[abigail]

First of all, I'm not an expert at this by any means.

I just started using a BuyNow button on my website about a month ago and I only seriously started programming it about a year ago while using Larry's ecommerce book. So all this is just my opinion and many people might disagree.

 

First of all, IPN and SSL are two different things.

 

For the SSL, I feel exactly as you do. I would rather pay for something after I at least have some paying customers at my website. For me, I am using my webhost shared certificate. It's not as elegant as your own certificate but it is free. About your webhost, I don't know what they provide. My site is new yet but you can try it out and see how I've done it and please give me improvement suggestions if you see anything: AdviceOfTheQueen.com.

 

With that said, as far as I know, with the simple payment you are doing, PayPal does not REQUIRE you to use SSL. However, I am now convinced that is the correct way for you to do it. And in addition, all your database interaction with your user should also be SSL. Using the shared certificate solved the problem for me because it is free. But I will point out it was a little complicated to get it programmed. You will probably have to spend some time to learn it. Use of the certificate is automatic (for me) but I have to know when to use a different url and because it's shared it's not https vs http. Look at my site and you will see what I mean. But now that it's programmed, looking back, it seems easy.

 

For the IPN, while you are using that free version of PayPal, there is no way for you to know if your customer's charge was successful. For example, maybe they typed a wrong number, maybe they went over their credit limit, maybe their card is expired. You have no way to know this. The only way you know this is by IPN. Implementing IPN isn't as hard as it first seems. Follow Larry's example because he has done most of the work for you. Whatever your customer does after they try to charge, it makes no difference. You could just as well update your database before they go to PayPal. The reason you care about what your customer does after they charge at PayPal -- you want them to come back to your site. You don't want them to go somewhere else online.

 

Somewhere else on this forum I posted about Stripe.com, which I am now using because of someone else suggested here at this forum. I don't want to become a Stripe 'evangelist' but you might like this better than PayPal. They REQUIRE you use SSL but you will find out Successful Charge immediately (without IPN). They still expect you to implement Webhook, which is similar to IPN, which will notify you when there is a ChargeBack.

 

You might also like to implement both PayPal test mode (I did) and Stripe test mode and see which you like better.

 

P.S. I didn't read the PayPal doc you posted (maybe in the past I already read it). Their document probably makes it more confusing than it really is.

[chop]

Abigail - Thanks for your time in posting a very informative chunk of information. Yes, I see the shortcomings of circumventing the IPN with PayPal more than I did before. I will check out your site as well as read over the Paypal .pdf. I am still wondering why an ssl is needed for Paypal to connect with the server on my end because the money transaction happens at their server not mine. I assume there's a good reason however.

 

thanks again,

chop

[abigail]

This is exactly what I didn't understand at first.

It is because someone can "get between" your site and PayPal.

I don't think I can explain it very well (I'm not sure the correct termonology).

So someone would appear to your user as if it is PayPal but really is not. They then have your user's credit card number.

Also read my much earlier post here (when the book was brand new) when I was asking Larry about this (he can explain it better).

 

But if you read further about PayPal, I think you will find like I mentioned that they don't REQUIRE the SSL. I think you have option of using Encrypted Button. I think that is how they get around having to use the SSL. It might be a good way for you to do it.

 

But now that I understand that someone could "get between" my site and my database update, so even that part is not safe without SSL -- that's why I like it now. It took some designing of my site to figure out when I want to use SSL.

Larry makes it seem easy but real world cases probably take lots of planning -- more than just implementing. That's been my experience anyway.

 

I just finished my BuyNow button a few weeks ago so it's all fresh for me. That's why I know exactly where you are with this. Getting your thinking straight is what you have to do now.

 

I sent you email through the forum with more information I didn't think I should post here. Let me know if you don't get it.

 

Remember, IPN is separate from SSL. They are entirely different issues.

[chop]

Thanks Abigail. Yes, I understand that IPN is separate from SSL.

 

If I could get away without buying a certificate and not having an "untrusted" screen come up that would be good. As I mentioned, the transaction actually takes place on Paypal so I'm not sure how big the risk is in not having https. When the IPN response kicks in, however, and my notification (ipn.php) page is accessed from Paypal, will this create an "untrusted" screen. Also, though you say:

 

they don't REQUIRE the SSL

 

on page 151 of "e-commerce" Larry states:

"The notification URL needs to be a page a page on your site accessed via HTTPS".

 

So I wonder if this is possible at all. I am browsing through the IPN.pdf to see if it mentions this and will call tech support if I can't find out. Will post the results later.

[abigail]

You do have a good point -- because the user goes to PayPay, security is their responsibility, I would think.

And I think I remember that Larry said that in his book, about the IPN needing HTTPS.

But the IPN is just a file that never shows in the browser. I looked into my ipn.php file I used for testing and there is this line:

 

$fp = fsockopen ('ssl://www.sandbox.paypal.com', 443, $errno, $errstr, 30); // Test

//$fp = fsockopen ('ssl://www.paypal.com', 443, $errno, $errstr, 30); // Live

 

I think this is what Larry was talking about.

 

I don't think you need ssl on your site to do the IPN.

[Larry]

First of all, you need SSL if you're going to do e-commerce. Period. Maybe you can "get away" with not buying a certificate, but that doesn't mean it's a good idea. I would hope that you would lose business/money if you don't have SSL. By that I mean that I would hope some customers would be driven away from a site that doesn't use SSL.

 

Also, just to be clear, the thank you page is where the user is redirected to after completing the transaction. That should be on SSL so the user doesn't see a security error. Keep in mind that a user may not go to the thank you page, which is why the IPN is required, too.

 

You should use SSL on your site so that the IPN script can be accessed by PayPal securely. It's important data that will be transmitted to your site (to the IPN script); that data should be protected. Those lines Abigail highlights are the IPN's verification with PayPal, which also has to be over SSL (although PayPal's certificate).

 

Whether the IPN is access via a browser or not (it's not) has nothing to do with whether SSL is required. There's a difference between perceived security and actual security. SSL provides both. The IPN script needs actual security; user interactions (i.e, things run through a browser) need both.

 

Use SSL! Honestly, if you're not willing to spend $85 on a certificate, you really have no business trying to do e-commerce. I'm not immune to the costs of things, and I'm personally very cheap, but doing business costs money. If you're not willing to do security right on the most basic level, you really shouldn't be doing an e-commerce project at all.

[chop]

I believe you!

I don't want to jeopardize this site. From your explanation of "perceived and actual" , I understand that the ipn script needs ssl because of the sensitive data included in the variables it's sending. I'm just trying to understand the workings of ssl: when it's needed and at what point does it become trivial.

 

For instance, let's say that a customer completes a payment at Paypal and chooses to go to the "thanks.php" page. Let's assume that all that's on that page is the following:

echo "Thank You."

 

You seem to be saying that it does because of "perceived security" (rather than actual) but it's important to do it anyway because so the customer doesn't think it's unsafe. Can you clarify what might cause an "unsafe" warning to pop up? Is it the fact that the last (Paypal) page was secure and now the very next one isn't? Personally, I've not seen such a warning appear from playing around in the PP sandbox. That doesn't mean it can't.

 

At this point I'm still in the sandbox experimenting so I haven't screwed anything up yet.

 

To summarize:

 

IPN.php needs ssl

the thankYou.php needs ssl

everything else (the actual payment process) is on payPal's side and that's their certificate

 

This is what I am hearing. Please let me know if I'm still missing the boat.

thanks.

[Larry]

SSL is needed whenever the data being transmitted between the client and the server (or, in the case of IPN, between one server and another server) needs to be kept safe from prying eyes.

 

Yes, the user may see an "unsafe" warning when going from a secure page to an unsecured page. May not. And it may not be an actual security problem, but it's something to keep in mind.

 

Overall, you seem to have it. And, of course, never cut corners when it comes to security!

[chop]

Okay, will see about getting a certificate.

Thank you both for helping me out.