1

Object payments

I don't know if this has been discussed, but I think we really need to make it so users can pay objects, objects can pay users, and objects can pay objects (and thus their users).

If you do implement this, please add more sophistication to the UI. Starting with the SL model as an example, consider some enhancements:

When paying an object:

  1. Custom note at the top (e.g., "Select your clothing multi-pack option")
  2. Variable list of of more than 4 price options
  3. Each price option has a custom label (e.g., "6-pack" or "2 weeks")
  4. Each price option has a custom memo for the transaction log
  5. Each price option has a custom SKU for the transaction log

When an object pays you:

  1. Custom note (e.g., "John Doe paid S$100 to start a 2-week rental")
  2. "Reject payment" button with an optional reason note (when online)
  3. Object (script) detects transaction outcome
  4. Custom memo for the transaction log
  5. Custom SKU for the transaction log

When an object pays an object:

  1. Custom note for user
  2. Custom memo for transaction log
  3. Custom SKU for transaction log
  4. Receiving object (script) can reject it based on details
  5. Paying object (script) detects transaction outcome

 

And although this does have security ramifications, I would strongly propose an auto-pay capability. In SL, you can own an object and give it permission to pay someone, even when you are offline. But that's a burden in many cases, in part because one has to own land to do so. I mean where a scripted object owned by someone else asks your permission to automatically withdraw money from your account in the future. This probably should only be allowed to happen in response to the user clicking on or otherwise intentionally interacting with the object, to avoid unsolicited spam requests. One option would be to have an alternative menu option near "Pay" that is like "Schedule payments". It may be worthwhile for the "contract" dialog where the user schedules payments to offer simple, automated contract terms that the script cannot alter once the user agrees. Here are some possible examples the script could configure in its offer:

  • Pay S$50 per day at 3:00pm
  • Pay S$10 per visit to this experience
  • Pay <unspecified> (max S$100) per week on Monday at 12:00pm
  • Pay <unspecified> per week on Monday at 12:00pm
  • Pay S$100 per <unspecified> usage

The <unspecified> cases would be where the script has relaxed constraints in what it is allowed to request when the time comes. I expect users would be less likely to approve those contracts.

The object that accepts these recurring payments would get an event with all the relevant information about the contract so it could react. For example, it could give away this week's subscriber gift. Or it could trigger the update of a custom log via a web service.

Recurring payments add system complexity, of course, but it's really something that is sorely missing from SL, IMO. This would help facilitate rentals and subscription memberships.

2 comments

Please sign in to leave a comment.