Paypal vault for recurring payments - paypal

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.

Related

Pay as you go with Paypal

I want to implement a pay as you go with Paypal, as I read the subscriptions API we need to create a plan and product, and as I understand it, it works based on the regular payments which obviously we don't want that we want if the user's budget is below a certain amount we recharge the user by a fixed amount again, can anybody guide me how to approach and implement pay as go using Paypal?
You are correct, subscriptions bill on a regular schedule whereas what you are describing is the ability to bill an arbitrary amount at any time.
That feature is called "reference transactions", or sometimes "billing agreements". It is not enabled for PayPal business accounts by default. To request the feature, the owner of the PayPal account should contact PayPal's general business support (note: not technical support) and explain the business need for this reference transactions feature.
If it's approved for the account, PayPal can then guide you on which API integration to use; potentially something like the newest v2/vault.

PayPal Recurring payments/subscription

I need to create a subscriptions system in my app, where users can subscribe to a certain package and they must be billed monthly.
Moreover, I need to charge their credit card automatically, and without requiring them to have a PayPal account.
I read about https://cms.paypal.com/us/cgi-bin/?cmd=_render-content&content_ID=merchant/erp_overview, but is seems it's not available anymore as I click on sign up and it gives me an error ("Sorry, this feature is not available at this time.").
Then I've read about PayPal Standard Payments, which have a subscription method (https://developer.paypal.com/docs/classic/paypal-payments-standard/integration-guide/subscribe_buttons/)
From what I can read there is that this is what is suitable for my use case, and it says that I need to enable the above mentioned service, which it doesn't work.
Can someone point me in the right direction on what service should I use from PayPal in order to implement recurring payments (basically my users will subscribe themselves to a service on my website, and I need to charge them monthly).
Thank you.
If you're wanting to handle credit cards directly I would highly recommend going with Payments Pro w/ Recurring Payments APIs.
You'll have to pay a monthly fee to get it all activated, and it's a little bit more expensive than what you were looking at, but it will give you much greater flexibility building your application(s) into various experiences for your buyers.

Easiest way to add PayPal to existing Stripe billing flow

I have an educational website that uses 'Stripe Connect' to accept payments from students, and split the payments between myself (the platform provider) and the teachers (content-creators).
Payments to teachers are currently handled through Stripe. Whenever a student purchases content, the teacher automatically receives the payment directly into their Stripe account. I retain a portion of the transaction directly into my Stripe account. It's an easy system and works nicely.
The problem is that students want to pay with PayPal.
So, I would like to add PayPal as a payment option for students, without forcing content-creators to connect two separate accounts--one for when viewers pay with PayPal, and another for when viewers pay with Stripe. The only idea I have so far, is to deposit all PayPal payments to one PayPal account, then manually "payout" teachers into their Stripe accounts every week.
But is there an automated way to do this? Stripe says they don't accept payments from PayPal.
Any ideas/help would be appreciated. Thanks!
Adaptive payments does support chained payments, as Andrew says in his answer; it would work very much like what you describe having set up with Stripe.
However, this will not meet your requirements of having both PayPal and Stripe payments arrive in a single teacher account. Unfortunately, Stripe & PayPal see each other as competitors and to my knowledge neither one has built a tidy product to consolidate "their" payments into the other company's account.
If you are willing to move away from Stripe, PayPal does provide many solutions that consolidate "raw" credit card payments and PayPal account payments into a single receiver account, including through Adaptive Payments as cited by Andrew.
I would add that Braintree, having been purchased by PayPal, provides perhaps the most Stripe-like integration for a product that would accomplish this goal. However, I do not believe that the Braintree SDK will do the chained payments for you; you might have to do some work to make that happen on your end (take the first payment, then calculate and make payouts either weekly as you mentioned or per-incoming-transaction).
A couple other things to think about: if you split some payments into delayed fulfillment but others are chained inside one payments provider you will need to support two very different flows; you may find it easier (for both you and your content providers) to select one model and run everything through that model.
Also, instead of payments going to you & then chained to the content providers you could have payments to go directly to the content providers and then trigger billing (either invoicing or automatically collected via recurring payments) from the content providers to you for your cut.
The best pattern depends largely upon how you want the legal & financial responsibilities to lie: are you providing the good or service and people are paying you for it, making you like a retail store or distributor for producers? Or are content providers providing the good or service being paid for to the students, and you are like a marketplace/facilitator/advertising venue? This question becomes significant as soon as someone is unsatisfied with something they have bought :).
You can use the Adaptive Payments platform with PayPal to split payments just like you're doing with Stripe. Specifically, you'd use the Pay API setup as a chained payment with a secondary receiver.
If you happen to be working with PHP my class library for PayPal will make all of the API calls very simple for you.

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.

Recurring payments with arbitrary amounts and at arbitrary times?

We'd like to find a payment provider that lets us do something similar to Hailo, ie:
Users sign up and give us their credit card details/authorise us to charge their account. They only need to do this once.
In Hailo's case, users might take a cab journey at any time and be billed any amount (within reason). In our case, users might need a job done at any time, again with an invoice for an arbitrary amount.
So ideally we'd be able to charge users accounts at any time, for any amount, without further authorisation. This is possible because Hailo (and I believe Uber) have it implemented. However, I don't know if they use a third-party payment provider or rolled their own.
Something like BrainTree's recurring payments is close to what we want, but not exactly. We want to be able to bill at arbitrary times, not on a fixed schedule.
The best option we currently have is to use recurring billing, ie save invoices and then charge them all at once at the end of the month. This isn't ideal from a cashflow -perspective, though. Another option is to use GoCardless' variable billing, (you ask customers permission to bill up to £X per month), though from speaking to people it seems they'd be leary of that as it seems like an upfront commitment.
Can we do it our way? How do companies like Hailo and Uber do it?
We're in the UK, by the way.
In PayPal world - we call this kind of functionality as Reference Transactions - here are the 2 how-tos that would give you more info on how to implement reference transactions with PayPal accounts and direct credit cards:
Reference Transactions for PayPal users
Reference Transactions for Credit/Debit cards
You can also use our Preapproval functionality - which would give you delegated access to a PayPal account to make payments on behalf of them. Here is it's how-to.
Full disclosure, I work as a developer for Braintree.
Using Braintree you can create transactions at any time, not just on a recurring basis. In fact Uber is a Braintree customer. You would store the card in the Braintree vault and create a new transaction when you are ready to bill the customers credit card.
Braintree has recently announced an international expansion that will support merchants in the UK and other countries in the next few months.
From your description Authorize.net CIM will do the job - http://www.authorize.net/solutions/merchantsolutions/merchantservices/cim/
It's PCI compliant and let you store your customer credit card details with them and return a token for the customer. Then you can use this token to charge customer credit card whenever you need. Also their recurring billing facility would let you charge a fixed recurring charge if needed - http://www.authorize.net/solutions/merchantsolutions/merchantservices/automatedrecurringbilling/
DataCash will let you do this, amongst many, many other things. You just provide their 16-digit reference number in the XML rather than a card number.
(Note: I'm an ex-DataCash employee, and we use DataCash as a payment gateway at my current work.)