What does _xclick-merchant means in terms of PayPal? iTunes buttons use it, but if I try to substitute any other PayPal email in it'll just say that it doesn't even exist. Is there any documentation if I wanted to try to implement it myself?
_xclick-merchant means in paypal terms that which merchant id is registered with the api key provided by the paypal at the time of merchant account creation. Api key is unique for every merchant account and if you change with any other email it will not be found because paypal in his end checks for both api key and provided paypal email if matches payment screen appear other wise error which you are getting.you can get all your required information here
https://developer.paypal.com/
Related
We are developing a marketplace webapp which charges customers on behalf of sellers.
After reading through PayPal's API documentation, the only solution seems to be the Permissions service.
According to the documentation. After retrieving the access token and token secrete of a seller through the RequestPermissions call, we generated X-PAYPAL-AUTHORIZATION header to initiate an express checkout payment id. However, the payment id generated is associated with our PayPal account instead of the seller's, which is not the anticipated behavior.
Adding seller's email address in the SUBJECT field as noted in PayPal Name-Value Pair API Basics does work, but as we tested it, it has nothing to do with the access token and token secrete.
The problem with the SUBJECT field is that we cannot make sure the seller's email address with us is the one PayPal have on file.
The GetBasicPersonalData permission seems to be able to get a valid email address, but that needs to be pre-approved by PayPal. In fact, I have come across many websites that does not require this permission but able to initiate payment on behalf of other users. Is there a way to just get sellers' email or PayPal Id without GetBasicPersonalData permission? We don't actually need any other personal data except email or PayPal Id.
Is there a way in PayPal Classic API (PayPal Payments Standard with the BuyNow button form) where I can turn off the sending of the customer receipt email?
See, there's a bug currently on the PayPal website where it won't let you add another primary account. So, this means the CEO's name and primary email account are going out on every customer receipt. I called PayPal tech support and they said it was down for now, but after 3 days of reattempting to add a replacement primary account, the bug still is there. So, I thought I'd go another route -- not sending the receipt at all. Is that possible?
Unfortunately there is not a way you can turn of the email notifications that go out to the buyer.
I am about to set up an IPN script after users make a purchase from my site but I just had a thought, what if the email address they signed up to my site with differs from the email address they signed up to PayPal with?
i.e. they sign up to my site with forename.surname#domain.com but their PayPal account login is surname.forename#domain.com.
The PayPal IPN will send back surname.forename#domain.com and I have no way to identify who has just made that purchase.
I realise in this simple case it may be possible to find an email address similar to that in the database but in the real world people have crazy email addresses and that isn't always going to be possible.
Has anyone solved this problem before?
It may be best to use a different identifier such as an invoice number or pass a custom value to PayPal for the payment. PayPal will return this via IPN and can be used to link the payment to the customer's account on your website.
This way you pass a value to PayPal that is linked back to that customer's account regardless of their PayPal account details.
Hope this helps!
I suggest that you should force the customers log in before placing an order, then you can get the email they used in Paypal from the return value, and combine the two emails in some way or even just leave them.
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 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.