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.
The
ItemDetailsstruct currently has the following relevant fields:PaymentCurrencyAmount price(for subscriptions, the price persubscriptionPeriod)DOMString subscriptionPeriod(pricewill be charged every one of these, e.g. "P1M" = every month)PaymentCurrencyAmount introductoryPrice(a reduced subscription price for some amount of time)DOMString introductoryPricePeriod(introductoryPricewill 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:
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
introductoryPriceCyclesandintroductoryPricePeriod.For example, if something is normally $10 / month, but you want to charge $2 / week for the first three weeks, that's:
Indeed, the Android Play Billing API actually has three fields related to introductory price:
SkuDetailshasgetIntroductoryPrice,getIntroductoryPriceCyclesandgetIntroductoryPricePeriod. 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.