10-10-2014 03:56 AM
We are using both the CIM and ARB APIs, and handling transaction information via a Silent Post URL.
For ARB transactions, we recieve both the [x_subscription_id] and [x_subscription_paynum] in the Silent Post data, thus identifying the transaction as an ARB payment.
However for CIM transactions there is no identifiable data in the Silent Post that allows us to determine that the transaction is a CIM payment (versus a SIM or AIM payment, or one via the virtual terminal), and from which CIM customer.
According to John Conde's All About Authorize.Net’s Silent Post article (which was very useful - thanks John), he states:
"[Silent Post] reports the same information as an AIM transaction response but also includes the subscription ID and subscription transaction number for ARB subscriptions and CIM Profile ID for CIM transactions"
and goes on to show a [x_cim_profile_id] field in his example.
However we have never seen a [x_cim_profile_id] field in any Silent Post data we have received.
Is this just John's wishful thinking perhaps, or is it a basic piece of data that Authorize.Net have neglected to supply? Maybe there's a good security reason for not sending the customer profile id or the payment profile.
We are using our own customer reference, and recieve this via the [x_cust_id] field, so we do have the facility to cross-reference it, however it does seem like a shortcoming of Silent Post and the various payment APIs.
@John: would be especially grateful for your comments on this.
10-10-2014 04:31 AM
I think you do not need to wait for the silent post response for the CIM / SIM / DPM / AIM kind of methods. Here once the transaction logged those will be processed. You should update your DB by looking at the CURL response in case of AIM / CIM and for SIM / DPM looking ate response through relay url.
Yes for ARB you need the silent post response as it happens after a period.
@John please correct me if I am wrong as I am new to Authorize.net integration.
10-13-2014 02:47 AM
Silent Post can facilitate reconciling across different implementation systems, which may not necessarily all have access to a core or common database.
The Authorize.Net merchant tools / virtual terminal are inherently not able to be integrated, so transactions originating via these methods must be reconciled using Silent Post.
This was a question about the presence [x_cim_profile_id] field in John Conde's example, not why or why not to use Silent Post.
Where possible, of course we consume the API reponse, but as Authorize.Net has presented this mechanism, it should include useful data; in the case of CIM, a customer profile ID would be useful.
10-30-2014 02:21 AM
Apologies for the duplicate message, but now that mentions are working...
Any thoughts on the "x_cim_profile_id" field in your article?