I am using paypal to handle subscriptions to my website and am concerned because PayPal emails users each month when their payment is sent. I realize this is very transparent but I see it as detrimental to my business. Other subscription services I purchase don't send me an email each month reminding me that I am paying them and how to cancel. I'm not trying to hide the fact that I am charging my users but I also don't want paypal activelty reminding them that they are paying money and giving them a link to cancel their accounts.
Does anyone know how to stop automatic emails from being sent from the merchant end or can it only be done by each individual user?
If it can't be done does anyone know of other services I can use to run my subscription billing that give me that control? Thank you!
I currently manage 3,000+ subscriptions via PayPal and have used PayPal for subscriptions for three years. You are correct, this is for transparency. I've never seen the option to disable this, and I doubt PayPal would ever offer it. You'll learn that PayPal is much more interested in catering to buyers than sellers. They keep the buyer happy to the detriment of the seller. For example, PayPal recently reversed 7 months of subscription payments because the buyer called into PayPal and claimed it was unauthorized. We keep plenty of records to prove this isn't true, but PayPal consistently rules in the buyer's favor regardless (we have, yet, in three years to "win" a claim against us). There is very little protection for sellers of digital goods.
Depending on how you decide to run your business, the payment reminders can be used to your advantage. I often receive emails from buyers who claim that they've canceled, yet, we've charged them again, or, they claim they've been charged for months and didn't know it. Thanks to the emails from PayPal, I know, without a doubt, that they were notified each time they were charged, and that if they had actually cancelled, they wouldn't have been charged.
There are many other payment processing services like PayPal that are more "hands-off", but their rates are equal or greater. The only one I've found that's comparable is Payza. Again, there are others, but you have to weigh the benefit of full control (including being the help desk for payment issues), and higher rate, versus PayPal's practices.
Related
Is there a way to programmatically deny (or "unclaim") a direct PayPal payment?
Let's say someone sends ten payments of $1 each to a corporate account. This is already an accounting headache, but if you think you can refund them as they never happened, there's a non-refundable part of a commission. Ten payments will cost you $3 USD or about as much in other currencies no matter what. This is infinitesimal amount business-wise, but related accounting expenses can be ten or even hundred times as much depending on which country a business in.
So best case would be to reject such payments before they even happen.
I read about IPN notifications, but nowhere there's mentioned a possibility to respond to a specific payment event with some sort of refusal. Yet I saw sometimes my own payments made by using standard "Pay Now" buttons to some merchants were tagged as Unclaimed until a manual intervention from the merchant. Therefore there must a be a way to do this.
My use case: buyer buys service from seller, our app facilitates and guaranties the transaction. It should work in the way that buyer sends the money to us, we check if buyer received the service, in that case we send the money to seller. Otherwise we refund the buyer. Important is to have 2 payments solutions for the buyer: paypal account and card payment without account. The whole use case is international.
I'm testing this in sandbox environment.
Possible solutions:
Adaptive payments - Delayed chained payments:
Works fine. Disadvantage is that the seller must grant us permission so that the refund works. The problem here is that the permission api is under maintenance, so i am waiting for all the changes https://developer.paypal.com/docs/classic/permissions-service/integration-guide/PermissionsWhatsNew/ . Is this big deal?
Express checkout Authorize/Capture + Mass Pay:
Works OK. Advantage here is that in case of refund (void after authorize) we don't have to pay the fee. Disadvantage here is that I'm not sure if authorize holds the funds, so that even buyer without account paying with card cannot touch the money and I can capture them in 3 days. Another issue is that when I authorize 40$ from PayPal account with 30$ balance, I capture the whole 40$. How come?
I have no previous experience with PayPal I now the app should work on international scale. Please if you have any tips, articles or practical experience with this use case share it!
EDIT:
Delayed Chained Payment is great. I solved the issue by making my application the secondary receiver and the seller primary one. Seller must grant a permision to my app in case of refunds, but there is no better way.
However, now the issue is that when buyer pays without account (Guest Payment - with card) all receivers must be Business or Premier account holders:
Each receiver of a guest payment must be a verified PayPal business or premier account holder.
Source: https://developer.paypal.com/docs/classic/api/adaptive-payments/Pay_API_Operation/
The issue is that in sanbox it works even if the primary receiver (seller) is NOT Business or Premiere account. What is wrong?
1) Do you have yourself set as the primary receiver? If so, I don't think you would need to have permissions granted unless you had already run ExecutePayment to push the money to the secondary receiver account. If you're refunding before that happens you shouldn't need permissions (though I haven't tested this specifically, so I could be wrong.)
2) Regarding the fee, if you refund a payment that went through Adaptive then PayPal would refund the fee back to you, so you're not really gaining anything here as far as that goes.
The authorizations can be tricky. I theory, the authorized funds should be guaranteed for 3 days, but you still capture within 30 days (or maybe 60) even though it may or may not have funds available at that point (it would simply succeed or fail).
You could run a Reauthorization after the first 3 days to get yourself an additional 3 days of guaranteed funds, but I don't think you can do that more than once.
Much of that depends on the card issuing banks, though. Even though PayPal's docs may specify certain things regarding how authorizations work, if the card issuing bank has different rules associated with their credit cards that could throw things off.
As for why a $40 auth would work when the PayPal balance is only $30, I think that may be because of secondary funding sources. If you have bank account and/or credit cards setup in the account, PayPal would assume it can pull from those sources when the time comes to capture if the PayPal funds alone don't cover it. Depending on your use-case this may or may not be ideal.
You are mixing multiple concepts with this question. There are different PayPal PAYMENT products (adaptive with chained payments vs express checkout) and then there is the question of authorizations vs immediate payments.
Agree with Andrew that fees in the refund case is not the right basis to choose a solution. Much more significant is what the sender & receivers will see in their accounts (payments to/from you, or from/to the other party?), simplicity/reliability of the overall system (can an error on your side cause failed or multiple payments?), liability, and even regulatory questions (e.g., are you acting as an escrow service?).
If PayPal gives you an auth from a PayPal buyer it means that PayPal guarantees (with certain very limited exceptions) that it will honor a capture of those funds within the specified time and amount limits (which can vary with the specific scenario). PayPal might make that guarantee based on the sender's balance, credit cards, bank accounts, or combination of factors. You as the recipient needn't care - that is between PayPal and the buyer. (And it's PayPal's limits/conditions which apply to that auth, NOT the conditions of the sender's underlying credit card/bank/etc; PayPal protects you from that complexity.)
In contrast if the auth is from a card network rather than a PayPal account (ie the user gives card info rather than using a PP account, whether or not PayPal is your payment processor), then that network specifies and controls the conditions of the auth.
PS: if you are waiting for Adaptive Payments changes, you may have a long wait. Release 89 was quite some time ago and PayPal's priorities are on the RESTful APIs, not Adaptive.
I am developing a website where the users can sell their products. Users can then also buy products on the site, obviously, lol. However the problem is that I am currently using Paypals Parallel Payments and it limits the number of items a user can buy to 6 different sellers at a time including the sites fee.
So I was thinking about switching to using PayPals Masspay API instead. It would work like this. The user buys as many products as they want up to the limit of 250 different users using eithier the Masspay api if acceptable for 1-to-1 payments or something else. Once the payment is completed to the sites paypal account, It will start a masspay api call to pay all the differn't users upto 250 users using the funds from the payment to the site once those are completed.
Also I am limited to paypal right now so I can't use any other payment services.
So is this ok to do or is this a bad way to do it maybe for some security reason I do not know about?
It seems like the only good option, on the plus side, it benefits from the lower fees that masspay offers vs the %2.9 + 0.30 Cents.
First, you'd have to get it approved by PayPal to enable MassPay for your account.
Then, you'd need to be careful about chargebacks and dealing with refunds. If somebody submits an order for $1k, for example, and you dispersed that money among 25 different people, and then the buyer submits a dispute with their credit card company to get that $1k back, you'd be stuck trying to collect all those pieces from all the people you distributed to.
I am using PayPal PreApproved payments for my crowd funding website, where project backers are only charged if the project is successfully backed.
I am worried that high rate of payments will fail when the PayPal API tries to collect the funds when a project is successful:
a backer might not have any funds in their PayPal account
a backer might close their account once the project is successful (to intentionally stop payment)
a backer might remove/cancel their preapproved payment
etc...
There are a number of ways that the payment could fail which would mean that the project owner would not get their funds.
Can anyone suggest a way of tightening or securing payments. Please note, that PayPal will only allow you to use PreApproved payments for crowdfunding. Please also note that project owners need to be able to receive the funds from my site. Sometimes, these funds can be as small as $10 or up to $10,000 so we need to use PayPal to pay them as there is not other method of getting the funds to the project owner
I've implemented Paypal Adaptive payments and used them for payments at http://www.wethetrees.com and we had the exact problems you are describing. The capture rate is almost random, we were down to 35% with one campaign and had to manually send all backers invoices.
When capturing we had backers with closed/unauthorized accounts, insufficient funds, unavailable payment methods etc. We switched to just doing direct capture for a while, which is great since we get 100% of all pledges, but Paypal closed our account without notice when one of our campaigns mentioned the word "Cuba".
The solution in the end was to scrap Paypal so now we're using Wepay and Dwolla, and we're considering Bitpay (Bitcoin) as well. Seems to like Paypal wants to kill crowdfunding or doesn't understand it. Anything less than a 90% capture rate is totally unacceptable and will cause projects to fail.
Preapproval isn't the only thing they'll allow you to use. That's just one part of the Adaptive Payments API, but you could go with a delayed chained payment, too.
This way your account can be treated sort of like an Escrow. You can use the Pay API to create payments in the system that are split between receivers accordingly. Only the primary receiver would get paid at first, though, and then you can call ExecutePayment to submit the secondary payments from the primary account within 90 days.
This way the primary account holds all of the funds so they're available to pay out when the goal is reached. If the goal is not reached the payments could be refunded.
I need to be able to initiate transactions between two unknown parties via Paypal, say donor and recipient, without ever having to be exposed to the money itself - is this possible?
Basically, I want a donor to be able to click the donate button, fill in the amount and then be passed to Paypal to verify their details. My site will also supply the recipients account details to Paypal so the money goes directly to them rather than to my Paypal account. Essentially I want to enable transactions without having any legal or tax responsibilities for the money.
This needs to happen for an unlimited number of donors and recipients.
Can I do this? Paypal haven't been very helpful at all.
I am sorry to hear that you feel PayPal hasn't been helpful at all, but there are many resources at your disposal. It sounds like you have just not been asking the right person, or asking the right questions. Customer service for large corporations are difficult to traverse, but there are many people at PayPal who would have been easily able to answer your questions.
I always say this, though i'm not sure how many times on this forum: It is possible to do whatever you want with PayPal. Give me your idea, I will give you the way. Whatever you want to do can be done with the right coding.
You can use Website Payments Standard (WPS), and you would only need your merchant's email address to create buttons that go to their account. (set the business variable)
You can also use third party API calls for Website Payments Pro (WPP) and Express Checkout (EC) to process direct credit card transactions as well as PayPal payments via API for your merchants. (set the subject variable to the seller you're submitting the API on behalf of)
As for not having any legal or tax responsibilities for offering the service of payment connectivity (marketplace functionality) between sellers and merchants: IMHO you are dreaming. However, you will want to contact your local legal and tax representative to ask what liability you have. Though this should go without saying; this is StackOverflow, where you should ask questions regarding programming, not tax and legal advice.
Your tax and legal concerns are separate concerns, irrelevant to the technical question of whether it is possible to do what you want with PayPal or not.