Integration and Testing

[erdz1]

We are using Java SDK to leverage Accept Hosted integration method (without IFrames)

That means, user is presented with a separate (not embedded) AuthorizeNEt payment web page, and when payment is successfull, Authorize.NET will redirect users browser, back to our URL with a blob of data we instucted AZ to put into that URL.

So we get the redirection, we get our data blob.

But how do we know the transaction ID  (so that we can store it in our DB for audit/control needs) ?

There was a similar question asked several years ago:

https://community.developer.authorize.net/t5/Integration-and-Testing/Transaction-ID-from-getHostedPa...

but no workable answers were provided, unfortunately.

--- 

For a bit more background:

We use Accept hosted, rather than any 3rd party Java script libraries (like authorize.js)  -- because we are not allowed to load JS script from external sites.  So we essentially warn the user that they will be redirected to Authorize Net payment screen, and that will be outside of our privacy Perimiter

(Authorize.NEt payment hosted page, not only hosts their own JS scripts, but it seems to have scripts from other domains as well )

[Renaissance · Accepted solution]

@erdz1

You use webhooks. This is a routine item for redirect method integrations and webhooks is the answer. FYI I also use webhooks in my iframe based integrations. They work extremely well.

[Renaissance · Accepted solution]

Here is an actual payload from a real webhook, as opposed to what the docs say. Notice there is no merchant refId 

{"notificationId":"f6ffd89e-7e5b-4ff4-b15e-39a68500ce70","eventType":"net.authorize.payment.authorization.created","eventDate":"2019-03-09T15:13:16.7573039Z","webhookId":"9ee234eb-e3b6-4139-b261-0ed4b9c14499","payload":{"responseCode":1,"authCode":"O4XCGB","avsResponse":"Y","authAmount":91.64,"entityName":"transaction","id":"xxxxxxxxxxxxxxx"}}

I pointlessly blotted out the transId. This is a sandbox run. 

[Renaissance · Accepted solution]

@erdz1

You use webhooks. This is a routine item for redirect method integrations and webhooks is the answer. FYI I also use webhooks in my iframe based integrations. They work extremely well.

[erdz1]

@Renaissance  Thank you for the suggestion.

I have looked into this, but I could not find a way to pass merchantReferenceId (or refId )

into AcceptHosted APIs

According to the AZ's webhook docs, it is the merchantReferenceID that allows the link between our internal transaction id, and the subsequently published Authorize NET notification.

What mechanism did you use to pass in that  refID ?

For the background, we use

AZ's Java SDK, and following this sample to create Accept Payment page

Thank you again for the follow up

[erdz1]

I think I found something, but would like to confirm:

(slightly different name): setRefTransId

in java API

// Create the payment transaction request
TransactionRequestType txnRequest = new TransactionRequestType();
txnRequest.setTransactionType(TransactionTypeEnum.AUTH_CAPTURE_TRANSACTION.value());
txnRequest.setAmount(new BigDecimal(amount).setScale(2, RoundingMode.HALF_UP));
txnRequest.setRefTransId("merchantRefId-that-willbe-passed-inwebhooks");

Which, I presume, will correspond to the magical refId in the REST API

