How to know when a transaction completes with Paypal? - paypal

I'm currently using Stripe Connect to allow sellers on my website to sell products to other users. I don't want to be a man in the middle and hold the money and then pass it along for legal reasons, so stripe connect works quite well for me, whilst still allowing me to know when a charge went through fully or was refunded, etc.
I'd like now to offer sellers in my marketplace the option to get paid by Paypal. This could be as simple as storing the seller's Paypal email and rendering the PayPal button on their shop, however, it seems now I wouldn't be able to track if a buyer actually finalized a purchase or abandoned the sale. I need this info for various reasons.
My question is how can I do this with PayPal?

All current PayPal checkout integrations have a "Capture" step, so you can know if a payment was successfully captured or not. Since you want to track this information on a server, you should use a server-side integration.
Implement two routes, one for 'Set Up Transaction' and one for 'Capture Transaction', documented here.
The best front end to use for approval is: https://developer.paypal.com/demo/checkout/#/pattern/server , paired with the above two routes you created.
Oh and since you'll be sending the payment to an account other than your own, specify this in a payee object when you set up the transaction.

Related

Using Paypal (or alternative) so my customers can sell items directly

I've been searching Paypal's products and docs and I can't seen to confirm or deny if Paypal is a solution for what I need, so wanted to ask the community.
I run a web platform for creators to spin up websites. One common request is to create a page for them to sell their merch. I don't want to re-create Shopify/etc.. so have been telling them to go use that and link to their store from their website. But I'm wondering if there's an easy way to give them a very basic store experience using standard Paypal Buy Buttons.
My ideal approach:
Create a ShopItems model and users add items with price, description, shipping cost.
User adds their Paypal merchant ID
I generate a Buy with Paypal button that simply sends info to Paypal about the product being sold, how much to charge, etc..
I dont need any shopping cart functionality, and I dont want to have anything to do with the payment. I just want the end customer to feel like they're purchasing something (not sending someone $ via venmo), and have a place to add their shipping info, etc..
Currently, I see how a user can create accounts in their paypal account and then they're given a specific button for that item, but I'm trying to make this a little simpler where the user creates the product in my system and I just use Paypal for invoice/payment.
Would love any thoughts / ideas.
Integrate a version of PayPal Checkout: https://developer.paypal.com/docs/checkout/
Some sample demo code here: https://developer.paypal.com/demo/checkout/#/pattern/client (use the server version if you need robust payment completion notification -- this requires implementing two routes on your server, one for 'Set Up Transaction' and one for 'Capture Transaction', documented here: https://developer.paypal.com/docs/checkout/reference/server-integration/ )
If you know the merchant ID you're processing transactions for, this can be specified when loading the SDK: https://developer.paypal.com/docs/checkout/reference/customize-sdk/#merchant-id
Whether or not you specify a merchant ID on the SDK line, that same or some other identifier needs to be specified in the purchase_units payee object when setting up the transaction: https://developer.paypal.com/docs/checkout/integration-features/custom-payee/

Best practice for integrating a single PayPal subscription?

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.

How to accept subscription payments for services on my website that would go to multiple users

I am building an application that has two types of users: owners and buyers.
When a user signs up for a payment subscription to the services offered on the website, the system checks to which owner those selected services belong to and should then make that subscription payment go to that owner. So basically, users have no idea that payments go to multiple people. As far as they are concerned, they are just selecting certain services on our website and signing up for a monthly recurring subscription payment. The system then decides where that subscription money should go.
So, how can I do this? What possible systems can I use? I have looked into two: PayPal and Stripe. I can see how I might be able to use them for this if I get really creative, however I just wanted to ask you guys to see if any one has experience in doing something like this and what is a good way to do this.
Thank you.
Here're description about PayPal Adaptive Payment, you need setup preapproval and Chained Payment .
In this scenario, you act as Primary Receiver. You can setup the payment that Primary Receiver keep certain percentage amount ($10 in in 2nd picture), or distribute all payment to multiple receivers (service providers). It's up to your business logic.

Paypal vault for recurring payments

I'm going to offer my customers a selection of subscriptions to digital content. I want the customer to be able to add or delete subscriptions later, with as little hassle as possible.
It seems that if I use Paypal vault, I can collect the card information on the same subscriptions screen without multiple redirects and later change the monthly total without another checkout process or even customer sending approval to Paypal!
Does Paypal allow this? It seems too easy and also too permissive. Also, do I need to worry about PCI compliance?
Does anyone know a better way to do this (with or without Paypal)? I don't know how to use paypal recurring payments without a lengthy checkout if they ever change their subscriptions. Google wallet does not have subscription cancellation in their API! Several other alternatives only allow preset subscription amounts.
The CSC/CVV is missing from the examples here: https://developer.paypal.com/docs/integration/direct/store-a-credit-card/ which makes me think you cannot use the card at will. The customer is probably going to be asked for authorisation.
Normally your online payment provider needs to support recurring payments (installments, subscriptions). PayPal does, there's a specific API:
https://developer.paypal.com/docs/classic/paypal-payments-standard/integration-guide/installment_buttons/
For the customer it's one-off, then the card is billed, say, monthly.

Applying for PayPal adaptive payments, filling the form

So the idea is simple, the product is sort of a marketplace.
Main Flow
Sellers put stuff for sale
Buyers place order requests (application created preapproval on PP)
Seller approves order request (transaction happens and application receives the money)
Seller fulfils order request
Buyer approves (money released to seller, a % cut is taken by the app)
Buyer complains within 48 hours (refund or a dispute which can end in refund or no refund)
Pretty much technically we have it covered by PayPal's API, the problem is filling out the form on apps.paypal.com.
So, the questions I have are for the following sections of the form.
Services used by app
Adaptive Accounts
What are adaprive accounts? Is this for the app, sellers, or buyers?
3rd Party Permissions -
Request users grant you permission to make API calls on their behalf.
Are these permissions for the app? Or for some 3rd party apps, running under our app?
If it's for the main app, why's it called 3rd party?
Testing Information
How thorough and detailed does it need to be?
From the perspective of seller, buyer, or both?
How can I give them scenarios when we have different gateway now, and hence different workflow than what we want to achieve with PayPal? Or do I have to give them the staging site, after we've done the sandbox PayPal implementation?
Do they want staging or do they want to make purchases on production? Staging might be off here and there.
Any other advice
If you've been through the process yourself, please share your experiences, highs and lows.
Here are good instructions on filling out the paypal form and getting approved to use adaptive payments: http://www.chainedpayments.com/EZChain/SubmitAppToPayPal.html