I am working an e-commerce site which will allow pdfs to be downloaded once payment is done.
So, user will put them in a cart, click buy using paypal and from there will come back to see download link on a success page.
I have implemented PDT.
Not sure which is the best option ?
Please help. I want to take care of any connection lost scenario too, like user completes payment at PAYPAL and while returning back to our site's success page, connection is lost and for some n days, user couldnt access internet as well.
I would just use the IPN.
Keep a record in your database that has all of the order items.
e.g. Order and Order Items (in 2 tables)
Then send that primary key across as the "custom" variable.
Then your ipn handler page will validate the payment and then email the customer their digital goods.
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'm currently using the Paypal's PDN method of data transfer to keep all my transactions made through the Paypal shopping cart in a MySQL database of my own.
However, when Paypal redirects a customer to my handlePayment.php page, it takes about 10 seconds to do so. If the customer closed the window, the payment would still be made but the order wouldn't get posted to my database.
Is there a way where I can either:
a) speed up the redirect so it's instantaneous?
or
b) add a description under the store title in the paypal shopping cart, that says "please wait to be redirected after you complete payment?
Do both. Whichever arrives first wins, and the other gets ignored. The payloads are similar, so there's not much code to add.
If you rely solely on IPN, it might not have arrived by the time the visitor gets back to your site (especially if they click to it rather than waiting for the redirect). But if you rely solely on PDN, you get the problem you describe. So do both.
I have implemented PayPal payments using PDT. I realize a combination of PDT and IPN is recommended, however for my purposes PDT is sufficient.
I am able to direct user to PayPal, collect payment and then conduct an action (updating account credits for the user in the database) when the user returns to my site. The URL shows an address like:
http://www.domain.com/process_pdt?tx=45138128VH922173V&st=Completed&amt=1.99&cc=USD&cm=&item_number=
So far so good. The problem I have is refreshing the browser with this URL causes the user's account to get credited again without redirecting the user to PayPal to collect payment a second time.
I have read that I should add the transaction id (tx in URL above) to the user table and check to ensure this tx id has not already been used. If it has, I should display an error message. Is this the only way to go about this, i.e. by storing each tx id in the user table and then checking for the id's existence each time the process_pdt URL above is called by the user (legitimately or fraudulently)?
Ah, yes: this is indeed the only way to go. As a simple sanity check you may want to do a redirect from the process page to a URL that does not include the txn_id (that way a casual refresh won't cause the problem, but if they use their back button it will still happen) but you must verify that the txn_id is only used once yourself.
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!