Paypal Merchant account for multiple websites - paypal

My client having single paypal merchant account. IPN Notify Url sets to one website. But we are using same account for two websites. The problem is after payment process completed, paypal redirects to IPN Notify Url. But, I want to redirect to My website. Means Paypal redirects to their respected websites without considering the IPN. Is it possible? If Yes please suggest me.
thanks in advance

I am in the middle of getting the exact same thing setup currently. PayPal calls this a "Parent/Child Account". Basically what happens is the following:
You setup 1 main account on PayPal which has your bank information stored
You setup a secondary account (with no bank account, however both are business accounts)
Call PayPal and inform them you want the secondary account linked to the main PayPal account so that they both share the same financial information (Parent/Child Accounts). They will make the change in their system so that both of the PayPal accounts look like 100% separate businesses with no information leaking from one to the other, it's as if neither of the two checkout pages know each other.
On the back-end, what happens is you get paid on the 2nd account and the money is transferred to the main account at the end of the day, which you can then transfer to your bank account.
I believe this is a U.S. only feature, however feel free to call them and ask for help in getting it setup. If they give you the run-around, telling you that this is impossible, tell them you need to speak to someone else. I was on the phone with 7, yes SEVEN, different people in one call, and I had to call back and went through 4, yes FOUR, for a total of ELEVEN people, before I finally got to the one person who set it up like I wanted it setup. It is possible. Be persistent and don't let them tell you it isn't (unless their reasoning is you not being in the US).
Good luck!

Related

Paypal Chained Payments - "The login information you entered belongs to the recipient of this transaction."

In testing my Chained-Payments application in the paypal sandbox account, I encountered an error
The login information you entered belongs to the recipient of this transaction. Please change your login information and try again.
Now, to me, this restriction on multi-recipient payments is silly. The account I tried to test with receives a commission fee on the transaction. So yes, that accounts $.50 commission would effectively be a discount on the purchase because it would leave the account and return.
Is there any way around this? I was wondering if a user was to use two different email addresses attached to the same account, would this be possible?
User#gmail can pay to bob#company & refer#company.
refer#company cannot pay to bob#company & refer#company
Can refer-alias#company pay to bob#company & refer#company if refer-alias and refer are both attached to the same account.
I'm several days from going live so can't test this myself yet, otherwise I would, and will, if I don't get a response, but it would be extraordinarily useful to know in advance.
Update: I did move to the Live environment last week and found out that no, there's no way to send money from an account that is also one of the receivers. Different email addresses don't enable this either.
While there's no reason I can think of that a user would want to do this when they're the sole receiver, there are reasons that you'd want to make a purchase through a system even if you are of the recipients.
Obviously, there's usually code work-arounds, but it's still a nuisance. What I did was put all my email-addresses in an array, and I run a search on the array
if (ArrayFind(RecipsArray,senderEmail)) {
disperse special way, excluding the conflicting address.
} else {
disperse normal way
}

PayPal - several API type "can it be done questions"

I have an app that is both Web and Mobile. I know what I am trying to do is a bit messy but I was hoping someone could help guide me through the options please. I have done some reading and check replies on Stackoverflow but I'm am getting confused.
The main criteria here is I do not want to have the users log in to PayPal every time, approve a transaction every time. So I guess part of the solution is to have them set up an Agreement to pay ?
I have a Business account.
a)
is it possible to transfer funds from a users bank account they have with paypal, to some other paypal account. In other words make a payment from their bank account to a specified paypal account they do not own (namely some merchant)
b)
is it possible to transfer funds from one paypal account to another. Lets say mine to someone else's.
c)
is it possible to transfer funds from one paypal account to another. Lets say someone else's to mine.
d)
is it possible to transfer funds from my paypal account to someone else's bank account.
e)
I guess PayPal IPN could be used for instant notification ?
All of the above needs to be done in the background without user involvement apart from them entering the amount, and say yes proceed. No passwords or bank account details to be entered etc.
I would preferably like to do the above on a web server rather than on a mobile device. So within server-side code.
thanks in advance
It is possible to do some of what you are asking using a Billing Agreement. In a BA, you agree that I can charge your Paypal account without a further login. It's a one-time setup.
You can use the MassPay API call to pay anyone. All you need is their email address. There is a fee to you to do this, tho.
You can make third party calls (where I make calls on your behalf) so it's theoretically possible for me to issue a MassPay on your behalf.
You cannot send money to a bank account (i.e. ACH-style). You can send it to their paypal and they can log in and move it from there.
All transactions will send an IPN if you have one specified.
Hope that helps

Paypal ExpressCheckout + chained Payment

