2024-05-07 Carrier Billing - Meeting Minutes

Owned by Pedro Díez García
Last updated: May 25, 2024
5 min read

Attendees & Representation

Type @ and your name to indicate your attendance

LF Staff:

Community:

Pedro Díez García (Telefonica)

@Pedro Antonio de Alarcon Sánchez (Telefónica)

Ludovic Robert (Orange)

@K Barath (Ericsson)

@Ersilia Mazzocco (Vodafone)

Surajj Jaggernath (Vodacom)



Date


Status: FINAL

Final Date for Comments:  

Agenda

The project's Antitrust Policy, which you can find linked from the LF and project websites. The policy is important where multiple companies, including potential industry competitors, are participating in meetings. Please review and if you have any questions, please contact your company legal counsel. Members of the LF may contact Andrew Updegrove at the firm Gesmer Updegrove LLP, which provides legal counsel to the LF.

  • Management of new meetings
  • Consolidated Work
  • Refund Track - Proposal Review
  • AoB

Minutes

Management of new meetings

  • Pedro Díez García need to ping again Evan Harrison from LF in order to generate Meeting Link in Zoom.


Consolidated Work

  • N/A


Refund Track Review


  • Discussion during the meeting:
    • Pedro comments he has focused in the Commonalities track and some pending actions are not covered yet. We will be updating proposal and informing via PR and slack channel. Some feedbak product received, and pending one expected for the next week.
    • From 3rd April meeting:
      • Refund creation
        • Request model based on Payment API.
          • type
            • Discussion around this concept. After Telefonica's checking it is concluded so far that in total refunds amount is not required to be indicated CLOSED. Pending to adapt this consideration in the proposal
              • Consider the description of Use Case within refund Proposal
              • Ersilia will check internally about VF DE feedack regarding the Amount in the total refund.
            • With regards to partial refund, there is the comment about how to manage the taxes. OPEN
        • List Of Refunds
          • Request Model
            • Regarding filter criteria:
              • Ludovic Robert initiates a thread for further investment/discussion regarding the consideration of service as input for filter criteria OPEN
    • Comments from Orange within PR (Ludovic Robert)

      • Most of this points are not request for change but question I got when I did this review. Kept for tracking and proposal evolution

        • Are we sure to manage refund_in_progress, totally_refunded, partially_refunded as TransactionOperationStatus ? my point is that a payment could have been Succeeded and then refunded. Both state are valid. Need to be sure we did not need to tackle that in a specific refundStatus.
        • I'm still not sure if refund should be managed in a separate yaml or same yaml that payment. Have you @PedroDiez good rationale to make them separate?
        • Are we sure that refundAmount should be mandatory ? if type is total this could be source of unnecessary error (what about a request with type:total and amount inconsistent btw the payment and the refund?).
        • If requester fill refundDetails do we need to make check vs payment item? I guess yes.
        • In payment we require a referenceCode in the request - do we need one here for the refund?
    • During meeting:
      • Refund `type` concept
        • OPEN With regards to partial refund, there is the comment about how to manage the taxes (i.e. for partial refund it is needed to indicate proportional taxAmount?, it may be complex for developer). Pen
      • Orange comments discussion:
        • ONGOING Are we sure to manage refund_in_progress, totally_refunded, partially_refunded as TransactionOperationStatus ? my point is that a payment could have been Succeeded and then refunded. Both state are valid. Need to be sure we did not need to tackle that in a specific refundStatus. 
          • The use of statuses related to the refund within the payment status concept can create confussion and misunderstanding. It is agreed to be renamed to "refundStatus" an also align this in carrier billing payment resource. Agreed by de WG. To be renamed
          • Also it is seen more suitable to move the "status" of the resource to the higher level of the resource, along with resource Identifier, because now it is part of "amount" model. Agreed by the WG. To be changed
          • Also need to cover the scenario where having several refunds in place.
        • ONGOING Are we sure that refundAmount should be mandatory ? if type is total this could be source of unnecessary error (what about a request with type:total and amount inconsistent btw the payment and the refund?).
          • Commented by Pedro that still pending feedback from business. Expected to have by the end of April
          • Ludovic highlights that solution would tend to be simple and decoupled from business and alignment is needed. Pedro will check internally. It could be easier in that way to manage as an oneOf option.
          • As commented before, amount would not be considered in total refund in principle
        • ONGOING If requester fill refundDetails do we need to make check vs payment item? I guess yes.
          • Yes, it is agreed the information has to be consistent between payment and related refunds. HTTP 422 (specific code pending) commented as initial approach.
          • During this point also exceptions model commented two main points:
            • createRefund
              • For non existing "paymentId". Probably suitable exception is 404 NOT FOUND
              • Set of 403 exceptions (Business Exceptions) explained
                • Pedro will provide more detail for "CARRIER_BILLING_REFUND.PAYMENT_NOT_ELIGIBLE_FOR_REFUND" within PR, requested specifically by business
                • Barath and Ludovic comments about "CARRIER_BILLING_REFUND.REFUND_DENIED" one and the consideration to have alignment with the event case (async checking)
                • Ludovic initiates discussion about the use of HTTP 403 vs other status, commenting 403 to his view is closer to authorization topics and also realted to Issue#127 discussion. Pedro will think about it and also discuss with Jose. See align error model bullet
        • OPEN Commented `merchantIdentifier` as filter criteria for get a list of refunds
          • Commented it makes sense for aggregator case from the business point of view, however it can be tricky for the developer as it would have to query payment list endpoint to obtain the information. Need to have some thinking about this 
        • OPEN I'm still not sure if refund should be managed in a separate yaml or same yaml that payment. Have you @PedroDiez good rationale to make them separate?
          • Pedro comments it is not a technical consideration but a strategical one, in order to not have a big API with the aim of have full APIs implemented as well as to provide flexibility for Telco Operators to their roadmaps delivery of features.
        • OPEN Align error model with commonalities one and also provide a rationale about how exceptions would apply to Carrier Billing. New Issue#154 created after meeting
        • OPEN Mentioned during the meeting the need of controlling amounts have to be positive. New Issue#153 created after meeting
        • OPEN Mentioned during the meeting the need to agree on a scope for Carrier Billing within the contect of Meta-Release v0.4 (Fall24). New Issue#155 created after the meeting
  • Next actions are:
    • Make clear changes in the PR
    • Everybody to think about pending points


AoB

  • @Ersilia Mazzocco (Vodafone) and Surajj Jaggernath joins the meeting
  • Next Meeting will be held on 15th May (16:00 - 17:00)


Action items