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)
Date
Status: AGENDA
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
- Meeting minutes moved to CAMARA Wiki Confluence site.
- Pedro Díez García have contected Evan Harrison from LF in order to generate Meeting Link in Zoom. Pending
Consolidated Work
- PR#151 MERGED - meeting_minutes_readme_information - https://github.com/camaraproject/CarrierBillingCheckOut/pull/151
Refund Track - Proprosal Review
- Proposal:
- PR triggered - PR#152 - https://github.com/camaraproject/CarrierBillingCheckOut/pull/152
- 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.
- Discussion during the meeting:
- From 3rd April meeting:
- Refund creation
- Request model based on Payment API.
- 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
- type
- 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
- Regarding filter criteria:
- Request Model
- Request model based on Payment API.
- Refund creation
- 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.
- 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 specificrefundStatus
. - 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
istotal
this could be source of unnecessary error (what about a request withtype: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?
- Are we sure to manage
- During meeting:
- Refund `type` concept
- From 3rd April meeting:
- Next actions are:
AoB
- Next Meeting will be held on 2nd May