I would like to support payments in my web application which acts as proxy between group of customers and merchant. I'm still trying to research this, but I'm new to subject and a little confused. Maybe someone could point me to good direction.
Is below scenario possible with paypal services (or other similiar sites)?
Customer creates account and my application stores his billing data
(credit card number) in 3rd party service, so I don't need PCI
compliance certificate
Customer A, B and C are creating common
group order from one of registered merchants. For example there are
3 products in this global order.
After some time one of customers
accepts group order and application create 3 payments to merchant
without needing confirmation from all customers
Those orders will be daily and payment will be delayed so that's why I don't want confirmation from users.
I was reading on Paypal site about Adaptive Payments, but there is step "Redirect the Customer to PayPal for Authorization", so I assume it's not for me, because it needs confirmation.
https://developer.paypal.com/docs/classic/adaptive-payments/ht_ap-basicChainedPayment-curl-etc/
I'm from Poland so Paypal Direct Credit Card Payments are not available for me.
https://developer.paypal.com/webapps/developer/docs/integration/direct/rest_api_payment_country_currency_support/#direct-credit-card-payments
I found REST operation - store a credit card so maybe one thing is easy :)
https://developer.paypal.com/docs/api/#store-a-credit-card
Let me see if I can answer your questions (I'm with PayPal / Braintree), and I'm perfectly fine with you asking it here.
The short answer to your question is that yes, this is absolutely possible with PayPal services. Let's break down each part with some options:
Storing billing data
It looks like you already found the answer here - you can absolutely use the vault for storing that information (https://developer.paypal.com/webapps/developer/docs/integration/direct/rest-vault-overview/).
Creating an order for later capturing & Capturing the payment
What I would look into here (to see if that works for your needs) is the auth-capture mechanism (auth: https://developer.paypal.com/webapps/developer/docs/api/#authorizations and capture: https://developer.paypal.com/webapps/developer/docs/api/#captures). Here's how it basically works:
- You use authorize to hold funds in the buyer's account for a period of time.
- From the auth you will get a key back that will allow you to reference that authorization in the capture step
- When you are ready to capture, you simply use the capture endpoint with that key, and you capture those funds.
There's also on other mechanism which you might want to check out - the orders endpoint adds more of a flow on top of auth / capture to allow you to have auth / capture more bound to a order processing - you can check out more on that here: https://devblog.paypal.com/rest-orders-api/
A few other notes. There are a whole series of products in the classic suite to also do 2) and 3). One of the best resources I like in the classic docs is the use case page at https://developer.paypal.com/webapps/developer/docs/classic/use-cases/ - it tends to help guide you based on real world scenarios.
I hope that all helps, and I'd be happy to follow up with more specifics if there is something that I missed from your scenario.
Jonathan LeBlanc (#jcleblanc)
Related
I am starting a business and I would like to offer Paypal as a payment option, but for my business it is essential to be able to block an amount of money, just like a car rental or a hotel does on a credit card. Would it be possible to block an amount from my users PayPal account and release it or book it for good later?
My business is of course an online service, and I want to do this pragmatically in a Spring based application.
I think what you are looking for is Authorization and capture.
I haven't used that feature from Paypal, but have used it elsewhere. What you are looking for is usually called card authorization, preauthorization, or preauth.
Yes it's possible
PayPal's REST API offer 3 primary ways to ensure you paid for product/services that you give to your customers
sale. Makes an immediate payment so you get paid immediately
authorize. Authorizes a payment for capture later.(this is what you see in a car rental or hotel)
https://developer.paypal.com/docs/integration/direct/payments/authorize-and-capture-payments/
order. Creates an order. - which gives you the flexibility to
multiple to do multiple authorizations and captures (these are for
complex use cases such as when you buy a computer from Dell you would
be authorized for the desktop, monitor, keyboard at different points
of time based on availability and then the funds captured when they
are shipped)
I'm new to PayPal and overwhelmed by all the possible approaches for integrating with PayPal.
As a start I want to implement one single subscription with monthly recurring payment. When the user returns to the site after fulfilling the payment, he/she will instantly be upgraded to "premium" member (digital product only - no shipping involved).
The first alternative I've looked into is the Express Checkout API, which looks ok, but is there any simpler way to do it?
Can I for example create a standard button (JS button or the form based), but still be able to verify the payment details when the user returns, using either the REST API, IPN or something else?
Any hints on best practices are appreciated.
Yes, there are entirely too many ways to solve this problem by now.
You can probably satisfy your requirements via buttons (aka Standard), Express Checkout (aka Pro) style APIs, or RESTful APIs, but there are a few gotchas to know:
First, PayPal has several products to do recurring payments; these products have functional differences and are tied to different integration styles. So (for example) PayPal's product called "subscriptions" (tied to Website Standard aka buttons) has different (and generally less flexible) capabilities than "recurring payments" (tied to Express Checkout) which in turn differs from "billing agreements" (tied to REST APIs, although the term "billing agreements" is also used in the express checkout recurring payments product). Oh, and there's another similar product tied to the Adaptive Payments suite of APIs.
Confused yet? Sorry. But it is important to determine whether the specific product you want to use will satisfy your requirements first before you do any integration, or you might end up redoing that integration work later (and potentially have to migrate customers, if you have already opened your business) in order to get access to specific features of another product later on. E.g., the subscriptions product has very limited ability for sellers to modify the subscriptions after they are set up. If that is OK, then great, use it -- it's simple to integrate. If I can oversimplify a bit: the Standard subscriptions product is the oldest and most limited; the Pro recurring payments is more flexible and mature; the REST billing agreement product is the newest, very flexible, but not yet as widely used; it may lack a feature you need today, but is the most likely to be continually improved going forward. I would not personally recommend the Adaptive product, although it also has its benefits.
Now, to your integration question: fortunately all these PayPal products can use IPNs. Unfortunately, IPNs are not instant. They generally arrive quickly (1-2 seconds) but delays can happen and it is quite awkward to be unable to process the customer. I would use IPNs only when shipping physical goods, not for immediate access to digital goods or in other cases where customers are waiting for a page from you. Fortunately, each of the other methods has a way to instantly determine the success of a PayPal action without waiting for an IPN:
Website Standard Payments will include GET or POST variables when it posts the user back to your site that will tell you about the outcome. If you use the Payment Data Transfer feature, these variables will include signature information so that you can post them back to PayPal & PayPal will verify their validity (so that a would-be thief could not fool you by engineering a post that looks like a PayPal success redirect).
The two API-based methods are even easier: the APIs themselves return all the information you need in the API response. So wherever in your code you make the call to create the subscription/agreement, if you get back a success then do your work to make your user premium.
There is the odd case of a user successfully paying and then getting "lost", as it were, e.g. the redirect failing/browser closing before they return to your site, or your site choking while trying to turn on the user. For this reason many people advise using IPNs, which PayPal will attempt to redeliver until you verify them back to PayPal. Not a bad idea, depending.
And of course you can call search & get details type APIs to get information about your transactions & agreements at PayPal -- although again, you will need to integrate with the right API that matches the product you are integrated with (e.g. Standard-based subscriptions won't show up if you ask the REST interface for billing agreements).
Hope this helps.
I have looked around SO for this but I can't seem to find anything like it.
On my service, I wish to charge on a per-month basis depending on how many users my clients have.
So this question is split up into two parts.
What I want to know is it possible for a client to use their own paypal account (without entering any CC details) with conjunction with CreateRecurringPaymentsProfile via the NVP, I have looked through the documentation and can not discern anything. So clearly it is not possible to do it via NPV - From what I've seen so far.
i. If I do an Express-Checkout Subscription, I can do 20% change on total amount every 180 days (I DO NOT want to do this) - I want to be able to get the Profile via the IPN and then modify the monthly amount on as-need basis
ii. There was some mention of Referenced Transactions, but the Documentation is very confusing.
So say there is a way to create a recurring payment subscription via a PayPal Account on the PayPal website, next step is to be able to update the Subscription via UpdateRecurringPaymentsProfile NVP command.
While I am happy to pass on CC details (which already works great), I am just wondering if it is indeed possible create a button, which would create a Subscription - once on success an IPN request is sent back with the ProfileID which I can modify the Billing Amount by NVP.
So TL;DR;
The current flow I have
Register on our website
Enter CC Details
Backend submits the data to PayPal and if passed - continues on.
On any Account modifications, update Profile Monthly Amount Automatically.
The flow I want
Register on website
Click on an Authorize Button Redirected to PayPal
Login to their PayPal Account Create Recurring Profile.
On any Account modifications, update that Profile Monthly Amount Automatically.
edit to add - this is all working now, had to contact and harass PayPal directly for a lonngg time.
I'm a little confused because it sounds like you answered your own question, but then said that's not what you want..??
Express Checkout does exactly what you outlined at the end of your post, and it triggers an IPN just like any other PayPal transaction. You are indeed limited on how much you can adjust the amounts of profiles created with EC, though, just like you mentioned with the 20% every 180 days. If you create profiles with Payments Pro (DoDirectPayment or PayFlow) then you're not limited and you can adjust the amounts however much you need to whenever you need to.
Reference Transactions and Preapprovals may be something to look into as well. I actually wrote an article about what they are and how they differ from each other awhile back that you might be interested in.
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.
I.e. user clicks buy, I authorize their card and wait 2 weeks and see if enough users have pre ordered a given product before charging them and shipping.
I'd like the following -
To avoid pci compliance I'd prefer to whisk users off to paypal for getting c.c. details.
progmatically reauthorizing any preorders and capturing funds is fine after 2 weeks. But for my prototype doing this via the paypal account dashboard is fine.
my app being notified when a user successfully preorders (ie. there card is authorized by paypal) in order to update my "preorder" counter on the site.
For my prototype I want to avoid as much coding on this so offloading as much as possible to paypal, even if it means I have to manually handle reauthorizations and payment captures is actually better in the short term.
Can paypal uk provide this functionality and if so which business solution is this? standard or pro?
You should be able to do this with standard; However considering that you eventually would want a "tighter" integration with your back-end systems and, it might be a good idea to start with pro itself.