Why I will avoid Direct Delivery for as long as possible.

[Luna Bliss]

I know you didn't mean to Arwen...who would think such a thing would be used for griefing.

It seems that if there's a way they will find it!  Oh well, being on the streets might be a greater harm..

[Toysoldier Thor]

---

Arwen Serpente wrote:

Very very interesting development:

All, and I mean all the orders that were stuck in "Queued" are now marked "Aborted". Somebody's reading what we are writing. So now, I have no idea if these customers got the items, and the money went to LL not me, or if the transactions were truly cancelled.

Does anyone know how an order becomes "Aborted"?

---

LL could be secretly reading these posts and / or it could be my Twitter posts this morning to @secondlife and @rodvik slamming their handling of all these issues with a link to the thread might also perked their attention.  a lot of LL staff and SL residents have @secondlife on their twitter follow.

[Czari Zenovka]

---

Amethyst Jetaime wrote:

---

Flea Yatsenko wrote:

DD was designed to avoid this problem. I don't mean to be a LL apologist, but Magic Boxes rely on a lot of very awful communications methods (like llEmail) which leads to long script delays and events falling off of the event queue and being forgotten forever by the simulator.

This is a known bug with magic boxes and it's probably giving your product away for free. I'm using DD and it isn't happening to me and I have scripts that notify me when an object is rezzed out. I know it sucks but you can't rely on an LSL script to handle the amount of data transactions required for interaction from a website. There are scripting limitations as well as network lag, sim lag, etc.

I know SLMP and the grid is in a bad place right now, but you really should get off of the box. I'm not the only one who has seen sales skyrocket since switching and I haven't had a single person message me for a redelivery other than people who didn't know where the received items folder was. With Magic Boxes, I would get them constantly.

A few weeks ago something awful happened to the grid and it's still getting sorted out. Whatever is going on is way beyond a simple SLMP/DD/Box problem. Just grit your teeth and hang in there.

If you are concerned about not being able to track what's been delivered, write or find a script that will notify you when someone rezes out a product. It's far more reliable than ANS, magic boxes, or transaction or order history.

---

Bully for you.  Just because your little corner of the world is all roses doesn't mean that this is not a showstopper issue for many others.  If I were you I'd keep your fingers crossed you won't be effected  - as it could start for you at any time.

The MP DD problems started to occur

way

before the recent problems with the grid so they are unrelated.  There are a LOT of  merchants who have seen their sales hit rock bottom and/or who aren't being paid and it is severely cutting into income that supports their SL projects and/or tiers or even their real lives.  They have a RIGHT to be on a "soap box" about it.

You advise about getting a delivery script is way off base too.  Knowing a product was delivered to a customer is not the problem here.  The problem is that creators KNOW they have been delivered and they have not been paid.  They not only reported the lack of payment problem on JIRA but have filed tickets on specific incidents when a customer admits directly to the merchant that they got the product and yet the merchant has NOT paid.  That is what is so disturbing.  Why haven't they been paid when the money was deducted from the customers account?  No script in the world is going to correct this, only LL can and they are not.

People have been severely effected by the fact that obviously LL introduced this way before it was ready to be released and now apparently isn't even doing what they can to remedy it even in a small way by at least paying merchants when product was delivered and who have reported the issue  DD is at this point a major FAIL.  Even the CEO has admitted this. 

And lest you think that you are totally immune, many people in SL have heard about this and have told me they have stopped shopping on MP all together and aren't shopping in world either.   So you are probably losing sales yourself.

---

THIS^^ In spades!  Yes I know there are some people who haven't been affected, thus far, but there are certainly more than a "few" who ARE affected.

