search

laravel / cashier-stripe

Laravel Cashier provides an expressive, fluent interface to Stripe's subscription billing services.
https://laravel.com/docs/billing
MIT License
2.39k stars 679 forks source link

Cannot collect paymentMethods which are not "type: card" #1024

Closed christoph-kluge closed 4 years ago

christoph-kluge commented 4 years ago

Description:

You cannot lookup payment methods which are not card's. In my exmaple I need sepa_debit

Steps To Reproduce:

Use $billable->paymentMethods(['type' => 'sepa_debit']). It will always return an empty collection.

Code Reference:

https://github.com/laravel/cashier-stripe/blob/12.x/src/Concerns/ManagesPaymentMethods.php#L64

This is always using type => card and does not allow a search for custom payment methods. This is caused by the + operator. See: https://www.php.net/manual/en/language.operators.array.php

for keys that exist in both arrays, the elements from the left-hand array will be used, and the matching elements from the right-hand array will be ignored.

driesvints commented 4 years ago

Cashier only supports Credit Cards atm. Please see https://github.com/laravel/cashier-stripe/issues/435

christoph-kluge commented 4 years ago

Referring to the issue. It's open since '17 and we're now in '20. You have mentioned that people should contribute but obviously you're not accepting any contributions anymore because you feel it's not important. On the other hand you're not able to give an ETA to deliver this feature. Whats the point of contributing then?

Don't you think that increasing functionality in iterations could get this feature earlier finished and tested?

driesvints commented 4 years ago

As I tried to explain in the other issue, there's a whole lot more to be done than simply updating a few lines in order for us to support more payment methods. Not only the existing implementation needs to accommodate for more payment methods, lots of them have quite some side effects and their behavior is different in nature compared to credit cards. It'll take quite some research and investigation in order to know exactly what the implications are for each different payment method.

I don't want to rush this and risk shipping a half baked implementation which will lead to bugs in the library and broken apps for our users. We're talking about a sensitive subject that involves money and we shouldn't speed this. I currently do not have the time to put in the effort required to properly investigate this all and see what the implications are for the library as a whole but anyone is free to help out and post a detailed summary at what's needed to be done. And that goes further than changing a couple of lines.

christoph-kluge commented 4 years ago

I see where you are coming from and it's all valid arguments but the communication is a totally different. Don't get me wrong: it's no offense. I simply think that the EU community has a bigger interesst in finishing/rolling this feature than the US community. Let's create a roadmap, allow multiple collaborators to support single cases and let them test instead of leaving it all to one person. I'm fine to collaborate on all use-cases which are relevant in my scenario.

There is a lot more to be done than this before we can offer proper support for other payment types. Like updating the payments.blade.php file, making sure that webhooks come in properly, updating other payment methods, etc...

Let's make this happen. Since you'll have the most thoughts about it, please share it with us. People can follow and contribute. I'm a fan of simple bulletpoint lists as a starting point.

What do you think @driesvints?

Sidenote: As of now I'm a bit dissapointed that I can't leave my comments about this inside #435. This way it would reach more EU users/volunteers to get this done.

driesvints commented 4 years ago

@christoph-kluge sounds good. I've unlocked that issue so you can share your thoughts there. Let's follow up there 👍