Instant Payment Notification (IPN) is a message service that notifies you of events related to PayPal transactions. You can use it to automate back-office and administrative functions, such as fulfilling orders, tracking customers, and providing status and other information related to a transaction. — PayPal

Once again the documentation, tutorials and code samples I found on this was a bit all over the place. Sort of messy and outdated. So, once again I decided to do my own thing and just follow the steps required and implement them myself. And since the tutorial on PDT turned out to be a bit of a success, I decided to share this too. Hopefully it can make the lives of fellow developers easier

How it works

The concept is pretty simple. You first give PayPal an address to a listener, for example http://business.example.com/ipn/listener.php. Then, whenever something happens, PayPal will post information about the event to that address. So for example if someone completes a payment, your listener will be notified shortly after with the transaction details and all you need to know.

This tutorial will focus on the listener part, as the setting up part on PayPal is very simple (Leave a comment if you disagree). Just go to the PayPal account settings, find the IPN settings and give the URL to your IPN listener. For testing we don’t even need to do that. All we need to do is to set up a PayPal Developer Account. We can then use their very handy Instant Payment Notification (IPN) simulator that you find among their Test Tools. So let’s get started!

Step 0: Sign up for a Developer Account

If you haven’t, go sign up for a PayPal Developer account. We don’t need to set up any accounts this time, as we will simply use the mentioned simulator.

Using the simulator is ultra simple. You just enter the address of your listener and choose a transaction type. You can then fill out all the data that should be in this fake transaction and then just hit “Send IPN” at the bottom. Luckily PayPal actually fills out all the fields with random test data, so unless you are trying to test something specific, you can just ignore the data and hit the button right away

Now, to the actual listener file…

Step 1: Catch the IPN

First thing we need to do in our listener is of course to catch the data we get from PayPal. The data is sent as a POST request, so PHP has actually done that for us. We just need to grab it

Step 2: Verification

Since what we got could just be plain bogus from some stranger, we need to verify it with PayPal. This is done by taking all the POST data in its unaltered state, add one field to the beginning, and then send it back. In return we should then get one word, VERIFIED or INVALID. To do that, we can use our old buddy cURL.

Note that in the very beginning actually check for a field called test_ipn. If that exists with a value of 1, it means it’s a request from the sandbox. In other words, we can choose the correct PayPal interface by just looking for that.

You can also see I set two cURL options called SSL_VERIFYPEER and CAINFO. The reason for that you will find in my post on cURL SSL verification.

Step 3: Fix character set

Now that we know the data is valid, we can start to deal with it. What you get could be in a different character set than what you want though, so we should fix that first. The data should contain a key called charset which specifies what character set the data is using. We just need to check for that and if needed convert from that to what we want, for example UTF-8.

Step 4: Use the data!

Yup, believe it or not, that was everything that was needed to catch an IPN message from PayPal. Where you go from here completely depends on what exactly you need to do.

What you at least should do is the following:

1. Confirm that the payment status is Completed.
   PayPal sends IPN messages for pending and denied payments as well, so don’t ship stuff or anything until the payment has cleared.
2. Use the transaction ID to verify that the transaction has not already been processed.
   This prevents you from processing the same transaction twice. You can for example store the transaction id in a database and check against those before you do anything with incoming IPNs. If you’re smart you could also store the time the IPN came in and the raw IPN data. This way you have a log of all incoming messages you can use if you need to reprocess something or for debugging if something weird is going on.
3. Make sure the receiver’s email address is the one you expected.
4. Make sure the price, item description, et cetera, match what it should be.

And then finally you should of course make sure your customer gets what they should

You can read more about PayPal Instant Payment Notifications in their IPN Guide.

Working sample

I have put together a working sample you can check out over at samples.geekality.net/ipn. Hopefully this tutorial and that sample can help you get started with all of this

I also put together an IPN handler class you can use pretty much out of the box. The sample uses it, and it’s very simple. Just extend the class, override the process method and do what you need. Below is a simple example.

