Multiple merchants / customers per "Order"

[toobulkeh]

One thing that we felt was unique with balanced was that each "order" pool provided a separate escrow account in a grouping that would shield our marketplace from liabilities.

Unfortunately, we can't use the Order construct as we require multiple merchants to be paid per Order, and would like to offer multiple customers per Order.

We'd love to see this new feature!

Thanks

[steveklabnik]

/cc @mjallday , I don't think that this is going to happen due to the way that Orders are intended to be used.

[mjallday]

I believe the issue is that this will confuse who the funds are earmarked for which is the opposite of what credit card companies want to have happen. A single merchant makes it very clear that any funds within that order are for them.

Having said that, this is a good scenario for shopping carts. The question is how do you break down the funds and record who is owed what from the funds within the order.

[toobulkeh]

Our merchants all submit "time-sheets" as they're selling services/hour instead of a set product.

We then verify the time sheet with the customer and mediate until everyone's happy (usually very short process) and then execute on all the transactions.

Orders is the right construct, we just have a use for multiple merchants / order.

[steveklabnik]

Right, my understanding is that in the shopping cart case, you still have one Order per seller.

[toobulkeh]

:+1:

going back to @mjallday's comments -- an Order is an earmark of funds between a buyer and seller in a marketplace. I don't see why it can't be a many to many relationship. I'm not sure why we care about credit card companies, they never see our balanced config.

This doesn't mean that anyone is required to use multiple sellers, just that it's available.

[steveklabnik]

I don't see why it can't be a many to many relationship.

If you don't keep them separate, you end up aggregating. This is messy from an accounting standpoint. The idea is to keep 'this money goes from this person to this other person' as clear as possible.

Think about how money laundering works: you put a bunch of money from different sources, launder it, and then pull it out in different ways. Laundering is impossible when money flow is clearly accounted for.

[MDrollette]

So, how would one organize a situation where there are multiple sellers and one buyer? A single credit card transaction that's purchasing multiple products from multiple sellers. The funds are disbursed to the sellers once they fulfill the products. Is this the "shopping cart" case you're referring to? Is that outside the scope of Orders currently? How should this be recorded in Balanced if at all?

[mjallday]

@MDrollette if you look at how companies such as amazon do it, the answer is one present one charge to the buyer via your UI but behind the scenes there are multiple debits (one per merchant). in Balanced you'd need to also have multiple orders currently.

[jkwade]

And to be explicit: Yes, @MDrollette yes the one::many situation is the "shopping cart" model referred to above. This is outside the scope of Orders currently.

[jkwade]

@toobulkeh thanks for your email yesterday. I'll just reply here since the conversation's already begun.

One thing that we felt was unique with balanced was that each "order" pool provided a separate escrow account in a grouping that would shield our marketplace from liabilities.

Orders was built to offer basic accounting and order reconciliation assistance to marketplaces for their nominal transaction model. Balanced only offers marketplaces protection from liabilities that are spelled out in our Terms.

From what liabilities are you hoping to receive protection?

[toobulkeh]

@jkwade Worker's compensation / employee liabilities. If a worker (seller, merchant) gets a payment from our company compared to from the buyer, then they would be considered an employee (after a certain amount of payments), instead of a 1099 of the buyer.

It's only if we get audited, but we would prefer to be absolutely specific that the money never came through our marketplace, but we just took an "agent fee" off the top of the transaction, per se.

I understand that Orders was originally designed with something else in mind, I'm just trying to make the case for expanding on that definition instead of limiting it, allows both situations to coexist in different implementations of balanced.

It's definitely something we'd need to the point of moving our implementation to Revmo / Braintree / Paypal at this point. On top of not charging for payouts, and providing payout-to-account/email instead of bank accounts.

[toobulkeh]

In response to @mjallday -- how do you have one credit charge from a buyer tied to multiple orders? That might solve this problem. Is that possible?

[mjallday]

@toobulkeh i believe the standard process is to have a charge per merchant. from what i know this is how companies such as amazon will do it. in the UI it appears to the buyer as a single transaction but on your card statement you will see a charge per merchant.

i'll try and find an example on my credit card statement to back this up, gimme a few minutes.

[toobulkeh]

