How about Paypal?

[moazam1]

It's a wonderful package @taylorotwell Can you add Paypal or Authorize.net in this package please?

[davzie]

I think this is probably remaining Stripe only for the foreseeable future until some major work on the API and keeping it clean is done. Just my personal thoughts on where it's heading though.

[taylorotwell]

Keeping it Stripe. Keeps the API cleaner.

[dmyers]

I saw the StripeGateway class and thought there could eventually be multiple gateways through a driver pattern.

[BenjaminRH]

Keeping it Stripe. Keeps the API cleaner.

Shame, that. Stripe is nice for quick weekend projects or side projects like Laracasts, but is too immature for actual business use. Braintree is a better alternative with a similarly excellent API.

[davzie]

Why is it immature for business use? On 23 Mar 2014 12:19, "Benjamin Harris" notifications@github.com wrote:

Keeping it Stripe. Keeps the API cleaner.

Shame, that. Stripe is nice for quick weekend projects, but is too immature for actual business use. Braintree is a better alternative with a similarly excellent API.

Reply to this email directly or view it on GitHubhttps://github.com/laravel/cashier/issues/7#issuecomment-38380856 .

[BenjaminRH]

A number of reasons, including things like:

• Stripe has a terrible dashboard. I realize it's much toted for having a brilliant API, but unfortunately that's not sufficient for a mature business. "Build it yourself" isn't always the right answer.
• Braintree supports multiple merchant names for a single account. This is extremely useful. We've gotten tons of calls from using Authorize.net complaining that they didn't recognize the name on their bills
• Braintree can return a valid credit card number, which is very useful for legacy systems. This isn't really applicable to Laravel, but it definitely gives me confidence that the people behind Braintree are more experienced

When I'm back home I'll pull up my document from when we did comparisons, but these are a few things I remember off the top of my head.

[taylorotwell]

I think you mean not suitable for YOUR business. It's certainly suitable for a multitude of other businesses.— Sent from Mailbox for iPhone

On Sun, Mar 23, 2014 at 7:28 AM, Benjamin Harris notifications@github.com wrote:

A number of reasons, including things like:

• Stripe has a terrible dashboard. I realize it's much toted for having a brilliant API, but unfortunately that's not sufficient for a mature business. "Build it yourself" isn't always the right answer.
• Braintree supports multiple merchant names for a single account. This is extremely useful. We've gotten tons of calls from using Authorize.net complaining that they didn't recognize the name on their bills

• Braintree can return a valid credit card number, which is very useful for legacy systems. This isn't really applicable to Laravel, but it definitely gives me confidence that the people behind Braintree are more experienced When I'm back home I'll pull up my document from when we did comparisons, but these are a few things I remember off the top of my head.

  Reply to this email directly or view it on GitHub: https://github.com/laravel/cashier/issues/7#issuecomment-38381026

[moazam1]

I think Stripe is better than Braintree. It's just my personal opinion

[robclancy]

I was under the impression strips was THE tool for businesses.

[nbransby]

Stripe is great although doesn't have escrow like Braintree.

I am disappointed to hear cashier hasn't been designed to be provider agnostic - a case of not practising what you preach Taylor (StripeBiller, From Apprentice To Artisan)? ;)

[danielfaulknor]