That’s all! I’m sorry it took so long to get this tutorial written, but hopefully someone can find it useful. I have learned a lot writing it at least! Please leave a comment if it was helpful, if it wasn’t helpful, if there are mistakes, typos, or if you just want to say thank you

rgbstock.com

Well, step one to solve this is of course to find all the images on a page, and that is what I will present in this post. It will be sort of like a backend service we can use later from an AJAX call. You post it a URL, and you get all the image URLs it found back. Let’s put the petal to medal!

Getting the URL

We’ll use POST for this, and it shouldn’t require much explanation.

Loading the HTML

To load the HTML we’ll use the handy cURL library, which I’ve used in earlier posts as well.

We just create and execute a request for the supplied URL. The response is stored in a variable so we can use it later.

We won’t bother with any fancy error handling or anywhere else. If it doesn’t work, we’ll just give an empty list back. Bad URLs, faulty HTML, not our problem

The SSL and cacert.pem stuff is explained in an earlier post.

Parsing the HTML

You might have seen examples on how to find things in HTML using regular expressions. This is by most experienced developers regarded as A Bad Idea™. What we can, and probably should, use instead is the DOMDocument class you find in PHP. This class can parse XML and HTML into a neat DOM which is a lot easier to work with.

Not everyone writes perfectly formed HTML without errors so we load the HTML, the DOMDocument class will do its best to plow through the HTML and figure it all out. When it does come across things that are a bit out of wack, it will let us know by spitting out warnings. There’s a big chance it managed to deal with it fine, but just for our information. However, like I mentioned earlier, we don’t care about errors here and we definitely don’t want those warnings messing up our output.

So, what we do here is to tell libxml (which is used internally) to enable user error handling instead. When we now load the HTML, those errors and warnings are then instead collected quietly. We can get to them afterwards by calling libxml_get_errors, but since we don’t care about them at all we just clear them out instead. Easy peasy.

Dealing with relative URLs

As you perhaps know you can have both absolute and relative URLs in HTML. The relative URLs are relative to the base path of the HTML page. Unless the HTML page has a base tag. In that case we need to use whatever that specifies instead. So, how do we deal with all of that?

Well, I decided to stick that in a different post. What’s important here is that we can get the base tag from the DOM like this:

Of course if there is a base tag, it should only be one, but since we get a collection back from getElementsByTagName I just use foreach for simplicity.

Next up we have a function which turn a relative URL into an absolute one. The signature looks like the following and the content you can read more about in that earlier mentioned post.

Getting the images

Now to the fun part. With the HTML loaded up and the base path figured out, we just need to fetch the images.

Now that was pretty simple, wasn’t it? The perhaps weird thing here is that I first collect them in an array, using the image source as a key. This way we won’t end up with duplicate image URLs. We also skip images which for some reason were to not have any URL.

We could of course also get other stuff from the image tag here, like the height, width, alt text or title, or we could do some more elaborate filtering to try to weed out uninteresting images. For example really tiny ones or whatever else we might think of.

Echo it all out

Now we just need to echo it all out in a format we can use easily on the client side. And we will, surprise, surprise, of course use our good friend JSON for this

We set the appropriate header, wrap it up in a result array, encode it, and spit it out. And that’s pretty much all there is to that part.

Working sample

When I implemented this I decided to wrap most of this up in a class I called Image_Finder. I have also created a tiny interface for this so you can test it out for yourself. Will go through that interface (or a variant of it) later, but since that’s all HTML and JavaScript you are of course more than welcome to have a peek at the source of it

Either way, you can find it all, code and sample, at samples.geekality.net/image-fetcher. Let me know if you like it. And definitely let me know if you find any bugs ;)

Bugs, improvements, suggestions, praise; please leave a comment. I like to learn

rgbstock.com

In this case you might want to proportionally resize the image to the appropriate size when you get it uploaded. You can then store the resized image instead and serve it directly with no problems afterwards. It doesn’t have to be difficult! Here’s how

The form

To keep this ultra simple, we will just have a tiny form with one field and a submit button.

