Meta Apis (Recommendation?)

[venkatramanm]

Meta apis like /get_cancellation_reasons and /get_return_reasons , Can this be different by different bpps?

If these are generally expected to be standardized by network facilitators (as in ONDC) , these apis may be removed from the specifications.

My preference is to leave at BPP Level and have bpps implement the same list as prescribed by the Network facilitators. @pramodkvarma @ravi-prakash-v

This way, the baps can always show from the BPP response. But users will have consistent experience within the network.
If Baps do it off a static list to avoid network calls, then this api will become redundant. We need to decide the fate/recommendations for usage of these apis.

[venkatramanm]

In /cancel , we are expecting this cancellation_reason_id but we don't have any api where we accept return_reason_id.

• I think in core specs, we don't need a concept of return reason as it is a retail specific notion.
• We can just have cancellation_reason
• In Retail adaptation, Once could use some of the cancel reasons to be usable pre-delivery and some post-delivery thereby implying return reason or cancellation reason.