Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Subscriptions: May need an "introductory price cycles" field in ItemDetails #20

Closed
mgiuca opened this issue Oct 30, 2020 · 1 comment · Fixed by #41
Closed

Subscriptions: May need an "introductory price cycles" field in ItemDetails #20

mgiuca opened this issue Oct 30, 2020 · 1 comment · Fixed by #41

Comments

@mgiuca
Copy link
Member

mgiuca commented Oct 30, 2020

The ItemDetails struct currently has the following relevant fields:

  • PaymentCurrencyAmount price (for subscriptions, the price per subscriptionPeriod)
  • DOMString subscriptionPeriod (price will be charged every one of these, e.g. "P1M" = every month)
  • PaymentCurrencyAmount introductoryPrice (a reduced subscription price for some amount of time)
  • DOMString introductoryPricePeriod (introductoryPrice will be charged for the first one of these, e.g. "P3M" = for the first three months)

But "introductory price period" shouldn't really be a duration string (e.g., "P3M" for two months); it should actually be called "introductory price cycles", an integer representing an exact multiple of the subscription period, in which to charge the reduced amount. For example, if something is normally $10 / month, but you want to charge $8 / month for the first three months, that's:

{
  price: {currency: 'USD', value: '10'},
  subscriptionPeriod: 'P1M',
  introductoryPrice: {currency: 'USD', value: '8'},
  introductoryPriceCycles: 3
}

You wouldn't want to have introductoryPricePeriod: 'P3M' because then that suggests a single lump sum for 3 months. We want to conceptualize this as a recurring payment of N payments every M units of time.

However, apparently that isn't enough either, because some developers may wish to use a different billing period during the introductory pricing phase. This seems very strange to me, but @emilieroberts has stated internally that it's possible to do with the Android Play Billing system, and some developers want to do this. That means we need both introductoryPriceCycles and introductoryPricePeriod.

For example, if something is normally $10 / month, but you want to charge $2 / week for the first three weeks, that's:

{
  price: {currency: 'USD', value: '10'},
  subscriptionPeriod: 'P1M',
  introductoryPrice: {currency: 'USD', value: '2'},
  introductoryPricePeriod: 'P3W',
  introductoryPriceCycles: 3
}

Indeed, the Android Play Billing API actually has three fields related to introductory price: SkuDetails has getIntroductoryPrice, getIntroductoryPriceCycles and getIntroductoryPricePeriod. It would not be possible for us to losslessly map those three fields onto our two fields. So I think we need to follow suit and expose all three.

@emilieroberts
Copy link

emilieroberts commented Oct 30, 2020

I think in simple cases it seems strange, but for long subscriptions or high-value subscriptions, it makes more sense. For example:

MyAwesomeMovieStreamingService $2 Halloween Madness Sale!

  • $20/month, first 2 weeks only $2 for a limited time
  • $200/year, first month only $2 for a limited time

The dev wouldn't necessarily want to advertise a first year subscription for $200 + 2 - (200 / 12) = $185.33

phoglenix added a commit that referenced this issue Jan 13, 2022
phoglenix added a commit that referenced this issue Jan 14, 2022
Fixes #20 

Adds v2.1 full API interface and summary of added fields
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants