"Pay" versus "Buy" contents

To me, the "Buy" option is superior in every way compared to the "Pay" option when buying something. It allows you to see the box's contents, and money transfer and item transfer occur at the same time, meaning you'll almost never have delivery problems, since if the item doesn't deliver, the money won't be paid either. On the other hand the "Pay" option does not show the item's contents (which I suppose some creators want to hide what they're trying to sell on purpose), and also the money goes through first, causing many misdelivery problems. I actually once tried to buy an item that's really a tip jar disguised as an item for sale, basically giving the store owner the specified $L and getting nothing in return.
So I was wondering, why do some shop owners still choose to use the "Pay" method? Are there any benefits of this method that I'm not aware of?

I'm not sure you're correct about buy meaning that the money isn't paid if there's a problem. I've certainly had issues where I've used buy and haven't received the item, unless LL have fixed something I'm not aware of I'm surprised to hear this.

Pay is often used in vendors, many creators use centralised systems to store their items and use scripted vendors to deliver the items.

Yeah, that. Also, split profit scripts only work with "pay".

As a customer, I prefer "buy", too, for the simple reason that you can see contents and permissions. But money transfer/item delivery are in that same order. With pay, it just seems longer sometimes because with vendor systems, the script has to contact the server first.

"Buy" does make for a lot fewer things that can go wrong, but at the cost of tons of flexibility.

"Pay" is the most practical way to do split sales, commissioned vendors, networked vendors (there is often, not always, overlap among those). Scripted vendors allow group discounts, non-L$ purchase options like prepaid or gift cards, gift deliveries. "Pay" allows for the sale of services and off-grid items, while "buy" is only really good to obtain assets.

I can't think of any benefits..."Buy" is vastly superior, as you say. It allows people to see what actually is included in the sale, like what layers things are available on and what the perms are. This is a very efficient way to give customers lots of the info they need. Of course if they don't have enough funds, they will get a "buy lindens" window instead.


I have a few split-proceeds vendors in other areas which use the "Pay" option, and they are a bit of a pain. People are constantly trying to buy things for a linden despite the price being visible, and they pay, it gets returned..they try again with 10 lindens, etc etc....tsk-weirdos.

The times I didn't receive the item using "Buy", the money didn't go through either, so I thought that the money transaction and item transaction happens at the same time or something.

This can be blamed on the money handling script. If properly configured, there will only be one possible pay option. The actual cost of the item you're trying to buy. Without a box to type in a different amount.

Pay is, in fact, vastly superior to Buy, because it allows for many more options both for the seller and for the consumer. As stated previously, using Pay allows for the purchase of gifts to be delivered to somebody other than the payer (important if the item in question is no-transfer), the use of gift cards to pay part or all of the cost of the item, profit sharing for the seller, and more options as well that can make the experience more flexible for all involved.

Hmm. Anything I make only gives you the option to pay the right price, and I would never dream of giving automatic refunds if (as can happen even with just the one price button shown) the amount paid doesn't match the purchase price; that's apparently wide-open to fraud if someone's using a specially-modified client.

Nothing's gone wrong yet, but if something does and someone manages to pay the wrong amount to one of my vendors, I'll get an IM notifying me and they'll get one suggesting they contact me to arrange a refund. That's what I suggest to people for whom I make vendors, too, and they find it a perfectly satisfactory solution.

You can do that with permissions or a separate terminal or XStreetSL. Plenty of options and certainly not a reason not to use "Buy" at all.

Gift cards doesn't mean you can't use "Buy".

Throw in "getting money without delivering the goods" as a seller perk for Pay too for those sellers who just tell you to buy it a second time because "it's LL's fault, not mine, just gimme me some more L$!".

From the consumer's point of view there are nothing but downsides to "Pay" over "Buy".

The problem with "checking permissions" is that lots of things show incorrect permissions when in inventory. For example, a couch that has no mod animations will show as No Mod in inventory even though all the prim parts are full mod. Same thing happens with scripts that are no mod. Having an angry custom IM about permissions is a regular occurrence for me even though I explain in the notecards that some items will list as No Mod in inventory when they are actually completely modifiable on all the parts someone would normally want to modify.

It gets very frustrating...

How do you do that, Kitty? Or do you mean have a vendor that accepts gift cards as well as a prim that sells its contents?

If the script is copy/transfer for the owner of the prim then it can just be set for sale the normal way.

Regular people would use "Buy", gift card users would use "Touch" and "Pay".

Yes, the pay option triggers a pay event inside a script, therefore, shop owners can track sales data. I wrote my own POS system, and when a vendor is paid, aside from vending the item. It reports the sale to my POS system. The POS system records the sale and fires off an email which ultimately bounces to my phone, so I get sales info within minutes of a sale. Also, at midnight SL time, the POS system compiles a daily report which includes the name of the avatar, what they bought, how much they paid, and emails that as well. Therefore since I keep my emails, I have a permanent record (without having to download then entire transaction log each month).

While the inherent buy option might be slightly more efficient, it's only by a small amount. There has been 1 or 2 occasions in 3 years of vending using scripted vendors where the money was paid and the item failed to deliver. In each instance, the customer contacted me and told me of the problem, and I quickly checked my transaction log and delivered the item promptly. Both customers went away happy (because I responded so quickly), and had no problems shopping with me in the future. Also, SL was experiencing issues at the time they purchased, and if they were following LL's own advice not to buy when there are issues, they likely wouldnt have had a problem.

The 'Buy' option is a function inherent to any object. No script events are triggered when the Buy option is used. The primary advantage to the Buy option is that there is no script involved, hence no script lag added to the sim. It also may be slightly more reliable than scripted vendors, but only slightly. A well written scripted vendor is VERY reliable, and allows a host of sales gathering information important to serious businessmen to be gathered.

