views:

35

answers:

2

Reading PayPal developer documentation (and this is a lot of documentation) I'm not sure if IPN is mandatory or I can simply ignore it.

Of course, I must implement some other mecanism in order to know if the payment was correct. I thought doing something like this:

  • Create a new payment (via web service) with a different code in both returnUrl and cancelUrl. This codes are generated randomly for every payment and stored in DB.

  • When the user finishes the payment (OK or KO), PayPal will redirect its page to my site and I will be able to know if the code is correct.

  • If there is a problem (user closes window, response doesn't arrive, codes don't match...) will be handled manually looking the transactions on PayPal site.

Do you think is this ok?

Thanks.

A: 

No, I think that sounds awful.

The user could skip the payment step and simply edit together your required URL, then paste it into the browser address bar. That would give them free product.

You can use the PayPal SOAP APIs to verify the transaction once you receive the URL. You merely can't trust that URL blindly the second you receive it.

You'll need to be careful not to allow users to send you the URL of some other person's payment, and receive the product twice for that payment. (Once to real payee, once to fraudster...)

It's important that you verify that you were paid the correct amount. (Assuming you care that you were paid the correct amount.)

In general, when you interface with PayPal, whatever method you use, it is important that you understand software security and threat modelling. Otherwise, there is really only a small chance you will be secure from fraud.

Heath Hunnicutt
No, I admit it's ugly, but I think it isn't easily hackable. But I like your idea of using PayPal SOAP services. I must use one service (https://svcs.sandbox.paypal.com/AdaptivePayments/Pay/) in order to send information to PayPal and generate de PayKey, and another one (https://svcs.sandbox.paypal.com/AdaptivePayments/PaymentDetails) when the user comes back to my site. Is it ok?
Sinuhe
A: 

Paypal have designed their system to be as logically secure as they think it can. I would not start redesigning a system they have spent a long time developing and thinking about. Your just ignoring so many security features that are there for your benefit.

For one if those two keys are ever accessbile in raw format client side at any point, you have an easily hackable system. Simply click through the to Paypal payment page, then type the return address in your browser without actually paying, your system is going to treat it as a valid transaction unless you manually check for yourself before dispatching the goods (for egoods it would be too late though).

Or the hacker can guess the return key. It's going to have to be long, and highly randomised, if it's an incrementing key you again have a super easily hackable system.

For verifying a payment IPN is essential. Don't take shortcuts, do it right when there is money involved.

Tom Gullen
Actually IPN is asynchronous. SOAP API could be used instead.
Heath Hunnicutt
@Tom: The user will never know my randomly generated codes. But I have to admit its ugly.
Sinuhe
@Heath: So, in your opinion, I can get the same (and more) information using the PayPal SOAP services?
Sinuhe
Saying they will never know the codes is quite a dangerous thing to say, there are clever ways this could be extracted in some circumstances. Theoretically if the code is known, you will be exploited, I'd rather just implement it the way paypal recommend.
Tom Gullen
@Tom: You're right, it isn't a good idea. But my real question is about if IPN is really necessary or there are some other valid methods. For example, SOAP. Do you think this is a valid solution?
Sinuhe