support more means of payin and payout #974
Comments
|
@nobodxbodon One of the values of having individual tickets for each payment option was that we could more naturally collect details as well as gauge user demand scoped to the particular option, which helps in evaluating the options. What are your thoughts on how to do that with this single mega-ticket? |
|
@whit537 as you mention there are two folds - details and user demand. It's proved that there's user demand for each of the means above, while having 10 +1's in one issue doesn't guarantee higher priority than the other which has 5. IMO we as a project are better to set priority and discuss with the whole picture in mind, which this ticket is trying to provide. About the details, I agree it's natural to put the specific details for an individual payment method in the corresponding issue, even if it's closed for now. If the details is relevant for other payment methods, we can extend the discussion here. For instance, based on gratipay/gratipay.com#4310, maybe it's worthwhile to add a column in the table "supported by Braintreee", to research which has built-in support from our processor. |
That doesn't sound right to me. I think we should generally only comment on open tickets. GitHub may even suppress notifications for comments on closed tickets, if I'm not mistaken.
Fair enough, but can't we have both? Individual tickets to track details and user feedback for the individual options, plus this ticket or some other mechanism for decision-making? |
More than I thought! https://www.braintreepayments.com/payment-methods |
As I just tested, at least the reporter of the issue still gets updates after issue is closed.
Sure we can. There are just benefits in discuss in one place that I don't see otherwise. First, it lowers managing cost. Second, it gives user a clear view of the similar tasks we have on our plate and they will likely not just simply +1 to a specific payment method, but join in discussion of the overall plan. If we don't "push" user to this ticket, I don't see they will care so much about other similar (but competing in priority) requests. Besides, I don't think closing the individual tickets hinders user feedback, as user are more likely to just open new ticket like gratipay/gratipay.com#4310 . And IMO they are proved to be legit feature request, and we already have enough knowledge about the relative popularity. That all being said, plus my preference to close 'hibernated' issues, managing issues needs team effort, and managing this kind of mega-ticket especially so. So, please reopen whichever you see necessary (last suggestion is to reopen "After deciding on concrete implementation plan and dev work starts", but feel free to ignore) |
Fair enough. Both benefits you name are valid. Since our mega-ticket here is the new status quo, it would take management cost to go back to individual tickets ... and I for one don't want to pay it right now. :) I'm willing to keep running with the new status quo and see how it continues to shape up. |
|
Here's one that fits well with the meta-ticket: ShareX is based in Turkey, which can't receive PayPal payouts. This is a +1 for "any payout method that isn't PayPal."
|
|
For Payoneer, see gratipay/gratipay.com#481. |
|
Added faircoin: gratipay/gratipay.com#4402. |
ghost
mentioned this issue
|
A repeated +1, here for consistency:
streamlink/streamlink#1016 (comment) |
|
Would it be possible to add Transferwise or ACH, but only for amounts over $xxx? That makes us seem a little more flexible. #dothingsthatdontscale |
|
Braintree is rolling out ACH: https://www.braintreepayments.com/en-ee/features/ach-direct-debit. |
|
Does that mean |
|
I think so. |
As there are quite a few similar issues in gratipay.com, all are re-ticketed here for further discussion and planning. After deciding on concrete implementation plan and dev work starts, we'll reopen specific issue for tracking purpose.
The text was updated successfully, but these errors were encountered: