|
|
|
[
Permlink
| « Hide
]
Strife Onizuka added a comment - 30/Aug/07 10:43 AM
Not sure about fraud but it would make business customer service easier.
I strongly support this proposal. The fact that an object cannot tell whether llGiveMoney has succeeded or not is a major shortcoming in the design of LSL. It causes a lot of customer complaints which take a large amount of time to resolve.
This would be immensely useful and really should have been implemented a long time ago.
See also for a proposal of a similar event and related comments.
(As in, see also SVC-177 which I've linked to this.)
inventory_given would be great, too. But there's a related issue that needs a proposal. I have had to deal many times with people who accidentally mute me (it seems too easy to do, apparently) and they can't take delivery of a product. And then, they don't know they can't get communication from me.
llGiveMoney() is almost useless without at least a boolean to show if it was a success. It makes it only safe to use in a refund situation, when the money is known for sure to be there. Otherwise, it's crippling a good portion of the automated SL business that should, by now, be out there.
It's quite staggering to imagine how many hours in SL are wasted by simply going in to pay rents and such when just one wee bool in the right place would sort it all out. This is paramount, and its absence is really rather embarrassing to coders outside of SL. This is very important to me because I have made a HUD that allows users to create things which they can purchase directly from the HUD. I can't use the normal pay object method because it only pays the owner of the object, when it needs to pay me. The only option in this case is to use llGiveMoney. The problem with llGiveMoney is that it never returns a value (it's always 0 even though it is a function) and does not trigger the money() event. This means there is no way to check if a payment was actually made, or if the funds were insufficient. I would be happy if llGiveMoney just returned a 1 if it succeeded or a 0 if it failed due to insufficient credits. That is all that is needed here I think.
Upgraded to critical because there is now an Abuse Report type called "Commerce - failure to deliver goods and services". This means failed transactions can result in vendors being banned or suspended.
If we can be reported for failing to deliver, we need to be given the tools to ensure delivery. Darling Brody I see this as critical as well. I have been called a "SCAMMER" twice in the last week for failing to pay someone when my script reported to them that they were paid.
In one of the cases, my transaction log shows 2 out of 3 payments going through, when there was plenty of money in the account. It appears to simply be a failure of llGiveMoney(), since I made sure the script only reports the payment if llGiveMoney was called. I am not getting any script errors, it is reporting that the function is being called (with a positive amount less than my balance), and yet the transactions are simply not going through. In at least two other cases, all llGiveMoney() requests did not result in transactions, for a period of time (several hours). I started receiving complaints, rerezzed the money giver and reset it and it started working again. A second instance of it worked fine all the way through. So it's like it... lost the ownership or something and could not give money. Or suddenly lost the permission. I have added new code now to detect the loss of permission and to report it and disable the script if that is detected, but it I am just guessing at why llGiveMoney() could have started failing in one object, at this point. This means the Second Life financial payment process, at least from scripted objects, is unreliable. How can anyone carry on scripted business transactions when the cash balance can't be checked or tested beforehand, and even ignoring that (I had to implement a "bank" object so that I would be able to track the balance), payments / money transfers to other residents MIGHT be successful, might not be, with no way for a script to know if they are? This is an enhancement request if llGiveMoney() was reliable. I learned this week, after hours of reviewing transaction histories and log files that llGiveMoney is clearly NOT reliable. We need a way to know if a money transaction failed (was discarded or lost). Even if there was only a money_not_given(reason) event, at least we could record that and manually correct it later. But I like the proposal above, very much. This issue was originally raised nearly 2 years ago, and its status was raised to critical a few months ago. I've also had private conversations with Lindens and it is recognised that this is a serious shortcoming. But, we have had no official comment whatsoever from Linden Lab on this important topic.
Come on Lindens, if you are serious about people being able to do business in SL, please give us the tools to be able to do it instead of spending huge amounts of development effort on supporting "adult" content, and other things which are of little or no interest to most residents. I agree 100% with Lamorna. Come on Lindens!! This is a VERY HUGE problem. Please take it seriously.
Can we at least get some feedback? Please? SVC-2224 is a generalization, not a duplicate of this issue.
I can understand why they would not want to, currently there is no way of knowing if a transaction succeeded unless you have a bot watching the transaction log. This means that an account cannot be easily emptied of all it's L$ without sending up red flags. By knowing the balance or knowing if a transaction failed, you can know when to stop filtering money from an account.
while (TRUE) {
llGiveMoney(AgentKey, 100);
}
That's how easy it is to drain an account now. @Strife
Noone is asking for a BALANCE of your account in world, which is what you would need to drain and account without using a loop like Lavanya posted above. We are asking for a YES NO answer for when a transaction worked. ie. Send money. ((( Did it get there ))) Send products. This infroamtion is already available via the transaction history page in real time if you want to run a CURL/PHP script on an external server to read it and then alter the scritp every time LL alter the format of the transaction history page. .....SO... there is no reason why it cant be returned in a data server event. Just an integer will do. 0 for failed, and Positive integer for the transaction number from the history page when it works. @Darling, Strife, People are probably cross-posting their ideas but I think it's SVC-4699 that's asking for that. Wouldn't surprise me if someone people are also confusing the two issues.
Incidentally, I am strongly in favor of this issue. This should have been in place from day one for all transactions and it's a travesty that it isn't there especially as, as mentioned above, people can be abuse reported for SL screwing up transactions. There are blog posts online that reveal how to work around llGiveMoney(). Our company has lost hundreds of thousands of lindens to avatars exploiting this. This is a much needed development.
With the increase of blog posts about ways to exploit this, our company has also lost a significant amount of L$ due to this issue. It's unthinkable that LL has let this sit without even commenting on it since 2007. Honestly, because of the exploits this opens up, this is truly a bug/security issue rather than a new feature request.
Dont count of this being implemented any time soon. This issue has been asked for many many times with no luck.
The best solution is to create vending machines and delivery servers which check the payment history before handing over the product. Unfortunantly such automated login functions are regularly blocked by LL to stop automatic account hacking. What we really need is a url that only works from in world which returns the transaction page as a list. The idea is for the a URL like PaymentHistory.secondlife.com to return the payment history for the owner of the object. Then it is just a matter of matching one of the payments with the request for product delivery using LSL. I'll split this suggestion off as another issue as it can be implement easily. webpage interface is far easier for the labs to do than adding functions to the scripting lanaguage. Let's be clear about this. If your script receieves the event for payment recieved, it's a near certainty that you got paid and can dispense your product or service. The problem I reported is when your script attempts to pay someone. You have no way in your script to know if it failed. This makes auto-pay scripts for rent or wages impractical, unless you trust the owner of that object never to be out of money. Your basic vendo or rento is not affected.
Lavanya, I really do wish that was true. With the exploits that have been posted online in recent months, receiving L$ is nowhere near a guarantee that it is safe to dispense product. Just off the top of my head, I can think of three unique exploits that are commonly abused at the present time related to this that having this return would prevent.
@Lavanya Hartnell
Networked vending machines are effected. that is when you own the vending machine. the customer pays you. you pay me. and i deliver the product to the customer. dishonest people will use exploits to prevent the creater being paid. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Critical
llGiveMoney() method needs a money_given() event handler.
