Paying a vender without using the right-click and 'pay' ?

[jak Scribe]

I may have overlooked something but I will ask anyway

I have an object containing many textures.  To choose an animation the Object is set to "Click to: Touch"

Each texure has its own price (stored in a linkset) and once a texture has been chosen using a Dialog, the fee is paid and 'customer' receives the texture.

At the moment the 'customer' has to right click the object and select 'Pay' etc... which is not very user friendly.

Is there any other way (perhaps via a Dialog) to allow the 'customer' to pay ?

[Quistess Alpha]

31 minutes ago, jak Scribe said:

Is there any other way (perhaps via a Dialog) to allow the 'customer' to pay ?

You can set the "click action" to pay (edit window, or llSetClickAction) , so they can left click instead of right click; but unfortunately, the user needs to initiate the payment interaction, there aren't many good ways to directly suggest it to them.

You can use a SLURL, but it's not intended and buggy (obscures the name of the thing you're paying, doesn't respect llSetPayPrice)

default
{   state_entry()
    {   llSay(0, "[secondlife:///app/agent/"+(string)llGetKey()+"/pay click here to pay]");
    }
    money(key payer, integer amount)
    {   llInstantMessage(payer,"Thank you for your donation.");
     	// Used for testing, turns out it only works if you're on the same region (obviously?)
    }
}

 

Edited September 29, 2023 by Quistess Alpha

[Qie Niangao]

You want to use Pay.

By design, the paths for moving L$s from one account to another are limited and use only a few easy to recognize user interfaces: Pay (with some variants depending on llSetPayPrice) and Buy…

… and then there's the wildcard, llTransferLindenDollars (and its OG equivalent, llGiveMoney). Those only work with PERMISSION_DEBIT though, and that's made scary to grant, and for good reason: it can drain an account of all L$s in short order. So you never want to ask for it, but in theory you could, in an attachment the customer owns. No sensible customer would grant this permission; requesting it would be enough to spook any customer, and if one should grant it, a bug in the code would terminate an account. So don't do that.

The only other thing that comes to mind is a "prepaid balance" that the customer could buy (with the Pay interface), and then the vendor's internal accounting could use those prepaid funds to cover purchases by dialog, and refund any balance upon customer request. This is basically the same as buying yourself a (refundable) "gift card" and wouldn't be as dangerous as PERMISSION_DEBIT, but still it's just unusual enough that merely offering the option will freak out some customers and make everybody nervous until that prepaid balance goes to zero—unless somehow all your prospective customers have reason to trust you'll always refund that balance,

[Fenix Eldritch]

It is possible to make different prims in the linkset have different click actions. So you could have your dispenser setup with prim buttons using the default "touch" action that allow the user to select the desired item, and then have another prim set to "Pay Object" to serve as the checkout button which when clicked would bring up the pay resident GUI.

Edited September 29, 2023 by Fenix Eldritch

[jak Scribe]

Thank you !!

At the start of my selection dialogs I set:

llSetClickAction(CLICK_ACTION_TOUCH);
llSetPayPrice(PAY_HIDE, [PAY_HIDE ,PAY_HIDE, PAY_HIDE, PAY_HIDE]);

and after the texture is chosen:

llSetPayPrice(PAY_HIDE, [Price,PAY_HIDE,PAY_HIDE,PAY_HIDE]);
llSetClickAction(CLICK_ACTION_PAY);
JS_Dialog(60,"XJSV_Pay","Please 'Click' me again to Pay", [],""); // calls my own Dialog Script

Now the 'customer' only has to click the object again and the pay dialog pops up

 

[jak Scribe]

My Vendor has textures belonging to others, who also set the prices.

How can I use llTransferLindenDollars to send them the money collected if I should not (understandably) use PERMISSION_DEBIT ?

Edited September 29, 2023 by jak Scribe

[Qie Niangao]

Just now, jak Scribe said:

[...] Now the 'customer' only has to click the object again and the pay dialog pops up

Cool! (seriously)

But while the click action is "Pay", other customers will be presented with a pay dialog on touch, and will they know to click right and select "Touch" in order to choose a different option?

(To the other question, though, if it's your script and your intended llTransferLindenDollars recipient, it's not that scary. Trusting somebody else's script do do what's right is a whole different thing.)

[Quistess Alpha]

7 minutes ago, jak Scribe said:

How can I use llTransferLindenDollars to send them the money collected if I should not (understandably) use PERMISSION_DEBIT ?

PERMISSION_DEBIT is fine as long as you understand the use and the risks. Especially if the vendor's script is visible to you, you know it's not going to do anything too dumb.

[jak Scribe]

And if I create a new account that is the owner of my vendor.

The account would only contain the money received from a customer for a few seconds before it transfers it to the creator of the texture.

[Fenix Eldritch]

I personally would not try to toggle the click action of the same prim like that... I think it would be safer to have dedicated prim buttons whose click action is set from the beginning and does not change. Less room for wonkyness, especially when dealing with payments. Because what happens if the dispenser is set to "click-to-pay-me" mode, but the user backs out at the last moment? You'd need a way to reset the device either on command or after a timeout.

 

Edited September 29, 2023 by Fenix Eldritch

[Quistess Alpha]

1 minute ago, jak Scribe said:

And if I create a new account that is the owner of my vendor.

The account would only contain the money received from a customer for a few seconds before it transfers it to the creator of the texture.

👍 that is indeed standard practice for this sort of thing.

[jak Scribe]

>> Qie Niangao

I have a texture on the front of my Vendor that I could change to "Busy" for the few minutes a 'customer' is using it, and possibly set a flag as well to stop another avatar-id as the one waiting to pay.

[jak Scribe]

>> Fenix Eldritch

Good arguments Fenix.

My Dialog Script is already set to time out after 60 seconds, and then the control is passed back to the default state, that way everything is reset again.

JS_Dialog(60,"XJSV_Pay","Please 'Click' me again to Pay", [],"");

[jak Scribe]

Thank you all for your suggestions and ideas.