Attendees & Representation

Type @ and your name to indicate your attendance

LF Staff:

Community:

Pedro Diez Garcia (Telefonica)
Ludovic Robert (Orange)
Rafał Artych (Deutsche Telekom)


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
  • Review of Issues
  • AoB

Minutes

Management of new meetings

  • Pedro Diez Garcia PENDING to ping again Evan Harrison from LF in order to generate Meeting Link in Zoom.


Consolidated Work

  • N/A


Issues Review

- Refund Track Review

  • Issue: Issue#104
  • Pull Request: PR#152
  • Current Status:
    • Summarized in Issue#104
    • type of refund
      • Total refund: Agreed so far that total refund consider all payment amount, so amount is not required to be indicated.
        • Ersilia from Fodafone also comments/confrims that total refunds consider all payment amount 
        • OPEN Regarding design model, one approach would be to take at root level clientCorrelator an referenceCode to generate a common baseline object and model the refund type as an extension of that model. Ludovic Robert comments doing that would have the drawback to adapt the model in Payment as well and therefore the impact would be greater. The point is kept open for everyone to think about that.
      • Partial refund:
        • Management of taxes: 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).
          • Initial view on this point: For a given process payment and refund should follow the same model (as this process will be for the same merchant/aggregator). So isTaxIncluded would have to be the same value, otherwise generate an exception.
          • Pedro Diez Garcia comments this initial view, just to have coherent behavioir between a given payment and related refund(s). Ludovic Robert indicates that makes sense and a exception has to be defined. Rafał Artych will check internally in the meantime. Pedro Diez Garcia will draft a proposal within Error Model Issue.
    • List of refunds:
      • CLOSED Make double check about the consideration of service as input for filter criteria would be discarded so far. Ludovic Robert comments we can move forward without considering this point. It is agreed to not consider so far and maybe a point for the future.
      • ONGOING `merchantIdentifier` as filter criteria for get a list of refunds. Initial Consideration: 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. Ludovic Robert indicates Orange has many integrations with aggregators to deal with this refund flow so it probably makes sense to consider. Action Point is to think about how to include the merchantIdentifier in refund response model
    • status:
      • Aligned status names (paymentStatus and refundStatus), also covering the query params. This information is placed at root level of the resource. DONE in PR#152
    • Issue#153 - Management of non-negative amount and taxAmount. DONE in PR#152
  • Points not covered so far:
    • OPEN Remaining Payment Amount not refunded. Pending to be managed by Pedro Diez Garcia 
    • OPEN Issue#154 - Align error model with commonalities one and also provide a rationale about how exceptions would apply to Carrier Billing
      • Initial proposal pending from TEF in Issue 154 - Dealing with the suitable status for the exceptions, to progress in the meantime while commonalities track is consolidated
      • To also consider 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 Diez Garcia indicates the intention is to manage in two steps: First Step is to compile current exceptions and provide reason to keep or change current status. Second step would be aligned with the purpose of Commonalities Issue#196. Both Rafał Artych and Ludovic Robert have concerns about if we have in CAMARA enough time to cover this within Meta-Release Fall24. Commented by Pedro that the issue is open for comments. Also conversation about Issue#127 is held to manage the pending PR. Pedro will talk to Jose about that.
    • OPEN Refund interface yamI separated or under the same basepath. To manage once PR has a stable status, latest point to address


- Carrier Billing Scope for Meta-release v0.4 (Fall24)

  • Issue: Issue#155
  • Discussion during the meeting:
    • Pedro Diez Garcia basically shares TEF view. Priority is refund and aligment with Commonalities Metarelease Fall24. If other topics to be adressed, it is fine but not having bandwith to lead it.
    • Ludovic Robert sees reasonable the scope even he will check offline and comments the need to cover with a first set of testing. Shares with Rafal the point to have a minimum set of testing for each API
    • Rafal Artych will check internally offline and in the meantime also comments about the point to manage with testing point


- Next Actions

  • To continue the work around Refund proposal
  • Make proposal for STEP 1 Error Model
  • Generate Issue for testing track


AoB

  • Next Meeting will be held on 29th May (16:00 - 17:00)


Action items