Attendees & Representation
...
- 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.
Status title OPEN
- 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.
- 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
Status title OPEN
- Ludovic Robert initiates a thread for further investment/discussion regarding the consideration of service as input for filter criteria
- 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:
- Tracking to be done under Pull Request
- Exceptions and notifications models added to the proposal
- Refund `type` 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 and its pending Business feedback from TEF. 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).Status title OPEN
- Get list of payments.
So far it is fine to not consider `service` as filter criteria.Status colour Green title CLOSED
- Controlling Time for refund execution:
- Comment raised by Barath (Ericsson), asking whether it has to be controlled by the API the period alloewd by business to be able to allow refund. Orange and Telefonica comments that is Business Logic from Telco Operator according to their business workflow.
- Orange comments discussion:
Are we sure to manageStatus colour Yellow title ONGOING 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
.- The use of statuses related to the refund within the payment status concept can create confussion and misunderstanding. It is agreed to be renamed to "refundStatus" an also align this in carrier billing payment resource. Agreed by de WG. To be renamed
- Also it is seen more suitable to move the "status" of the resource to the higher level of the resource, along with resource Identifier, because now it is part of "amount" model. Agreed by the WG. To be changed
- Also need to cover the scenario where having several refunds in place.
Are we sure that refundAmount should be mandatory ? ifStatus title OPEN type
istotal
this could be source of unnecessary error (what about a request withtype:total
and amount inconsistent btw the payment and the refund?).- Commented by Pedro that still pending feedback from business. Expected to have by the end of April
- Ludovic highlights that solution would tend to be simple and decoupled from business and alignment is needed. Pedro will check internally. It could be easier in that way to manage as an oneOf option.
If requester fill refundDetails do we need to make check vs payment item? I guess yes.Status colour Yellow title ONGOING - 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 will think about it and also discuss with Jose.
- createRefund
In payment we require aStatus colour Green title CLOSED referenceCode
in the request - do we need one here for the refund?- Checked online during the meetings and it is ok
Commented `merchantIdentifier` as filter criteria for get a list of refundsStatus title OPEN - Commented 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
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?Status title OPEN - Pedro comments it is not a technical consideration but a strategical one, in order to not have a big API with the aim of have full APIs implemented as well as to provide flexibility for Telco Operators to their roadmaps delivery of features.
- Tracking to be done under Pull Request
- From 3rd April meeting:
- Next actions are:
- Make clear changes in the PR
- Every to think about pending points
...
- Abdel Elmoumen from Orange joins first time WG
- Ludovic comments about two points:
- He has provided some feedback within Issue#139 - https://github.com/camaraproject/CarrierBillingCheckOut/issues/139
- Need to discuss within WG about metarelease scope within the WG. Specific point for the next meeting. Commenting in advance we should have a clear view before mid June as workload in summer generally decrease.
- Next Meeting will be held on 7th May
Action items
- Pedro Díez García Adapt in PR#152 clear changes AI#1:
- AI#2: @all think about pending points
- AI#3: Pedro Díez García Get feedback from Business
- AI#4: Pedro Díez García Think about considerations regarding Errors
...