Skip to main content
Answer

Virtual Currencies and mobile apps

  • August 18, 2025
  • 6 replies
  • 146 views
Andy Dent
Forum|alt.badge.img+4

Context1

I have an existing iOS app using RC for subscription and lifetime purchase of Pro features.

I am about to roll out a Mac version (part of Shipaton).

For both, I would like to implement virtual currencies. This is a long-planned feature to be used to buy content where a portion of the payment would be forwarded to content authors. I’ve implemented most of the local document model including content rights tracking all the way down, was holding off hoping you’d solve the rest for me.

I have also considered allowing coins to be used to purchase short-term access to Pro features, for people who hate subs and don’t want to commit to the size of the lifetime purchase.

These products (Touchgram) emphasis user privacy and preserve anonymity, requiring accounts only for people who will be submitting content for re-sale.

 

Context2

As a separate Shipaton submission, I’m building a Compose Multiplatform app. However, if virtual currencies prove problematic, I think the business model can work with subscriptions alone. I would prefer to have the option to use coins because they enable some neat models for people running martial arts studios or coaching online.

 

Server backend required?

Looking at the docs, specifically the tips on security, there’s a fairly strongly worded:
 

Transactions that add or remove virtual currencies to your customer balances, except for In-App Purchases, should be initiated by the backend of your Application. … require RevenueCat secret API keys to be authenticated, and these keys need to be securely stored and never be exposed to the public.

 

Is this a rule you enforce?

A big part of getting excited over RC providing virtual currencies for a solo founder was thinking I didn’t have to add a backend.

 

Backend platform suggestions?

If the answer to the above is that a backend cannot be avoided, do you have any suggestions as to platform on which to deploy. I’m not interested in building a web front-end to it but will want to communicate from Apple Swift and Compose Multi-platform apps directly to this backend.

Without necessarily getting commercial platform recommendations from you, against which tech stacks are you happiest with your test coverage of these APIs?

 

Local mobile SDK?

If you do not enforce backends, will virtual currencies be supported by the local Swift and Kotlin SDK or do I have to drop REST code into the apps?

Best answer by MarcosC

Hi Andy,

I’m Marcos from the Engineering team at RevenueCat. Thanks for reaching out and for the context on the question.

 

Let me try to address your questions

 

Server backend required?

We decided to require a backend for spending virtual currencies because we cannot guarantee that the person making the request is the one wanting to spend the currencies.

If I knew your app user ID and the public key (which is public) I could spend virtual currencies for that subscriber and we wouldn’t have a way to prevent that. We know it adds a little bit of friction, but we have the goal to make that available through the SDK in the future.

 

Backend platform suggestions?

You can try any, you have Supabase, Firebase, or any other FaaS (lambdas, azure functions). You need something that can hold secrets.

The important parts is, keep the secret secret and ensure that you want to spend currencies for the given user

 

Local mobile SDK?

For now, you need a secret, so it won’t be available on the SDK. In the future we will allow it, but once we solve the security problem I’ve mentioned before.

 

Hope you find this helpful.

Feel free to reply or DM me with any other feedback or question.

Regards,

Marcos

 

 

 

Inventor of the Touchie!
This post has been closed for comments

6 replies

MarcosC
RevenueCat Staff
Forum|alt.badge.img+7
  • MarcosC
  • RevenueCat Staff
  • Answer
  • August 20, 2025

Hi Andy,

I’m Marcos from the Engineering team at RevenueCat. Thanks for reaching out and for the context on the question.

 

Let me try to address your questions

 

Server backend required?

We decided to require a backend for spending virtual currencies because we cannot guarantee that the person making the request is the one wanting to spend the currencies.

If I knew your app user ID and the public key (which is public) I could spend virtual currencies for that subscriber and we wouldn’t have a way to prevent that. We know it adds a little bit of friction, but we have the goal to make that available through the SDK in the future.

 

Backend platform suggestions?

You can try any, you have Supabase, Firebase, or any other FaaS (lambdas, azure functions). You need something that can hold secrets.

The important parts is, keep the secret secret and ensure that you want to spend currencies for the given user

 

Local mobile SDK?

For now, you need a secret, so it won’t be available on the SDK. In the future we will allow it, but once we solve the security problem I’ve mentioned before.

 

Hope you find this helpful.

Feel free to reply or DM me with any other feedback or question.

Regards,

