Instant Payment Notification script receives among other parameters the following one:
payer_id = LPLWNMTBWMFAY
What is the meaning of that string?
It's an external unique identifier of a particular PayPal account. Since email addresses change over time. A PayerID is static.
As others have said, payer_id can be used to identify a Paypal account. HOWEVER! -- a single Paypal account can have several payer_ids associated with it, one for each credit card or funding source used by that account. Because of this, a given Paypal account does NOT map one-to-one to a single payer_id.
For example, if Bob buys from my website (through Paypal) using his Visa card, the transaction will include one payer_id. If Bob later buys using his Mastercard, the transaction will include a different payer_id.
I confirmed this in a phone call with Paypal Merchant Technical Solutions, in May of 2013, after running into problems with my order processing (due to an incorrect assumption I had made about payer_id being a reliable way to see if a customer already existed within my customer database).
NB: One ramification of this fact is that, when writing a Paypal IPN-processing script, payer_id should properly be stored only in the "orders" database table, and not stored in the "customers" table.
See also this answer: Is the paypal payer_id unique per credit card?
EDIT:
Apparently, each PayPal account does get just one payer_id. (That is not what I gleaned from my aforementioned phone call with Paypal Merchant Technical Solutions, but I can't find my notes on that call, so perhaps there was some confusion there.) Regardless, the payer_id does NOT uniquely identify a customer – as in a single, unique individual somewhere out there in the world. A customer could use multiple Paypal accounts, or could make some purchases as a "guest" using a different funding source than their primary Paypal account, and merchants would get different payer_ids for each one – even if the person's name, address, and all other identifying information were exact matches.
For these reasons, it is misleading for Paypal to call the payer_id variable a "Unique customer ID". Unfortunately, that description still persists in their documentation (scroll to the bottom of the "Buyer information variables" section):
https://developer.paypal.com/docs/classic/ipn/integration-guide/IPNandPDTVariables/#id091EB01I0Y4
It's just the id of the user who paid. You have to log it, to be able to give it to Paypal in case of conflict.
Payer_id is just paypal id of who pay the payment.
Email id is dynamic and always change, but payer_id is static.
Related
I want to verify that whether user has entered valid Paypal id or not. If not than user can't do registration. I've also visited this [1]: How can I verify a PayPal ID? question but it doesn't help me :(
You can't find a direct answer because "valid PayPal ID" doesn't have a single fixed meaning. You will need to be more specific as to what you are trying to discover. Then there may or may not be a way to accomplish what you want, since PayPal protects some aspects of their customers' account and identity information for their protection (and for business reasons).
A bit of background that may help you clarify your question, if not necessarily answer it:
Any email (or phone number) can be configured to receive PayPal payments, in many cases even if the email was not attached to a PayPal account at the time the payment was sent. However, not all PayPal products can function in this way (e.g. you cannot make API calls as an account that has not been set up and has not generated API credentials). Are you asking about receiving money, and if so with which product(s)?
Most people can pay through PayPal if sent to a PayPal page, whether they are accountholders or not (depending upon the PayPal product being used). In addition to guest payments and/or direct credit card payments through PayPal, people can set up PayPal accounts when they arrive and immediately pay with them. So collecting email first and refusing to go forward if there is no PayPal account attached to that email would loose you potential customers. It would also "let through" many customers who could not pay, such as people who know an email address but don't own the attached PayPal account. PayPal also intentionally declines to easily answer questions about whether an email has an associated PayPal account in order to make it harder for bad actors to accumulate lists of PayPal accounts (often with associated personal information) for spear phishing campaigns. There are some APIs that allow you to get limited information about a PayPal account but there are limits associated with these APIs; see e.g. GetVerifiedStatus documentation at:
https://developer.paypal.com/docs/classic/api/adaptive-accounts/GetVerifiedStatus_API_Operation/
Note also that Verified has a particular technical meaning in PayPal, and is NOT AT ALL THE SAME as "able to pay you."
If you want to know if someone can log into their PayPal account, and then use that PayPal account to get information about the user (as well as potentially pay you), that's easy: use Login with PayPal. That's what it's for. Naturally this requires the user to login and assent to your use of their information.
If you want to know if someone can take a particular action (e.g. make a payment), at this moment, the only way to be certain is to actionally request that action. You have options short of actually requesting money; if you want to ensure the user has funds and reserve them for you to collect shortly you can request an authorization rather than a sale. If you want to make sure the user can log in, has payment mechanisms and generally looks ready to pay you (but WITHOUT reserving and guaranteeing funds) you can request an Order.
Hopefully one of these things is what you are asking for?
If you have a PayPal AccountID (a PayPal-generated ID rather than an externally-generated identifier like email or phone number) you can pass it to certain APIs (such as the GetVerifiedStatus), so many of the same options above apply.
I was wondering, if you have coded a website which uses paypal payments as a payment method (the kind of payments where you get redirected to their site for payment, not web payment pro).
What kind of details can I store? Is it just their paypal email address that can get supplied to me or do other details regarding their paypal account also get sent to me via their API which can be stored on my site?
As already mentioned, you get the details of the transaction, so email address, name, delivery address and the contents of the shopping cart.
You can send custom parameters from your form though, such as phone number.
Paypal, by default doesn't ask users to provide a phone number and therefore usually doesn't send you one. However, it's often useful for retailers to have a customers phone number.
If your shopping cart is populated by your website and then customers are asked to complete a brief, name, phone number, email form before submitting to Paypals site you can send these extra form fields to Paypal and have them come back to your server for storage/checking.
However... I found it very erratic! There seemed to be a problem with my account when I did this and the PP technical team couldn't explain why it was only sometimes working! I gave up in the end and found a Payment gateway with credit card and Paypal integration, now all my payments come through the same channel and callback methods regardless of type.
http://www.securehosting.com I use now.
Mostly only the details pertaining to the transaction can be retrieved in the usual procedure, as it appears even when you see the transaction details in your paypal account when you receive payments. However, it would be helpful for you if you can provide more information on what you wish to look for.
I am trying to setup a chained payment app, and got the application approved. I was hoping that like in parallel payments, chained payments can have users with or without a registered paypal account. But with email accounts that are not registered, the api returns an error code 520009 saying the account 'email#domain.com' is restricted. I did see the following link having the same issue.
https://stackoverflow.com/a/10262241/903978
Though in their dev doc says anyone with an email can get paid/ notified (except the app owner who needs a verified account), It is throwing an error. I have posted a ticket to paypal/mts but have nt heard from them yet.
My app case is,
1. User gets paid eg $100. They are the primary recipient in chain.
2. application (secondary reciever) gets a cut of this payment. say $2.
Any one know if chained payments need primary as well as rest of the recipients to have valid paypal accounts and not just an email? Or is there something in the call that allows primary recipients with just an email address?
( I know that application owner needs a registered paypal account).
Thanks
Paypal/mts confirms that their documentation is incorrect. Chained payments require confirmed paypal accounts and not just an email ID. They said they will update the documentation.
I can confirm this also, Paypal Adaptive Payments with Chained Delayed payments does require the secondary receiver and the primary one to be verified, but there seems to be some confusion about 'confirmed' and 'verified'. When pressing PayPal on this we discovered the criteria differs (or so they told us at Eco Market) and that users sometimes have to have confirmed their email address (simply clicking the verification email they get sent), but sometimes also have to go a step further and verify their account (going through the other steps like bank account confirm). They told us is varies based on country sometimes but for security reasons didn't tell us much more on how they do this (not overly helpful).
What we do to handle this is catch the error and as a marketplace we automatically contact the customer/seller to inform them the order cannot be processed due to the sellers account not being verified.
Going a step further, you could also validate sellers (again in a marketplace model) accounts by using the exact same API to take a small payment from them (which could be refunded using the API), which would allow you to validate sellers to make sure that they had a verified account before signing up.
Hope it helps if anyone else has any experiences of this and how they handle it I'd love to hear.
Jason Dainter
Eco Market
In my experience, in adaptive payments, (in particular chained payments) you need this environment:
a) the app holder/developer must have a registered and verified paypal business account (the premium account is ok too but not the personal)
b) the recipients must have a business account
if the amount doesn't exceed the limits it is ok if it is not verified too but if the amount exceeds the limit you'll have a problem in the chain.
c) the sender must have a paypal account, a simple personal account will fit.
Sometimes (rarely) happens that one payment fails due to restrictions on the sender email. The most frequent case I saw this happens was when the sender made a preapproval with one e-mail and then, before the preapproval was payed, he/she changed the e-mail in his/her paypal account. Silly but paypal has no control on this environment.
Hope this is helpful for you.
Cheers, Fil.
Genoa, Italy
I'm changing my online store right now. I decided to remove accounts altogether... so that the users can go straight to paypal express checkout and just pay.
I'm doing the paypal part first, then i redirect back to my site to let them fill in a shipping address, billing address, and then review the information before submitting the order.
So far i noticed that Paypal always sends back the same PayerID if you are logging into a paypal account. Also, if you don't log into a paypal account (and just punch in your credit card), it will return the same payerID for that credit card in the future.
Is it safe for me to keep track of shipping address in order to create an address book and link them to the payerID? That way, returning paypal customers will be able to select a saved address...
Does paypal recycle these IDs... or are they always going to be unique and there is no fear of me showing someone elses information to another customer...
Thanks.
No, PayerID's are unique to each account. They won't ever change for the same account.
I wanted to use Paypal's IPN service to verify payments for a recurring subscription charge for my website. How do you tie the IPN confirmations to a user in your site?
The IPN confirmation message has a name, email, paypal ID, recurring payment ID, but it seems to not give a unique identifier since I don't know where the paypal ID or recurring payment id comes from and it may not be trivial to uniquely match up the name/email that a user has on their paypal account (or entered there) with the name/email I have for them on my site (there may be many John Smith's and the person may choose to use a different email.)
1) When I send the initial payment request to Paypal, I can attach a unique UUID in the URL I ask them to send back to me, so if I save that unique ID for that user I can match that payment confirmation to the user who initiated it. Am I making that harder than it is? Is there an easier way?
2) Also, for a recurring/subscription charge, does paypal always use the URL I specified with the initial payment initiation? Does anyone have practical experience using the recurring Paypal payments with IPN's, does it reuse that unique URL? Or do I have to associate the Paypal ID's with the user after the first recurring payment is received?
Attaching unique data to the payment request is pretty much the accepted way to do it.
I don't have any experience with recurring charges.
I recently also set up some reoccurring payments with Paypal.
I actually wanted people to register as members after paying for the subscription, if they wanted to. As having to sign up as a member could add some friction to the sale process. So I don't send any user info along with the Subscribe button.
What my IPN script does is generate a unique activation code tied to the Paypal subscriptionID in the Activations table, then it sends this code to whoever paid for the subscription, with instructions on how to activate.
At the point of activation, you need to register or login. At this point the userID is added to the relevant row in the Activations table.
When the EndOfTerm IPN notification comes in the IPN script looks up the userID from the Activations table based on the SubscriberID given in the IPN. Then I can do whatever I need to do to that user to disable their subscription.
At all time the URL of the IPN script remains the same.
1) You can send an 'item_number' parameter with the initial subscription setup, which will get passed back to you. I'd suggest embedding an identification token in it.
2) If you mean the 'return' parameter, no, that's for sending the user to at the conclusion of the subscription setup. The renewal is automatic and doesn't 'ping' that page.
1) You want to be using the item_number parameter. Set this in your HTML form shown to the customer, and it will be returned to you by the paypal IPN, so you can put a database row ID in here, and use it to match up to the right person later.