Script That Allows Purchase From the Demo?

[FairreLilette]

Is there a possible way to add a script into a DEMO which would allow a person to click on the DEMO HUD and choose purchase?  Or perhaps for a demo to include a separate purchase HUD along with the DEMO?

If this were an option, would you like this option - the ability to purchase the item right from the DEMO instead of having to go back to the (inworld) store?  

Maybe this wouldn't be so great for clothing that has many colors because that would be a lot of items to load into such a HUD but what if it were for hair or skin or makeups plus other items?    

I'm mostly asking because it is some times difficult to go to the store and find the item again (especially if too much lag).   Me personally, I'd love it for hair.

I think I'd also love this ability to buy right from the DEMO because then I could quickly delete all my other demos...it might help to keep my inventory organized.  

Opinions?  Comments?  

Edited May 3, 2020 by FairreLilette

[Claireschen Hesten]

It's doable i have an item of footwear from Riders where the HUD shows all the available texture/customise options that certainly way back in 2013 when MP says got them could be bought from the HUD 

[Rolig Loon]

You could certainly write an easy script that opens a link to the page in the creator's MP store where the full item is.  That would be a nice, secure way to make a purchase without needing to got to all the trouble of searching MP for it. 

[missyrideout]

Funny you should ask, I was wondering this very thing today! It would in theory be great for busy events. You take your demos home, make your choices and click buy. On the other hand it’s somewhat alarming when an attachment requests permission to take L$ from your balance. If some reputable creators or even caspervend implemented such a feature,  I bet people would use it. 

[missyrideout]

Feel like it would be great for sales. A large part of my cost saving on SL is forgetting to buy demos I liked..... 

[Chaser Zaks]

You can do this securely, however it comes at a cost.

Basic idea of what you'd need to do:

1. Have a button to "buy full version" on the hud
2. Pop up a dialog explaining the debit permission, as well as a confirmation
3. Request debit permissions
4. Make payment through LLTransferLindenDollars
5. Verify payment through transaction_result
6. Send HTTP request to a server somewhere authenticating the payment
7. Have the server send out a copy of the full version

The cost:

1. First and foremost, you have to get the resident to trust you with the debit permission, which is already big and scary message. Some people may take this as a scam and start spreading rumors.
2. You also have to be able to have a server somewhere that can process transactions. If  you are using something like caspervend, you might be able to set up a API, but I don't know if they do have a API.
3. If the payment succeeds, but the authorization fails with your server, you cannot issue a refund because the debit permissions is with the resident, not you. So you will have a angry customer.
4. You have to make sure that your script transfers no more than what the resident is told will be transferred, otherwise it can constitute as fraud, which LL is not friendly towards.

Overall, I would say that this is more of a hassle than it is worth, especially if you do not have someone who is very familiar with handling LSL transactions and how to properly deal with them and make fail safes.

My advice, just link them to the MP.

[Rolig Loon]

8 minutes ago, Chaser Zaks said:

First and foremost, you have to get the resident to trust you with the debit permission, which is already big and scary message. Some people may take this as a scam and start spreading rumors.

That's precisely why I suggested simply writing a script that leads directly to the MP page where you can buy the real article.  The potential buyer will be paying through MP, so there's no question of security.  I would hope that NO resident would be foolish enough to believe a HUD that says, "Here, trust me to take money from your account to pay for something that you can buy from Marketplace yourself."

[Chaser Zaks]

4 minutes ago, Rolig Loon said:

I would hope that NO resident would be foolish enough to believe a HUD that says, "Here, trust me to take money from your account to pay for something that you can buy from Marketplace yourself."

well... about that....

People for some reason just press "Yes" on stuff without reading it, which is why this I created a issue regarding it, and LL decided to accept: https://jira.secondlife.com/browse/BUG-228237

Edited May 3, 2020 by Chaser Zaks

[Nova Convair]

I would never give an attachment or demo permission to take L$ - I would be pissed and buy somewhere else if that premission request ever pops up.

 

[Bitsy Buccaneer]

5 hours ago, Chaser Zaks said:

1. First and foremost, you have to get the resident to trust you with the debit permission, which is already big and scary message. Some people may take this as a scam and start spreading rumors.

Shudders at what might happen if this approach became accepted and people lost their respect for that purposefully big and scary message... IMO that's reason enough to say a giant no to this immediately. It would foster conditions where scams become easier.

(besides everything else that Chaser wrote)

[Maitimo]

I would love for demos to have a link to the full MP item, but no way on earth would I trust one to directly take L$ from me.

[FairreLilette]

11 hours ago, Rolig Loon said:

