Some of the options are not listed in the Resources drop down menu under Refunds section of Transaction Recording Policy

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:

1427-transactionattributes.png

1426-customattributes.png

However, the Resources drop down menu does not have all the options in the Refunds section:

1428-refunds.png

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 Solved
0 3 392
1 ACCEPTED SOLUTION

Not applicable

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:

  • Starting at the beginning, every transaction of any type must capture a Status, which is then available as txProviderStatus in the Transaction Success Criteria expression.
  • For Revenue Share plans, you must also capture either the Net or Gross Price, whichever is defined in the Rate Plan. These kinds of transactions are called a Purchase.
  • In order to post a Refund against a previous transaction, you must be able to identify that Purchase: that's in the Link Resources with Unique Transaction ID section.
  • For the Refund transaction, the Parent Transaction ID is required; the Parent is that Purchase.

So for a purchase-and-refund API, you'd need two sets of calls that have a Status, Price, and Transaction ID:

  • For the Purchase, it's:
    • Some value to check to determine whether the purchase should continue to be processed. If so, then there also has to be....
    • The amount of the purchase.
    • The ID of this purchase.
  • For the Refund, it's:
    • Some value to check to determine whether the refund should continue to be processed. If so, then there also has to be....
    • The amount of the refund. You can refund all or part of the purchase. You may make multiple refunds that total up to the original purchase amount. It has to match the category of the purchase, net or gross.
    • The ID of that purchase.

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.

View solution in original post

3 REPLIES 3

Not applicable

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.

@coverbeck,

Thanks for your answer. I understand now why all the resources are not shown up for Refunds.

Not applicable

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:

  • Starting at the beginning, every transaction of any type must capture a Status, which is then available as txProviderStatus in the Transaction Success Criteria expression.
  • For Revenue Share plans, you must also capture either the Net or Gross Price, whichever is defined in the Rate Plan. These kinds of transactions are called a Purchase.
  • In order to post a Refund against a previous transaction, you must be able to identify that Purchase: that's in the Link Resources with Unique Transaction ID section.
  • For the Refund transaction, the Parent Transaction ID is required; the Parent is that Purchase.

So for a purchase-and-refund API, you'd need two sets of calls that have a Status, Price, and Transaction ID:

  • For the Purchase, it's:
    • Some value to check to determine whether the purchase should continue to be processed. If so, then there also has to be....
    • The amount of the purchase.
    • The ID of this purchase.
  • For the Refund, it's:
    • Some value to check to determine whether the refund should continue to be processed. If so, then there also has to be....
    • The amount of the refund. You can refund all or part of the purchase. You may make multiple refunds that total up to the original purchase amount. It has to match the category of the purchase, net or gross.
    • The ID of that purchase.

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.