Can Someone Advise Me on Debit Permissions, Please?

I bought a gumball machine for use in a park that I am building on my land and it says that to issue refunds to people buying the gum I have to allow the item permission to debit my SL balance. It pops up this message every time I click on it, although I am not aware of what it does when someone other than me (the owner) tries to access it.

Is this normal? I get a message afterwards from SL saying that the script is asking for ongoing permissions to debit my account. Should I be worried about having all of my money stolen? How are vending machines normally handled?

Thanks in advance for all replies!

If it's asking your for Debit Permissions then you own the object. It most likely works by people paying into it (and they get the merch), you collect the money and keep your commission, the remainder is then taken from your account and passed along to the person you licensed the object from.

I personally avoid objects from other persons that require me to grant the object debit permissions as, because I most likely can't see the script, I have no idea if there's a backdoor leading directly to my pocket.

Your mileage may vary.

you need to click yes if its to deposit the lindens to your account etc or the machine simply wont work. Its asking permission to access your account which yes is normal when you set up some kind of vendor if you dont click yes the actual machine will never actually work. Debit is permission to put money in your account or take it out in your case its to put money in your account when people pay for the gumballs

If the payments are only supposed to go to the owner, it shouldn't need debit permissions. Maybe the OP can let us know if there is someone else that is supposed to get paid, or is all the money supposed to go to the owner?

I use vendors that do as you describe, and so far they have worked and are harmless. In view of the above posts, I'd say watch your payouts in account transac tions or wherever, and if it is screwing you, get rid of it, complain loud, long and everywhere to LL and theResidents about fraud, and delete and purge the mofo.

Oh okay so it enables both me getting paid and me refunding people who may have paid and not gotten the gum? I see...

Also, there were two versions of the machine. One was a revenue split and the other was 100% owned with no split. I got the latter. I am assuming the fact that it was more expensive offsets the fact that I will not be splitting revenue.

Thanks again for your help with this. I just get the immediate red flag going when something starts asking for automatic "anything" involving my money...

Kascha a wise person...

Refunding customers that don't get the product is a valid reason for debit permissions assuming that the machine knows that it did not give out the product. If there's a way for the vendor to actually know this, why wouldn't it just correct the problem by sending the product again? If there is no way for the vendor to know this, then I can think of no good reason for it to have debit permissions.

The merch is most likely delivered by a networked prim owned by the creator. You'd have no idea if the merch fails to be delivered unless the customer notifies you (and as you're not in charge of delivery you then have to, in turn, notify the creator about the failed delivery).

To make change if the buyer pays the wrong amount. That's what one (open source) vendor I have used in the past does.

Oh wow. you know I didn't even think of that? I have seen that; where I have been refunded when I overpaid for clothing in the past. It might be time for me to face the fact that I really am a ditz!

Thanks to you and everyone. Now everybody that visits my park can be sure they will have a face full of bubblegum to enjoy. No chewing 20 pieces at once though; you won't have any teeth left in your mouth!

Just throwing my L$2 in on this... I am also loath to use Permission Debit, certainly not from anyone else's scripts, and I don't even like using it on scripts I've written myself.

There's a way to script vending machines to ensure that customers cannot overpay (or underpay) which removes the possibility of having to give them back their change. You do *Not* need Permission Debit to receive money via object, only to pay money out. So if the vending machine is scripted correctly (and assuming it is not profit-sharing of course) then it can be done without Permission Debit.

The LSL command in question looks like this:
llSetPayPrice(PAY_HIDE, [amount, PAY_HIDE, PAY_HIDE, PAY_HIDE]);

The amount variable is the number of lindens the machine will accept. Everything else set to Pay_Hide means that the customer is presented with a Pay box that has only the correct Amount as an option to pay, they cannot pay more or less and they cannot enter some other number.

I've scripted a few vending machines that work this way, specifically to avoid using Permission Debit.

-Atashi

the refund on a vendor is when they underpay or overpay. The money is given back if its not enough or the remainder of the money they put in over the actual charge is given back with a product. That is if the person who wrote the script is making it run like that

In any event usually a refund is given from a vendor if the script is set up to give underpayment and overpayment back hence its credit/debit permissions. If its split revenue it first has to all go into the account of the person's who machine it is and then whatever percentage that is supposed to be given to the person who he is splitting revenue with will be deducted from the account and distributed to the originator who you got the machine from (its not a refund but its done the same way) . No vendors wont know a product has not been given it executes its program and then goes back to the beginning and sits there and there is no way for it to figure out if the person actually got it either. Anyhow this is the reason for debit permissions

Please read the LSLwiki on this subject. A script must *always* check in the money() event handler that it in fact got payed what was set in the llSetPayPrice() call. If not, it should refund the buyer's money (which would entail PERMISSION_DEBIT) or somehow otherwise arrange for a fair handling of the situation.

The whole PERMISSION_DEBIT thing is one really good reason to keep an alt, so whoever owns the objects with this permission don't need to carry much of a L$ balance, just in case.

I was always under the impression that the ability to remove only the fixed amount of money was not error proof since its only a display thing so even if you have a button for the exact lindens needed its still possible for errors to occur at least it was like that last year when i learned all that stuff

I can confirm what Atashi said. I used a vendor script found on the LSL Wiki in my early SL days, later changed it to display a payment button instead of an input field and recently realized that I can do without the debit permission.

I think what the SL Wiki means is that if you use the standard payment dialog with an input field, it's only common sense to check if you were underpaid (or overpaid). In order to pay back wrong amounts, you'll need the debit permission.
But if the payment dialog allows only the correct amount, without displaying an input field, you don't need to check the paid amount and you'll never have to pay out money. It works fine without debit perm.

It's true, prim properties like a changed "Sit" entry in the pie menu often have a short delay. I never saw that happen with a payment dialog though. I'll test it in an area with extreme lag (=sim with casino + camping chairs ). If it isn't error proof, I'll have to change my vendor scripts.