Please Help! Need info about revoking permissions for object to withdraw funds from my SL account!

[Crystal Glasswing]

Hi, I am opening a new inworld store, and, since I am not the best at creating clothing yet, I have decided to go with some affiliate/franchise programs for some of my sale items (wherein I place vendors from an affiliate creator in my store, and I get a commission from sales).

So I am looking for affiliate programs, mostly.  Today I found one, and placed a vendor in my store. the vendor asked for permission to withdraw funds from my account (this is normal).  I gave the permission, expecting 1 linden to be withdrawn. But nothing was withdrawn, and then the vendor said it needed to update. So I ran the updater, but then it said it couldn't update successfully, so I was left wondering whether my account is safe, or what?

I took the vendor back into my inventory.  It is a Casper vendor. I have IM'd the vendor affiliate program owner, but no response yet...

This is what I need to know: Does taking the vendor back into my inventory REVOKE permissions I gave to be able to withdraw funds from my SL account?  I am seriously panicking here -- I have a product (vendor) that doesn't work, and I gave it permissions to allow withdrawal of funds from my account!  Stupid, I know -- but any help will be appreciated.  I think that I read somewhere that the money withdrawal script only works until the item is removed, by taking into inventory, or deleting.

Please help! I have transferred most of my lindens to an alt, but I am still worried!

thank you in advance,

-- Crystal

 

 

[Phoebe Avro]

The vendor can not take any of your money now its been taken back into your inv

[Crystal Glasswing]

Okay! Phew!!! Thank you for your response

 

[Ciaran Laval]

---

Crystal Glasswing wrote:

Hi, I am opening a new inworld store, and, since I am not the best at creating clothing yet, I have decided to go with some affiliate/franchise programs for some of my sale items (wherein I place vendors from an affiliate creator in my store, and I get a commission from sales).

So I am looking for affiliate programs, mostly.  Today I found one, and placed a vendor in my store. the vendor asked for permission to withdraw funds from my account (this is normal).  I gave the permission, expecting 1 linden to be withdrawn. But nothing was withdrawn, and then the vendor said it needed to update. So I ran the updater, but then it said it couldn't update successfully, so I was left wondering whether my account is safe, or what?

 

---

It shouldn't take anything until someone purchases from the vendor, that permission is to allow the percentage sharing process to function.

 

Casper is a very reputable brand, not sure why the update isn't working but hopefully the affiliate will get back to you about that.

[Amethyst Jetaime]

Any vendor system will do this.  Even if it is not an affiliate it still needs debit permissions so that if a customer pays a different price for an item then they should or the vendor cannot deliver for some reason, the vendor can refund the money.  This is a requirement that LL set up that people that create payment scripts have no choice but to follow.  People can't pay someone using a scripted object without it.  A vendor will not work if you do not grant debit permissions.

The key then is to be sure that a vendor system is functioning correctly.  You can test it yourself by 'buying' something cheap from your own vendor and then looking at your transaction history to see that the money is split properly.  Yes you may lose some L's on commission if there is one, but its a small price to pay for peace of mind.

Caspertech is a well known and widely used vending system.  A creator that makes a vendor system that cheats people won't stay in business long and probably end up banned by LL for fraud once they get the AR's. 

[Rolig Loon]

---

Amethyst Jetaime wrote:

Any vendor system will do this.  Even if it is not an affiliate it still needs debit permissions so that if a customer pays a different price for an item then they should or the vendor cannot deliver for some reason, the vendor can refund the money.  This is a requirement that LL set up that people that create payment scripts have no choice but to follow.  People can't pay someone using a scripted object without it.  A vendor will not work if you do not grant debit permissions.

[...]

---

Well, that's not strictly true.  There's no requirement that a vendor be able to make change.  The LSL requirement is that IF the vendor is supposed to make change, it must have permission from its owner to do it. I rarely create vendors with a PERMISSION_DEBIT request in them, because the vendor only offers items at a single fixed price.  There's no way for a buyer to pay any amount other than the fixed price, so no need to offer a refund. 

[Dirtnap Mumfuzz]

Casper Warden (creator of Casper vendors) does not steal, nor do any of his vendors.

If you have an issue or question regarding a Casper vendor, feel free to seek support from the CasperTech user support group.

 

I have had many first hand contacts with this customer-friendly and very reputable creator.

When dealing with Casper and his products, you have nothing to worry about.

 

You've made a good choice in vending systems.

[Sassy Romano]

As of today you are ok.  As of today Casper is a trusted merchant of vending systems.

There was a time when Apez was a trusted brand name of vending solutions, then it went pop taking people's funds with it.

It would be nice if the person granting permission could set a risk threshold of how much a script could debit per day but you can't so use vendors from merchants you trust, so do your homework first.

 

[Crystal Glasswing]

Thank you all for your responses. Very informative!

As you can tell, I don't visit these forums very often.  I was suprised to see so many additional replies! Thank you again, a bit late, I know

[Casper Warden]

It would be wonderful if this were true. Unfortunately, it's not entirely accurate to say "there's no way for a buyer to pay any amount other than the fixed price". 

This is restricted by the viewer, not by the server, so in the following situations an incorrect amount could be paid (including L$0)

 

• The viewer could be modified, or hacked
  
  
• It's been seen that simulator lag causes packets arriving from other objects to show the wrong pay dialog on the object you're paying
  
  
• A viewer bug could be introduced at any time which affects this

 

Good practice dictates that responsible server software (in this case, our scripts) should be prepared to accept anything from systems that we don't control. 

For this reason (and the fact that the system often needs to refund a transaction even if the amount is correct, as well as pay commission) all CasperVend vendors ask for debit perms.