Marcos

 

 

 

Marcos
Andy Dent
L
  • Lexycon
  • New Member
  • August 24, 2025

I want to ask sth. on that topic that affects me as well. If we go with our own backend for spending, how should we make sure that the user has permission? We end up in the same problem, don't we? I mean we would need the user to login to sth as well (Google Play Services, Game Center, whatever). You see any solution to use this VC anonymously?

Andy Dent
Andy Dent
Forum|alt.badge.img+4
  • Andy Dent
  • Author
  • Helper
  • August 24, 2025

If we go with our own backend for spending, how should we make sure that the user has permission? We end up in the same problem, don't we? I mean we would need the user to login to sth as well (Google Play Services, Game Center, whatever). You see any solution to use this VC anonymously?

Exactly - it’s a classic Leaky Abstraction.

I am a little disappointed that there isn’t some kind of reference architecture for these backends being shipped along with the SDK for them to invoke it. There’s enough extra work required for developers, who may not be familiar with building server-side stuff, that they could well build something at least as vulnerable as your concern.

Do you think it’s going to be adding more secure overall experiences if hundreds of server-naive developers are leaning on ChatGPT to create a backend for them that calls RevenueCat’s virtual currency API?

Whilst I have some ideas already, due to at least trying to maintain a modicum of security via obscurity I don’t think it’s safe for me to publish them on this forum.

Inventor of the Touchie!
L
MarcosC
RevenueCat Staff
Forum|alt.badge.img+7
  • MarcosC
  • RevenueCat Staff
  • September 1, 2025

Hi Andy / Lexycon,

Thanks for the feedback on the feature. 

The problem we have right now is that we don’t have control over some aspects of the application so we cannot guarantee that this feature would not be abused, that’s why we made the requirements about having a backend for now. We don’t control how the feature is used, so we cannot assess the risk of this abuse. BTW, we are working on removing that need, but it requires significant work to do it in a generic way that solves most apps.

We decided to open this up with that limitation in place as we noticed that, even in this current state, it would add value to a lot of apps. The feature is going to keep evolving and we’ll be adding more to it (one being - removing the need of a backend to spend)

 

> If we go with our own backend for spending, how should we make sure that the user has permission?

It’s not a matter of checking if the user has permissions, but making sure we are spending on the right user. Of course, if you had “login in with X”, then that would be simple, as you would need to check that before making the call. 

If you don’t have authentication in place, there are other means. You can just do what Andy mentioned about security via obscurity (and then check if anybody abused it). You can also use Apple App Attestation → https://developer.apple.com/documentation/devicecheck/establishing-your-app-s-integrity or Play Integrity → https://developer.android.com/google/play/integrity/overview 

All of these depends on how you are using virtual currencies, and how much does it affect you if somebody could potentially abuse it

 

Regards,

 

Marcos
Andy Dent
Forum|alt.badge.img+4
  • Andy Dent
  • Author
  • Helper
  • September 1, 2025

>making sure we are spending on the right user
I recently realised I need to have a unique user ID anyway for another app because I’m sharing the offering between Mac and iOS.

This was discussed on the Shipaton Discord in a thread about auth and restoring purchases where Jaewoong enlightened me about the vulnerability of relying on the anon user ID.

The workaround I'm looking at is

  1. Create a UUID anon local unique ID and use that with RevenueCat as the App User ID
  2. Persist that ID using a triple-level store of
    1. iCloud Keychain https://support.apple.com/en-au/109016
    2. iCloud Key-Value Store
    3. App Group UserDefaults cache for fast local access

The redundancy here is because it’s not an updateable value - I either have a single saved ID or not.

I could even expose it to the user if they want to use it to migrate themselves but am holding off on that because I have abuse concerns a bit like your open questions with the backend.

Note that I ran a similar scheme past a couple of Apple advisors during WWDC 1-1 labs, mostly from the perspective of getting app store approval for the restorability and they said it sounded OK.

Inventor of the Touchie!
MarcosC
RevenueCat Staff
Forum|alt.badge.img+7
  • MarcosC
  • RevenueCat Staff
  • September 1, 2025

​@Andy Dent  Missed that thread on discord :( thanks for sharing.

Have you seen this? → https://github.com/codykerns/StableID it does what you want to do with iCloud

Marcos
Andy Dent
Terms & ConditionsCookie settingsAccessibility statement