search

balanced / balanced-api

Balanced API specification.
221 stars 72 forks source link

Limit number of debits per Order #673

Open remear opened 10 years ago

remear commented 10 years ago

Currently any number of debits can be added to an Order at any time, indefinitely. Should this be limited?

rmanisha commented 10 years ago

What do we gain by limiting the number of debits?

remear commented 10 years ago

My opinion here is to not limit the number of debits per Order, but instead limit the timeframe for when debits may be added to the Order. 5 minutes, for example.

mjallday commented 10 years ago

@remear rather than limiting the number of transactions associated, to me it sounds like it would be beneficial to allow an order to have a state. e.g. it could become possible to close an order which would essentially the same thing by no longer allowing debits into the order.

remear commented 10 years ago

@mjallday This issue was split off from https://github.com/balanced/balanced-api/issues/660#issuecomment-51260209. The main concern we're been looking to address is reducing payout fees when using Order. If we make payouts free from Orders or reduce them, eventually a point will be reached where one can continue debiting into the Order and continually credit out for free.

In any case, I'd like to have the ability you mentioned. Perhaps an Order can also be automatically locked to disallow additional debits once a payout is issued.

mjallday commented 10 years ago

what would stop me from creating an order per debit and crediting out? i'm not clear on how this changes the payout fees.

remear commented 10 years ago

In the case that payouts from Orders were free, nothing, which I feel is problematic for the reason you described.

Since we have no restriction on how many debits may be added to an Order, nor a timeframe limit on when they may be added, if only the first n payouts were charged in some way to help reduce fees, once that limit is passed, there's nothing stopping more debits being added to the Order to achieve free payouts indefinitely.

Therefore, my opinion is that trying to deal with special pricing for payouts from Order is not the best solution. Instead, I'm leaning toward providing a way to specify orders and amounts to be drained from them into a single batch credit which would resolve the primary concern of the Order payout fees issue.

mahmoudimus commented 10 years ago

@kyungmin - this is a product discussion.

kyungmin commented 10 years ago

Orders aren't more expensive than regular transactions though, since they would still be charged (n * 25¢) if they did the same operations without using orders. Why are we trying to reduce the payout fee for Orders?

remear commented 10 years ago

@kyungmin

Compare:

Debit 5 buyers for Merchant A services -> Escrow -> 1 consolidated payout to Merchant A = 1 credit @ 25¢ totaling 25¢.

vs

Debit 5 buyers For Merchant A services, one Order per buyer -> 5 payouts, one from each Order to Merchant A = 5 credits @ 25¢ totaling $1.25.

kyungmin commented 10 years ago

@remear can you explain what each scenario is describing? And why does the second scenario say one order per buyer? I thought we were talking about n debits in a single order.

remear commented 10 years ago

@kyungmin What I just described was in response to your question, how using Orders becomes more expensive than not using them. With Orders there is currently no possibility of consolidating payouts. So for each Order, there's at least one payout per Order that will be charged. If you have 5 Orders, that's 5 payouts. If you don't use Orders, you'd charge the buyers, the funds would go to escrow, and you could consolidate the payments into 1 credit. This cost difference causes Customers to ask why bother using Orders, it's way more expensive than not using them.

This is somewhat off topic for this ticket and should be pursued in https://github.com/balanced/balanced-api/issues/660. This ticket aims to discuss the need to limit debiting into an Order, which becomes a concern if we Offer free-ish payouts from Orders as per https://github.com/balanced/balanced-api/issues/660#issuecomment-51257206.

dmdj03 commented 10 years ago

If credits from an order are free, then there's no difference between making subsequent credits from additional debits in a single order vs. creating new orders from these debits and crediting again. They'll all result in the same number of credits issued.

MDrollette commented 10 years ago

In our case a Seller has many (hundreds) of Orders, each with many debits into it. Currently, with 1.0, we are able to manage the Order bucketing on our end and consolidate it to a single ACH payout to a Seller.

Switching to 1.1 requires us to have many thousands of additional ACH payouts across our marketplace.

A solution for us would be to expose Accounts and Transfers (#33 and #506) so that we could "credit" the Sellers "Balanced Account" from each Order, rather than an ACH transfer. And then do a single ACH credit from the Sellers Balanced Account.