I am looking for a way to check which of my costumers email addreses are linked to valid Paypal accounts before i decide to propose this payement method on my website. while searching on google i found this website which does the job perfectly and is 100% accurate
http://prime-position.ch/cache/9.php
, the only problem is that it is very slow and takes hours with big email lists so my question is how do i find this script in particular or another one that does the same job.
Well... to answer your question... you can't verify an email with PayPal (w/ or w/o API).
Even with mass payments, they don't give errors, they just notify the recipient to create a PayPal account if they want the money. And the mass payment fails if they don't claim the funds sent to a non-existing PayPal email in 30 days.
That script is a joke and does not work! If this was your attempt at phishing for PayPal emails... you need to step up your game :)
UPDATE:
AddressVerify API^ is of no use to you. It requires their home address and will not work without it. I don't think you have that... plus your account may get flagged after too many tests.
Related
I have Integrated Paypal using php. I know there is return url ,that means when payment is received it will return to the url for our website.My Question is if payment is received and due to internet problem it does not return to our web page, how do I know that payment is received from a particular user?
If there is a network issue and PayPal cannot issue the IPN message, then according to their documentation, they will retry 15 times up to 4 days.
The IPN message service does not assume that your listener will receive all IPN messages. Because the Internet is not 100% reliable, IPNs can get lost or be delayed. To address these issues, the IPN message service includes a retry mechanism that re-sends a message at various intervals until your listener acknowledges receipt. An IPN message may be present up to four days after the original was sent. The maximum number of retries is 15.
https://developer.paypal.com/docs/classic/ipn/integration-guide/IPNIntro/
This item below might help. Instant Payment Notification should work, but in the case of a network failure, if the payment reached PayPal but the purchaser did not get back to your site to complete a purchase, then you should still receive an email from PayPal telling you that you have received a payment.
using paypal button - can my webpage tell if paypal transaction was successful or not?
You get a confirmation email with their name and email address - be aware that occasionally this may not be the user's current, most active email address. You can also log in to your PayPal dashboard to see all details as well, of course.
You can look up your payment details from the email and compare them to your own user records in your database. If the email they use for PayPal is not the same as the one they registered on your site with, you can still look up their name from the email - in practice it seems to happen extremely rarely that payments have such a problem in my personal experience
I set up a script which emails my users with a passcode to get to the online product they bought which is emailed to them so they can submit that later along with their email address. This is the first thing that happens on return to my script so at least if the site fails to respond properly they can get to what they bought later.
The script uses PHPMailer and cc's me with their passcode so I have it available to re-send to them if they write with a complaint. It doesn't help if the PayPal return for Instant Payment Notification fails completely but the other answers cover that very fully and detail the PayPal repeat attempt process well.
Instant Payment Notification scripts can be downloaded from PayPal for modification by yourself as per the article linked to above.
To be perfectly honest, this is one of PayPal Standard's largest holes. IPN is a POST callback (as is PDT) and they check to make sure they get a 200 response or else they retry (and you can use the IPN history in your PayPal account to resend missing IPNs). But this method still relies on you getting the callback in a timely manner and it's not foolproof. Worse, you need to verify the IPN call and that introduces yet another point of failure in calling PayPal to make sure they did indeed send you the IPN you got.
There's a couple of ways to deal with this
Audit your account regularly. This is a good idea in general, but for a small website this shouldn't be terribly hard. Match your invoices up to your PayPal payments. Obviously this doesn't scale well so...
Switch to Payments Pro. There's more hurdles to this (like more PCI compliance, SSL certificate, etc) but the major advantage is that the API is far less susceptible to the whims of the Internet and only involves one call for credit cards (you can ignore the IPN because the API tells you everything you need to know). The worst that can happen is you send a payment API call and fail to get a response. This is exceptionally rare as PayPal makes sure their API is 99.9% reliable (IPN relies on your server being reliable). Speaking from experience, Payments Pro has far fewer issues than IPN does.
In your application, you should have a status field for orders. If you haven't received the ipn, you wouldn't change the status to Paid.
After that, if you receive an email from Paypal that someone has paid, check the order number, and change the status manually.
how do I know that payment is received from a particular user?
Paypal will send an email both user and you.
Paypal offers 2 solutions for your problem.
PayPal IPN - it notifies the server with a POST request to a specific URL, whena transaction has been successful, declined, aborted by user and so on. Paypal provide an IPN Simulator (the worst simulator ever) in order to test its functionality. you may give it a try at : https://developer.paypal.com/developer/ipnSimulator/
Paypal WebHooks - The webhooks are the "New Kid in the Block",they are basically "user-defined HTTP callbacks that receive events for the subscribed event types. Webhooks are asynchronous, the order is not guaranteed, and idempotency may lead to the same event being sent more than once." as stated in the Paypal documentation.
You can read more about it on : https://developer.paypal.com/docs/integration/direct/rest-webhooks-overview/
For any further help, comment below and I shall try to help.
Cheers,
You have to use notify_url for this purpose
<input type="hidden" name="notify_url" value="https://domain-name.com/ipn.php">
I am working on an API that can be used between my server and my iOS app. I have an SQL database that contains an Accounts table which includes a column called BALANCE.
People can make a real money deposit to my website through PayPal or I will be allowing them to send money orders. The problem is, when the PayPal SDK checks to make sure it was a legitimate deposit, then it credits that users account balance. When I receive the money order, I credit their balance via my website.
Each time the balance is credited, a call to my API happens. The thing is, I can do this over and over without actually getting PayPal deposits or money order deposits.
See, the users will transfer balances between each others accounts. So I don't need any help with making sure deposits were legit, I got that already. Right now a simple API call will transfer one balance amount over to another account without proof that the call was for a legitimate reason. I don't want to be able to have people somehow tap into the API and credit their own balance somehow. It needs to be where people can't just alter it.
So what can I put in place so that people cannot just tap into my API and credit their balance without actually sending money? Since this is real money, I am putting a lot of time into security.
You could authenticate with OAuth, which is what the majority of web service API's are using these days.
This tutorial may be of interest to you.
recently I helped some friends ship an invite system in their website that works like this: A user creates an account, we send a verification email and when he verifies the e-mail he gets one free credit to spend on the website. In addition to that, he has personalized links he can share on social networks or via e-mail and when people register using this link (e-mail verified accounts again) he gets one credit per invite. Much like the invite system on thefancy.com or any other reward driven invite system on the web.
Lately we see elevated rates of fake user account which probably are automated. The registration page features a CAPTCHA but we're aware this can be bypassed. We also see elevated rates of users creating disposable email addresses to create accounts following specific invite links thus crediting one legit users that onwards uses the free credits he earns.
I am looking for an automated way to prevent such kind of abuse. I currently investigating putting rate limits on invites/registrations that come from the same ip address but this system itself has it own flaws.
Any other production tested ideas?
Thank you
Edit:
I've also proposed 2 factor registration via SMS but was turned down due to budget shortage.
It seems you need to require more than just a verified email address before a user can send invites, ideally something that shows the user has participated in your site in some way. Without knowing what your site is it's hard to give specifics, but the StackOverflow equivalent would be requiring users to have at least X reputation before they can invite others. If you're running a forum you could require that they've made at least X posts.
I'd also suggest a small time limit before new accounts can invite - e.g. they have to have been a member for at least X days. This complicates automated invites somewhat.
An extremely simple method that I have used before is to have an additional input in the registration form that is hidden using CSS (i.e. has display:none). Most form bots will fill this field in whereas humans will not (because it is not visible). In your server-side code you can then just reject any POST with the input populated.
Simple, but I've found it to be very effective!
A few ideas:
Ban use of emails like 'mailinator'.
Place a delay on the referral reward, allowing you to extend fraud detection time period, giving you more time to detect bogus accounts and respond accordingly.
Require the referred user to create a revenue generating transaction before you give out any referral rewards (I know that might not be a shift you can make) - possibly in turn increasing the reward to account for the inconvenience to the referrer (you should be saving money through decreased fraud so not a hard sell).
Machine learning. Ongoing observations and tuning with your fraud detection. The more data you have the better you will be able to identify these cases. (IP addresses as you mention.) Shipping / billing info even more telling if it applies - beware adjacent PO boxes.
Add a CAPTCHA test to the confirmation page. I would be wondering if your CAPTCHA is sturdy enough if it is getting bypassed somehow. You might consider using the (hateful) reCaptcha which seems popular. A CAPTCHA on the confirmation page would reduce the risk that a 'bot is submitting the confirmation page. In other words, it would implement the idea of client interaction with the site after registration. A similar method would be to ask for the registrant's password.
I'm a bit of a newb and have never integrated paypal into a website before so I apologise for my lack of knowledge.
I'm trying to build a website which allows users to sign up and, assuming they get themselves paypal premier accounts (so they can receive payments by credit card) they will be able to receive payments from other users of my site.
So someone will sign up using their Paypal email address, and other users will then be able to send them money through my site. If they use one of my special services then I also want to be able to take a 1% fee of the money sent.
I'm using cakephp and I've searched and found a few cakephp related paypal components but to me it seems that these are aimed at people who want to just use their own paypal account to receive money. Like having a paypal checkout button. Whereas I want to be able to direct money into many different paypal accounts. Is this possible? And if so can any kind soul direct me to where I should be reading (pref something not too difficult - I'm a learner!).
Also as a side note, are there any special security issues I need to take care of when dealing with paypal, especially considering the particular nature of what I want to achieve? How easy would it be for a bad person to alter someones paypal email to direct funds to themselves?
many thanks in advance
Dave
A few years ago I did a similar thing, although the specific code is languishing on an old computer somewhere... Anyway, the way I did it was to use a combination of IPN and Paypal Mass Payments. Any payments have to run through your own PP account first and foremost, at which point on a successful payment IPN calls a script to run Mass Payments and send the money to the intended target(s).
It's a bit fiddly, and I seem to remember (at least when I did it) there were some odd bugs in IPN, but this should do it for you.
HOpe this helps a bit!
I am developing a website in PHP that accepts PayPal payments. It uses the IPN from PayPal and has a custom payment template etc etc. It all works great through the Sandbox server but when it comes to showing my client, I don't want to have to tell them to login to/create a Sandbox account, create a buyer account and make a payment - he hasn't got time for that and probably won't be able to do it.
Therefore, my question is - is there any simple way that I can show my client the PayPal integration in "test mode" without him using the sandbox? I realise that I can set the transaction value to 0.01 and just test on the live PayPal server but that isn't an ideal solution.
Cheers!
Edit: Just to better explain what I mean, this is what my client sees when he first goes to checkout;
alt text http://img3.imageshack.us/img3/2545/67913734.png
As you can see, he has to login to his Sandbox account before then purchasing the item using the buyer email that he sets up. It's just confusing and totally non user-friendly.
Unfortunately there isn't a way around this problem via paypal. Their sandbox will always require you to be logged in to actually demo.
Here are the solutions I have taken especially with remote clients.
Use Skype or similar service so I can share my screen as I demo how it works. This solution seems to work fairly well, and eliminates the need for them to take the extra steps required.
When working on something I want to quick demo for a client and get their take, I have started using http://www.jingproject.com/ It allows me to make a quick video of the process. It uploads it to their server and provides a url I can send the client to watch what I did.
Wish I could provide a more elegant solution.
What I'd do is integrate with the actual PayPal live site and use real money. The great thing is you can refund the transaction (including the fees) so nobody pays anything. I believe the refund timeframe is 30 days, but there's no reason to wait too long and risk it. The added advantage is that you get to prove to your client that the PayPal integration really works.
If there's a concern with littering the seller account with test transactions and refunds then go ahead and set up a separate seller account. It's quick to set up as long as you don't expect your test account to be receiving thousands of dollars.