topic Re: RefID - Merchant-assigned reference ID for the request. in Integration and Testing

RefID - Merchant-assigned reference ID for the request.

Yanping — Wed, 14 Mar 2018 19:37:09 GMT

Reading through https://developer.authorize.net/api/reference/#transaction-reporting, I am wondering how the "RefID" is used, description "Merchant-assigned reference ID for the request." It is not clear to me. Is it the same as "x_cust_id" in previous API?

What I need is to return transaction associated with a specified invoice_number.

Thanks

Re: RefID - Merchant-assigned reference ID for the request.

mmcguire — Thu, 15 Mar 2018 20:51:46 GMT

RefId is a field where you can send ids from your internal system for your reference. Note: It is not stored with the transaction information, unlike other fields such as customer id or invoice.

If you use createTransaction you can send an invoice number in the order section.

example:

<order>
<invoiceNumber>INV-12345</invoiceNumber>
<description>Product Description</description>
</order>

Re: RefID - Merchant-assigned reference ID for the request.

Lilith — Thu, 15 Mar 2018 21:17:31 GMT

@Yanping -- adding on to @mmcguire's response above, if you look at the Response tab for getTransactionDetails, you'll see that we return invoiceNumber in the order element of the response. As long as the invoice number was passed to us in the original transaction request, it should appear in this call's response.

Re: RefID - Merchant-assigned reference ID for the request.

Yanping — Fri, 16 Mar 2018 13:17:27 GMT

Thanks. invoiceNumber is the field to go

Re: RefID - Merchant-assigned reference ID for the request.

Yanping — Fri, 16 Mar 2018 13:19:39 GMT

Just to be sure, does AIM support RefID?

Re: RefID - Merchant-assigned reference ID for the request.

Lilith — Thu, 22 Mar 2018 17:10:16 GMT

@Yanping I want to make sure we're talking about the same thing, because many developers use "AIM" to mean more than one thing.

We typically used "AIM" to refer to a direct connection that exchanged transaction requests and responses as name-value pairs. And while we still offer support for AIM, we've de-emphasized it in favor of the Authorize.Net API.

AIM doesn't support a dedicated reference ID field, but it does support merchant-defined fields. Any field you send us that isn't part of our specification, and which doesn't contain sensitive details like card numbers, will be echoed back in the response.

That said, I only recommend going that route for a legacy application. For new applications, I strongly urge you to use the Authorize.Net API and its dedicated refId field.

Does that help?