2024-04-03 Carrier Billing - Meeting Minutes

Attendees & Representation

Type @ and your name to indicate your attendance

LF Staff:

Community:

@Pedro Díez García (Telefonica)

@Ludovic Robert (Orange)

@Rafał A. (Unlicensed) (Deustche Telekom)

@Ajit Raghavan (Ericsson)

@K Barath (Ericsson)

Date

Apr 3, 2024

Status: FINAL

Final Date for Comments: Apr 12, 2024 

Agenda

• Management of new meetings

• Refund Track - Initial Proprosal Review

• AoB

Minutes

Management of new meetings

• As per TSC guideline, meetings are being moved to CAMARA Wiki Confluence site. @Pedro Díez García comments some questions/doubts clarified by @Ludovic Robert and @Rafal Artych regarding how to manage the meetings within this new context.

  • First Meeting Minutes following this approach are the ones of this 3rd April Meeting. Some indication will be done within WG repository meeting minutes `README.md` file to point to this site. AI#1

  • @Pedro Díez García will contact Evan Harrison from LF in order to generate Meeting Link in Zoom. AI#2

Refund Track - Initial Proprosal Review

• Before presenting baseline proposal, brief summary of the requirements context (TEF Business Requirements) is commented, as previous meeting only @Ludovic Robert was able to attend.

  • @Ludovic Robert also clarifies, after checking internally with business, that refund amount cannot exceed payment amount due to legal/fiscal reasons. @Ajit Raghavan shares the same view on that based on their experience.

• Baseline Proposal:

  • New API

    • Resource Model based on having paymentId in the path: /payment/{paymentId}/refunds

      • Explained the proposal based on POST (refund creation) and GET (list of refunds), as it is the minimum needed to detail the model. Baseline proposal attached within Issue#104

        •  Pending to detail:

          • Endpoint to query details of a refund

          • Notification metadata model

          • Excepctions Management

      • Refund creation

        • Request model based on Payment API.

          • amountTransaction

            • paymentAmount to be renamed as refundAmount.

            • chargingMetaData not observed as needed in principle.

            • paymentDetails to be renamed as refundDetails.

          • type

            • Discussion around this concept. @Ludovic Robert indicates probably when the refund is total there is no need to indicate the refundAmount by the merchant. In partial refund yes, it is needed. @Pedro Díez García also has doubts regarding this and will check with business. With regards to partial refund, there is the comment about how to manage the taxes. OPEN

        • Response model

          • Based on request model along with status of the procedure. Regarding status, so far are identified `processing`, `denied`, `succeeded`. Some discussion around `failed` status, but not considered so far.

          • In the same fashion as payment model, refundCreationDate and refundDate are defined.

      • List Of Refunds

        • Request Model

          • It is commented about the `access` scope of the refund procedure, indicating that the merchant (App - oAuth client) that performed the payment is the unique one allowed to perform the refund and consequently to query for refund(s) details. This statement is agreed by the WG.

          • Open discussion about how to deal in a 3-legged model, that is in the case the authorization is related to a user phone_number to which the payment was not involved. OPEN

          • Regarding filter criteria:

            • Basically same initial approach as in payment is proposed, with the difference of not considering merchantIdentifier (the payment is univocaly associated to a given merchant and the resource is modelled on a paymentId basis). WG seems reasonable this consideartion from the beginning.

            • @Ludovic Robert initiates a thread for further investment/discussion regarding the consideration of service as input for filter criteria OPEN

        • Response Model

          • Same as refund creation

          • Added the concept of remainingBalance, understood in the way of remainingAmount of a given payment not refunded. @Ludovic Robert comments the term can be ambigous and proposes to rename it to `remainingAmount` or other better wording. To be considered for the proposal

            • Both @Ludovic Robert and @Ajit Raghavan prefers to model this information in a separate endpoint or even within payment model, as it is more consistent than having that object N times, each per potential refund associated to a given payment and harder to understood and interpret by an API cnsumer. Taking note of these comments by @Pedro Díez García as it is needed to be reviewed.

• Next actions are:

  • Consider initial comments in the proposal @Pedro Díez García 

  • Think about open questions @All

  • Elaborate more detailed proposal to generate initial PR @Pedro Díez García AI#3

AoB

• @K Barath (Ericsson) joins the meeting for the fist time. It will also support @Ajit Raghavan due to meetings collision

• Next Meeting will be held on 17th April

Action items