[Perrie Juran]

---

Casper Warden wrote:

It would be wonderful if this were true. Unfortunately, it's not entirely accurate to say "

t

here's no way for a buyer to pay any amount other than the fixed price

". 

This is restricted by the viewer, not by the server, so in the following situations an incorrect amount could be paid (including L$0)

 

• The viewer could be modified, or hacked
   

---

If someone downloads a "hacked" viewer then 99.99999999% of the time then they are downloading something other than the Official Viewer or a Viewer not from one of the registered TPV's.  In that case they are getting what they deserve.  (And yes, I know someone on the TPV list could slip nefarious code into their viewer.  But at this time in history I'd consider the likelihood of that infinitesimal also. LL would dump their ass so fast they wouldn't know what hit them.)

 

---

Casper Warden wrote:

• It's been seen that simulator lag causes packets arriving from other objects to show the wrong pay dialog on the object you're paying
   

---

True that Server Lag can cause problems and maybe sometimes people have to learn the hard way to be careful.  But it doesn't remove completely User responsibility to be careful.  Just like in RL when you are driving in heavy traffic, you use extra caution.

 

 

Personally I have only ever had a problem with this happening one time and when I contacted the Merchant about what happened they corrected the transaction for me.

 

---

Casper Warden wrote:

• A viewer bug could be introduced at any time which affects this

 

---

I am guessing you mean a bug introduced by LL.  This could happen but again I put it in the highly unlikely category and such a bug would get rolled back pretty dang fast if it should happen.

 

 

 

---

Casper Warden wrote:

 

Good practice dictates that responsible server software (in this case, our scripts) should

be prepared

to accept anything

from systems that we don't control. 

 

---

This statement kind of doesn't make sense.  Did you mean to say, "....should be prepared for anything.....we don't control?"

 

And actually yours is client software.  It only accesses SL's Server software.

 

 

[Rolig Loon]

Good points, Perrie, but I look at it from a simpler perspective.  Yes, there's always the possibility of an error or of a deliberate hack.  That being the case, I have two choices:

If I make the vendor offer items only at a fixed price and do not include PERMISSION_DEBIT, then Caspar's scenarios offer a tiny probability that some buyer may get ticked at me.  If it's a hacker, he gets what he deserves, and he probably won't complain. If it's a real customer, I can send a redelivered item free.  The worst I can lose is an item of merchandise.

If I include PERMISSION_DEBIT, however, I have opened the door to my account.  A small error won't hurt much, but a hacker could clean out my bank balance. 

I can't predict low-probability events any better than the next person can, but I know which ones will do me the most harm.  If there's an easy way to avoid them, I'd be silly not to take it.

[Perrie Juran]

---

Rolig Loon wrote:

Good points, Perrie, but I look at it from a simpler perspective.  Yes, there's always the possibility of an error or of a deliberate hack.  That being the case, I have two choices:

If I make the vendor offer items only at a fixed price and do not include PERMISSION_DEBIT, then Caspar's scenarios offer a tiny probability that some buyer may get ticked at me.  If it's a hacker, he gets what he deserves, and he probably won't complain. If it's a real customer, I can send a redelivered item free.  The worst I can lose is an item of merchandise.

If I include PERMISSION_DEBIT, however, I have opened the door to my account.  A small error won't hurt much, but a hacker could clean out my bank balance. 

I can't predict low-probability events any better than the next person can, but I know which ones will do me the most harm.  If there's an easy way to avoid them, I'd be silly not to take it.

---

SL being what it is the one thing that we can predict is that problems can and do happen.

If there is a simple way to avoid a low probability event it isn't silly to take it.

When I lived out in the boonies, most nights after 10PM I'd never see another car drive down my road.  But I'd still sure be foolish to go sleep out  there on the road.

What bothers me more and I consider this a LL responsibility and fault is that there is no easy way to my knowledge for me to track and/or revoke any persistent permissions I may have granted and ESPECIALLY that the one so-called irrevocable permission is still live on the Servers.

[Casper Warden]

(Old thread, but I bring this up since a couple of users have referred back to this.)

Rolig, I hear you and I do understand your feelings on this matter.

Unfortunately, if my vendors didn't request debit permissions, there would be so much functionality that simply wouldn't work any more. It would render many of our most powerful features completely defunct. Features such as:

- Affiliate vendors
- Profit sharing
- The ability to block a rogue customer from purchasing
- Customer discounts / rewards
- Group discounts
- Gift cards
- System maintenance or offline vendors
- No copy / limited quantity vending

.. and probably a bunch of other features which don't spring to mind right now. 

In the context of this thread, an affiliate vendor /requires/ debit permission or it cannot pay the creator.

I understand that you may not need any of this functionality, and if so, then all power to you! In this case, you can use a much simpler system which doesn't include this functionality.

For those who are interested, here is the permissions statement that we distribute with every copy of the system. I hope this clarifies our position!

By the way, I absolutely and completely support the idea of a feature which can restrict the amount of L$ a script can pay.

[Rolig Loon]

I understand, and I agree, Caspar.  There is a market for systems with all those extra features, and I know that you serve it well.  As a skilled professional, you know where the big security risks are and you have spent a lot of effort addressing them.  I have much less confidence that the average scripter has that sort of experience.  Therefore, I am very reluctant to recommend that most amateurs should decide that they can whip together a safe vendor with PERMISSION_DEBIT, and I really caution buyers from picking up untested scripts.  As I said in earlier posts, I avoid the problem personally by not including features that require PERMISSION_DEBIT in scripts that I write.  If I ever had a client who asked for them, I might consider it --- or I'd just send them to you.