I need to implement a penalty system, where if a user does not do any job then he needs to pay some penalty. Which payment method should we use to get it collected automatically, without forcing them to pay. Can we use paypal,. Which paypal api will suit my requirement. I cannot ask user for their api credentials so is there any workaround so that I can charge them
This can be handled in a couple of different ways.
First, you can use Reference Transactions with Express Checkout and/or Payments Pro.
Alternatively, you could use the Adaptive Payments API to setup Preapproval Profiles for use with the Pay API.
Related
I wanted to ask if someone knows a possibility to pay make PayPal payments without user interaction. I am currently working on a Project, where we want to make PayPal Payments on demand without the user having to login to PayPal.
What I found was:
DoReference Transacations
Recurring Payments
The 2 Options would work for my purposes, since its OK if the user has to log in once. Since both of these methods are deprecated I wanted to know if there is another option.
At Cheddar we use the DoReferenceTransaction method with a "billing agreement" to enable transacting against a customer's paypal account repeatedly on any schedule for any amount. We have some documentation in our KB regarding how to create the billing agreement token via your app. Section 2.1 of that article would be relevant to anyone getting started with setting up a billing agreement for purposes of executing reference transactions. The rest of it is specific to Cheddar.
We, too, are aware that this method is officially deprecated. Our inquiries with PayPal suggest that it will be supported indefinitely. The new REST api does not support a modern equivalent. In other words, there's no new replacement for the DoReferenceTransaction method of Express Checkout or any alternative that enables autonomous recurring billing for variable transaction amounts on a custom schedule. If there was, we'd be using it. Practically speaking, there are countless implementations in the wild using reference transactions so I expect it would be impossible for PayPal to stop supporting it without an alternative (new) method.
FWIW, I recommend using a subscription management service provider like Cheddar. There are others that support recurring payments via PayPal account as well. Recurly comes to mind. Recurring billing and subscription management is complicated and it's made quite simple by these services. I recommend against using PayPal's native recurring payments as it is unnecessarily restrictive and once you start using it, you can't stop.
This is my first time using the PayPal API so go easy on me.
The case I am trying to handle is as follows:
My customers can purchase software licenses that can either be one time payments, or yearly payments.
They can multiple products to the cart, and each product can have either one of the pricing plans mentioned above.
If I understand correctly, "payments" in the API handle one time transactions, and "billing plans" are used for recurring payments.
Is it possible to processes both in one call to the API? If not, is there a different way to achieve this?
Any suggestions would be greatly appreciated! TIA!
Not one API call, but you can do it in one checkout flow with multiple API calls.
For PayPal wallet payments (logging in to PayPal and paying) I would recommend using Express Checkout w/ Recurring Payments.
With that you would be using SetExpressCheckout, GetExpressCheckoutDetails, and then either DoExpressCheckoutPayment, CreateRecurringPaymentsProfile, or a combination of both of those depending on the products in the card and whether they need one-time payment or recurring.
The CRPP call will allow you to setup a recurring profile and include an "initial payment" which would be charged when the profile is created. This could be used as the one time payment if you want, and then you wouldn't need the DECP call.
Alternatively, you could use DECP to process the one time payment and then follow that up with CRPP to create the profile. There are advantages and disadvantages to the different methods depending on your business needs.
For setting up profiles with direct credit cards you'll need PayPal Payments Pro. In this case you would either use the same CRPP call mentioned above, but it would be used by itself and include the credit card details. Or, depending on the version of Pro they put you on, which depends on the version of PayPal account you have, you might end up using PayFlow instead.
If you're working with PHP this PayPal PHP SDK will make all of those API calls very quick and easy for you.
I know that's a pretty broad answer, but that's because it's a pretty broad question. :)
I am setting up a monthly automated backend process that will transfer money from a central account to thousands of PayPal accounts. The transactions will vary anywhere from $50 to $10,000. The key requirements here are:
Receiver must pay the fees
No user input required. By this, I mean this process should run without any kind of action on my end (I've noticed that some PayPal integrations require a redirect, approval on the sender side, etc.).
Here are the possible ways I see that you can send money using PayPal:
Mass Pay
Uses classic SOAP APIs. Sender must pay fee, so not an option
Payouts API
Uses new REST APIs. Sender must pay fee, so not an option
AdaptivePayments
Uses classic SOAP API. However, you can force the receiver to pay the fees.
Rest API Payments
See https://developer.paypal.com/docs/rest/api/payments/#payment
Uses REST API, which is good.
Can you force the receiver to pay the fee?
Can this be used without a web browser?
So, it seems like AdaptivePayments or REST API Payments are the only options that could work (there could be more, though). I'd obviously prefer to use the more modern REST API, especially for a new project, but if the functionality that I want to achieve is not possible, then I supposed I will have to use the classic Adaptive Payments option. Any insight would be greatly appreciated.
The only option that allows you to force the receiver to pay the fee is Adaptive Chained Payments, but that would not work for your situation. The type of payment you would be sending would be an Implicit Simple payment, which only allows the sender to pay the fee.
So, your best option would be to use the MassPay API, primarily because of the fee. For US payments, the fee is 2%, capped at $1 which is a significant saving over sending a regular payment at 2.9% + $0.30.
If the fee is that important, you could program it to reduce the amount you send by 2% or $1, whichever is higher.
I need a help regarding paypal.
That is. Once I have logged in with paypal and made payment, Then for another payment no login will be asked, Direct payment will be done using paypal. Please comment your suggestions. Thanks in Advance.
You have a couple of options for this.
First, you could take a look at Preapproval, which is part of the Adaptive Payments platform. It allows users to create a Preapproval profile that your application can then use to trigger payments at any time without further approval as long as the payment fits within the guidelines of the preapproval profile.
Another option would be to look into Express Checkout with Reference Transactions. This would give you a little bit more flexibility and would be more in line what you're asking for, I think. Users would agree during their first payment with you to allow you to auto-charge this same account in the future. Then you would use DoReferenceTransaction to trigger future payments based on that "billing agreement" which is what it would be called that way.
I would recommend going with Express Checkout, and you might want to look at Digital Goods, too, which just adds some more functionality with quicker PayPal checkout in various ways.
It's all handled through a few simple API calls, so don't let all the info scare you.
My PHP class library for PayPal will make all of the API calls very simple for you regardless of which method you choose. Again, though, I'd recommend Express Checkout.
I am a bit confused about the REST and Classic API and which one serves my business case best. My requirement is to be able to send money to one or many customers by just using their email addresses. No need to receive Payments, just to send...Additionally i do not want approvals, i just want to send the payment and the payment to be executed, since i am performing a receiver email validation via the getVerifiedStatus call.
I know there is the Mass Payment option and the Adaptive Payments option however for consistency i need to use only one API. Which API covers my needs?
This isn't yet covered well by PayPal's new REST APIs. But the MassPay api (with # of payments = a set, or just 1) can definitely do what you want. Check PayPal's handling of exception cases that is built into the MassPay product to ensure it meets your requirements; if it does then this is a great answer. The adaptive payments pay() can also definitely work; to determine which works for you will require evaluating the underlying PayPal products moreso than the APIs. They do NOT work entirely the same way....
I would stick to classic API for now as it's much more mature than the REST API is. For your situation I'd go with Adaptive Payments, specifically the Pay API. Since you are the app owner and the payer, you can simply trigger payments however you want to anybody you need.