It also has the small issue of not being supported in quite a few countries... pretty much leaves me to write something myself around PayPal :(

[PhillipMwaniki]

Stripe isnt in Kenya, and thats a big issue on my side

[pablorozin]

@taylorotwell I know that Strip is excellent, but I live and work in Argentina and here is obsolete, as it is in many other countries, because it doesn't work with many of our national banks and local payments solutions. Are you planing to add the posibility of using other gateways instead of Strip like Paypal?

[eduacostam]

I'm with @PabloRozin here, I'm also from Argentina and the business for which I work was using Stripe a few months ago. Stripe sent us an email telling us that because we have less than half of our customers living in the USA they had to close our account.

The thing is, regrettably, that Stripe has a long way to go before it can be used for any businesses that has more customers outside the USA than inside the USA. Braintree (and PayPal for that matter) do not have this limitation and work all over the globe. I think it would be great to allow cashier to use a driver model in which we can hook different providers.

I understand that this is no easy undertaking and it might be outside the scope of the package, and that's okey... Just my two cents.

[tomicakorac]

+1. Stripe is an awesome service of course. However its availability around the World is quite limited, to say the least. If @taylorotwell sees any interest in folks not residing in the few countries supported by Stripe using Cashier, he should most definitely consider adding support for other payment processors, such as Paypal, 2checkout, Skrill etc. The way it is now, over 90% of potential Cashier users remain out of the game, which is sad.

[lucabartoli]

21 Countries out of 205? Are you serious?? Furthermore, only 9 countries are production ready by now, 8 in beta and 4 in private beta. Really, a payment platform which accept payments only by the 10% (5% production ready) of the world is just a bit more than a college summer project.

@taylorotwell I really don't think Stripe is suitable for any global business in the world. Maybe you've agreed to a partnership with stripe or you like stripe more than any other platform, no one will blame you for that, but please don't deny the evidence. Otherwise, why not implementing the new paypal RESTful API? What about the framework agnosticity? Can you really ignore the fact Paypal is the most widespread payment service in the world?

[tomicakorac]

@lucabartoli that isn't constructive at all from your side, is it? Please bear in mind that Github's issues are not meant to be used as a discussion forum. You should not use it to express your opinions and emotions, but rather to share useful information.

After all, both Cashier and Laravel are open source libraries, and if you are that much affected by lack of PayPal integration, there's literally nothing stopping you to build a PayPal integration library on your own and share it for the benefit of us all.

[lucabartoli]

@tomicakorac everyone in this issue expressed his opinion, referring the fact Taylor doesn't consider this as issue at all. Mainly, I followed the flow, expressing my opinion about the coverage of stripe. We are here because we all think Cashier is an amazing component, but stripe is useless for 196 countries out of 205 worldwide (at the moment). Can I write my own implementation? sure I can. is it the point? no. You're free to answer, but you're right, this is not a forum, so i will not comment anymore about that. Feel free to read between the lines and catch the real meaning of my comment. Nothing personal against you or Taylor, believe me.

[taylorotwell]

If someone wants to write a 100% cashier syntax compatible PR to support PayPal then go for it and send it over.

On Thu, Oct 1, 2015 at 7:02 AM, lucabartoli notifications@github.com wrote:

@tomicakorac everyone in this issue expressed his opinion, referring the fact Taylor doesn't consider this as issue at all. Mainly, I followed the flow, expressing my opinion about the coverage of stripe. We are here because we all think Cashier is an amazing component, but stripe is useless for 196 countries out of 205 worldwide (at the moment). Can I write my own implementation? sure I can. is it the point? no. You're free to answer, but you're right, this is not a forum, so i will not comment anymore about that. Feel free to read between the lines and catch the real meaning of my comment.

Nothing personal against you or Taylor, believe me.

Reply to this email directly or view it on GitHub: https://github.com/laravel/cashier/issues/7#issuecomment-144706940

[tomicakorac]

Can I write my own implementation? sure I can. is it the point? no.

Actually, that's exactly the whole point of Open Source development.

[onlymega]

The easiest way to integrate Paypal in cashier is to pre-pay stripe credit using the Paypal express checkout. User pays with Paypal some fixed amount (prepays his subscription) and this amount is added to the stripe customer (as account balance credit).

[tomicakorac]

@onlymega I'm afraid you've missed the point. Vast majority of the World's population are not allowed to have a Stripe account at all, as Stripe only operates in a very small number of countries. The problem is not paying from the buyer's side, it's funds withdrawal from the seller's side.

[onlymega]

I have two projects running on Stripe cashier library and many users simply cannot pay because their cards are declined (5-10% of transactions are failed even if user has payed firs time with the same card without any problems). It would be nice to add the prepay option using Paypal express checkout to solve such issues.

[taylorotwell]

There is about a 0.01% chance that Cashier will ever support Paypal. The whole process of processing subscription payments on a recurring basis is a giant leaky abstraction because each payment provider is going to be slightly different. There isn't some PSR for subscription processing. We can never use a library like OmniPay because it doesn't do subscription billing, it does one-time billing, meaning you would need to write all of your own actual recurring billing logic, refunds, cron jobs, proration, coupons, etc.

The best chance to have something like Cashier for Paypal is just fork Cashier or even start from scratch and write a package for subscription billing specifically for Paypal. It will never be jammed into Cashier.

On Wed, Dec 2, 2015 at 1:37 PM, onlymega notifications@github.com wrote:

I have two projects running on Stripe cashier library and many users simply cannot pay because their cards are declined (5-10% of transactions are failed even if user has payed firs time with the same card without any problems). It would be nice to add the prepay option using Paypal express checkout to solve such issues.

— Reply to this email directly or view it on GitHub https://github.com/laravel/cashier/issues/7#issuecomment-161409650.

[TheSachin]

@taylorotwell - Hi I understand that you don't wish to integrate PayPal into Cashier. But Stripe is not as spread as PayPal.

The whole process of processing subscription payments on a recurring basis is a giant leaky abstraction because each payment provider is going to be slightly different

I agree with that too. Can we have separate package for PayPal, or that would be too much overkill.

[kevosomi]

I stand to be corrected but what @taylorotwell is pointing out here is pretty simple, he likes to work with stripes, which is pretty opinionated but acceptable considering that Laravel and Cashier are open source. However, as the end consumers of these awesome products, we would appreciate a little guidance on how to 'hack' into cashier and bring in Paypal or any other gateway for that purpose.

[PhillipMwaniki]

We will have to consider starting a paypal-cashier project. Taylor is going to stand his ground on this no matter what we say.

[kkomelin]

Let's look at the problem from a different angle and find a positive point. Developers have to code a little bit more in countries that are not supported by many services, which gives them experience and makes them stronger. There is no the third option, you either swim or sink. BTW, my country is not supported by Stripe and Braintree too.

[davco98]

So, if you're trying to startup a business outside the US, and you want to use Laravel, you have to frickin' wait until Stripe decides to enter your country.

[kkomelin]

So, if you're trying to startup a business outside the US, and you want to use Laravel, you have to frickin' wait until Stripe decides to enter your country.

"Entrepreneurs are simply those who understand that there is little difference between obstacle and opportunity and are able to turn both to their advantage." - Victor Kiam

[jcsoriano]

(Now almost 2018 - more than 3.5 years since this issue was closed)

I checked Paypal's PHP SDK and it seems to now support almost the same flow as Stripe and Braintree's recurring payments now (if I'm not mistaken):

https://paypal.github.io/PayPal-PHP-SDK/sample/#billing

1. Create a plan (https://paypal.github.io/PayPal-PHP-SDK/sample/doc/billing/CreatePlan.html)
2. Use that plan for the recurring billing (https://paypal.github.io/PayPal-PHP-SDK/sample/doc/billing/CreateBillingAgreementWithPayPal.html)

Does anyone think integrating Paypal is becoming more of a possibility now with the current state of their API? I've worked briefly with both Stripe API and Paypal REST API (not the "classic" API) and I'm seeing the usage of both are very similar now.

Just wondering if the door is opening for Paypal to be included to this wonderful package.

[tomicakorac]

Most of us do. However as this issue is closed and Taylor clearly has no interest in reconsidering the decision, this remains highly unlikely to happen.

[robclancy]

So, if you're trying to startup a business outside the US, and you want to use Laravel, you have to frickin' wait until Stripe decides to enter your country.

Or you could you know... use your programmers to solve the business problems? Many people use PayPal with Laravel and other frameworks. It doesn't need official support to work.

[robclancy]

Most of us do. However as this issue is closed and Taylor clearly has no interest in reconsidering the decision, this remains highly unlikely to happen.

If there was a PR or someone showed how apparently similar they are now I'm sure he might consider it again (consider, not do it). That said, if it is so similar it wouldn't be hard to fork and adapt?

[jcsoriano]

So I checked the source code of this repo and found that this package seems only for Stripe. I checked back at the docs and found that the Braintree implementation is an entirely different package. So it seems for anyone who'd like to contribute to make Laravel Cashier Paypal a reality (developers in 150+ countries will thank you profusely!), they'd have to create something like a cashier-paypal implementation that adheres to how Taylor does it in these two packages.

If anyone has the skill (that I don't have) to take this on, this might be a good starting point on creating subscription billing with Paypal's newer REST API (as of 2017): https://devdojo.com/blog/tutorials/using-paypal-in-your-laravel-app

I understand that anyone can make their own implementation but the way Taylor does it is just beautiful. I'm sure people from non-developed-countries would absolutely appreciate also being able to do

if ($user->onTrial())

or

$user->subscribed('main')->cancel();

and all of those goodness just by doing something like

composer require laravel/cashier-paypal

like you guys in developed-countries are able to do with laravel/cashier and laravel/cashier-braintree :D

It might also make good business sense for the Laravel team to make this possible. I'm sure Laravel usage would get a big boost because devs from 150+ countries can now also integrate billing to their apps easier (let's face it, what percentage of Laravel apps don't need billing nowadays?).

More Laravel usage = more users of Laravel's paid products like Forge, Spark, Envoyer, etc.

(The friction experienced by developers from 150+ countries to be able to do something as fundamental as subscription billing when using Laravel might be a lost opportunity!)

[pursehouse]

Why is it called Cashier if it is hard set to only support one gateway? Shouldn't it just be laravel-stripe?

[robclancy]

Because cashier sounds way cooler.

[pursehouse]

that's really shitty though... example Spark is built to support Cashier structure. So if Cashier was a library structure as opposed to just a strict one-off tool, then people could write Cashier compatable libraries to work with the gateways they use. Instead this is just some random library for a specific company, not a functionality expansion. So every implementation of any gateway has to be rewired on both sides to be usable.

[pursehouse]

and the refusale to make that ability possible isn't much motivation for people to try to help the framework that is literally telling them it doesn't care what they need. So the solutions are all going to stay internal

[robclancy]

Nah cashier does sound way cooler and if someone made drivers for other providers well enough they would be merged.

I'd rather the framework be the focus instead of gateways which change lots, have lots of differences and already have many libraries.

You know you can also write your own code right? You don't need everyone to do it for you.

[pursehouse]

@robclancy from looking at the code, it currently has no abiltiy to support other providers. That's why the "cashier-braintree" is a totally unrelated project as opposed to an extension.

as far as...

You know you can also write your own code right? You don't need everyone to do it for you.

you realzie the point of these public projects is so that the 4 years of people complaining about the same exact problem can be solved instead of everyone solving it themselves internally. Especially when this is tool is meant to be a selling point for a not-free package. Telling people they have to switch providers in order to use a product is not a great path.

[robclancy]

Look at the 3rd comment. Anything after that is pointless bitching like what you are doing now. All providers have libraries you can use. This one works with stripe.

[pursehouse]

well then I guess laravel shouldn't exist at all. cuz people can write their own code. Congratulations

[robclancy]

You're dumb as hell.

[pursehouse]

clearly this is a scenario where Stripe is giving kickbacks to the Laravel owner to soley support their platform. So that people will use switch to their platform and make them money. Cuz "why make things dynamic and extendable" is the absolute opposite of an engineering goal. And you already showed you don't know the codebase with your comment that another provider would be added, but already a new one is in another project by the same people. Because Cashier has no technical dynamics in it.

[robclancy]

Holy crap dumb as hell and a conspiracy theorist.

I don't need to know the codebase because I can do this thing called programming. And I could change it to support whatever I wanted.

[pursehouse]

if you don't know it, why are you speaking

[robclancy]

Because this isn't about code, this is about you being stupid.

[pursehouse]

4 years of community complaints on this. About something you have no knowledge of.... once again, why are you involved?

[mikerogne]

Laravel Cashier does support Braintree... I'm confused ¯_(ツ)_/¯