Attendees & Representation

Type @ and your name to indicate your attendance

LF Staff:


Pedro Diez Garcia (Telefonica)

Ludovic Robert (Orange)

Rafał Artych (Deustche Telekom)

@Ajit Raghavan (Ericsson)

@K Barath (Ericsson)


Status: FINAL

Final Date for Comments:  


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
  • Refund Track - Initial Proprosal Review
  • AoB


Management of new meetings

  • As per TSC guideline, meetings are being moved to CAMARA Wiki Confluence site. Pedro Diez Garcia 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 `` file to point to this site. AI#1
    • Pedro Diez Garcia 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 Diez Garcia 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 Diez Garcia as it is needed to be reviewed.
  • Next actions are:
    • Consider initial comments in the proposal Pedro Diez Garcia 
    • Think about open questions @All
    • Elaborate more detailed proposal to generate initial PR Pedro Diez Garcia AI#3


  • @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

  • AI#1: Pedro Diez Garcia to generate a PR in Carrier Billing WG in documentation → meeting minutes → README
  • AI#2: Pedro Diez Garcia to contact Evan for Zoom Meetings Link
  • AI#3: Pedro Diez Garcia Generate initial PR with detailed proposal. Expected for the first half of Week-15