How It Works
Fasty Vendor has four pieces. You only touch two of them in Second Life: the hub and the vendors. The other two live on the web and work for you in the background.
The four pieces
Hub An object in your store that holds your product items and hands them to your customers. One script.
Vendor The board your customers pay. It shows one product and takes the L$. One light script.
Fasty server Records every sale, picks which hub delivers, tries again when something fails, and feeds the panel.
Panel Your store in the browser at app.fastyvendor.com. Prices, vendors, sales, customers: all live.
The important idea: the vendor does not hold your products. It only takes the payment. The products stay in the hub, so you can have hundreds of vendors around the grid and update a product in one place.
The path of a sale
Here is what happens when someone pays a vendor:
The customer pays. The vendor only accepts the exact price. It gives the sale a unique ID and saves it in its own memory before doing anything else.
The vendor tells the server. The server records the sale and chooses a hub (the vendor's preferred hub, or your main one).
The hub gives the item. The customer receives the item in their inventory, usually about two seconds after paying.
The customer gets a receipt link in chat. The sale shows up in your panel at the same moment.
Sales on the Second Life Marketplace take a shorter path: the Marketplace delivers the item itself and tells Fasty about the order, so it shows up in your panel next to your in-world sales. See Marketplace Sales.
When something goes wrong
Second Life is not always kind: regions restart, scripts get slow, servers go down. Fasty is built so that the customer always gets the product:
| What breaks | What Fasty does |
|---|---|
| The Fasty server is down | The vendor sends the sale straight to the hub. When the server comes back, it catches up with what happened. |
| The hub moved (region restart, new URL) | The vendor asks a small backup registry where the hub is now, then tries again. |
| The main hub is offline | The server sends the order to your backup hub in another region. |
| Nothing answers at all | The vendor keeps the sale and tells the customer by IM that the purchase is guaranteed. Fasty keeps trying on its own until it is delivered. |
| A gift recipient is offline | The hub waits and tries again every 5 minutes, so the gift doesn't land in a full offline inventory. After 24 hours it sends anyway (Second Life keeps the offer). |
There is one more rule behind all of this: when in doubt, deliver again. A customer who gets a second copy is fine. A customer who gets nothing is the worst thing that can happen. You can read the full story in Delivery You Can Trust.
Why one script per object matters
Each vendor runs one small script, and it is designed to stay light on memory forever: nothing piles up over time, no matter how many sales it makes. That matters because you might have hundreds of vendors around the grid, and nobody wants to reset them by hand. The hub also runs a single script.
What lives where
| Where | What |
|---|---|
| In the hub | Your product items (copyable) and an optional texture per item, used as the product image. |
| In each vendor | The Fasty Vendor script and, if you want, a child prim called display that shows the product image. |
| In a redelivery terminal (optional) | The Fasty Redelivery Terminal script. Customers touch it to get their purchases again. |
| On the server | Your products, prices, groups, vendors, sales, customers and settings. |
| In your browser | Nothing to install. The panel works on a computer or a phone. |
Next step
Ready to try it? The Quickstart takes you from an empty prim to your first sale.