Notice that the form has enctype="multipart/form-data". If it’s not, the file upload won’t work. Up next is the file which catches the uploaded data.

Processing the upload

First thing we need to do is to check that the upload went alright.

If all good, we can turn the uploaded file into an image resource.

Before we can actually resize this image, we need to figure out a couple of things. We need the size of the frame we want to fit this image into, the current size, and the size it should have to fit inside the frame without messing up its aspect ratio.

We calculate the scaling by dividing the wanted dimension with the current one. I do this for both the width and the height, and then choose the lesser of the two. This makes sure that both wide and tall images will fit into our frame. When we have the scale, we simply multiply it with the current height and width to get our new dimensions.

With that calculated, we can simply create a new empty image resource and fill it with a resized copy of the original image.

Where you go from here is a bit up to you. You could turn the image resource into a PNG or a JPEG and then store it as a file, in a database, or whatever you feel like. Just as an example I’ll turn it into a JPEG, catch the data in a versatile variable and output it to the browser.

First I create a JPEG image out of it and catch it using output buffering. With the data in a variable it can easily be stored in a database, dumped to a file or to the browser. If you wanted to dump it to a file, you’d probably want to swap NULL with the filename. And if you wanted to output it to the browser, you could just skip the output buffering and let the data flow to the browser freely. But, just so you can see how to catch the data in a variable, I will do it the hard way

Next up we need to clean up after ourselves. Never forget that!

Finally we’ll set a proper content-type so the browser understands what it gets and output the data.

And that’s all

Working sample

You can check out a working sample and complete source code at samples.geekality.net/image-resize. Don’t abuse it ;)

Let me know if this was useful or if you have some ideas for improvement. Also, if I have messed up somewhere, please do let me know so I can fix it and possibly learn something new

The result was not what I expected however. All I got to see was the messages that had been printed out. No exception or stack trace to be seen.

The reason for this is quite simply that a Unix process has three different streams: stdin(0), stdout(1) and stderr(2). When we pipe output from one process into another we sort of connect stdout of the first one to stdin of the second.

So, to be able to see my giant stack trace, we can for example redirect stderr to stdout. This way we will get both streams into stdin of the next process.

Fancy, huh? We can also direct these streams into files, which might come in handy.

If you want the output to be appended to the log files instead of replacing them, you can do adjust the command to this:

I usually do this whenever I reinstall Windows. At least on my desktop computer. My laptops usually have password protection enabled. Anyways, I don’t reinstall that often so I always forget how to do it. Even though it’s very simple… Decided to share the procedure here, so I know where to find it

1. Press Win+R to open up your Run dialog
2. Type in control userpasswords2 and hit enter
3. Under the Users tab, uncheck the checkbox that says “Users must enter a user name and password to use this computer”
4. Click the Ok button
5. Enter your current password, and you’re done

The next time you reboot it should go straight into Windows instead of stopping at the Welcome screen, waiting for you to type your password.

The batch file simply looks like this:

You can duplicate those two last lines for other folders you want to back up as well. I have one copying my D drive to external drive X, one copying my E drive to another external drive Y, and one copying some folders on my C drive to external drive Y.

Robocopy

Robocopy is of course the command that does the backing up. The options I use here are as follows:

1. Source (directory we want to back up)
2. Destination (where we want the backup to be stored)
3. Copy Data, Attributes and Timestamps
4. Mirror (Copy all subdirectories, even empty ones, and delete files no longer in the source directory)
5. Copy files in Backup mode (assert the Windows NT “backup right” so an administrator may copy an entire directory, including files denied readability to the administrator)
6. Exclude Junction points
7. Retry zero times on failed copies (prevents spending lots of time on locked files for example)
8. Don’t display any progress
9. Log what happens to the given file instead of printing it out in the console

Don’t get stuck in a loop!

The robocopy switch, /XJ, is very important to remember if you copy for example your user directory. The reason is that some folders in Windows are something called junction points and some of these will cause robocopy to enter a never ending loop. The copying will basically never finish until the target device run out of space or something else happens. Happened to me. Not very fun to clean up

