Feature request: refund virtual currency spend back into original expiring credit bucket

Hi RevenueCat team,

I’m using RevenueCat Virtual Currency for subscription-based credits where credits expire at the end of the subscription billing period. The normal spending behavior works well for this model: expiring credits are consumed first, and unused subscription credits do not roll over into future periods.

I’m running into an issue when consumed credits need to be refunded.

Flow:

1. A subscription grants expiring credits for the current billing period.
2. My backend spends credits through the virtual currency transactions API.
3. In some cases, that spend needs to be reversed/refunded.
4. Today, the only option I see is to create a positive virtual currency adjustment through the API.

The problem is that this positive adjustment appears to behave like a new non-expiring/admin adjustment, rather than being tied back to the original credit bucket that was consumed. So if the original spend used expiring subscription credits, the refund can effectively turn those credits into non-expiring credits and allow them to roll over into a later period.

That breaks the intended semantics of subscription-period credits: reversing a spend should restore the user’s credits according to the original credit source and expiration rules, not create a new permanent balance.

Feature request:

Could RevenueCat support a first-class “refund virtual currency spend” operation that reverses or refunds a previous virtual currency transaction while preserving the expiration behavior of the originally consumed credits?

For example:

POST /virtual_currencies/transactions/{transaction_id}/refund

Desired behavior:

• If the original spend consumed expiring subscription credits, the refund restores credits into the same expiration bucket.
• If that period has already expired, the refunded credits should also be expired/unavailable.
• If the original spend consumed non-expiring purchased credits, the refund restores non-expiring credits.
• If the spend consumed multiple buckets, the refund restores the original bucket allocation.
• The operation should be idempotent and visible in customer history.

Is there currently any supported way to do this, or is this a gap in the current Virtual Currency API model?

Thanks.