Open APIs

Hi All,

While working on a very common use case for device acquisition based on installments, I had the following queries with respect to the product catalog:

1. Should the following feature to create installment plans be managed in the product catalog?
   1. A mechanism to arrive at the charge for each month based on the interest rate, period & total amount (calculation of charges in the product catalog itself while creating such offerings)
2. Modelling installment plans in product catalog: For identifying incase a productOffering is based on installments or not could be based on a characteristic (Let's assume "installmentPlan"= Upfront, 12 months, 24 months etc.) However, the characteristic would have to be strong-typed for the downstream systems to identify it to refer to the plan period selected.
   1. #Moreover, this would remain as a policyRule/priceLogicAlgorithm to determine the charge associated with each plan type
   2. This has a limitation that for a particular selected plan the monthly installment remains the same, lets assume $100 for each month. Incase the payments need to be increased monthly, $100 for month 1, $110 for month 2, so on, should we consider strong typing another characteristic with the %age increase.

Didn't find much help on this topic in previous discussions. Any potential plan for such an evolution.

Thanks in advance for your replies and thoughts!

Regards,

Hi All,

While working on a very common use case for device acquisition based on installments, I had the following queries with respect to the product catalog:

1. Should the following feature to create installment plans be managed in the product catalog?
   1. A mechanism to arrive at the charge for each month based on the interest rate, period & total amount (calculation of charges in the product catalog itself while creating such offerings)
2. Modelling installment plans in product catalog: For identifying incase a productOffering is based on installments or not could be based on a characteristic (Let's assume "installmentPlan"= Upfront, 12 months, 24 months etc.) However, the characteristic would have to be strong-typed for the downstream systems to identify it to refer to the plan period selected.
   1. #Moreover, this would remain as a policyRule/priceLogicAlgorithm to determine the charge associated with each plan type
   2. This has a limitation that for a particular selected plan the monthly installment remains the same, lets assume $100 for each month. Incase the payments need to be increased monthly, $100 for month 1, $110 for month 2, so on, should we consider strong typing another characteristic with the %age increase.

Didn't find much help on this topic in previous discussions. Any potential plan for such an evolution.

Thanks in advance for your replies and thoughts!

Regards,

------------------------------
Akshay Sahni
Functional Architect
Orange Innovation India
------------------------------

Hi,

to disambiguate the semantic around "payment plan", I propose 2 different terms:

• Payment Plan Template
• Payment Plan Schedule

Managing Payment Plan Templates is a design time activity. it defines how the the payments will be calculated, (interest rate, number of instalment, Escalation formula, rounding rules etc). in essence, a payment plan is a payment option.

Managing Payment Plan Schedule is a run-time activity. it defines the list of payments payer must settle, each payment is an amount and a date. Further activities are involved when payment is collected, unpaid etc.

To answer your question: I don't know  any TMF guide about Payment Plan Template, only for Payment Plan Schedule.

Here are some options to consider:

1. manage them outside the catalogue in a dedicated application. TMF Catalogue has no support for Settlement option, payment method etc.
2. you could compromise with policyRef (with polymorphism) in the catalogue, under the relevant product offer
3. you could also compromise with ProductTerm, but the datamodel is weak, you would have to extend the API or maybe use the @schemalocation to "define additional attributes and relationships."
4. Another approach, if you're open minded, is to consider the Payment plan as a product offering. Considering that this settlement option is a product offering typically sold by banks (loans etc), I think it's legitimate that CSP can do the same. Modelling it as a PO offers multiple advantages:

product relationships, bundling, eligibility rules are easy to model, and the icing on the cake is that all the calculation parameters can be very easily modelled as product characteristic, some of them may even be selectable by end-user for instance to let customer choose the number of instalments.

Furthermore, you mention "charges", "amounts" ($100 for month and an increase) in your post. That suggests a pregnant confusion between prices and payments.

Let's take the opportunity to remind us that a payment or an instalment is not a price. I see this confusion is very pregnant.

• A Payment Plan Template is not a productOfferingPrice
• A Payment Plan Schedule is not an array of productPrices

amounts should be computed at runtime based on rules not stored in the catalogue.

here is an basic example of a Payment Plan Template. I added your geometric escalation rule. This is something you could store under ProductTerm

{  "planId": "PHONEONLY_10X_DP15_ZURICH",  "description": "15 % down payment at purchase, then 10 monthly instalments that rise 5 % each time; nominal annual interest 10 % only for phone sold with post-paid mobile subscription",  "downPayment": {    "rate": 0.15,                    // 15 % of product price    "dueTiming": "atPurchase",       // settled immediately (same day as sale)    "appliesTo": "principal"         // reduces the financed principal; no interest charged  },  "installmentRule": {    "count": 10,    "frequency": "monthly",    "escalation": {      "method": "geometric",      "increment": 0.05,      "base": "previous"    },    "principalBase": "netPrice * (1 - downPayment.rate)",  // financed 85 % of price    "amountAllocation": "pro-rata",       // geometric weights normalised to the financed base    "rounding": {      "mode": "halfEven",      "scale": 2    }  },  "financeTerms": {    "nominalAnnualRate": 0.10,    "compounding": "monthly",    "dayCountConvention": "ACT/365F"  },  "constraints": {    "gracePeriodAllowed": false,    "earlyRepaymentAllowed": true,    "penaltyRate": 0.02  },  "engineHints": {    "weightFormula": "w(n) = (1 + increment)^(n-1)",    "normaliseWeights": true  },  "schemaVersion": "1.0"}

💡Payment plans are mentioned in customer/party API and the payment API. Those are not for Payment Plan Template, but maybe they give some insights on how the templates are managed. there could be more to search in TMF confluence website.

------------------------------
Kind regards,

Matthieu Hattab
Digital Sales Domain Architect
Lyse Tele AS

Original Message:
Sent: Jul 24, 2025 00:32
From: Akshay Sahni
Subject: Installment plans for devices and charge modelling in the product catalog

Hi All,

While working on a very common use case for device acquisition based on installments, I had the following queries with respect to the product catalog:

1. Should the following feature to create installment plans be managed in the product catalog?
   1. A mechanism to arrive at the charge for each month based on the interest rate, period & total amount (calculation of charges in the product catalog itself while creating such offerings)
2. Modelling installment plans in product catalog: For identifying incase a productOffering is based on installments or not could be based on a characteristic (Let's assume "installmentPlan"= Upfront, 12 months, 24 months etc.) However, the characteristic would have to be strong-typed for the downstream systems to identify it to refer to the plan period selected.
   1. #Moreover, this would remain as a policyRule/priceLogicAlgorithm to determine the charge associated with each plan type
   2. This has a limitation that for a particular selected plan the monthly installment remains the same, lets assume $100 for each month. Incase the payments need to be increased monthly, $100 for month 1, $110 for month 2, so on, should we consider strong typing another characteristic with the %age increase.

Didn't find much help on this topic in previous discussions. Any potential plan for such an evolution.

Thanks in advance for your replies and thoughts!

Regards,

------------------------------
Akshay Sahni
Functional Architect
Orange Innovation India
------------------------------

Hello Matthieu, All, 

Thanks for your reply.

Thanks for bringing in clarity as to the capabilities that should be/NOT be managed in the product catalog, agree with the installment payment schedule being not managed in the product catalog. We can also infer that penalties for termination of the above scenario be also only "defined" in the catalog with the actual charging happening in the customer bill API/component. The product order could only reflect the terminate order, with the appropriate termination definition?

Would appreciate to have your opinions on this?

Regards, 

Hi,

to disambiguate the semantic around "payment plan", I propose 2 different terms:

• Payment Plan Template
• Payment Plan Schedule

Managing Payment Plan Templates is a design time activity. it defines how the the payments will be calculated, (interest rate, number of instalment, Escalation formula, rounding rules etc). in essence, a payment plan is a payment option.

Managing Payment Plan Schedule is a run-time activity. it defines the list of payments payer must settle, each payment is an amount and a date. Further activities are involved when payment is collected, unpaid etc.

To answer your question: I don't know  any TMF guide about Payment Plan Template, only for Payment Plan Schedule.

Here are some options to consider:

1. manage them outside the catalogue in a dedicated application. TMF Catalogue has no support for Settlement option, payment method etc.
2. you could compromise with policyRef (with polymorphism) in the catalogue, under the relevant product offer
3. you could also compromise with ProductTerm, but the datamodel is weak, you would have to extend the API or maybe use the @schemalocation to "define additional attributes and relationships."
4. Another approach, if you're open minded, is to consider the Payment plan as a product offering. Considering that this settlement option is a product offering typically sold by banks (loans etc), I think it's legitimate that CSP can do the same. Modelling it as a PO offers multiple advantages:

product relationships, bundling, eligibility rules are easy to model, and the icing on the cake is that all the calculation parameters can be very easily modelled as product characteristic, some of them may even be selectable by end-user for instance to let customer choose the number of instalments.

Furthermore, you mention "charges", "amounts" ($100 for month and an increase) in your post. That suggests a pregnant confusion between prices and payments.

Let's take the opportunity to remind us that a payment or an instalment is not a price. I see this confusion is very pregnant.

• A Payment Plan Template is not a productOfferingPrice
• A Payment Plan Schedule is not an array of productPrices

amounts should be computed at runtime based on rules not stored in the catalogue.

here is an basic example of a Payment Plan Template. I added your geometric escalation rule. This is something you could store under ProductTerm

{  "planId": "PHONEONLY_10X_DP15_ZURICH",  "description": "15 % down payment at purchase, then 10 monthly instalments that rise 5 % each time; nominal annual interest 10 % only for phone sold with post-paid mobile subscription",  "downPayment": {    "rate": 0.15,                    // 15 % of product price    "dueTiming": "atPurchase",       // settled immediately (same day as sale)    "appliesTo": "principal"         // reduces the financed principal; no interest charged  },  "installmentRule": {    "count": 10,    "frequency": "monthly",    "escalation": {      "method": "geometric",      "increment": 0.05,      "base": "previous"    },    "principalBase": "netPrice * (1 - downPayment.rate)",  // financed 85 % of price    "amountAllocation": "pro-rata",       // geometric weights normalised to the financed base    "rounding": {      "mode": "halfEven",      "scale": 2    }  },  "financeTerms": {    "nominalAnnualRate": 0.10,    "compounding": "monthly",    "dayCountConvention": "ACT/365F"  },  "constraints": {    "gracePeriodAllowed": false,    "earlyRepaymentAllowed": true,    "penaltyRate": 0.02  },  "engineHints": {    "weightFormula": "w(n) = (1 + increment)^(n-1)",    "normaliseWeights": true  },  "schemaVersion": "1.0"}

💡Payment plans are mentioned in customer/party API and the payment API. Those are not for Payment Plan Template, but maybe they give some insights on how the templates are managed. there could be more to search in TMF confluence website.

------------------------------
Kind regards,

Matthieu Hattab
Digital Sales Domain Architect
Lyse Tele AS

Original Message:
Sent: Jul 24, 2025 00:32
From: Akshay Sahni
Subject: Installment plans for devices and charge modelling in the product catalog

Hi All,

While working on a very common use case for device acquisition based on installments, I had the following queries with respect to the product catalog:

1. Should the following feature to create installment plans be managed in the product catalog?
   1. A mechanism to arrive at the charge for each month based on the interest rate, period & total amount (calculation of charges in the product catalog itself while creating such offerings)
2. Modelling installment plans in product catalog: For identifying incase a productOffering is based on installments or not could be based on a characteristic (Let's assume "installmentPlan"= Upfront, 12 months, 24 months etc.) However, the characteristic would have to be strong-typed for the downstream systems to identify it to refer to the plan period selected.
   1. #Moreover, this would remain as a policyRule/priceLogicAlgorithm to determine the charge associated with each plan type
   2. This has a limitation that for a particular selected plan the monthly installment remains the same, lets assume $100 for each month. Incase the payments need to be increased monthly, $100 for month 1, $110 for month 2, so on, should we consider strong typing another characteristic with the %age increase.

Didn't find much help on this topic in previous discussions. Any potential plan for such an evolution.

Thanks in advance for your replies and thoughts!

Regards,

------------------------------
Akshay Sahni
Functional Architect
Orange Innovation India
------------------------------

Hello Matthieu, All, 

Thanks for your reply.

Thanks for bringing in clarity as to the capabilities that should be/NOT be managed in the product catalog, agree with the installment payment schedule being not managed in the product catalog. We can also infer that penalties for termination of the above scenario be also only "defined" in the catalog with the actual charging happening in the customer bill API/component. The product order could only reflect the terminate order, with the appropriate termination definition?

Would appreciate to have your opinions on this?

Regards, 

Hi,

to disambiguate the semantic around "payment plan", I propose 2 different terms:

• Payment Plan Template
• Payment Plan Schedule

Managing Payment Plan Templates is a design time activity. it defines how the the payments will be calculated, (interest rate, number of instalment, Escalation formula, rounding rules etc). in essence, a payment plan is a payment option.

Managing Payment Plan Schedule is a run-time activity. it defines the list of payments payer must settle, each payment is an amount and a date. Further activities are involved when payment is collected, unpaid etc.

To answer your question: I don't know  any TMF guide about Payment Plan Template, only for Payment Plan Schedule.

Here are some options to consider:

1. manage them outside the catalogue in a dedicated application. TMF Catalogue has no support for Settlement option, payment method etc.
2. you could compromise with policyRef (with polymorphism) in the catalogue, under the relevant product offer
3. you could also compromise with ProductTerm, but the datamodel is weak, you would have to extend the API or maybe use the @schemalocation to "define additional attributes and relationships."
4. Another approach, if you're open minded, is to consider the Payment plan as a product offering. Considering that this settlement option is a product offering typically sold by banks (loans etc), I think it's legitimate that CSP can do the same. Modelling it as a PO offers multiple advantages:

product relationships, bundling, eligibility rules are easy to model, and the icing on the cake is that all the calculation parameters can be very easily modelled as product characteristic, some of them may even be selectable by end-user for instance to let customer choose the number of instalments.

Furthermore, you mention "charges", "amounts" ($100 for month and an increase) in your post. That suggests a pregnant confusion between prices and payments.

Let's take the opportunity to remind us that a payment or an instalment is not a price. I see this confusion is very pregnant.

• A Payment Plan Template is not a productOfferingPrice
• A Payment Plan Schedule is not an array of productPrices

amounts should be computed at runtime based on rules not stored in the catalogue.

here is an basic example of a Payment Plan Template. I added your geometric escalation rule. This is something you could store under ProductTerm

{  "planId": "PHONEONLY_10X_DP15_ZURICH",  "description": "15 % down payment at purchase, then 10 monthly instalments that rise 5 % each time; nominal annual interest 10 % only for phone sold with post-paid mobile subscription",  "downPayment": {    "rate": 0.15,                    // 15 % of product price    "dueTiming": "atPurchase",       // settled immediately (same day as sale)    "appliesTo": "principal"         // reduces the financed principal; no interest charged  },  "installmentRule": {    "count": 10,    "frequency": "monthly",    "escalation": {      "method": "geometric",      "increment": 0.05,      "base": "previous"    },    "principalBase": "netPrice * (1 - downPayment.rate)",  // financed 85 % of price    "amountAllocation": "pro-rata",       // geometric weights normalised to the financed base    "rounding": {      "mode": "halfEven",      "scale": 2    }  },  "financeTerms": {    "nominalAnnualRate": 0.10,    "compounding": "monthly",    "dayCountConvention": "ACT/365F"  },  "constraints": {    "gracePeriodAllowed": false,    "earlyRepaymentAllowed": true,    "penaltyRate": 0.02  },  "engineHints": {    "weightFormula": "w(n) = (1 + increment)^(n-1)",    "normaliseWeights": true  },  "schemaVersion": "1.0"}

💡Payment plans are mentioned in customer/party API and the payment API. Those are not for Payment Plan Template, but maybe they give some insights on how the templates are managed. there could be more to search in TMF confluence website.

------------------------------
Kind regards,

Matthieu Hattab
Digital Sales Domain Architect
Lyse Tele AS

Original Message:
Sent: Jul 24, 2025 00:32
From: Akshay Sahni
Subject: Installment plans for devices and charge modelling in the product catalog

Hi All,

While working on a very common use case for device acquisition based on installments, I had the following queries with respect to the product catalog:

1. Should the following feature to create installment plans be managed in the product catalog?
   1. A mechanism to arrive at the charge for each month based on the interest rate, period & total amount (calculation of charges in the product catalog itself while creating such offerings)
2. Modelling installment plans in product catalog: For identifying incase a productOffering is based on installments or not could be based on a characteristic (Let's assume "installmentPlan"= Upfront, 12 months, 24 months etc.) However, the characteristic would have to be strong-typed for the downstream systems to identify it to refer to the plan period selected.
   1. #Moreover, this would remain as a policyRule/priceLogicAlgorithm to determine the charge associated with each plan type
   2. This has a limitation that for a particular selected plan the monthly installment remains the same, lets assume $100 for each month. Incase the payments need to be increased monthly, $100 for month 1, $110 for month 2, so on, should we consider strong typing another characteristic with the %age increase.

Didn't find much help on this topic in previous discussions. Any potential plan for such an evolution.

Thanks in advance for your replies and thoughts!

Regards,

------------------------------
Akshay Sahni
Functional Architect
Orange Innovation India
------------------------------

Hi,

to disambiguate the semantic around "payment plan", I propose 2 different terms:

• Payment Plan Template
• Payment Plan Schedule

Managing Payment Plan Templates is a design time activity. it defines how the the payments will be calculated, (interest rate, number of instalment, Escalation formula, rounding rules etc). in essence, a payment plan is a payment option.

Managing Payment Plan Schedule is a run-time activity. it defines the list of payments payer must settle, each payment is an amount and a date. Further activities are involved when payment is collected, unpaid etc.

To answer your question: I don't know  any TMF guide about Payment Plan Template, only for Payment Plan Schedule.

Here are some options to consider:

1. manage them outside the catalogue in a dedicated application. TMF Catalogue has no support for Settlement option, payment method etc.
2. you could compromise with policyRef (with polymorphism) in the catalogue, under the relevant product offer
3. you could also compromise with ProductTerm, but the datamodel is weak, you would have to extend the API or maybe use the @schemalocation to "define additional attributes and relationships."
4. Another approach, if you're open minded, is to consider the Payment plan as a product offering. Considering that this settlement option is a product offering typically sold by banks (loans etc), I think it's legitimate that CSP can do the same. Modelling it as a PO offers multiple advantages:

product relationships, bundling, eligibility rules are easy to model, and the icing on the cake is that all the calculation parameters can be very easily modelled as product characteristic, some of them may even be selectable by end-user for instance to let customer choose the number of instalments.

Furthermore, you mention "charges", "amounts" ($100 for month and an increase) in your post. That suggests a pregnant confusion between prices and payments.

Let's take the opportunity to remind us that a payment or an instalment is not a price. I see this confusion is very pregnant.

• A Payment Plan Template is not a productOfferingPrice
• A Payment Plan Schedule is not an array of productPrices

amounts should be computed at runtime based on rules not stored in the catalogue.

here is an basic example of a Payment Plan Template. I added your geometric escalation rule. This is something you could store under ProductTerm

{  "planId": "PHONEONLY_10X_DP15_ZURICH",  "description": "15 % down payment at purchase, then 10 monthly instalments that rise 5 % each time; nominal annual interest 10 % only for phone sold with post-paid mobile subscription",  "downPayment": {    "rate": 0.15,                    // 15 % of product price    "dueTiming": "atPurchase",       // settled immediately (same day as sale)    "appliesTo": "principal"         // reduces the financed principal; no interest charged  },  "installmentRule": {    "count": 10,    "frequency": "monthly",    "escalation": {      "method": "geometric",      "increment": 0.05,      "base": "previous"    },    "principalBase": "netPrice * (1 - downPayment.rate)",  // financed 85 % of price    "amountAllocation": "pro-rata",       // geometric weights normalised to the financed base    "rounding": {      "mode": "halfEven",      "scale": 2    }  },  "financeTerms": {    "nominalAnnualRate": 0.10,    "compounding": "monthly",    "dayCountConvention": "ACT/365F"  },  "constraints": {    "gracePeriodAllowed": false,    "earlyRepaymentAllowed": true,    "penaltyRate": 0.02  },  "engineHints": {    "weightFormula": "w(n) = (1 + increment)^(n-1)",    "normaliseWeights": true  },  "schemaVersion": "1.0"}

💡Payment plans are mentioned in customer/party API and the payment API. Those are not for Payment Plan Template, but maybe they give some insights on how the templates are managed. there could be more to search in TMF confluence website.

------------------------------
Kind regards,

Matthieu Hattab
Digital Sales Domain Architect
Lyse Tele AS

Original Message:
Sent: Jul 24, 2025 00:32
From: Akshay Sahni
Subject: Installment plans for devices and charge modelling in the product catalog

Hi All,

While working on a very common use case for device acquisition based on installments, I had the following queries with respect to the product catalog:

1. Should the following feature to create installment plans be managed in the product catalog?
   1. A mechanism to arrive at the charge for each month based on the interest rate, period & total amount (calculation of charges in the product catalog itself while creating such offerings)
2. Modelling installment plans in product catalog: For identifying incase a productOffering is based on installments or not could be based on a characteristic (Let's assume "installmentPlan"= Upfront, 12 months, 24 months etc.) However, the characteristic would have to be strong-typed for the downstream systems to identify it to refer to the plan period selected.
   1. #Moreover, this would remain as a policyRule/priceLogicAlgorithm to determine the charge associated with each plan type
   2. This has a limitation that for a particular selected plan the monthly installment remains the same, lets assume $100 for each month. Incase the payments need to be increased monthly, $100 for month 1, $110 for month 2, so on, should we consider strong typing another characteristic with the %age increase.

Didn't find much help on this topic in previous discussions. Any potential plan for such an evolution.

Thanks in advance for your replies and thoughts!

Regards,

------------------------------
Akshay Sahni
Functional Architect
Orange Innovation India
------------------------------