Reduce Order payout fees

[remear]

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:

orders = merchant.get_open_orders()
merchant.bank_account.credit(orders)

or even:

merchant.settle_unpaid_orders

[mahmoudimus]

ping @balanced/spec-ialz what are your thoughts on this?

[matthewfl]

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

[mahmoudimus]

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
#660 (comment)
.

Mahmoud Abdelkader
Co-founder & CTO @ Balanced

[mahmoudimus]

ping @balanced/spec-ialz - I'm thinking we should pass a group of orders into an credit.

[mjallday]

@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)

[mahmoudimus]

@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.

[mahmoudimus]

@remear another thing we can do is just offer the disbursements here for free if they're coming from an order.

[mahmoudimus]

@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))

[remear]

@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.

[mahmoudimus]

@remear can you clarify?

[remear]

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.

[mahmoudimus]

@remear good point. Not sure if that's a bad thing either though. At least people would be using orders :)

[mahmoudimus]

@remear should we open up another issue that discusses that downfall for an order? Should an order have limited movements?

[rmanisha]

@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.