Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Attendees & Representation

Type @ and your name to indicate your attendance

LF Staff:

Community:





Date


Status: REVIEW_PENDING

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 Díez García 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.
        • OPEN About the design model, pending to be discussed during the meeting
      • 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.
    • List of refunds:
      • OPEN Make double check about the consideration of service as input for filter criteria would be discarded so far.
      • OPEN `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.
    • 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
    • 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.
    • OPEN Refund interface yamI separated or under the same basepath. To manage once PR has a stable status


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

  • Issue: Issue#155
  • Discussion during the meeting:


- Next Actions


AoB

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


Action items

  • AI#1:
  •  
  • No labels