Will "Commerce Linden" be removed as the Marketplace escrow account with Direct Delivery?

[Sassy Romano]

Open question to Commerce Team Linden.

When Xstreet was around, there had to be an escrow account, it had to because it had no direct access to our account details.  Xstreet used an unreliable non guaranteed, unverifiable delivery method (llGiveInventory).

... and things worked rather well when all is said and done.

LL buys Xstreet and we know what happened next but due to the "bolt on's"  has always kept the escrow account but the events of the Valentine's Day Massacre had me thinking about this and it strikes me that the use of the escrow account going forward, will neither help prevent such an event from happening again, nor is the escrow account needed anymore.  Why?  read on.

Reasoned analysys of the process flow of MP purchases suggests that the following happens:-

 

1. Pay Commerce Linden, put purchase details into a data table which includes all the transaction details and a couple of fields, one indicating "delivered", the other "merchant paid".
2. A completely disconnected process then cycles through this table (A simple SQL query for those which are not yet delivered) and passes these to the delivery process which currently calls our Magic Box and still uses llGiveInventory (unreliable, non confirmed delivery).  Send ANS data at this point too it would appear and sets delivered field to yes.
3. Next, an equally disconnected process then cycles through this data table to reconcile payments and updates the MP orders status.

The fact that each of these is so hopelessly disconnected from the other is what should never happen in an electronic transaction but I can appreciate how it got to be this way, however, we have an alternative with Direct Delivery available.

Commerce Team Linden, with the use of DD, you will have:-

 

1. Full control over the payment process on the Marketplace
2. Full and direct access to our accounts
3. Full and direct access to our inventory to be delivered
4. Full and direct programmatic ability to determine delivered status

As such, given that this is a wholly electronic transaction, the following may now be easily done:-

 

<START TRANSACTION>

• Customer purchases off MP
• Transfer funds direct from customer to MERCHANT, pay LL commission.
• Direct Delivery of product to customer
• Update records, send ANS etc.

<END TRANSACTION>

See the difference?  There is now a direct relationship between the customer and the merchant.  It's wholly encapsulated in a formal transaction that either completes in full or rolls back, since step one is that the merchant gets paid, the customer can contact the merchant and we can clear up the mess.

Commerce Team Linden, you have stated that steps are being taken to avoid this in future but the above is the correct way to address this, there is no longer any need other than poor back end processes, to maintain Commerce Linden as the escrow account once Direct Delivery is implemented in full.

Keeping the escrow account and just expecting Direct Delivery to "deliver better" is not the right answer here.  llGiveInventory and MagicBoxes has shown itself to be far from the biggest issue now.  The long delays in the European morning are nothing to do with MagicBox load other than a false one that LL has effected and the overall architecture of the Marketplace back end processes is questionable.

Can you confirm that Commerce Linden will be removed with Direct Delivery and crucially, if not, why not?

Thanks.

[Toysoldier Thor]

I wondered myself how DD was gonna solve the Valentines Day Massacre myself when LL commerce said with DD it will all be better.  But since LL Commerce doenst talk much about the details of DD I assumed they did what you said Sassy and were fixing the stupid poor transaction processing that LL does now.

If they are ONLY fixing delivery then DD will do nothing to fix the disaster LL created last week.  That was just a PR gimmick to prmote DD. 

I have had almost no problems with Magicboxes in all these years.  The midnight delays are backend server probs as you said sassy.  The gifting is not a magicbox problem either.  A ton of blame is put on magicboxes that LL has allowed to be blamed when they know full well its not.  It just hides the crap backend system processes that LL didnt want to clean up / fix all these years and it allowed them to go onto their pet project DD.

A Project that has now taken over a year for them to develop and still not fully deployed.  A project that has also all but distracted an entire Development team from doing almost any other fixes to MP that merchants keep asking for.

The broken transaction processing that Sassy explained and that showed its perfect example of what can happen to this flawed design will still likely be in place and DD will do nothing to reduce the risk of another V Day massacre.

 

LL Commerce Team said a very fluffy statement with NO hard facts that they will be looking at improving backend systems to improve redundancies.... exactly what ?  What exactly failed and what will be fixed? and When?

 

[Pamela Galli]

Bump

[Josh Susanto]

I'd just like to reiterate that everyone but me is hallucinating.

What really happened, just like LL said it would, is that DD was fully deployed months ago and is working perfectly.

Just check what they told us in August and September, and it becomes very clear that scenarios like the V-Day scenario many have oddly described here in the same way, have been simply impossible all this time. 

 

 

[Sassy Romano]

Any comment please CTL?

[Darrius Gothly]

---

Sassy Romano wrote:

Any comment please CTL?

---

CTL won't reply Sassy. CTL is way too busy coding up a new "All stuff goes in here so no one can find it" junk folder feature. CTL does not have time to respond to serious and well-considered questions, suggestions or statements.

[Sassy Romano]

Darrius... I believe that change can be influenced.

On the basis of probability, I also believe in aliens from space.

As we know, the use of the commerce linden intermediary is down to the organic way that MP was developed from the Xstreet migration, with bits being slapped together in a way that just about makes it work (questionable) but the demonstration from V-Day Massacre and the daily morning delays in Europe are sufficient to demonstrate that the handling is innapropriate.

The Direct Delivery initiative should be the trigger point for this to be architected properly since MP shouldn't be considered as an afterthought, after all, if there's so little drive behind improving it and treating it as the unwanted stepchild, why was it bought in the first place? 

(I know you know this Darrius, i'm just waffling)

[Darrius Gothly]

---

Sassy Romano wrote:

... if there's so little drive behind improving it and treating it as the unwanted stepchild, why was it bought in the first place? 

---

That's a question that I think many a soul (and Avatar) would like to have answered. It certainly would delight me to have an actual answer from LL for anything they've done with Marketplace and SL too.

[Sassy Romano]

Opened as a JIRA if anyone wants to follow it https://jira.secondlife.com/browse/WEB-4508