I see. Thanks. But the gift card can't, of course, be used as part payment in such a system?

The idea that 'buy' lets you see what exactly what you'll get is laughable. OK it might work for non-prim clothes, body-parts and other specific types but "an object" is "an object". I could, for instance, call my creation "genuine Ferrari with RL keys" and put it in a fancy vehicle set 'for sale, contents'.
It would still be a plywood cube though - and you couldn't tell until you bought it and rezzed it.
More normally, anything made of prims will just show as 'an object' and you can't tell anything about its construction or any animations, scripts, etc. that it itself contains.

Actually, thinking about it, unless you're buying a copy of something the contents could always be misrepresented - you're trusting a pretty picture and, possibly, description on the vendor. That fabulous looking skin could actually just be a renamed freebie and nothing like it is shown.

Given that, I can't think of ANY real advantages to 'buy', except when set to 'original' or maybe 'copy', although I'm not even sure about that one.

As the consumer, either you trust the merchant or you don't. As a merchant 'pay' has many, many advantages because it is scripted so can, simply, do more. My favourite reason for using 'pay' is for anyone that has more than one store-location: networked vendors mean you only need to update the stock in the server(s) and not in every individual vendor.

Well, it kind of does, because otherwise you'll be selling people copies of the gift card script and notecard (and some systems use multiple scripts) when they buy the product.

Quite right: a customer should never shop anywhere they haven't shopped at previously.

Who's daft idea is it that stores should be organised for the convenience of their customers anyway? Stores are there for the entertainment of their owners and actual customers are a nuisance that must be tolerated in order to maintain the illusion of running a business (though they can be used to test the sales systems occasionally).

This isn't a matter of "keeping the seller from cheating me", it's "letting me know what the seller is doing" (or even knows what they're doing).

I recently bought a jacket with prim tails and shirt/pants alternate layers, and the permissions were:

Jacket: copy/mod
Shirt: transfer
Pants: copy/mod
Tails: transfer/mod

It was pretty obvious that the creator simply hadn't given any thought whatsoever to the permissions. If it had been in a "Buy" box I'd never have bought it.

"Buy" hasn't failed even once in 3.5 years for me ("Stale transaction" aside since that doesn't end up taking/keeping the money).

"Pay" on the other hand has failed literally dozens upon dozens of times. Couple that with the not-uncommon sentiment that "it's all LL's fault, nothing to do with me, just buy it again or go away!" or the ridiculous "it'll come, just relog a few times" hollow excuses all make "Pay" inherently unreliable.

If there's more than a handful of people on the sim, or if the sim is acting up I'm just going to pass over any store that relies on "Pay" over "Buy".

There were a few instances where sims couldn't update the inventory server properly and new inventory would seemingly get added to your inventory but where that update never made it to the inventory server so it would get lost on the next relog (tp to a different sim) but that one affected "Buy" and "Pay" alike.

A simple license check would solve that problem though if you're worried about someone ending up with a no mod/no copy copy of the script (without state since it's "Contents".

You get to see the perms. Which is often crucial to my buying description and many vendors do not say what they are (or accidentally get them wrong).

Seeing the object name helps to .... I might not be so interested in that outfit if most of it is composed of copyable items from another outfit I already bought from the same vendor last year.

Being able to see which layers are included is about as important to me as being able to see the permissions is as well.

If it's something I plan to wear over/under something else I need to know whether it includes a jacket/shirt version.

Equally important but not always so easy to tell is whether it's an outfit that has both composites as well as individual items. Often I want to buy an outfit not necessarily because I like it but because I might want to wear parts of it with something else which obviously won't work if it's all composited onto one layer.

And if a vendor takes this attitude, they're a scumbag. Somebody of this moral fiber can just as easily put things in the contents of a "buy" vendor that look good but are in fact nothing but a lie. Buy vs. Pay isn't going to do a thing to protect the consumer from such a scumbag.



Funny, I thought I was a consumer, and I do see positives to using Pay rather than Buy, as a consumer. From YOUR point of view there are nothing but downsides, but you presume far too much to be telling me what I think, thank you very much.

Feel free to name some .

You mentioned being able to "gift" something but as I pointed out that's hardly a reason to not have "Buy" available as well since it can be accomplished with permissions alone or a different approach or simply using XStreetSL.

And if you wanted to nit pick over it: the buyer has no way to know that the person they're giving it to didn't already cap their IMs in which case they'll never receive the gift. Additionally it's always more personal to be able to give someone something rather than have a vendor do it (and IM caps don't apply to avie-to-avie inventory offers so it's - again - inherently safer to do it that way).

You also mentioned gift cards but once again that's not a reason not to have "Buy" as an option when someone isn't using a gift card.

The rest you mentioned was from the seller's point of view and in that case having customized sales reports is a big plus but that hardly matters to the consumer.

Tell me one legal method you can "Buy" a NO-TRANSFER item and give it to somebody as a gift. Some people like the ability to COPY things in their inventories. Ergo "Pay" is a bonafide win for the consumer, because there's absolutely no way in this world any vendor is going to be stupid enough to let you "Buy" something of theirs and make it Copy and Transfer just for you so you can gift it to your buddy.

You can wrap a box containing "copy/no transfer" items inside of another box that'll appear "no copy/transfer" in inventory. The one downside there is that the buyer has to remember to just give the inventory item directly rather than rez it (or it would turn "no transfer" for them).

An alternative is a twist on the normal "click to unpack" where the click is what triggers the actual llGiveInventoryList on a vendor prim so what's inside of the "Buy" prim in the store is simply a "no copy/transfer" box with one script in it.

Or have both "Buy" for buying and "Pay" for gifting on the same prim.

Or again you can simply have everything listed on XStreetSL and refer people to that for gifts.