Attrib

In my case I am copying a whole drive, and the attributes on the resulting folder is a bit weird. So, to have the folder show up in Explorer without having to make it show system files and hidden files, I remove the system- and hidden-attribute from the folder.

How to run it

You can either run this yourself in a Command Prompt or schedule it using the Task Scheduler. What is important to remember is that you should run this using Administrator rights.

So, if you use a Command Prompt: Remember to use an elevated Command Prompt. And if you use the Task Scheduler, remember to select that the task should Run with highest privileges in the task properties.

If you just want to run it in the command prompt and see the progress a bit easier, you can remove the /NP and /LOG options. You will then see what happens as it goes through your files

Payment Data Transfer (PDT) is a secure method to retrieve the details about a PayPal transaction so that you can display them to your customer. It is used in combination with Website Payments Standard, so that after a customer returns to your website after paying on the PayPal site, they can instantly view a confirmation message with the details of the transaction. — PayPal

I’ve tried to figure out how to use PDT and found that most samples and classes to build from are usually quite ugly, old or outdated. I didn’t find them too useful anyways… So, therefore, I’ve tried to do my own thing based on the documentation found on the PayPal Developer websites. (Seriously, how many versions of documents and developer websites do they have anyways? It’s like a complete jungle…)

Since the documentation was a bit of a mess, I thought I make a small tutorial on the steps needed to get started. That way I can learn it better myself and hopefully help some other poor souls that need to figure this stuff out as well. Please provide feedback if you have any! Would love to make this page nicer and clearer if possible

Step 0: Sign up for a Developer Account

Before you start playing around with PayPal stuff, I would recommend that you get a PayPal developer account. You should also set up a business account in the PayPal Sandbox which you can then use instead of your real account. A lot safer, cheaper and easier than using a real one.

Step 1: Enable PDT for your PayPal account

For this step I’ll just quote their PDT page (one of many, it seems):

Apparently they have changed their UI now, so the instructions in their PDT documentation is wrong… Thanks for the heads up Yuriy! The description below should be correct now

To use PDT, you must activate PDT and Auto Return in your PayPal account profile. You must also acquire a PDT identity token, which is used in all PDT communication you send to PayPal.

Follow these steps to configure your account for PDT:

1. Log in to your PayPal account.
2. Click the Profile subtab.
3. Click the My Selling Tools button in the left column.
4. Find the Selling online section and click Update in the Website preferences row.
5. Under Auto Return for Website Payments, click the On radio button.
6. For the Return URL, enter the URL on your site that will receive the transaction ID posted by PayPal after a customer payment.
7. Under Payment Data Transfer, click the On radio button.
8. Click Save.
9. Find the Selling online section and click Update in the Website preferences row again.
10. Scroll down to the Payment Data Transfer section of the page and take note of your PDT identity token.

The last point is particularly important and you should not only view the token, but note it down. Reason being that you need this in your code when we’re going to talk to PayPal later.

As an aside, I would also recommend you turn off the “Block Non-encrypted Website Payment”, at least while testing, since it’s a lot easier to make PayPal buttons on the fly without encrypting them. I currently don’t know how, but I’ll probably try to figure out soon. I would also recommend that you set PayPal Account Optional, so that people can make payments without signing up (since some people don’t want to be bothered with that). To the right I have put a screen shot of that page with the mentioned options marked in yellow. Click on it for full-size view

Step 2: Create a button

The PayPal buttons consist of a form which has a number of hidden key/value pairs and a submit button. You can find info on how to make those in their Website Payments Standard Integration Guide so I won’t explain how to do that here. What I would like to mention in this case though, is that you can, if you need to, override the return URL that you set in the previous step for specific buttons. For example you can return them to the order they paid for rather than just a general return page.

I use the same URL for both since we will check things with PDT anyways. Here is an example button with the data I use in this tutorial:

So, the user will click the button, go through the payment procedure, and at the end there will be a link/button to return to the merchant. When that is clicked, we get to the next step.

Step 3: Catch the return

The URL they are returned to could for example look like this (split for easier reading):

As you can see we get some GET parameters to work with here, but the only one you need is the Transaction ID, tx:

The reason we don’t care about the rest is that they’re not trustworthy at all. Since they are GET parameters we can easily tamper with them in the address bar of our browser, and we just can’t have any of that, can we?

To get good and trustworthy data we need to send this transaction id back to PayPal together with our PDT Identity Token. If the id and token are valid, we will get real and actual transaction details back in return.

Step 4: Do a POST request back to PayPal

Sending the Transaction ID and our PDT Identity Token back to PayPal can be done in various ways from PHP. I used cURL which I found to be pretty clean and easy to use.

The cURL options we set means roughly: Use this URL, do a POST, send these variables, return the transfer as a string when I call curl_exec and do not include the HTTP headers in that string. The last two you can most likely leave out, but I explain why I added them in this post.

Note: For security reasons, PayPal will only allow you to use the transaction id to get a response up to 5 times. After that it will be invalidated and you will get an error back instead of the transaction data. Fair enough for regular use, but found it a bit annoying while developing since it took some tries to get the result I wanted

Step 5: Check the response

The response will be a string that looks something like this:

To make sure everything is well we must check that the status code is 200 and that the first line says SUCCESS. On failure it would say FAIL, or something like that. We can do that like this:

That response is not very useful right now though. Even if it is valid, the string is just, well, a long string. Not to mention it’s URL encoded and possibly in the wrong character encoding. We want to clean it up and turn it into a much more handy associative array.

Step 6: Clean up the response

We want to remove the first line, URL decode the string, turn it into an associative array and convert the encoding if needed. This is how you might do that:

The $response should now contain a nice and sorted associative array with the correct encoding and it’s ready to be used for whatever purpose you need.

Step 7: What now?

What you do with the validated and cleaned up data depends on what you need and what you want. You could use it to display a nice helpful message to the user, store it somewhere, maybe mark something as paid in your database, et cetera. You should also most likely check that the data you have gotten corresponds to what you expected. For example if the amount they paid matches the amount they should have paid and so on.

Important thing to remember about PDT

You are actually not guaranteed to get this PDT data. Unless the user clicks that last button in the payment process at PayPal and returns to your page, you will get nothing. They could for example close the browser tab when the payment is done or the power could go out just before they had the opportunity to. Theoretically it could happen!

If you want something that is fully reliable, you need to have a look at PayPal Instant Payment Notifications (IPN). PayPal sends these notifications to a certain URL you have provided behind the scenes and it is not part what the user does or does not do. They may not be instantaneous, but you are guaranteed to eventually get them.

What you most likely want is a combination of these two. Use PDT to give the returning users a quick response and store what you can/need in the database. Then use IPN to fill out the gaps of missed PDTs or missing transaction details (IPN will give you many more details than PDT does).

It took some time, but I have finally finished a tutorial on IPN Check it out if you’re interested

Working sample

Since the code above was a bit broken up, I have gathered it all in a single example page that should be operational. It contains a simple Buy Now button and it will display the PDT response when you return from the fake purchase. Since it uses the PayPal Sandbox you need to be logged in to your developer account. For the payment you can use one of your existing test accounts or you can pretend to be a person that just wants to use his credit card without an account (If you need help coming up with a fake credit card number that validates, have a look at darkcoding.net/credit-card-numbers).

You find it over at samples.geekality.net/pdt.

The process_pdt function you can see in the source code should be pretty self-contained and you should be able to just drop it in to whatever you are working on and use it out of the box. Just remember to fill in your actual identity token ;)

And that’s the end of this tutorial!

Think this was my first longish in-depth post, so if you have any feedback, found it helpful, please leave a comment. Also do that if something is unclear, could be improved or is flat out wrong. Especially if it’s flat out wrong. There’s a lot of wrong stuff on the Internet, and I don’t want to contribute to that