That's precisely why I suggested simply writing a script that leads directly to the MP page where you can buy the real article.  The potential buyer will be paying through MP, so there's no question of security.  I would hope that NO resident would be foolish enough to believe a HUD that says, "Here, trust me to take money from your account to pay for something that you can buy from Marketplace yourself."

Okay, I didn't even think that is what would occur because I've had to deal with that with tip jars since I have a little club and I always would hit DENY and I thought it was a scam...but my tip jars would never work.  I think that "taking lindens from you" is a permission for tip jars when you have A SPLIT and/or for contest boards when you ALLOW A MANGER to work the board.  The reason a tip jar or a contest board is asking if you will allow lindens to be taken from your account is because of the split even though it doesn't take lindens from you...but the contest board does.  Let's say you have a club and a contest board and you set that board to allow manager(s) to work it under the config card...it IS allowing someone else to take lindens from you IF say you are not at the club and a manager is working the contest board.

I do not understand why there would need to be a script asking such a thing for a purchase if say there were a space to click purchase on a purchase HUD?  I don't get that nor did I ever assume that would be the case because that's a third party or completely different kind of thing needed for clubs for objects where it's more than one person allowed to use the object yet the object's owner is only one name.  

We know darn well we can pay for a lot of things inworld without such a message INCLUDING Gachas from machines which have no such message.  It's through a vendor type of script.  Allowing someone to take lindens from you is allowing someone else access to your lindens IF you own a club and it's through config cards you give another person access to either your tip jar or contest board.  So, still I don't get the logic here about allowing lindens...it's absolutely 100% NOT necessary. 

For a HUD to work like this, it needs some kind of vendor then or what...there is no need to allow someone else to take lindens from you as it's not a contest board that you are allowing managers to work or anything like that.  

And, I'm mostly talking ease of use for inworld only because not all stores have demos on MP.  I encountered a small store on MP yesterday but then inworld in the store found a whole bunch of hairs; whilst on MP, the are but a handful.  I'm thinking for inworld because of lag and/or having to then go back to the inworld store and look around to find the item again.  

I also like one very full store listed on MP that has absolutely NO demos whatsoever and on average the items are about 400 lindens each.  You have to go inworld to get the demos.  There is another rather large store on MP I found yesterday with NO demos.  Not everyone on MP has demos.  Plus for busy events, it would be great.  All you'd need to get is the demo and then you can purchase from your lag-free home.  

Edited May 3, 2020 by FairreLilette

[FairreLilette]

10 hours ago, Chaser Zaks said:

Requesting Debit Permissions

There is absolutely 100% NO REASON to have this script in objects unless it's for items like a contest board with a config card where you are allowing managers access to working the contest board (see my post above) and it pays out of your account when the contest ends.    A purchase HUD wouldn't need anyone to allow managers to work any kind of a purchase HUD.  

This needs a proper vendor system made, most likely through CasperVend or something like that plus ignoring what Chaser wrote as that is utter nonsense and I think Chaser is way off base (see my post above).

I think to create such a purchase HUD needs someone new school not old school to figure out.  It would need a universal vendor script put into the purchase HUD.  Someone with a reputable name like CasperVend.  

I am contacting those who work with CasperVend right now to see what they have to say and if they could make such a vending system.  

Edited May 3, 2020 by FairreLilette

[Rolig Loon]

It all comes down to trust.  When you receive a scripted object like a HUD, you have no way of knowing how it works and what may be lurking in its innards. Scripts are generally distributed no mod, to prevent people from stealing or altering them. I could certainly script a HUD to send me money when you click it to buy something from me, but you have no way of knowing who you are sending the money to and no guarantee that you will get what you paid for. The same is true if you buy from a vendor in a shop in world, of course, but at least there you are in a shop where you have a better chance of knowing who you are dealing with.  If you buy stuff through the Marketplace, you know you are dealing with Linden Lab.  If you can be sure that a script in some random HUD is managed by a reputable outfit like CasparVend, you may generally feel a bit safer, but how do you -- the buyer - know that you're really dealing with CasparVend?  

All of that aside, any vendor script has to use llSetPayPrice or llTransferLindenDollars and other functions that require the script owner to provide PERMISSION_DEBIT.  In a shop, the script owner is the shop owner.  In a HUD, the script owner is YOU. And as the LSL wiki reminds scripters,

Once a script has the PERMISSION_DEBIT permission it can empty an account of L$.

 

[Adam Spark]

Even debit permissions still require a pay action on the users end, or receipt of lindens by the user. The permission just allows an object to take the Ls you tell it to take.

