Showing results for 
Search instead for 
Did you mean: 

Get Subscription Details from Transaction Refund

I am working on ARB Subscription and all the events relative to my needs are implemented, but i am having trouble in one of the events `net.authorize.payment.refund.created` where i try to get the subscription id against the transaction response when the event is fired and posted to my API endpoint.


I currently use the `GetTransactionDetailsController()` to execute the request like `$controller->executeWithApiReponse(AnetConstants\ANetEnvironment::SANDBOX)` and once response is received i use the following to get the subscription details from the transaction details response


but this gives me error

"Call to a member function getId() on null" which means the `getSubscription()` isnt returning the object, the same code works for the normal transaction or `net.authorize.payment.authcapture.created` and display the subscription id associated with the transaction.


What am i doin wrong here , do i need to use some other route to get the subscription id when the Refund response is received?




What i have currently done is get the referenced Transaction Id by using




and then lokoup into my local databases for the transaction_id in the payment Logs table and backtrack the Subscription id saved against the user.


I would love to adapt the conventional way, other developers are following in order to aacomplish the same task i would be waiting for a reply.

So when you run the refund the response is a transaction response type object. You’re using transaction request type method call when you call getTransaction().

I think you’re using the wrong controller too. I don’t use subscriptions in either of my clients apps, but the way refunds work is your are creating a new transaction and no products are tied to it. So for instance when your customer requests a refund they are not generating a subscription for that transaction. For my apps it is the same with line items passed in the original transaction API call.

So what you can do is pull the refTransId from the refund response and use that to make a transaction details method call for the original transaction. You’d just have them in one big script I think. So it would be refundTransaction($transId, $amount) initially, then you’ll execute next getTransactionDetails($refTransId), with $refTransId being what you retrieved from the refund transaction response object. It would be easy to tie the two together because if the refund response is successful $transId and $refTransId would be equal.
All Star
You replied while I was typing. Had other people texting me. I don’t use subscriptions and currently when I test refunds I have no purpose for retrieving line items. I think what I typed should work for you. Split it into 2 method calls.

How is it that the refunds are received? Meaning how is it that you know the customer has requested a refund and are you making a method call manually to process the refund? It sounds like you’re processing the refunds from the merchant interface and using webhooks. I’m using the actual backend of my clients site in my development.

In that case scrap the refund transaction method call cause that’s what you’re doing with the interface. I would run that refTransId you just posted in a getTransactionDetails call just like in my first post. Then extract the subscription from that response. You would do it your business as usual way as if you were getting it from the original transaction.

I might have not explained it correctly but the $response is not for the refund request the refund request is made via backend admin panel on my site using the API PHP SDK , the request when completes, it fires the webhook net.authorize.payment.refund.created, the webhook is targetting my custom API endpoint where i need to send the notifications, there i get the payload for the event and the Refund Transaction ID i pick that id and send a transaction details request and in response to the request i am trying to get the subscription, i hope i made it more clear what i am trying to do.

I got you now. Your explanation was good. If you’re using a backend, I would go back to my first post. I don’t think you need webhooks. The webhooks are an extra step in the process in your case.

I would have your refund script do the whole thing. So the programming would go like this-

-You do a refund request method call
-is successful, the response on that method call will be a TransactionResponseType object
-you pull the refTransId from that response. I think the property would be

$refTransId =

Double check me on that but should be close.

Then you do a method call getTransactionDetails($refTransId);

Then you pull the property for the subscription from that, as you are currently able to do with the original transaction.

You would want the transaction details method call to be under a conditional to only be executed if the refund response is successful. Otherwise your dB actions will go haywire if it the refund fails.

Someone else may want to chime in here, but as I see it webhooks are usually appropriate when you need events that are not within your control automated. So for instance in my app I get the initial transaction success delivered. I used the Hosted form, so that is completely out of my ability to have any control over or awareness of.

It would make sense if you’re using the merchant interface for refunds to have webhooks. That would save you from double work.

But when you’re doing a straight API call you are in the drivers seat the whole time. You have direct control over what happens if the request is successful and what happens if it fails, and you also have the ability to know instantly.

So instead of having a process of-

-do a refund API call
-have authorize ping my server with the response
-if response is successful execute dB entries, etc.

Simply have a process like this-

-do a refund API call
-get response from the API call itself immediately and if successful execute dB entries, etc.

If you use any of the sample code from the reference and it has those outputs in the browser that look something like this:

“echo transaction result: success. Auth code: 39592”

That “success” message is telling you the exact same thing that the webhook is telling you. So might as well skip the redundant confirmation from the webhook delivery and just execute your actions based on the success or failure of the API call.

Hi @buttflattery


You can call the getTransactionDetails API to get the subscriptionID linked to it .


subscription Contains subscription information.

id The subscription ID.

Numeric string.

payNum Identifies the number of this transaction, in terms of how many transactions have been submitted for this subscription.

For example, the third transaction processed for this subscription will return payNum set to 3.
Numeric string, between 1 and 999.

Send feedback at