When I am creating the Transaction Recording Policy, I am observing an issue under Refunds section. For Transaction and Custom Attributes, I can see several options for the Resources as shown below:
However, the Resources drop down menu does not have all the options in the Refunds section:
As you can see above, the following resource options are missing in Refunds section
/charges** /refunds/** /charges/**
Can you please explain why are we missing some of the resources in Refunds section ?
Solved! Go to Solution.
To expand on what Charles said, the UI imposes some rules to simplify entry, but are not strictly required.
Before diving in, this additional complexity only applies to Refunds, which requires Revenue Shares with Net and/or Gross prices, which most Rate Plans don't use.
First consider the values that have to be recorded or captured:
So for a purchase-and-refund API, you'd need two sets of calls that have a Status, Price, and Transaction ID:
The specifications for where to capture into which values are grouped by resource. Each call is matched by resource, and for that matching resource (if any), the captures (if any) are applied.
Here's the key point: if a Parent Transaction ID is captured, the transaction is considered a Refund.
While you could theoretically have any mix of resources and captures, the UI tries to divide them into just one Refund resource and everything else. If you use the API to set the Transaction Recording Policy, you can have multiple resources that are Refunds.
The UI also considers any resource that captures a Custom Attribute to be ineligible as a Refund. This is not strictly required either. Custom attributes have two main uses: (1) a multiplier for variable rate charges; (2) a "tag" for a transaction to be used for grouping in reports. A multiplier would not make sense for a refund, but a tag would. If you use the API, you can create Refunds that have custom attributes.
For refunds, only resources that are not otherwise selected are shown as available. Since you have /charges**, /refunds/**, and /charges/** selected, they are not presented.
That's the UI logic, although I don't remember the details of why it was implemented that way. I suppose it's because it doesn't make sense to have the same resource be both a refund and a transaction.
Thanks for your answer. I understand now why all the resources are not shown up for Refunds.
To expand on what Charles said, the UI imposes some rules to simplify entry, but are not strictly required.
Before diving in, this additional complexity only applies to Refunds, which requires Revenue Shares with Net and/or Gross prices, which most Rate Plans don't use.
First consider the values that have to be recorded or captured:
So for a purchase-and-refund API, you'd need two sets of calls that have a Status, Price, and Transaction ID:
The specifications for where to capture into which values are grouped by resource. Each call is matched by resource, and for that matching resource (if any), the captures (if any) are applied.
Here's the key point: if a Parent Transaction ID is captured, the transaction is considered a Refund.
While you could theoretically have any mix of resources and captures, the UI tries to divide them into just one Refund resource and everything else. If you use the API to set the Transaction Recording Policy, you can have multiple resources that are Refunds.
The UI also considers any resource that captures a Custom Attribute to be ineligible as a Refund. This is not strictly required either. Custom attributes have two main uses: (1) a multiplier for variable rate charges; (2) a "tag" for a transaction to be used for grouping in reports. A multiplier would not make sense for a refund, but a tag would. If you use the API, you can create Refunds that have custom attributes.
User | Count |
---|---|
7 | |
2 | |
2 | |
2 | |
1 |