Take the Relay For Life kiosks. I rez one and accept debit (I have to do this so that the money I get gets funneled automatically to the American Cancer Society). The kiosk is still not capable of blindly removing my lindens - just the lindens that the kiosk pays me.

So with that said I am sure it could be done without trust being a part of the equation.

[FairreLilette]

5 minutes ago, Rolig Loon said:

It all comes down to trust.  When you receive a scripted object like a HUD, you have no way of knowing how it works and what may be lurking in its innards. Scripts are generally distributed no mod, to prevent people from stealing or altering them. I could certainly script a HUD to send me money when you click it to buy something from me, but you have no way of knowing who you are sending the money to and no guarantee that you will get what you paid for. The same is true if you buy from a vendor in a shop in world, of course, but at least there you are in a shop where you have a better chance of knowing who you are dealing with.  If you buy stuff through the Marketplace, you know you are dealing with Linden Lab.  If you can be sure that a script in some random HUD is managed by a reputable outfit like CasparVend, you may generally feel a bit safer, but how do you -- the buyer - know that you're really dealing with CasparVend?  

All of that aside, any vendor script has to use llSetPayPrice or llTransferLindenDollars and other functions that require the script owner to provide PERMISSION_DEBIT.  In a shop, the script owner is the shop owner.  In a HUD, the script owner is YOU. And as the LSL wiki reminds scripters,

Once a script has the PERMISSION_DEBIT permission it can empty an account of L$.

 

Yes, I was thinking it would need a reputable name PLUS a way to identify itself with said reputation...such as an introductory message and/or website to visit once it begins it's attachment to the wearer.  If it's a wear HUD only...I'm wondering if there would be a way for the vendor to read the avatar to somehow help keep it fool proof?   

Also, I don't USE VENDORS AT ALL inworld for my store.  I just rez the objects and the objects are the vendors themselves which I set to BUY not PAY I believe.  I don't use vendors because I didn't know how they work and since it's such a little store for Dinkies, I didn't have time to do the pictures yet and that's why those particular Dinkie items I have are not listed on in my MP store - because I haven't had time to do any photos nor the desire to really since coronovirus kind of deflated my balloon in general.

But, of course, this needs some kind of reputable vending system and a way to identify such reputation.   But, I feel like this thread has completely wrecked the whole idea by scaring people and I feel I don't even want to be part of this thread any longer.  

[Rolig Loon]

4 minutes ago, Adam Spark said:

The kiosk is still not capable of blindly removing my lindens - just the lindens that the kiosk pays me.

Yes it is, and that's exactly what some of the objects that scam artists distribute to unknowing residents do.  The user clicks the object and authorizes PERMISSION_DEBIT, and then the script jumps directly to a timer that calls a money event every few seconds, transferring an unknown number of L$ every time until the user's balance is empty.  It's a sad but unfortunately common scam. 

[FairreLilette]

50 minutes ago, Rolig Loon said:

Yes it is, and that's exactly what some of the objects that scam artists distribute to unknowing residents do.  The user clicks the object and authorizes PERMISSION_DEBIT, and then the script jumps directly to a timer that calls a money event every few seconds, transferring an unknown number of L$ every time until the user's balance is empty.  It's a sad but unfortunately common scam. 

Okay, but some script tip jars come with those but the script splits the money (through a UUID and the splitees Username) and sends it to the person whom the split is for even though the object itself is owned by one person.  But, with a contest board, I have the ability to turn off manager access to the contest board through the config card.  If an object doesn't come with a config card as to whom you are allowing access to and an on/off way to allow that access than it is a scam even if it is for a charity event...it's done wrong!  And, you have to take out "fake" manager example name and put your manager(s) name in there on the config card because some config cards come with "fake" manager example name - meaning you write your authorized manager in that place instead.  I have no idea about kiosks but from these examples in this thread, it sounds like they are made wrong.  

Idea?  Okay, the script for the vendor of a purchase through the HUD would have to have a place where the seller writes their name and the name of their store and then a message says (for example)  "This is purchase for _____________ (fill in the blank) from ___________________ (fill in the blank store) sold by _______________________ (fill in the blank - Store Owner/Creator) for some examples, now click PAY (example).   

