This may sound odd, but should I check if the amount sent via IPN is correct?
In my IPN listeneer, I send the post values back to Paypal to vertify them, so I assume all values are the same as on PayPal. (Amount paid etc, item name, etc.)
And the next thing is, people can't find my IPN URL, because I generate an link and redirect them to it, which is encrypted.
The reason I'm asking if I dont have to check the amount is because i run my site with coupons, and checking if the amount is correct, would be hard.
And also, my IPN URL is dynamic.
The reason people check the amount is to make sure somebody didn't copy your HTML button code, change the amount of the product, and then submit a payment using that adjusted code. This would go through PayPal and your IPN would indeed come from them, so it would verify, but if somebody changed the amount like that and you shipped the product without realizing it that could be a bad deal.
This isn't required if you're using hosted buttons or encrypted buttons. That stuff gets hidden so people can't do that. Same goes with API requests. It's really only a potential problem if you're using standard HTML buttons or checkout code that isn't hidden in any way.
Related
I have googled this for a while and I don't think I was able to get a clear cut answer.
We have an application that displays a Subscribe button. Once clicked, It takes the user to the Paypal website where s/he can complete the txn.
Later on, Paypal sends an IPN to our site indicating whether payment was successful. This integration is done by setting hidden html variables.
Now, there is a need to allow the user to cancel their subscription. So far, most of my readings indicate that the user must login to paypal and manage his/her subscription there.
In addition to that, I was able to find some other people mentioning that It would work with using CreateRecurringPaymentsProfile.
The problem is that the later requires ProfileId which is returned thru CreateRecurringPaymentsProfile. it looks like there is a gap. I would appreciate if somebody can pinpoint to the right direction.
Thanks,
I am trying to setup Google Analytics Ecommerce Tracking. I appreciate this can relatively easily be done using PDT but I can't find any reference to using the IPN page to track the sales (which makes sense because a user never actually visits these). We use IPN to track the successful orders and it makes sense to tie the tracking in with this as this is the point that a successful order is flagged. We could in theory use PDT as well to track the sales but this will not contain all of the information for the transactions and (more importantly) the sale may not have actually completed when the PDT variables are passed back. To me this makes it much less desirable as it won't always be completely correct. Does anyone know of any way to use the ecommerce tracking via the IPN page instead, or is this not possible (or not sensible for another reason)?
Thanks so much as ever guys,
Dave
I'm facing the same issue. There could be a part of a solution, that could lose some transactions, by doing this:
set a cookie on the user's browser just before he's redirected to Paypal (or on the final basket), when you set your Order ID.
the user is sent to Paypal
Paypal IPN is triggered
user goes back to your website (one day, he will!)
read the cookie you've set, on your «my account» pages for example, and if it matches an order:
Paypal status «Completed»: add the Google tracking code, using order ID, then delete the cookie
Paypal status not «Completed»: don't do anything
It's not 100% perfect, as some transactions may never be tracked, but at least it's the same user who executes the tracking code.
I'm using paypal website standard and passing my order id that is generated on my site via item_number field. I was wondering, how does paypal know that the content in the form has not been altered by user? For example, someone could just change the amount of $10 to $5 and paypal would not not have any way of knowing. I've doe this before with other payment processor, and they make me send them md5 hash of amount and some other data + secret key, but I am not sure if paypal has this?
Based on this article, I believe it depends on whether or not you are using "Payment Data Transfer". If you're just using a button, then you'll need to manually verify the payment amount before shipping. If you're using PDT, you should be able to verify the payment_gross amount sent back in the response from PayPal.
Your right -- in general you can't keep someone from altering your data. If you must use PayPal (yeah, I know, no monthly fee) so far as I know you have three options:
Let PayPal host your button data. But this gives you little control over the process.
Manually verify each transaction, checking price etc before shipping item.
Using their API to receive completed transaction to automatically check data.
Another thing to watch out for is calculation of sales tax. PayPal's approach was too simplistic for our needs, which forced me to take control of the checkout process.
See this link.
you should try to implement it using ipn, pdt is prone to not passing the variables from paypal to your website if the user does not press the "go to store" button. as what others had answered hosting your button would make it secure at the cost of flexibility. Here is a link on the variables that could be altered on hosted buttons https://www.x.com/people/PP_MTS_Haack/blog/2009/11/11/override-variables-for-hosted-and-encrypted-buttons , as you would look into the variables, you cant really change the important ones.
The payments we gather on our website are for online subscriptions and registrations for conferences. In both cases, we want to gather absolutely all information other than the payment information ourselves, and ideally pass some of it on to PayPal (so users don't have to fill in name, address, etc. twice).
I know there are solutions where the information is gathered by the server itself and then redirected to PayPal via a web services call but that's not an option, unfortunately. All secure payment information gathered has to happen off-server due to network policy.
In addition, not every form will need to be processed using PayPal. Some people will be paying via check, etc. so they shouldn't be sent to a payment page at all. Most solutions I've looked at have a "Pay with Paypal" button, so I assume a form post is necessary to go to the PayPal site, but ideally we'd want to get there via a 302 redirect. Is that at all possible? (I'm aware we could do something like a form that was auto-submitted by JavaScript but I'd prefer to not go down that route).
Whichever system we implemented would need to handle recurring (periodic) payments also.
Paypal has something called Payflow Pro. They bought it from VeriSign a few years ago.
You can use it to do a full integration with the paypal api. So that the user enters their payment details on your site, and your backend code submits the transaction to paypal's servers. Paypal will then give you a transaction id back. Keep the transaction ID, chuck everything else (like the card number) out the window.
We have several clients that use Payflow Pro. It's very good and easy to use api.
I'm not entirely sure I understand the full scope of your question, but I think I do. I've coded a number these conf. registrations (though I have not interfaced with PayPal...rather iTransact and Plug'NPay) and in my applications, I had to read through the API documentation for the system being used (PayPal in this case). Then I logged into the payment gateway and usually they have an html form generator. All this does, of course, is returns an html form with the fields labeled appropriate to their API (so the billing name and address carry over from your system to PayPal's and the user doesn't have to re-enter their information), shows you what hidden fields you'll need(like cutomer_id, etc) and the form POST path.
Then what I do is I have the user register, preview their order details on another page (where you can choose to drop their info into a DB or wait until AFTER their credit card is processed) and then upon confirmation, they go to PayPal, pay with either credit card OR check (the options always exist) and when they hit confirm, the passback URL you put into a hidden var somewhere, takes you to a custom Thank You page (and hopefully processing script to capture successful transactions) which can be hosted anywhere on your servers.
It's pretty simple, just a bit labor intensive at first as you try and figure out the new form variables specific to a payment gateway API.
Hope this helped!
I'm having trouble figuring out how to prevent people from editing the amount in my shopping cart with tools such as firebug. How do I make sure users can't edit the hidden field? Can I encode the amount before sending it to paypal?
Thanks!
Francois
Okay, turning comment into answer...
Don't encode the hidden file! When a customer makes a payment, PayPal will handle the transaction and tell your automated system that it has received the payment. It should also tell you how much the customer paid you! You then compare the amount paid with the original invoice and if there's a difference, you just tell the user that the payment is incomplete. (Unless they paid too much, of course.)
As Chris Lively tells you, don't trust the customer! Always check the amount that has been paid. Once you do this, it doesn't matter if the user hacks into any hidden fields, since you check it afterwards.
If your security depends on keeping your users away from hidden fields, your security will fail! Your security should depend on your contact with PayPal directly. Only when PayPal confirms the payment, you should send the product.
I'm sorry to say, but you can not prevent people from fiddling with the html / post variables. One common security mantra is "Don't trust the client".
The process should be to have the client post back to your server. It recomputes the totals or whatever, then send that to paypal. Obviously there should be some sanity checks like preventing zero or negative quantities; however, the client itself should NOT have control of the totals.