Decision Proposal 263 - Telco Accounts Payloads

[CDR-API-Stream]

This decision proposal contains a recommendation for the candidate URIs and payloads for the Account data cluster for the telecommunications sector.

This consultation will be open for feedback until the 16th September 2022.

18/8/2022 - Please note that a minor amendment to the proposal was made based on feedback from the CX team. This included the addition of a type and billingType field and a format correct.

27/9/2022 Decision proposal updated
Decision Proposal 263 - Account Data Payloads.pdf

[Telstra-CDR]

We have reviewed the design proposal, Please see the detailed feedack

Concession, Rebates and Grants

Rebate is “not” a concession, Concession would indicate some eligibility rules and hence should be treated separately.
These are mainly aligned to the Services Australia (Govt) data base of valid CCHs
https://www.servicesaustralia.gov.au/individuals/subjects/concession-and-health-care-cards

/Telco/Accounts
/Telco/Accounts/{Accountid}

Suggestion to Limit size of payloads where applicable, Add additional Query Parameters also consider removing the
Authorized contacts from the account Payload responses and include as an additional End point, The same for Charges and question on if it should be in the account payload.

Page-size Default to 25, suggest to include a minimum page size.

Type Limited to Mobile, Broadband (what about Fixed, Entertainment(media) other types of products), this is similar to the feedback we have provided in the product reference payloads.

Plans An alternative model to consider and simpler hierarchy as an example to represent the product / plan / service hierarchy.

Plans How is version controlled (example plans that are grandfathered)

Plans There appears to be no correlation to the product reference data.

Service IDs - How do we represent Internet based services etc, customer will not know how a nbn service id is
represented, Telstra currently uses FNN to represent both Fixed line and Broadband services as a
example.

Charges - Requires a description, are these individual charges on the invoice? For example:
• Calls (domestic, international, landline, mobile)
• SMS/MMS
• Data Usage
• Add-ons
Pre-bill or post-bill?

/Telco/Accounts/{Accountid}/payment-schedule

Enums - Should Enums follow other naming standards which is generally upper case
e.g cardDebit → CARD_DEBIT

PaymentScheduleUType - What about methods that aren’t card, direct debit or manual?

Tokenised (bsb, Acc no) - challenging the intent of this.

Account Number Designation scope section indicates that Account Number should be masked. This description
indicates that a value needs to be returned as on the physical statement

[kirkycdr]

@Telstra-CDR Thanks for the detailed feedback. Please below. We will provide an updated version of this decision proposal shortly.

We have reviewed the design proposal, Please see the detailed feedack

Concession, Rebates and Grants

Rebate is “not” a concession, Concession would indicate some eligibility rules and hence should be treated separately. These are mainly aligned to the Services Australia (Govt) data base of valid CCHs https://www.servicesaustralia.gov.au/individuals/subjects/concession-and-health-care-cards

DSB: Thanks this is useful

/Telco/Accounts /Telco/Accounts/{Accountid}

Suggestion to Limit size of payloads where applicable, Add additional Query Parameters also consider removing the Authorized contacts from the account Payload responses and include as an additional End point, The same for Charges and question on if it should be in the account payload.

Page-size Default to 25, suggest to include a minimum page size.

DSB: noted

Type Limited to Mobile, Broadband (what about Fixed, Entertainment(media) other types of products), this is similar to the feedback we have provided in the product reference payloads.

DSB: Thanks, please see comments on the product payloads response

Plans An alternative model to consider and simpler hierarchy as an example to represent the product / plan / service hierarchy.

DSB: Thanks, this will be reviewed

Plans How is version controlled (example plans that are grandfathered

DSB: This would be specific to each service provider.

Plans There appears to be no correlation to the product reference data.

DSB: This was purposely excluded, Please let us know your reasoning if you believe it to be required

Service IDs - How do we represent Internet based services etc, customer will not know how a nbn service id is represented, Telstra currently uses FNN to represent both Fixed line and Broadband services as a example.

As I understand there is no standardization in this space (NBN), however, there is a unique identifier specific to each service provider

Charges - Requires a description, are these individual charges on the invoice? For example: • Calls (domestic, international, landline, mobile) • SMS/MMS • Data Usage • Add-ons Pre-bill or post-bill?

DSB: Yes this is covered in a separate billing proposal. Decision Proposal DP264

/Telco/Accounts/{Accountid}/payment-schedule

Enums - Should Enums follow other naming standards which is generally upper case e.g cardDebit → CARD_DEBIT
DSB: This is a reuse of an enum structure we have used in other sectors.

PaymentScheduleUType - What about methods that aren’t card, direct debit or manual?

DSB: There are UTypes for Direct Debit and Manual contained in the payment schedule payload

Tokenised (bsb, Acc no) - challenging the intent of this.

We have found in other sectors the some retailers use tokens for this purpose. Note isTokenised is optional.

Account Number Designation scope section indicates that Account Number should be masked. This description indicates that a value needs to be returned as on the physical statement

DSB: Good pickup will update this.

[kirkycdr]

27/9/2022 Decision proposal updated
Decision Proposal 263 - Account Data Payloads.pdf

[perlboy]

I know feedback period is closed but here's some quick late additions:

• Service Identifier needs clarification, it isn't actually unique in a lot of cases especially if using MSISDN (which is an internationalised FNN). It may also disclose PII (ie. their phone number) for which the Consumer doesn't intend
• Introduction of hasConcessions is a new pattern and I'm not sure is actually valuable as the ADR can always call concessions if it's relevant to their use case and get an empty array - it's a very small payload
• An account may have multiple services each on their own plans. A simple example is Telstra One addon which provides an Apple Watch with a usim on an addon service (ie. a standalone plan in the same account). serviceIds seems to be situated outside the plans array.
• charges array seems to have an object called charge in it, presume this is an editing defect
• charges are very freeform, suspect ADRs will find this problematic for bill comparisons
• Payment Schedule is missing digital wallet
• concessionStatus seems needlessly prefixed
• concessions contains concession, presume this is an editing defect
• rebateStatus looks orphaned, presume this is an editing defect and intended to be part of rebates array, on this basis it is needlessly prefixed and can be just status
• Unclear on the idea of a grant in concession payload

[CDR-API-Stream]

Marking this consultation as No Decision Made. While the proposal and feedback for this consultation have been incorporated into the draft standards this is not yet a formal decision of the Chair.