Flea, for every time you say you had problems with Magic Boxes I will say I never had a problem - for FOUR years.  (Not trying to be argumentative - we've just gone over this a few times already. )  So yeah, a bunch of us who have been merchants awhile are torked off big time!!!!

[Czari Zenovka]

---

Blot Brickworks wrote:

I posted yesterday that I had a shutdown weekend with sales being the worst for years.

I have put off DD till the last moment because my sales until now have performed very well for over 3 years

and I have worked on the "if it aint broke" theory and left well alone.

I dreaded the change over and now have a couple of weeks to transfer.I will start today but with no confidence whatsoever.

I see this a the crunch time for me and SL,it's been fun and I made a few bob,but if LL does not pay for itself I will abandon land and walk away.

If LL loses people who have been with them as regulars because of this **bleep** up they only have themselves to blame.

They should never have got involved in competing with their paying customers at all.

I will post on how my transistion to DD goes ......

---

*Waves to Blot*  Great to see you

I'm pretty much at the same point.  Once the frustration level of dealing with these issues as a merchant and it's time for me to say "Aloha" and go do something else in SL.

As a sidenote:  I am participating in the upcoming Silk Road Hunt 3 for the month of June.  I had a great conversation today with one of the hunt organizers who is a long-time SL resident, builder, etc.  She says she won't use the MP (and sounded like she never has) because she's never sure how reliable it will be compared to in world and went on to say that all her friends do the same.  Just an interesting "feel" for the "shopping habits" of established residents.

She also mentioned that LL has always made it difficult for the small merchant.  I'm not complaining on this issue as I know my success depends on me; but I did find it interesting she mentioned this as a totally unsolicited comment and, as a hunt organizer, has worked with all different types of merchant stores, sizes, etc.

Maybe LL *does* want the average Joe to go away.  *Adjusts my tinfoil hat*

[Czari Zenovka]

---

Arwen Serpente wrote:

 

Since all of these things have happened (and other issues such as the inbox initialization difficulties), I have stopped listing new items on the Marketplace.  I've expanded the number of inworld stores and am focused on inworld business.  The Marketplace is very much taking a backseat in my Business plans until it is running smoothly and consistently.

---

After Deja's post a month or so ago about concentrating on inworld sales, I've begun doing this as well and had forgotten how much fun it is to actually BE in my shop and interact with customers.  Meeting some great people and having more fun on the merchant side than I've had in a long time.  So yes, I am planning on doing the same.  At this point, once the Magic Boxes are shut off, I do not plan to switch to DD until and unless the major issues are solved. 

[Czari Zenovka]

---

Zanara Zenovka wrote:

 

If it's any help, I use a IM/Email on-rez notification script so I can see when things have been received which makes life a lot easier (there's a free IM one here -

https://marketplace.secondlife.com/p/ArtiZan-Business-Script-IM-Creator-on-Rez-notifies-when-products-are-unpacked/3061369)

 

---

I would like to use this, Zanara (and thank you for the link!) - but since my items have copy perms, will it send an email each time a new copy is rezzed?  Even if it did...at least I'd know the first time something was rezzed.

But then, if we know something was purchased and we didn't receive the payment (I have no clue if this has happened to me or not) - it sounds like LL isn't going to do anything about that.  Just thinking out loud here to figure out what would be helpful for my business.

[Flea Yatsenko]

I'm not here to argue or anything, I'm just trying to make sense of what's going on since LL doesn't really tell us anything and it's up to us to figure things out.

The thing I noticed with Magic Boxes was that they wouldn't tell you things were wrong. It wouldn't say transactions failed, it wouldn't tell you it tried to deliver an item and there was a problem with the delivery. It would just not do anything. I had a lot of people skeptical of the fact that there was a problem with magic boxes, and that it was extremely difficult to even know you had an issue because it was silent from the merchant's view of things.

Sales would drop off a cliff at times when the grid was fine and other people were having good sales. I couldn't explain it, and when I'd ask other people they'd just say it was market fluctuations. I have a pretty big cataloge of products that span a wide range of markets. There's no way that all of the markets I'm in would suddenly fall in demand on the same exact day.

I had a theory that LSL scripts were getting lagged and getting hung up on delays. Everything that happens in a script gets put on a queue (which is kind of like a line to buy tickets at a movie theater or something), and the simulator works its way through the queue to do what the script requests.

The problem with magic boxes (at least my theory) is that when it would communicate through llEmail, it would delay the script for 20 seconds. The problem here is that when it's delayed like that, the simulator just lets things build up in the queue. The simulator has a limit to how many things can be in the queue, and once that limit is reached, it just starts ignoring things that get added. There's a lot of communication between the website and this script to verify things and make sure it's worked. If the thing to verify has failed, you're not getting any information back. I really think that things were getting lost in the LSL queue and it was causing things to silently fail. It doesn't seem like LL has anything built in for magic boxes that can't communcate with the website, and not hearing anything in return from the box probably caused all sorts of chaos.

The biggest indicator of this to me is the fact that a Magic Box that couldn't contact the XStreet or SLMP website still showed up as functioning perfectly fine on the XStreet Magic Box status page.

The big difference for me and DD is that when sales go bad for me, it seems like they go bad for everyone. This really tells me that the problem isn't DD or Magic Boxes, but another piece of software that's used in delivering products and handling transactions.

So, technically, if a magic box had to talk to the website three times in a minute, the script would be in the delayed state for an entire minute. Anything that the script would get (communcations with the website, requests to transfer items, etc) and anything it would try and do (contact SLMP website, transfer an item, verify payment) would then get thrown into the queue durring that time and if the queue got too big, those events would just be ignored.

DD was designed to get around this issue. The problem with DD right now seems to be that instead of having problems with simulators running LSL scripts, we're having problems with whatever handles the DD code executing it properly. My guess would be that the servers in charge of this are overloaded or affected by something.

I can see where LL tried to solve the problem of Magic Boxes, but it looks to me that from the state of the grid, that LL has done nothing more than mitigated the problem from LSL scripts in simulators to a closed off system merchants have no control over.

It is very interesting that Magic Box sales were booming at the same time my (and a few others I've talked to) DD sales were booming.

My guess is that there's several layers of software that get transactions finished. I would guess you have DD or Magic Box software that talks to another piece of software that verifies transactions, takes L$, and transfers products. If DD and MB are both being affected at the same time, it seems a lot more likely that the problem isn't DD or MB, but the problem is far further upstream in the SLMP software stack or hardware stack.

I really wish LL would just talk to us and tell us what's wrong and give a rough ETA of when things might return back to normal.

I just want them to fix things soon. I am building up a ton of products in Blender that I'm terrified to upload and there's no way I'm touching my marketplace store right now. Migrating to DD from Magic Boxes with the grid like this or even updating products seems like playing Russian Roulette with your products.

There is a ray of hope throughout all of this, however. It means that Magic Box deliveries have probably been extremely bugged and unreliable for a very long time, and failing without us as merchants knowing. When LL released the DD code, it seems like they might have actually fixed it for a little while, and then whatever happened on the 30th has unleashed a tsunami of fail which has hammer the grid and every bit of LL's datacenters. I think that when LL gets this fixed, there's a good chance that sales will be like they were last month. It's just mind blowing how messed up everything has to be.

[Zanara Zenovka]

---

Czari Zenovka wrote:

---

Zanara Zenovka wrote:

 

If it's any help, I use a IM/Email on-rez notification script so I can see when things have been received which makes life a lot easier (there's a free IM one here -

https://marketplace.secondlife.com/p/ArtiZan-Business-Script-IM-Creator-on-Rez-notifies-when-products-are-unpacked/3061369)

 

---

I would like to use this, Zanara (and thank you for the link!) - but since my items have copy perms, will it send an email each time a new copy is rezzed?  Even if it did...at least I'd know the first time something was rezzed.

But then, if we know something was purchased and we didn't receive the payment (I have no clue if this has happened to me or not) - it sounds like LL isn't going to do anything about that.  Just thinking out loud here to figure out what would be helpful for my business.

---

Ideally you'd be selling items boxed and just have it in the box - i find in practice you occasionally get someone rezzing the original box a 2nd time, but not often. I just filter all the notices to a particular folder and just search for names as needed anyway

[Zanara Zenovka]

---

Flea Yatsenko wrote:

Yes, sales are bad. They have been bad since April 30th. It has nothing to do with DD itself and it has to do with the fact that the entire marketplace and grid are in really, really bad places right now. I know, I switched to DD as soon as it came out and I saw my sales double the month I did. The next month was a little behind the previous, and last month was a record breaker again, even with sales being very severely affected the last week of my fiscal month (part of the first month was when I figured out how to fix the broken Magic Boxes and I saw sales with Magic Boxes double).

Since the 30th, my daily income has been about 50-75% lower than normal.

---

You're trying to diagnose a general trend from isolated data. Not everyone's sales follow that pattern. Look at factors related to your own visiblity/functionality/marketing.

[PeachJubilee]

 MBs never confirmed payment.  How or why would they do that?

 

You are extrapolating from behaviour under DD, (that items are delivered and there is no trace of this from the merchant's perspective,) that MBs were silently doing the same and that there's a common, marketplace back-end cause for this. 

That's not plausible.  Aside from the fact that if this were the case, we'd be no more aware of it with DD than with MB.  The awareness of an "invisible sale and delivery without payment" arises from customers communicating back to merchants about sales that from the customers point of view appear to have been routine and complete.  It's implausible that either DD or MB entailed any kind of mind control function that could alter the chances of a customer contacting a merchant about such a sale, so we'd not expect that DD would alter how aware merchants would be of such a problem if it was there all along.

 

Regarding the MBs' function:

MBs received instructions to deliver: if this fails, no product is delivered.

MBs send the product: if this fails, no product is delivered.

MBs notify the marketplace the item was sent: this must fail if an item is to be sent without leaving a trail for the merchant

MBs notify the merchant: this must fail if an item is to be sent without leaving a trail for the merchant.

 

So for the MBs to deliver a product without leaving any trail or giving any money to the merchant, the MB had to fail two tasks in an otherwise succesful transaction, and one of those tasks is completely independent of the marketplace back end.

As to no-payment, no-trail deliveries under DD, these cannot have the same cause as a no-trail delivery under the MB system.  Nothing on the backend is capable of preventing an MB from informing its owner that it sent a product, and the MB problems you identify cannot possibly cause DD failures.

 

So whatever is failing on the marketplace end cannot interfere with MBs sending out messages, and none of the reasons given for MBs failing can possibly effect DD transactions. 

 

Also, it's not true that the MB did not give information, and in fact it gave more information tham DD.  The box did not just silently fail without leaving a trace.  That just was not possible.  Only the marketplace, the single source for information under DD, could make an attempted transaction fail without a trace or trail.  So we have two sources of information with MB and only one of those sources could be responsible for silent failed transactions that leave no trace that a transaction was even attempted.  Under DD, that same source of information that could cause silent failed transactions that leave no trace is the only source of information.  You're not better informed, but in fact have halved the sources of information and the retained half is the unreliable half.

[ab Vanmoer]

---

Flea Yatsenko wrote:

DD was designed to avoid this problem. I don't mean to be a LL apologist, but Magic Boxes rely on a lot of very awful communications methods (like llEmail) which leads to long script delays and events falling off of the event queue and being forgotten forever by the simulator.

This is a known bug with magic boxes and it's probably giving your product away for free.

---

Actually that is completely back to front.  It is not a bug with the magic boxes but with the marketplace software.

The magic boxes are instructed to deliver a product and they deliver it, the magic boxes are not involved in processing the payment.

Irrespective of the mechanism (DD or magic box), delivery is initiated by the marketplace software, so moving to DD will make no difference to this particular bug, the only difference is that while we have the magic boxes merchants are notified of deliveries by the box allowing us to reconcile deliveries and payments.

Once magic boxes disappear this ability to track deliveries also disappears. The only alternative will be to include an on-rez notification script such as the one Zanara has so kindly provided in each product.

[Czari Zenovka]

---

Zanara Zenovka wrote:

---

Czari Zenovka wrote:

---

Zanara Zenovka wrote:

 

If it's any help, I use a IM/Email on-rez notification script so I can see when things have been received which makes life a lot easier (there's a free IM one here -

https://marketplace.secondlife.com/p/ArtiZan-Business-Script-IM-Creator-on-Rez-notifies-when-products-are-unpacked/3061369)

 

---

I would like to use this, Zanara (and thank you for the link!) - but since my items have copy perms, will it send an email each time a new copy is rezzed?  Even if it did...at least I'd know the first time something was rezzed.

But then, if we know something was purchased and we didn't receive the payment (I have no clue if this has happened to me or not) - it sounds like LL isn't going to do anything about that.  Just thinking out loud here to figure out what would be helpful for my business.

---

Ideally you'd be selling items boxed and just have it in the box - i find in practice you occasionally get someone rezzing the original box a 2nd time, but not often. I just filter all the notices to a particular folder and just search for names as needed anyway

---

Thanks, Zanara.   I'm still using the MB so all products are boxed.  Good tip on filtering the notices.  Going to grab that script now!

[ab Vanmoer]

---

Zanara Zenovka wrote:

Welcome back Ab!

Just wouldn't be a decent migration nightmare without you!

---

Thanks Zanara, Arwen, WADE1 and everyone else

Not really back just sticking my head above the parapets :smileywink:

I took the last migration far too personally, putting far too much unproductive time and effort into trying to browbeat the commerce team into behaving professionally. And in the end it was all for naught, the Marketplace went ahead bugs and all while the merchants were left scrambling, trying to correct failed migrations and redoing listings to comply with the reduced functionality.

To this day a large percentage of the bugs and the majority of feature requests languish in the Jira, completely ignored by the Lab. And considering that the majority of feature requests were requests for important functionality that had previously existed in xstreet, which LL have chosen to completely ignore, many of which a half competent programmer could have implemented in a few hours, seems to me to be a clear indication of the low regard the commerce team has for the merchants.

 

 

 

[Sassy Romano]

---

PeachJubilee wrote:

.

MBs notify the marketplace the item was sent: this must fail if an item is to be sent without leaving a trail for the merchant

MBs notify the merchant: this must fail if an item is to be sent without leaving a trail for the merchant.

---

Well... the architecture is broken because there are non transactional operations and by transaction here, i'm using the term "transaction" in the atomic defintion of it either completing in full or rolling back.

The issue with MP is that a MB could send an item and THEN FAIL to communicate back to the back end just as easily as there be a forward failure of the back end to communicate with the MB to send an item.

Once that return failure exists, the back end now is potentially in a holding state waiting for a retry of a timeout and in the case of a timeout, the MP back end could refund the customer.

My view on the broken back end is articulated here https://jira.secondlife.com/browse/web-4508 and closed as expected behaviour.  It's dysfunctional and will remain so.

Since we are mushrooms, we have to be kept in dark places and fed **** but it's not too difficult to reason what is in place.  Unfortunately, it's something that has grown from their take over of xstreetsl and the reality is that Direct Delivery was/is a quick fix but still has tenous links to other parts of the processes involved and nobody has the time or inclination or direction from management to drive this whole platform to a sound architectural solution.

 

[PeachJubilee]

---

Sassy Romano wrote:

---

PeachJubilee wrote:

.

MBs notify the marketplace the item was sent: this must fail if an item is to be sent without leaving a trail for the merchant

MBs notify the merchant: this must fail if an item is to be sent without leaving a trail for the merchant.

---

Well... the architecture is broken because there are non transactional operations and by transaction here, i'm using the term "transaction" in the atomic defintion of it either completing in full or rolling back.

The issue with MP is that a MB could send an item and THEN FAIL to communicate back to the back end just as easily as there be a forward failure of the back end to communicate with the MB to send an item.

Once that return failure exists, the back end now is potentially in a holding state waiting for a retry of a timeout and in the case of a timeout, the MP back end could refund the customer.

My view on the broken back end is articulated here

https://jira.secondlife.com/browse/web-4508

 and closed as expected behaviour.  It's dysfunctional and will remain so.

Since we are mushrooms, we have to be kept in dark places and fed **** but it's not too difficult to reason what is in place.  Unfortunately, it's something that has grown from their take over of xstreetsl and the reality is that Direct Delivery was/is a quick fix but still has tenous links to other parts of the processes involved and nobody has the time or inclination or direction from management to drive this whole platform to a sound architectural solution.

 

---

What you describe would probably not produce a silent, no-trail delivery.  If the MB does not send confirmation to the marketplace or marketplace does not process the confirmation, there would have to be a second failure in the same transaction for the merchant to not be notified that the product was sent. 

 

What I contest is Flea's suggestion that DD failures entailing billing customers and sending them the delivery without the merchant knowing a transaction had happened, were happening all along with MBs but were "hidden" because MBs are "silent" when they fail.  That's not the case though.  MBs are not silent when they send a product out.  They talk to the marketplace and they talk to the merchant and there has to be at least two failings for the merchant to not be aware their box sent something out.  If these failings were happening and were "hidden" and "silent" under MBs then they are more hidden and more silent under DD, not more visible and louder as Flea is asserting.

 

***Also (completely besides the point) I noticed I'm logged in as PeachJubilee again  but I'm more commonly Anaiya Arnold.

[Sassy Romano]

---

PeachJubilee wrote:

 

What I contest is Flea's suggestion that DD failures entailing billing customers and sending them the delivery without the merchant knowing a transaction had happened, were happening all along with MBs but were "hidden" because MBs are "silent" when they fail.  That's not the case though.  MBs are not silent when they send a product out.  They talk to the marketplace and they talk to the merchant and there has to be at least two failings for the merchant to not be aware their box sent something out.  If these failings were happening and were "hidden" and "silent" under MBs then they are more hidden and more silent under DD, not more visible and louder as Flea is asserting.

---

oh ok yes, I would be surprised to see any data on customers receiving an item with absolutely no trail or anything whatsoever, plus nobody would know unless you had a rez script or the customers said so.

[PeachJubilee]

It's difficult to know who is talking and knowing about what with so much going on.

Someone reported a transaction that was only reported in one place with an odd order number (two digits short).  They only knew because the customer spoke to them.  There is another thread with discussion of a seemingly similar case instigated when  a customer contacted a merchant who could not find their transaction records, but that turned out to be caused by fragmented reporting (stale shopping cart order with transaction completing, transaction reports and notifying email chronologically disparate), er, I think...  

In the midst of this there is some speculation that low sales might be about items delivering but not being properly processed by marketplace and that we'd never know because we get no indication that an item was sent unless the marketplace properly finishes the transaction and tells us so.

 

(Assuming I've understood their posts properly), Flea seems to think that the last problem is more visible to a merchant with DD than MB because MBs "fail silently", but I think that if the market backend does not process an order properly after the item has been sent, that with DD you cannot know the item was sent, only that you were not paid, but with the MB a merchant had a very good chance of knowing the item was sent and even when it was sent.  If they were there at the time, they'd even see their MB change color. 

Items being sent are now invisible to us.  We only have the marketplace information, so if there is a backend problem processing transactions in addition to the real MB limitations and glitches, then that will be completely invisible to merchants with DD. 

[ab Vanmoer]

---

Sassy Romano wrote:

 

Well... the architecture is broken because there are non transactional operations and by transaction here, i'm using the term "transaction" in the atomic defintion of it either completing in full or rolling back.

The issue with MP is that a MB could send an item and THEN FAIL to communicate back to the back end just as easily as there be a forward failure of the back end to communicate with the MB to send an item.

Once that return failure exists, the back end now is potentially in a holding state waiting for a retry of a timeout and in the case of a timeout, the MP back end could refund the customer.

 

---

I have on more than one occasion seen a payment appear in my transaction history long before receiving the magic box delivery message. This would indicate that the MP is not waiting for a notification from the box before completing the transaction.

There may of course be other reasons for things being reported out of sequence .... but as you so rightly said, as mushrooms all we can do is speculate.

 

[Sassy Romano]

That's no surprise at all, it is all horribly disconnected and not transactional.

HOW IT IS NOW (more or less):-

Event 1.  Payment made to Commerce Linden, item added to "Order" queue.

Event 2. Queue processor trundles through Order queue and sends message to deliver

Event 3. Magic Box or Direct Delivery sends back "Success" status updated to "Delivered" and sends email.

Event 4  Payment reconcilliation process reconciles the payment from Commerce Linden to Merchant.

Any one of these can fail and there's little further work done.  For example, breakage between Event 3 and 4 when Direct Delivery items contained Unicode.  Payment couldn't be reconciled but the customer received the item and Commerce Linden was paid.  Merchant UNPAID.  MAJOR HUGE FAIL!

Failure at Event 3, requires that the MP have a process that cycles through the order queue and refund any failed/timed out orders.  ARCHITECTURE FAIL.  Customers disatisfied, hugely extended wait times before either delivery or refund.

Failure at Event 4.  Products delivered, Commerce Linden paid, merchant NOT paid.

Failure after Event 1.  Customer out of pocket and has to wait for the order processing queue to time out before refunding.  Customers disastisfied, hugely extended wait times before refund.  Commerce Linden has the money though, merchant NOT paid, unable to satisfy customer (outside of a goodwill gesture, something that LL lacks).

HOW IT SHOULD BE (more or less):-

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

Funds maintained directly between customer and merchant, easy resolution of all issues.

Transaction is transactional, it either completes in full or not at all, no part should be left hanging and unreconciled.

Asked for in https://jira.secondlife.com/browse/WEB-4508 Closed, will not finish, dysfunctional is "expected behaviour".

It is what it is.

[Toysoldier Thor]

<START TRANSACTION>

   1. Customer purchases off MP
   2. Transfer funds direct from customer to MERCHANT, pay LL commission.
   3. Direct Delivery of product to customer
   4. Update records, send ANS etc.
<END TRANSACTION>

 

I agree with the order of the transaction Sassy but what if there is a failure within a step - specifically step #2?  i.e. if during payment transfer from Customer to Merchant.... the process dies?  Transaction has stopped.  How do you propose Backout of the step so that no party is injured from the failed process?

There needs to be oversight checks and balances that monitors each step of the transaction and takes action if a critical process of step fails to complete.  This oversight process would also be responsible for generating all the status reports, updates, and notifications to any required consumer of this needed staus data.

[Sassy Romano]

Indeed Toy, i'm referring to the atomic nature of a transaction rather than specifics.  The point being that it either all completes successfully or backs out to no change.  This doesn't happen at present as has been demonstrated numerous times now, each time with either the customer or merchant left hanging financially.

It's not good enough although from LL's perspective, because it's just a toy platform and we're just considered children playing in their corporate enterprise, we are mere users and therefore it's "good enough".

I could put down so much more but it has all been said before so there's no point.

[Ann Otoole]

Some observations.

Waiting till now was a good idea as the process of converting is rather simple and seems to work as long as the back end systems are purring along happily.

Sending multiple folders has issues so one at a time it is. Seeing stuff pile up in lost&found on send to slm is disturbing.

Suddenly my sales have returned to more normal rate. But only on items that are now direct delivery. Magic box items are not moving.

Hopefully I can get this process completed this week.

 

[Luna Bliss]

I sent my 340 items to DD in 4 chunks...but I am using Firestorm. One chunk had 90 items.

V3 does not allow many items to be dragged into the outbox folders at the same time.

Also, be sure you're logged into your MP area when you do this...seems to prevent this 'won't initialize' thing.

 

 

[Flea Yatsenko]

The intermediary step with CommerceLinden is the step where transactions fail and the merchant has no idea the transaction has happened. An SLMP transaction has two steps before the merchant is even attempted to be contacted. A failure in any of those steps results in a potential customer trying to make a sale, then having it fail, and you as a merchant having no idea it has happened because the message to deliver the product never makes it to the target.

I'm also assuming that DD only notifies you after a request. We know Magic Boxes don't contact you until the product has been delivered (step 3).

The question is when is a transaction reported as underway in transaction history? Is it when the potential customer clicks the button to purchase? Does it start at any one of those steps? My guess is that the order queue is the cause of most of these problems. If you end up in a queue with a bunch of Magic Boxes that are taking forever to communicate or the DD backend is flooded, the queue would eventually have to drop orders from the queue before the queue starts to consume more ram than the server running the queue has.

If funds went directly to the merchant and the transaction failed with the current system, either LL would have to debit your account (no way I would ever trust them to do this properly) for the failed transaction after it gave you L$, or customers would have to request a refund or redelivery. From my experience, most merchants could care less about redelivering a product, so odds are a lot of merchants would just end up keeping customer's money while customers get ripped off.

You would need a web page where customers could have the item redelivered, but only after verifying the order completed and the merchant has transaction history showing the transaction took place. I think that a system like that would be far more reliable, and it would still allow customers to have their own items redelivered.

I think an ideal system would work like this

1. Customer presses button, creating a transaction.

2. Request is made to debit customer's account

3. L$ is sent to merchant

Then, the next step would be completely independent of the previous. If the first three steps fail, the merchant is notified (as soon as the customer clicks on "buy"). As long as the merchant gets his L$, the customer could have the item redelivered because it's using the existing transaction database.

1. Delivery software reads transaction history of merchant to verify customer paid for item

2. Delivery software delivers item

3. Customer has delivery status page that says product delivered. Redelivery would involve checking against transaction history of the merchant and verifying the merchant was paid.

With SLMP, I really think the biggest problem is that LL is adding layers of complexity that don't need to be there. LL has a habit of doing things like this.They need a system that uses more of the existing logging and data that works instead of throwing more and more databases and software at the problem.

The forum reply textbox is a good example of LL doing this. Firefox and Chrome all come with spell checkers that work great. You type, if you misspell a word, it gets a red squiggle underneath it. LL has replaced the textbox that supports this with a rich text editor that hides the Firefox and Chrome spell checkers, and instead we get the LL spellcheck which, as many of you know, don't know words like "roadmap".

Another example is Order History and Transaction history. Two areas that both log data and serve the same purpose, yet give different results (probably because they're separate databases or tables in a database). LL should be consilidating technology and creating a smaller, more efficient backend to the grid and SLMP. Instead, they just seem to be throwing layer upon layer of abstraction on top of their software stack to fix issues they have. So LL needs to have two instances of logging SLMP transactions, and yet another for accounts?

Has LL stopped a thought about the fact that they have so many issues is that they are maintaning 3 times as many options as they need? Augment the avatar transaction history to also handle SLMP orders, and suddenly things are a lot easier. You have a CommerceTeam that can focus on improving the shopping experience, search results, adding features (like multiple SKUs in a listing) instead of trying to keep track of two databases for logging sales data.

Sassy is definitely right about this process being transactional. As it stands, if one of the steps fail, the entire thing fails. If it was properly implemented, it wouldn't just stop if one part of the equation failed, It would offer merchants and customers work arounds and the ability to start where the process last left off. There is absolutely no reason why DD or MB (MB would have to poll a web URL to check the transaction occured) can only deliver the product after verifying a transaction occured.

DD was LL's attempt at fixing this problem. My guess as to why they settled on this instead of actually fixing the problem is that the people behind SLMP don't have access to a lot of the code in the rest of the grid and they work independently of other teams. It was mentioned before that Brooke and Dakota can't tell us anything, because they simply don't know anything because other teams are working on the issues.

This tells me that SLMP is in such a terrible place not because of the things that CommerceTeam has done, but because of management (or lack of). It is good everyone is trying to get Rodvik's attention to this instead of taking it out on CommerceTeam. Rodvik worked at EA and he probably doesn't have a lot of experience with e-commerce. LL needs to consider hiring an e-commerce guru that previously worked at a site like ebay or amazon.

 

[Kampu Oyen]

>After Deja's post a month or so ago about concentrating on inworld sales, I've begun doing this as well and had forgotten how much fun it is to actually BE in my shop and interact with customers.  Meeting some great people and having more fun on the merchant side than I've had in a long time.  So yes, I am planning on doing the same.

So you see - DD is working perfectly, just as intended.