EDIT:  Corrected stuff plus adding:   >>>  I don't think it was ever intended to be a scam but people don't understand how it works.  For a split you need to take out example name and write the name along with UUID (I think it's called) of the name the person the money goes to.  The one who owns the split object needs to write that in there.  Plus, if it's a manager thing...you need to take out fake manager example name and write correct manager name in it's place.  Does this make any sense what I am writing?  

Edited May 3, 2020 by FairreLilette

[Qie Niangao]

When you pay an object, the payment goes to the owner of that object. Period. But then the object itself can arrange to send some money to somebody else, but only if pre-approved (as a debit permission) by that object owner.

Tip jars are easy: the club manager (or whoever owns the tip jar) can trust to give those debit permissions, so when they get the tip income they can split it with the tip jar beneficiary. Totally different for somebody who just bought a demo: they have no reason to trust that demo object's payment script to do the right thing and not just suck their entire account dry.

Making it more cumbersome for the demo owner doesn't make it any safer I'm afraid. There's no mechanism for approving permission for only a particular recipient and/or only a particular amount of L$s.

[FairreLilette]

1 hour ago, Qie Niangao said:

Making it more cumbersome for the demo owner doesn't make it any safer I'm afraid. There's no mechanism for approving permission for only a particular recipient and/or only a particular amount of L$s.

Yes, it could be seem more cumbersome at first but not if it's written once and then can be copied by the owner of the script/config card it really wouldn't be that much more cumbersome.  (see my example below from my post just above yours Qie).   I mean *if* this could be worked out it could mean a whole lot of money more in sales and possibly a WHOLE LOT! more sales if it's done correctly.  So, it is something to consider, but consider carefully, as I had no idea someone would mention that "scary thing" you all are talking about which really needs a UUID and for people to take out example names.  

What if using my above example PLUS script saying prior to purchase...something like.. upon clicking pay, payment will go to ______________________ (this would be the owner/creator of said store).  And then, have the script have a UUID in it plus name whom the payment goes to (owner/creator of store).  >>>  My idea copy/pasted below.   And, if the money for objects splits, the main seller writes in the other usernames and UUID'S and the split amount in percentages.   The script itself could read object name via the script itself possibly without a need to write in every name of each item.  

2 hours ago, FairreLilette said:

Idea?  Okay, the script for the vendor of a purchase through the HUD would have to have a place where the seller writes their name and the name of their store and then a message says (for example)  "This is purchase for _____________ (fill in the blank) from ___________________ (fill in the blank store) sold by _______________________ (fill in the blank - Store Owner/Creator) for some examples, now click PAY (example).   

Adding:  I am asking this question because some HUDS are coming with REDELIVER options right on the HUD itself as well and you can buy a Gacha now directly from a HUD and a mystery prize comes out.  You can buy the Gacha from the Marketplace itself for 50 lindens for a chance to win a random prize, and you wear the HUD and click for a random prize.  This has nothing to do with Gacha, however...I've just noticed some HUDs "are changing" so to speak.  And, I like it!  Can it be taken further to purchase from a HUD demo?  I don't know.  That's why I'm asking but I didn't know there might be some "scary" message that doesn't need to be there.   One could even have HUDs that allow one to click for more demos right then and there of say some "unique objects not found in store" or the opposite "unique items not found on Marketplace" and get the demos from the HUD for another example.   HUDs are changing.  I like it!   But I WOULD NOT like it if it has some "scary" message in there about taking my lindens.  

Edited May 3, 2020 by FairreLilette

[Adam Spark]

1 hour ago, Rolig Loon said:

Yes it is, and that's exactly what some of the objects that scam artists distribute to unknowing residents do.  The user clicks the object and authorizes PERMISSION_DEBIT, and then the script jumps directly to a timer that calls a money event every few seconds, transferring an unknown number of L$ every time until the user's balance is empty.  It's a sad but unfortunately common scam. 

Seriously? Linden Lab lets scripts get away with this?

I've used shopping huds and gift cards that "buy" via the gift card hud. It never occurred to me that the grid would make it possible to have these things take your money without the explict action for every instance of payment.

This needs to change. Like a decade ago.

[Rolig Loon]

1 hour ago, FairreLilette said:

Idea?  Okay, the script for the vendor of a purchase through the HUD would have to have a place where the seller writes their name and the name of their store and then a message says (for example)  "This is purchase for _____________ (fill in the blank) from ___________________ (fill in the blank store) sold by _______________________ (fill in the blank - Store Owner/Creator) for some examples, now click PAY (example).

That's not what a script looks like.  You're describing something that looks like a text document -- like the script for a play or something.  A LSL script is a computer program, a set of instructions to your computer that tells it exactly what to do when someone clicks on the thing that it's in.  Qie and I have been writing things like this for a long time, so we're familiar with all the flexibility and limitations, and all the scary things that can happen in the hands of a careless or unscrupulous scripter.  The things that are the scariest are the loopholes that are unavoidable, or that you can fall through when you least expect them. 

Working with computers for half a century is sobering. It gives me respect for uncertainty and liability. Personally, I am cautious enough that I usually resist writing scripts that involve asking someone else to give PERMISSION_DEBIT and I have limited trust that the average LSL scripter can do it properly. That's why I suggested the much simpler and much less risky option of providing a direct link to a merchant's Marketplace site, where you can be sure who is handling the L$.

[FairreLilette]

10 minutes ago, Rolig Loon said:

That's not what a script looks like.  You're describing something that looks like a text document -- like the script for a play or something.  A LSL script is a computer program, a set of instructions to your computer that tells it exactly what to do when someone clicks on the thing that it's in.  Qie and I have been writing things like this for a long time, so we're familiar with all the flexibility and limitations, and all the scary things that can happen in the hands of a careless or unscrupulous scripter.  The things that are the scariest are the loopholes that are unavoidable, or that you can fall through when you least expect them. 

Working with computers for half a century is sobering. It gives me respect for uncertainty and liability. Personally, I am cautious enough that I usually resist writing scripts that involve asking someone else to give PERMISSION_DEBIT and I have limited trust that the average LSL scripter can do it properly. That's why I suggested the much simpler and much less risky option of providing a direct link to a merchant's Marketplace site, where you can be sure who is handling the L$.

I value your opinion very much Rolig as does most of the forum who know you.  If I could have called on anyone to help understand how this could be done, it would have been you.

However, I'm not writing that as a script example...I'm writing that as to what the script might say in NEARBY CHAT window...that's what I mean by the script "says" though I meant to write the script says that in the nearby chat window.  Sorry, I meant to clarify that.

I don't know how to write scripts altogether though Rolig, that's why I'm bringing up issues here about it but I also think it needs some reputable way to do it, possibly CaperVend maybe(?).  But, I have noticed HUDs are changing (read my add in my last post) about how HUDs are changing of late.  

Edited May 3, 2020 by FairreLilette

[Rolig Loon]

24 minutes ago, FairreLilette said:

I don't know how to write script altogether though Rolig, that's why I'm bringing up issues here about it but I also think it needs some reputable way to do it, possibly CaperVend maybe(?). 

Thank you.  Your expression of trust means a lot to me.  And that really is what it comes down to, as I said earlier ... trust and responsibility.  As a scripter, I feel responsible for more than just writing sets of commands that do what I tell them to. I feel an obligation to reduce the risks that my scripts might create -- risks for me and for whoever uses them. CasparVend and others who have been in business for a long time know this same sense of responsibility, which is why we can trust them to do their best to create reliable, safe products.

By raising this whole issue, I was not intending to get deep into the weeds about scary things that unscrupulous or clumsy scripters can do with your L$.  The fact is that we all have to balance risks every day. Cars are loaded with safety gadgets, guns and our front doors have locks, and we keep documents in safe deposit boxes in our banks, but we know at some level that the safeguards don't always work, and that bad guys find ways around them.  We can get super paranoid and hide away from society altogether, or we can accept some degree of risk. 

In this case, my way of reducing risk is to say yes, I can write a pretty secure HUD that ought to do what you are asking, and I think CasparVend can too. However, there's a much less risky way to reach the same goal. Create a HUD with a button that links you directly to the item in the merchant's Marketplace store. Buy the item there.  Let Linden Lab accept the responsibility for handling the money and delivering the product.  That way, nobody has to ask you for PERMISSION_DEBIT and I don't have any responsibility for what happens if I made a mistake or the Internet eats your transaction. AND, maybe most importantly, you don't have to worry that the HUD was created by some nasty crook who knows how to use good LSL functions to steal your money.

Edited May 3, 2020 by Rolig Loon
typos, of course

[Rolig Loon]

34 minutes ago, Adam Spark said:

Seriously? Linden Lab lets scripts get away with this?

I've used shopping huds and gift cards that "buy" via the gift card hud. It never occurred to me that the grid would make it possible to have these things take your money without the explict action for every instance of payment.

No, Linden Lab comes down really hard on people who run scams like that, just the way that RL police come down hard on con artists and people who hold up liquor stores.  That doesn't means that people can't find nasty things to do with basic tools and then risk getting caught.. 

Gift cards are good examples of limited liability systems.  When you buy something with them, the L$ doesn't come directly from your account.  Just as in RL, you hold a card that gives you permission to get a limited amount of goods.  You either paid for the card up front or the merchant has simply decided to be a nice guy and give you up to L$500 worth of products by presenting the card.  The card isn't asking you for any more than that, and once you've used up the value of the card, it's worthless.  Fairre's idea for a demo HUD could incorporate something like that too, as a promotional gimmick.  ("Use our demo to try out the product, and we'll discount the price of the final product by giving you a FREE L$50 discount when you click this button.")  It would be a nice way to encourage people to get the demo first.