views:

884

answers:

2
+4  Q: 

PayPal: IPN vs PDT

Hi,

I'm having some trouble choosing between PayPal's Instant Payment Notification (IPN) and Payment Data Transfer (PDT).

Basically, users buy a one-off product on my site, pay on PayPal, and return to my site. I understand how IPN works but I'm now seeing that I might be able to trigger the various actions that take place after a successful purchase more easily with PDT, as the data gets returned there and then (as opposed to needing a separate listener).

However, PayPal's PDT documentation contains this cryptic line: "PDT is not meant to be used with credit card or Express Checkout transactions." ... but I can't find anything further whatsoever on the topic.

  1. Are credit cards REALLY not meant to be used with PDT? I would like more than a sentence.

  2. Does that mean that a user must have/create a PayPal account to pay?

  3. Does it mean that if I want to allow users to pay with their PayPal accounts AND/OR with credit cards directly, I must implement IPN?

Could anyone who's gone through this kindly shed some light?

Thank you.

+6  A: 

The APIs for PDT and IPN are similar. The main difference is when you receive the notification. For that reason I would recommend implementing both.

  • With PDT you get the notification instantly and can do any additional processing required and show the user a confirmation page.
  • With IPN you are guaranteed to be notified that the payment was received even if the user's computer explodes before it can send you the PDT.

Implement both and get the best of both worlds. But if you're only doing one, IPN is the reliable one.

One catch: if you implement both then there's a chance your payments could be processed twice. Take care to ensure that doesn't happen. The application I wrote handles the PDT and IPN almost identically (the backend part is the same) and that code acquires a per-web-user lock in the database, so that if the same user tries to submit the exact same payment multiple times it can only be processed once. Once processed the result of that process is re-used for any subsequent attempts to process it.

Edit One more thing: IPN carries more information than PDT. There are lots of different messages that you can receive from IPN, such as chargeback notification, etc, and thus you really should implement it.

Mr. Shiny and New
Thanks, I see. So basically, link the database updates to IPN (as it will always get processed) and link user confirmations only to PDT (such as checking whether the payment has been processed by IPN on a pending page, for example) .... ?
Tom
+1 for implementing both IPN and PDT, we have done this and it works well.
Mark Redman
@Tom: My implementation is: When either a PDT or an IPN comes in, read the parameters and try to process the payment. The processor A) blocks out other simultaneous processing (for that user) and B) checks to see if it's been processed already. After processing is done, with IPN you are finished, with PDT you show the user a confirmation page or receipt page or whatever. Both the PDT side and IPN side can work properly if the other side is down, but you get good reliability from having both. A fairly high % of users don't click through before the IPN arrives.
Mr. Shiny and New
@Tom: Also, since the back-end implementation for PDT is so similar to IPN you may as well do them both, it's practically free.
Mr. Shiny and New
@Mr Shiny: Got it, thanks for all the info.
Tom
A: 

Thank you very much! This is exactly the information I have been searching for. Paypal should put this in their documentation. (or I have totally overlooked it). Any way Thanks again!

[Edit] I am working in php and testing my ipn en pdt scripts. In order to not get double payments in the mysql database I make the txn_id id field a unique column. If the query fail for IPN, DPT already made the insert into the database. That way I don't have to lock any tables. Am I right doing this?

Bram
@Bram: you should start a new question for this. But your approach looks like it will work. You definitely shouldn't lock tables for this.
Mr. Shiny and New