Carrier Billing Refund API Queries

[ajmhussain]

Dear @PedroDiez

We are assessing Carrier Billing Refund API V0.1.1 which we are planning to pick now for certification. But team has following queries which require your response:

1. Currently, as per our business needs, we support full refunds but do not support partial refunds. If we don’t implement partial refund, will there be any issues during certification?

2. Since we do not support partial refunds, the following API operation appears unnecessary:
   "Get the remaining amount not refunded for a given payment"
   Can you confirm if this operation can be safely ignored and still, we may get certified?

3. In the "Get a list of refunds" operation, why ‘paymentId’ required as a path parameter? Given the availability of query parameters such as refundCreationDate.gte, refundCreationDate.lte, ,merchantIdentifier, it seems redundant. Could you clarify its necessity?

Waiting for your response and appreciate your promptness.

Regards
Ajmal Hussain
Etisalat AE

[PedroDiez]

Dear @ajmhussain,

Please see below my feedback:

1. Currently, as per our business needs, we support full refunds but do not support partial refunds. If we don’t implement partial refund, will there be any issues during certification?

It is not a problem, in case your business does not initially require partial refunds or your current integration agreements do not require it. It is a feature covered in the API to be used by Telco Operator when it needs it, based on their business requirements. So, in summary, it should not be an issue, with the explanation that it is not a scenario required in a Telco Operator in a given country/market so far.

2. Since we do not support partial refunds, the following API operation appears unnecessary:
   "Get the remaining amount not refunded for a given payment"
   Can you confirm if this operation can be safely ignored and still, we may get certified?

Here, I will provide two views:

• Technical one:
  From the technical perspective, even in the case a Telco operator only supports "total" refunds, the endpoint can be implemented and is coherent. it can be observed in the description:

Case_3: Payment of 80 EUR, with 1 total succeeded Refund
  - remainingAmount: 0 EUR

Case_4: Payment of 80 EUR, with 1 total processing Refund
  - remainingAmount: 0 EUR (API cannot return 80 EUR, because there is an ongoing refund process)
     
     SubCase_A: Total Refund is succeeded
     - remainingAmount: 0 EUR

     SubCase_B: Total Refund is denied
     - remainingAmount: 80 EUR

So from technical point of view, my consideration is that it can apply as well.

• Business/Pragmatic One:
  This is a "facility" feature, in order to provide an easy way to an API client on which current conditions a refund can be made with regards to a payment. It might be skipped in case the business operation/agreements manages on other way (e.g. agree with partner integration querying refund details, so partner can check current refund status and behave coherently).

Maybe is a point to check with GSMA in terms of certification.
From business view, my view would be that not implementing it from the beginning should not be a certification blocker, just a warning that the facility is not supported.
In terms of business i think it is needed to provide certain flexibility to Telco Operators, specifically with "facility" features like this.
At the end, what is relevant is to have the same features within Operators involved in a given country/market, to ensure partners interoperability with all of them.

3. In the "Get a list of refunds" operation, why ‘paymentId’ required as a path parameter? Given the availability of query parameters such as refundCreationDate.gte, refundCreationDate.lte, ,merchantIdentifier, it seems redundant. Could you clarify its necessity?

This was discussed in the Subproject. The fact of designing refunds related to a given payment is just to drive the "user-driven" business case: Covering refund(s) for a specific payment. So when needed to check refunds, they are associated to a given payment.
Having a feature of listing all refunds managed for a given partner, seems more like a "backoffice" feature than a "user-driven" business case.

Best Regards
Pedro