Closed remear closed 9 years ago
ping @balanced/spec-ialz what are your thoughts on this?
This is going to end up being a very specialized scenario for credits, since this means that you will allow for creating a credit with multiple sources, eg passing an array of identifiers for the sources. Currently we do not do this anywhere else in the api. I blieve that we need to support pooling the money for a merchant before it leaves the system
In my opinion, an order is a source of funds, and I see it synonymous with it representing an amount. So, if anything, we are just passing in a list of scalar values as the amount to a bank account to be credited out.
This is obviously a specialization of transfer to an account, which we can expand to later, but this is a way to use accounts without exposing accounts and transfers to our customers.
On Tuesday, July 15, 2014, Matthew Francis-Landau notifications@github.com wrote:
This is going to end up being a very specialized scenario for credits, since this means that you will allow for creating a credit with multiple sources, eg passing an array of identifiers for the sources. Currently we do not do this anywhere else in the api. I blieve that we need to support pooling the money for a merchant before it leaves the system
— Reply to this email directly or view it on GitHub https://github.com/balanced/balanced-api/issues/660#issuecomment-49116476 .
Mahmoud Abdelkader Co-founder & CTO @ Balanced
ping @balanced/spec-ialz - I'm thinking we should pass a group of orders into an credit.
@mahmoudimus can you write some pseudo code showing how that would work?
i believe with accounts and xfers it would currently look something like
orders = [...]
for order in orders:
order.credit_to(order.customer.deposit_account)
customer.deposit_account.deposit_to(customer.bank_account)
@mjallday - right.
One of my main issues with your approach is that it requires two new resource and two different operations which I'm trying to avoid. This introduces a ton of complexity for satisfying a specific use case.
@remear another thing we can do is just offer the disbursements here for free if they're coming from an order.
@remear or we can make an invoice rollup happen at the end of each invoice-able day and rebate to the marketplace the fees for the number of output.
So, for all orders, o
, that were issued out to a particular merchant, n
, we can issue a rebate of Σ(n*(o-1))
@mahmoudimus The problem i see with making order disbursements be free is currently you can continue to debit into an Order as many times as you want.
@remear can you clarify?
I wanted to point out there's no limits on how many times you can debit into an Order. So that opens a venue where N buyers could be debited to an Order and ∞ payouts will be free.
@remear good point. Not sure if that's a bad thing either though. At least people would be using orders :)
@remear should we open up another issue that discusses that downfall for an order? Should an order have limited movements?
@remear @mahmoudimus I'm not sure I understand. Are you proposing we limit the number of debits that can be associated to an order?
Also, +1 for batching payouts to the same merchant. A common customer concern is that, because of Orders, they would exceed the total credits allowed to their bank account when collecting their fees.
@mahmoudimus We should move discussion about limiting the number of Order debits to https://github.com/balanced/balanced-api/issues/673.
@rmanisha the problem here is the fees. let's address the fee problem then.
Batch payouts may be done through the use of Account and Settlement resources, https://github.com/balanced/balanced-api/pull/707 This should resolve the order payout fee inconvenience.
Presently, when using the Order resource for n buyer transactions for a seller, n credits would be required for the seller to receive all the funds owed them. That's: n * 25¢ vs a single grouped payout from escrow at 25¢.
Inconvenience could be alleviated here by introducing the ability to batch settle open orders for a merchant into a single credit.
Perhaps in client libraries this could be done with something like:
or even: