CODEWITHSUNDEEP
phppaypal
Ciprian
Ciprian

Reputation: 3226

PayPal - IPN Listener and encrypting payment

I need to add payments to a website I'm working on and I'm not sure what to do. On the website, users will be able to purchase virtual points. So once they pay, their account will be credited with x number of points.

I came across this tutorial on IPN http://phprocks.letsnurture.com/paypal-ipn-with-php/ which I used, and was able to do a few tests using the PayPal IPN simulator(https://developer.paypal.com/developer/ipnSimulator). Everything went well and the user's data was saved to the database after the "payment".

However someone suggested another way to handle payments. Using this http://blog.scrobbld.com/paypal/protecting-your-payments-with-ewp/ tutorial which encrypts the payment.

In the second tutorial the author mentions this: "If they use Firefox, and have installed Firebug, it is more than easy to edit the DOM of the page, and post that off to PayPal instead. So instead of having the amount at 12.99 , I might set it to:"

<input type="hidden" name="amount" value="0.99">

but doesn't this if from the first tutorial take care of this aspect? Or does the encryption from the second tutorial offer more security for the payment?

// 3. Make sure the amount(s) paid match
if ($_POST['mc_gross'] != '0.34')
{
  $errmsg .= "'mc_gross' does not match: ";
  $errmsg .= $_POST['mc_gross']."\n";
}

So if I understand this right, I can use the ipn listener class from the first tutorial, together with the encrypted payment from the second tutorial?

Upvotes: 0

Views: 166

Answers (2)

EdSF
EdSF

Reputation: 12351

The key phrase in Andrew's answer is "has already occurred" (IPN).

If you can actually verify the pricing beforehand, aside from opting for encrypting things, you could use Express Checkout where data is handled server side instead of an HTML form that POSTs directly to Paypal as shown in the sample.

This way you can treat IPN more like what it really is - a "messaging" service based on events in the transaction, rather than making it part of the transaction (where you somehow need to invalidate transactions after the fact).

While "invalidating" (credit/refund/cancel) transactions do occur normally, IMHO, it "should" be because of your business rules (instead of some validation issue, like dealing with tampered data).

"If they use Firefox, and have installed Firebug, it is more than easy to edit the DOM of the page..."

Tampering with HTML form data is an inherent risk in all <form /> and all modern browsers have internal tools (Firefox, Chrome, Internet Explorer) to inspect everything it ("client-side") is involved in. That is why validation (both client and server side) are required in any time of web development.

Hth..

Upvotes: 0

Drew Angell
Drew Angell

Reputation: 26056

Within IPN the transaction has already occurred. So if it doesn't match you can send yourself a notification, automatically refund the payment, or handle it however you want.

A secure button, though, whether encrypted or hosted by PayPal (which is how I prefer) would not show the pricing data in the button code at all, so there's no way for anybody to even make a payment without the correct pricing.

So you could use both together, but the logic in the IPN really would be obsolete if you're using secure buttons in the first place.

Upvotes: 1

Related Questions