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)