# xGov-116: Subscription Payments

**URL:** <https://forum.algorand.co/t/xgov-116-subscription-payments/10875>\
**Category:** xGov Proposals Pilot\
**Tags:** xgov, voting-session-3\
**Created:** [January 2, 2024, 8:23am UTC](https://forum.algorand.co/t/xgov-116-subscription-payments/10875 "2024-01-02T08:23:38Z")\
**Posts on this page:** 1\
**Showing post:** 14

<div class="post-metadata">

**Author:** ![subtopia\_algo](https://avatars.discourse-cdn.com/v4/letter/s/ecc23a/32.png) [@subtopia\_algo](https://forum.algorand.co/u/subtopia_algo)\
**Post date:** [August 30, 2024, 11:31am UTC](https://forum.algorand.co/t/xgov-116-subscription-payments/10875/14 "2024-08-30T11:31:29Z")

</div>

Hello @lobo, Subtopia creator here. I randomly stumbled upon this and figured I’d further clarify the differences.

You can think of Subtopia as a subset of Stripe functionality that runs on-chain. It’s true that currently, recurrent payments aren’t supported. However, the architecture of the system is designed with upgradability in mind.

## Contract Deployment

- When a creator deploys a Product contract via Subtopia, it also deploys a special Locker contract, which is a stateful contract acting as an escrow.
- When a user subscribes to a product via a product contract integrated by the creator into their platform, it also creates a ‘user’ locker for them. This is used to track active/stale subscriptions for their wallet (think of it as a backbone for something like a subscription view page in AppStore or Google Play).
- Only one upgradable locker contract per user/creator needs to be deployed to manage all subscriptions (for users) and all product revenue flows (for creators), rather than an escrow per subscription as in this proposal.

## Types of Subscriptions

Product contracts are managed by a registry contract. Currently, the audited contracts are called ‘token-based’ contracts. Think of it as a paywall service:

1. You have a feature A that you want to charge money for.
2. You deploy a token-based contract (can be duration-based or unlimited), with options to create discounts.
3. You integrate it into your web app; the product contract serves as your API to inquire whether wallet A is a subscriber of service B or not.

## Revenue and Ownership

- Revenue withdrawals are tied to lockers, so as a creator, you can withdraw to your personal wallet at any time.
- You can transfer full ownership of the product contract to another user.
- When there are updates to the contract, you can choose to upgrade or not.

## User Perspective

As a user, you need to renew your subscription manually when it expires. This is a topic for debate:

- As a user, I’d much rather do it manually (as SilentRhetoric points out the subscription fatigue).
- As a creator, I’d want to maximize revenue streams.  
There might be a middle ground at some point.

## Future Developments

I am working on adding a third type of product contract for credit-based monetization. This will allow charging the user for each individual access to N number of features over your product (think of popular AI image generation tools where credits are charged per each image generation). This feature will be coming closer to autumn this year.

## Interoperability and Recurrent Payments

To sum up, I am also evaluating some options around interoperability with this proposal by @krby.algo as there is potential to generalize some of the overlapping interfaces/capabilities into a simple ARC.

Recurrent payments are rather trivial to implement in Subtopia at a later stage. All it takes is figuring out what/who will send a call to the product contract to renew the expired subscription (and lockers can be leveraged to a great extent as they are made for such purposes).

Refer to [docs.subtopia.io](http://docs.subtopia.io) for latest documentation explaining the architecture in detail.

---

_[View the full topic](https://forum.algorand.co/t/xgov-116-subscription-payments/10875)._