"createTransactionRequest": {
        "merchantAuthentication": {
            "name": "5KP3u95bQpv",
            "transactionKey": "346HZ32z3fP4hTG2"
        },
        "refId": "123456",

I did not see this parameter (refId or refTransId) in any of the examples for Get Accept Payment Page

Whic his why I would like to confirm if that's the right mechanims to pass refId into AuthorizeNet (so that it is that ID that will subsequently appear in the Webhook notifications as merchantRefId)

[erdz1]

I think I found something, but would like to confirm:

(slightly different name): setRefTransId

in java API

// Create the payment transaction request
TransactionRequestType txnRequest = new TransactionRequestType();
txnRequest.setTransactionType(TransactionTypeEnum.AUTH_CAPTURE_TRANSACTION.value());
txnRequest.setAmount(new BigDecimal(amount).setScale(2, RoundingMode.HALF_UP));
txnRequest.setRefTransId("merchantRefId-that-willbe-passed-inwebhooks");

Which, I presume, will correspond to the magical refId in the REST API

"createTransactionRequest": {
        "merchantAuthentication": {
            "name": "5KP3u95bQpv",
            "transactionKey": "346HZ32z3fP4hTG2"
        },
        "refId": "123456",

I did not see this parameter (refId or refTransId) in any of the examples for Get Accept Payment Page

Whic his why I would like to confirm if that's the right mechanims to pass refId into AuthorizeNet (so that it is that ID that will subsequently appear in the Webhook notifications as merchantRefId)

[Renaissance]

@erdz1 

I do not think the refId is in webhooks yet. You pass an invoice number in the API call. Then when you receive the webhook, you extract the transId and run a getTransactionDetails method call to retrieve the invoice number. You can tie the invoice number back to your internal records. 

[Renaissance]

@erdz1

If this answers your question could you kindly mark this thread solved? If not let me know where you’re stuck and I’ll get you tomorrow morning at breakfast (or at today’s breakfast if you’re fast enough)

[erdz1]

Thank you for the follow up.

We have not implemented webhooks.  As that requires a chunk of work, where we have to add to our 'client code' of authorize net, a chunk of 'server code' to accept the webhooks replies to fully test if merchantRefId is populated (as per documentation)

I have tested your suggestion that invoice ID that we can submit via Java-SDK API, will get passed into the authorize.net transaction record.

That works.  Thank you for that insight.

I cannot reconsile, however, our experience with Authorize.net documentation in regards to Reference Id.

Their doc states:

"

Although most of the fields in an event notification's payload use standard Authorize.Net API fields, which are documented in our API Reference, three fields are unique to webhook payloads.

The merchantReferenceId field corresponds to the refId field in the Authorize.Net API, and enables you to match webhook notifications with API requests.

In addition, two fields in webhook notifications identify the type of payload and the identification number associated with the webhook event.

"

https://developer.authorize.net/api/reference/features/webhooks.html

However there is no 'refId' method in the Java SDK Api.

The closest one is

txnRequest.setRefTransId

And that does not appear to work at all (because, even without webhooks,  when we go to Sandbox transaction search UI, we cannot find anything by that Id).

Will mark your answer as accepted, but we cannot use it at the moment (because we cannot use invoice id as charge reference id (our invoice id scheme is not unique across all transactions)),

and Authorize.NET sdk capablities (at least Java-SDK)  appears to contradict the documentation about refId field.

To even login in a deffect with Authorize.NET around this, we need to implement webhooks and provide complete end-to-end example (and that's taking some time)

[Renaissance]

@erdz1 

A few things. 1. your conundrum with the merchant ref id is a long going on thing.  They tend not to get around to changing things all that fast. This issue has been a hang up for developers for over a year.   In my case the invoice number solves the problem and it never has caused me any inconvenience.

Second, the way I think about these API properties is how can I make them work, vs how auth.net intends for you to use them. I often disregard the field names and use the property for a totally different purpose. It is thinking along the lines of "I need to pass a 22 character string, which property that I don't already use can I do that with". It usually gets the job done. For you, I would suggest creating a column in your db records called "po_num" or "order_reference" or whatever you want. Generate a unique id for each order and store it in that column. Then pass it in the API call under poNumber. For generating unique Ids, I find that functions that output timestamps in microseconds are useful. If you have a busy enough application that there is a chance of collisions using this, you can append a random letter to front and/or back of the string you create from your timestamp. 

[Renaissance · Accepted solution]

Here is an actual payload from a real webhook, as opposed to what the docs say. Notice there is no merchant refId 

{"notificationId":"f6ffd89e-7e5b-4ff4-b15e-39a68500ce70","eventType":"net.authorize.payment.authorization.created","eventDate":"2019-03-09T15:13:16.7573039Z","webhookId":"9ee234eb-e3b6-4139-b261-0ed4b9c14499","payload":{"responseCode":1,"authCode":"O4XCGB","avsResponse":"Y","authAmount":91.64,"entityName":"transaction","id":"xxxxxxxxxxxxxxx"}}

I pointlessly blotted out the transId. This is a sandbox run. 

[erdz1]

@Renaissance 

Thank you for the example of the webhook notification.

yes, you are right,  it looks like the merchaintRefId mentioned in the AZ's doc is not even present.

-- we will figure out away to use AZ's Invoice ID field, instead.

Thanks again for the help.