Upcoming LSL feature: llTransferLindenDollars and transction_result

[Kelly Linden]

---

GummieBear wrote:

Just a quick Q about this, great work By the way, as this results in a transaction id, will there eventually be a way via script or HTTP request to 'pull' and view a given transaction record? if this already exists please let me know as well.

 

Peace.

---

There are no plans at this time that I am aware of for this kind of feature.

[Kelly Linden]

---

MB Robonaught wrote:

Hi that'll be handy when available. I was wondering are there any plans on having a way to save multiple replies from the function in a text form instead of just memory? In memory that can really lag things bad if one is getting dozens of hits and even hit the cap for list storage

---

Not that I am aware of at this time.

[Vagabond Carter]

MB Robonaught wrote:

Hi that'll be handy when available. I was wondering are there any plans on having a way to save multiple replies from the function in a text form instead of just memory? In memory that can really lag things bad if one is getting dozens of hits and even hit the cap for list storage

---

One solution is to ship it to out-world storage, such as email via llEmail or a web server with http_request, that way at least you could have a reference you could look at later for comparison if an issue arises.

[Cold Spitteler]

data will contain a CSV of destination id and amount transferred on success and an error tag on failure.

 

I would interpret this to mean that on success there would just be 2 items in the cvs list and on failure there would be a third, currently on failure you just get the error tag.  I think that both the destination id and a amount transfered should also be included on failure.  This will allow the script to more easily retry a failed payment.

 

example:

    transaction_result(key transaction_id, integer success, string data)    {                list data = llParseString2List(data,[","],[]);        string error = llList2String(data,2);                if(error != "")            llTransferLindenDollars(llList2Key(data,0),llList2Integer(data,1));                  }  

 

[Honza Noyes]

Great idea, completely agree with that, but the status would have to be returned all the time with data because if they in future make the string data return more stuff, it would break back-compatibility.

Would be just enough to have the success return 1,2,3,4... and have those values stand for certain error, just like PRIM_POSITION or so.. But it would be great to have the function return the agent and amount all the time.

[Alexi Raynier]

Rather than adding a new feature why not do something really radical and needed, curtail adding new material for the rest of this year and actually take the time to fix the problems that have been caused by piling half tested or maybe untested new features onto an already overburdened system.  I realize this is a bit to ask of LL, but we do pay for adequate service and they are giving anything but adequate service at this point and it is high time they fixed this mess before it carshes around them like a house of cards.

[DirtRider Bingyi]

This is a very important feature.

[TaraLi Jie]

Frankly, most makers and significant users of vendors that I've talked to *DO* consider this a major bug fix.  The previous calls are being left in place for the time being under the Linden Lab policy of not breaking content, but in the future will likely be marked deprecated, and eventually removed.  This is a much more important fix for most people, I believe, than any other bug in the system right now.  Vendors able to tell when a transaction fails, and why?  Oooh, I can see LL's support costs falling rapidly!  Go look at SVC-114 on the JIRA, where Intan has been sending people to post about inventory loss - I expect a number of those complaints would have never occurred, because the system would be able to tell the user *WHY* the transaction failed.

[Argent Stonecutter]

---

Kelly Linden wrote:

• data
  will contain a CSV of destination id and amount transferred on success and an error tag on failure. 

---

Is this a good idea, given that the Linden CSV parsing functions are broken?

See SVC-285 for details.

I saw in a previous comment that you believe this to be more general, but really a list is more general since it can contain any type without quoting or casting errors (eg, from converting between floats and strings).

[Kelly Linden]

This feature is now on the LeTigre RC.

https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_RC_LeTigre/11#11.11.30.245889

[Honza Noyes]

Oh great work! Thank you Kelly!!!!

[Sayrah Parx]

Would you be able to include VWR-24513 in the scope of this project?

[Oskar Linden]

The RC channel LeTigre is scheduled for promotion next week. After the Wednesday rolls this feature will be available in all regions on the main grid.

__Oskar

[Taff Nouvelle]

will it be possible in the future using this function set to check if an item sent by a vender was actually received by the customer?

[Strife Onizuka]

I've gone ahead and written documentation for the functions based on the RC release notes.

http://wiki.secondlife.com/wiki/Category:LSL_Transfer

https://wiki.secondlife.com/wiki/LlTransferLindenDollars

https://wiki.secondlife.com/wiki/Transaction_result - I'm not happy with the table. Will revisit it later.

[Kylie Jaxxon]

---

Strife Onizuka wrote:

I've gone ahead and written documentation for the functions based on the RC release notes.

http://wiki.secondlife.com/wiki/Category:LSL_Transfer

https://wiki.secondlife.com/wiki/LlTransferLindenDollars

https://wiki.secondlife.com/wiki/Transaction_result

- I'm not happy with the table. Will revisit it later.

---

Wow...long time, no see.  Hope all is well and Happy Holidays!

[PurgatoryTech]

>> The only script in an object which will get a transaction_result event is the script that called llTransferLindenDollars. This is similar to how the http_request event works.

Actually, that's not how http_request event works. The http_response is sent to the prim, not the script, so you can send http requests in one script and receive the responses in another - which I do in one of my huds to distribute processing.

Whether this is the same for llTransfer events I don't know, but you are welcome to try it out :-)

[Kelly Linden]

There are two sets : llHTTPRequest / http_response which works as you describe and http_request / llHTTPResponse / llRequestURL which work as I described.

[Kelly Linden]

---

Strife Onizuka wrote:

I've gone ahead and written documentation for the functions based on the RC release notes.

http://wiki.secondlife.com/wiki/Category:LSL_Transfer

https://wiki.secondlife.com/wiki/LlTransferLindenDollars

https://wiki.secondlife.com/wiki/Transaction_result

- I'm not happy with the table. Will revisit it later.

---

Thanks strife.

[Cold Spitteler]

SERVICE_ERROR is returned in some situations where the transaction was succesfull.

https://jira.secondlife.com/browse/SVC-7623

[Lyle Maeterlinck]

I just wanted to say thanks for implementing this function. I think the ability to confirm a successful transaction before delivering a product is critical. We will be building this into the newest version of our affiliate vendors to replace the much more complicated system we currently have in place to confirm transactions.

[Kelly Linden]

---

Cold Spitteler wrote:

SERVICE_ERROR is returned in some situations where the transaction was succesfull.

https://jira.secondlife.com/browse/SVC-7623

---

This was determined to be an error in the lsl scripts and not a bug in llTransferLindenDollars. Specifically the scripter had added his own timeout which was shorter than the time a successful transaction could take and was not verifying the ID in the transaction_result message matched the one given by llTransferLindenDollars. This meant the script would associate the results with the wrong transactions.

 

• Always verify the transaction_result id matches what you expect. If possible keep a list of IDs to handle the case of multiple transfers.
• A transaction can take up to a minute and still succeed.

[Kelly Linden]

---

Lyle Maeterlinck wrote:

I just wanted to say thanks for implementing this function. I think the ability to confirm a successful transaction before delivering a product is critical. We will be building this into the newest version of our affiliate vendors to replace the much more complicated system we currently have in place to confirm transactions.

---

Glad you are finding it useful.