Script that pays for objects given to it...

I need some help here.

I need to script an object (just a simple, single-prim cube) to accept specific items and pay for them.

I'm working on a business that involves customers buying "tickets" (simple objects with unique names/properties/something) from a vendor. These items will be passed on to employees for service.

The tricky part is, I want a way to automate the process of employees returning the tickets for payment. Tickets will have different values, some as low as L$150, some as high as L$1000.

I know objects can accept items from players, I know objects can pay, I know objects can check their own inventory for items.

The obstacles I see here are:
- Identifying the person returning the ticket.
- Ensuring that the ticket is valid--not a randomly created item with the same name as a ticket.

I already have a way of identifying WHO gave the item. Yes, I know there's potential erros here, but let's just assume my employees are intelligent and know how to follow my directions.

Any ideas on how to ensure the validity of an item, though? Is there a way to check for an item within the item, or a line of a notecard within the item?

First you need to enable inventory drop in your script.

When someone then drops something on your object, a change event will be triggered.

This means, you can now use llDetectedName and llDetectedKey to get the UUID / Name of the person who dropped something into the objects inventory.

As long as you immediately search through the inventory and remove any contents after identifying them you should be able to tell what was given by whom.

Yeah, sorry, but no. Firstly, I already know how to enable inventory drop. I also know that llDetectedName/Key/etc. aren't triggered by the change event. I have my own method of identifying WHO is to be payed, this isn't the issue.

What I need is a way for the object to validate the item that was given. Say the correct object was named "ABCDEFG," I wouldn't want some random person to make an "ABCDEFG" item and turn it in to get money. Is there any way to have the object "scan" an item given to it to get more information? More than just the name.. The name of an embedded object, notecard, a line from an embedded notecard, etc.

Have the object that you give them be a script, which contacts your payout script via LinkMessages then gets deleted? Would a script dropped into the object "fire"?

You could use llGetInventoryCreator.
Would at least ensure that you are the creator of the object that's been dropped in, although there could be problems with people taking something else you've created and renaming it.

Result of dropping a script on a box that allows inventory drop:

I think transferring objects is always going to be difficult and risky.

Just get the employee to drop the ticket near the server object and and have it chat with the server to exchange the information. You can tell who owns the ticket, compare them to the employee list and then have the ticket delete itself at the end.

Probably a whole load more sensible safeguards to build in as well, limited number of payouts to an employee per day, keep track of number of tickets sold and redeemed etc..

I like that idea a lot, actually. I'll have to test that.
So, maybe have a script send an encrypted message with a password and current owner's key over an undisclosed channel, the payment object responds with a confirmation message that deletes the ticket, then pays to the recieved key.

Another problem... What if someone finds the appropriate channel and scripts something to listen in? They could find the passwords and make their own scripted objects.. Even the encrypted versions of the password are vulnerable, as they wouldn't even need to know what the password contains. Just posting the encrypted version would work, as it would be decrypted by the payment object.

There's a discussion somewhere in here about an XTEA implementation that might help. It's slow running though.

Another way to do it might be to have the ticket communicate with a server (object or webserver) via email. If you use a webserver, you can also use llHTTPRequest. That way, anyone trying to interfere would have to know either the key of your server object or the webaddress you are using. If using a server object, it can fall down on a sim reset when the object gets a new key though.

I've heard SL e-mail functions can literally take HOURS to happen... I'd rather not have to have an employee have to wait hours with the object down to get paid.

Edit:
I've found that there's over two billion negative channels that are script-only..
Do you think anyone would go through the trouble of writing a script to somehow spend long periods of time listening to those channels in close proximity to my objects, and possibly coming up with the right channel?

Some light reading:
Security through Obscurity

Correct, Silambus.

The OP has to determine whether the level of threat is significant enough to bother with crypto techniques. Fortunately, these techniques aren't terribly difficult to employ once you learn them.

The trick is that each ticket has a serial number and a cryptographic key. All tickets get the same key for a while, and then for higher security the key can change periodically. When it communicates with the ticket-taker, the ticket taker gives it some Non-Repeating Value (e.g., the current time). The ticket calculates a "digest" of its serial number and the received NRV and transmits that back to the taker. The taker verifies that the digest is valid (i.e., the ticket had the correct crypto key, even though that key isn't transmitted). If everything's good, then you pay.

But frankly, I think that checking the owner should be good enough for most purposes. You might also consider creating an alt account and giving the alt only as much money as tickets you've issued, making the alt own the ticket taker. Then if there's an attempt to take more than you've allotted you'd find out.

Finally, to avoid allowing everyone to rez objects at the ticket taker, you can make the object wearable -- say, in hand and for fun with an animation that holds the hand out like giving a ticket.

Have fun!
Jeff

PS: I'm not a crypto expert, and I may have some inaccuracies above. I'm trying to give you the high level view. I did study crypto well enough to be the lead engineer pitching network layer security protocol projects to major communications equipment manufacturers, but that was nearly 10 years ago now so I'm rusty.

I think checking the owner of the ticket against the staff list will have to be done. This will stop a random person from hacking the system.

Keeping track of the number of tickets of a particular type sold and subtracting the redeemed tickets from the total. This number has to always be greater than zero for the server to pay the employee.

Rezzing the object in world and deleting them is a nice way to reduce clutter in the employees inventory. You can move the script in an attached object to a non-functional state but you can't change the name or delete it, so the employee would have to keep track and delete them manually.

Another thing to consider is how can he employee trust a ticket that a customer gives them. How do they tell it isn't a fake? It could be attached and then querry a sever by email which in response can send an IM to the employee proving that the ticket was genuine.

I can't really see an easy way of giving a ticket a serial number.

Seems like llGetCreator could come in handy here. Or perhaps llGetInventoryCreator .

Just create unique objects that you give out for each dollar amount with only transfer permissions. Then all you have to do it check the objects properties (use a field somewhere for the amount to payout) and make sure it was created by you and you're golden.

Fun things you can do:

When you create your Ticket, provide it with a llRemoteScriptPin, and a script that will respond to a link_message with a specific num code the value of the ticket on another link_message with a specific num code.

Employee clicks on ticket taker, Ticket Taker turns on llAllowInventoryDrop, ticket is dropped into the inventory.

Verify you created the ticket with llGetInventoryCreator, rez the ticket, llRemoteLoadScriptPin, passing a random channel, another script that will verify the llGetInventoryCreator of the first script in the ticket, then request the value of the ticket from the first script via link_message, when the value is recieved. llWhisper that value to the ticket taker the llDie() to delete the object.

There's probably no need for a serial number, but the easy to generate one is to create the tickets by rezzing them from an object (ticket issuer) and have the issuer give the ticket its serial number.

Thraxis has the right idea here, I think.

Just have the ticket use the initial UUID it gets when rezzed as its serial number, and have it say that UUID to the ticket maker on a private chat channel after it's rezzed. The ticket maker can then keep track of the UUIDs of the tickets it's created. UUIDs are, after all, unique.

Would this work?

Hardcode a UUID for the payment server. Create UUIDs for each payment type. Hardcode them into no-mod scripts placed inside the tickets. Make the tickets no-copy. When ur employees drop the tickets on to the payment server, the payment server rezzes them, then links them into its link set. The payment server first verifies the ticket's creator. It then sends its UUID in a link_message to the linked ticket. The ticket verifies the payment server's UUID and responds by returning a link_message with the payment type UUID. The payment server then unlinks the ticket which dies when it senses that it's link number is 0 inside a change event.