Oh, I misunderstood your meaning. Interesting concept but it seems complex to explain to a customer.

I had to go back to the holidays to find a time where I bought multiple items that included items that were not fulfilled by amazon (if they're fulfilled by amazon, amazon groups them as one CC transaction, even if they come from different sellers).

A problem with this is if we charge the cards under the guise of a particular worker (to the point where there are different transactions per worker and maybe even a different string name appear on the customer's CC statement, if that's even possible), we'd have to make it appear like we're taking a fee from the merchant, and show the merchant that fee, like Amazon's model. Though I believe balanced already supports taking a fee cut in a single order.

I will propose this concept to the people that care and see what they think.

Could you provide an "invoice" construct, that groups together different transactions? Invoicing and transactional email notifications, in general, would be great to not have to implement via webhooks between balanced and mandrill. :+1:

Here's a complex Amazon transaction I'm going off of, which would be more than half of our transactions. http://jsfiddle.net/8Qpzb/

[mjallday]

@toobulkeh i like the concept of an invoice. i definitely think we should follow this line of thinking a bit more and see what comes from it.

an invoice groups together transactions from one seller to many merchants. is this an accurate definition?

[toobulkeh]

One buyer to many merchants. I would suggest many payouts to many merchants, and a single payout to the marketplace, but there may be room to adjust that.

Depending on how Orders are used, it could be a combination of Orders with a key on the transaction timestamps & buyer, as an assumption.

[jkwade]

@toobulkeh I wanted to address a specific comment you made, which leads to my general answer to why we've made Orders many::one:

I'm not sure why we care about credit card companies, they never see our balanced config.

We care very much about credit card companies primarily because they are the ones that provide the financial infrastructure this who thing runs on, so we have to play by their rules. Here's a specific example of the complications can emerge in the many::many world:

Imagine you receive a chargeback (CB) for a single transaction within a "shopping cart" order comprised of transactions from three different merchants. There is no mechanism by which the CB can be filled against just a part of the whole transaction, so the full amount will be removed from your account until the CB is settled and you'll be responsible for paying the other two merchants out of pocket for what they're owed

Many of the reasons Balanced has difficulty making Orders map from many::many is because the underlying infrastructure we're using is historically dependent on the concept of one transaction leading to one merchant. This is why Orders allows for the nominal case rather than more advanced transaction configurations. That said, just because something has always been done one way isn't a reason to keep doing that, so we'll continue searching for ways to help our marketplaces as much as we can. A N::N Order construct could be useful in the future, but would lead to too many other complications, so it's unlikely we'll offer it in 1.1.

[toobulkeh]

@jkwade That's a very good point, I was making my ignorant comment from the perspective of credit card companies seeing the balanced configuration, not what they can do with the credit card infrastructure.

The example you give, along with other examples (money laundering) brought up here are just barely related to the issue I'm talking about. We can still make transactions and orders however we want to using balanced, this Order construct does nothing to constrain our movements of funds. The only thing it provides is a logical grouping in balanced's system. I can do the same grouping in just our system and completely ignore the functionality you're providing.

The root of our problem stems from what you suggested was possible, this logical grouping, is no longer possible, and falls onto us and our development to achieve. While you're taking away a pair of scissors, you're preventing us from running at the same time, to use a relatable metaphor.

In any case, we appreciate the discussion and have already moved past this request in our development efforts, but we do not see any advantage for our application for sticking with Balanced.

[jkwade]

hey @toobulkeh you're 100% right that Balanced can build these logical groupings and by us not doing so you'll be required to do so. But maybe you can help us understand how we better can handle the CB situation I mentioned above. I'm not we won't ever do N::N Orders, just that we don't know a good way to do them now while taking into account all of the credit card network and financial reporting requirements we have. I was hoping we could brainstorm here.

[toobulkeh]

Well N:N orders would be easy, since you would have one transaction per merchant. 1 trans : N merchants is a "problem" with that scenario you bring up, but I think you answered the question you're asking. The marketplace will have to figure out how to handle that situation, often forking over the cash in between, if they've already paid out to the merchants, or the marketplace can do what the credit card companies may suggest, and NOT payout to the merchants until the CB period has passed.

Again, I don't see any issue passing off this responsibility to the marketplace. I do not see what limiting the marketplace helps.