I developed a Web Application that accepts payments via the ExpressCheckout API, for users to become a members.
Everything works fine.
I now want to extend my Web Application Services and offer my users with the possibility to buy items which are sold by third parties (my members).
The principle I would like to implement is quite simple: for each order, let the user pay for the item they choose and then transfer a part of the amount I received to the item provider, and keep some money for me. I would like to automate this process so that once I received the payment notification, I compute the amount of money to transfer to the item provider who might or not have a Paypal account (in other words, this means that I could maybe need to transfer the money to a bank account, using the IBAN/SWIFT data) and then proceed with the money transfer.
I tried to find a solution reading your documentation and came across the "chained payment" but the latter does not seem to be used within the ExpressCheckout workflow.
Also, since my implementation of the ExpressCheckout flow works, I would not like to have to find a totally different solution but rather extend it... if possible.
Could you please tell me which is the best solution for me?
In advance, many thanks for your help.
You could do 1 of 2 things. You could use Express Checkout with parallel payments. This means you could split the transaction up between different accounts at the time of purchase. The other option would be to just receive all of the funds into your account, and then when you are wanting to send money to the other accounts you could either use the Adaptive Payments (Pay) API or the MassPayments API to send money to the other accounts. Keep in mind you would have to send it to their PayPal accounts, you would not be able to send it directly to a bank account with either one of these API's.
I had the same issue and I got an answer from PayPal that it is not allowed to use Express Checkout to transfer money to your PayPal account and - at a later point in time - transfer the amount minus your service fee (which stays on your PayPal account) via Adapative Payments API to the seller's PayPal account. PayPal suggested to use Chained Payments API instead. All works fine in the sandbox, but once you need a Live APP ID from PayPal they will review your business case and deny it. At least that what happened to me.
I know that is old question, but anyway, I tried to find solution and was enable to perform the simillar thing like described in question. So, then I asked paypal about this, and they gave me advice to use SellerDetailsType Fields that 's called PayPalAccountID, description for this field is Unique identifier for the merchant. For parallel payments, this field is required and must contain the Payer Id or the email address of the merchant. It wasn't clear for me to use this field for solving my problem. Here is link https://developer.paypal.com/webapps/developer/docs/classic/api/merchant/SetExpressCheckout_API_Operation_SOAP/ I described field for soap request, for NVP it's called PAYMENTREQUEST_n_SELLERPAYPALACCOUNTID, but the idea is the same. I hope it will help someone.

How to protect against fraud?

I have a VoIP calling company for a Russian market with a Russian website where people can sign up for an account, buy credit and make calls. My service is not even popular and I have only ~100 customers. Recently, I had around 10 fraudulent users who used stolen credit/debit card or PayPal accounts to make payments. Even though my website is in Russian, I had fraudulent customers from Somalia who purchased $50 worth of credit with stolen information. Two days later after fraudulent user signed up & used up their credit, I received email from PayPal saying that those transactions were "unauthorized (transactions)." PayPal gave me 10 days to resolve this dispute and make refunds by talking to people whose financial information was compromised. After hours of arguing and debate, I had to make refund and accept the loss. But, is this how it works? What if I had 100 fraudulent customers who purchased $1000.00 worth of credit? How can I insure myself against this? Note that my service was in Russian, what if I had English website for everyone to sign up? How do you protect your service against such things?
Some of the measures I can think of are:
Customer must activate their account via verification email (Already implemented)
Accounts are by default aren't activated, I have to manually
activate them (Customers may not like this)
Calling the new customer at provided phone # to make sure if he
really signed up (I hate this one)
All of your advises and opinions are appreciated!
I worked at a similar company (no names) and the only thing we could do that actually solved the problem was to have the users sign up with a credit card, billing the minimum amount from their card while generating a code that was included in their statement (a'la "VoipMaster (4711)")
They then had to look up their credit card bill (many banks let you do it pretty much immediately online) and enter that code at our site. In other words, the user had to have access to the credit card bill to sign up, not just the credit card information.
I think that pretty much stopped fraud cold, but it's hard without marketing research to tell how many valid users didn't sign up because of it.
Its just the pitfall of accepting online payments. You do not lose $1000 worth of money when you have to refund though. Paypal should not charge you any fee's for reversing the money and therefore you have not lost anything apart from a small amount of time.
There are some things you could do to try and prevent this happening in the first place. The biggest thing would be to chose one or more vectors and then detect any changes on those vectors. A change would then need to have a secondary authorisation.
For example you could say that if you try and use a different paypal account to the last one you used, then you must go through confirmation stage.
Another one could be that if you purchase more than a certain limit then you go through the confirmation stage.
If your IP address changes you go through the confirmation stage (not so good, but its an idea nonetheless).
The confirmation process/stage could be anything you deem suitable to ensure to the best of your ability that they are legitimate. For example you may require email confirmation from them or require them to wait 24 hours for the credit to be given (provide a phone number they can call you on to fast track maybe).
Theres no sure fire way, but the harder you make it the less it will happen. Theres hundreds of things you could do based on the simple theory i posted above. Nevermind more complex things you could possible use. At $50 a time i would assume they are using your site as a test site to ensure the details all work ok, before going on to using them for larger payments elsewhere or transferring money to there own accounts. So if you make it harder for them to do that,, they will find somewhere else to test them.

Choosing the right Paypal system for processing registrations and subscriptions

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!