Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create MOM-2024-03-20.md #150

Merged
merged 1 commit into from
Mar 27, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
34 changes: 34 additions & 0 deletions documentation/MeetingMinutes/MOM-2024-03-20.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,34 @@
# Meeting Minutes
## Meeting Information
**Meeting Date:** 20-March-2024<br/>
**Status:** FINAL

## Attendees

- Ludovic Robert (Orange)
- Pedro Díez (Telefonica)


## Goals
Review of Issues/PRs and next steps</br>


Item | Who | Description
---- | ---- | ----
WG Status | WG | Highlights of WG status
[Issue#148](https://github.com/camaraproject/CarrierBillingCheckOut/issues/148) | WG | Apply Linter Configuration in Carrier Billing
[Issue#104](https://github.com/camaraproject/CarrierBillingCheckOut/issues/104) | WG | Refund functionality for Payment requests enhancement


### Items Discussion

Item | Discussion
---- | ----
WG Status | • **Linter rules**: Applied in WG.<br> • Begin work about refunds
[Issue#148](https://github.com/camaraproject/CarrierBillingCheckOut/issues/148) | Issue opened to apply Linter rules in Carrier Billing WG repository, set to `CLOSED`. Related [PR#149](https://github.com/camaraproject/CarrierBillingCheckOut/pull/149) approved and `MERGED`.
[Issue#104](https://github.com/camaraproject/CarrierBillingCheckOut/issues/104) | Telefónica comments about the main requirements requested by their business and compiled within the Issue. Also commented during the meeting and include later the requirement of obtaining the balance of a given payment (which amount is not refunded). Some comments and considerations provided by Orange (Ludovic):<br> • From Business perspective flow is delegated in Payment Aggregators with deals with the specific details of a given market and latter request in a homogeneous way to the Operator.<br> • Even some Operators (e.g. Telefonica case) the amount refunded cannot exceed payment amount, we should not impose that as a general rule for any implementation as it may be business cases where for customer inconveniences, the amount refunded could be higher (e.g. to enforce trustability / fidelization from the customer).<br> • With regards to asynchronism, it is asked whether refers to a 2-STEP procedure like payments. It is clarified that not related to a 2-STEP process but to design the solution to work with notifications as refund procedure could take some time before being committed.<br> • Regarding API design, Orange comments about other option to model endpoint(s) in a way refering to the payment involved in the path: `/payments/{paymentId}/refunds`.


### Next Steps
- Next Meetings:<br/>
• Next meeting: 3rd April, 16:00 - 17:00 CET<br/>