Economics in my Service built on TIC

General DFINITY
1

I understand that i need to fuel my canister with cycles to run. If i now build a service, what are the DFINITY platforms natural mechanism to potentially charge IC principals for use of my service through the UI or API? How would one advertise costs for it and conduct payment on the API level? For endusers elsewhere established subscription or item costs can likely be modeled with classical patterns and a Stripe integration (or alike), but the more native way would be something based on ICP and i don’t quite see yet how this would work in a non-awkward way.

2

There are no real purely native ways, but the complexities aren’t too hard to make something work. Some thoughts:

  1. Queries are read only and you can’t charge “per query” as you can’t make any update calls (e.g. reduce a users balance). You could charge a subscription tho - users pay in advance by sending ICP/some other token which includes their principal in the subscription list. This could be a list that has a second “paidUntil” date field which for example a monthly subscription. The queries can then exit out if the caller has no valid subscription (assert(validSubscription(msg.caller))
  2. Update calls can be charged per call if you want. We are working on frameworks to allow this to happen (payment in cycles/TIC or other tokens). You could also use the subscription model, or even a prepayment plan where users pay for calls in advance (e.g. top of their account with TIC, which get used on each update call).
  3. Remove your query calls and just use update calls, so you could have more flexible payment schemes for queries. I wouldn’t go down this route though as it adds latency on the calls (query calls are usually instant, updates take a second or two).
  4. Subscriptions could be integrated with Stripe. I think I read that you can have the webhooks for payments sent directly to your canister (like paypal IPNs).
1 Like
3

Thanks. That’s useful insight at this point.