SIM/DPM and relay reponse failure handling

[nikolayv]

Hi all,

I've been reading the forums for a while, but i have not figured out yet a proper solution for the following issue:

1. Let's assume i am using either DPM or SIM for my merchant server

2. A user either gets redirected to auth.net hosted payment form for SIM or fills out the payment form on merchant server for DPM, posts the form

3. Authorize.net captures the transaction and attempts to send a response to the specified relay url on the merchant server

4. This is where the issue appears - lets imagine that for a moment the merchant server becomes unavailable for whatever reason (lets say the server has 99.99% uptime, with 10000 orders per day the probability of a single response failure is quite high). The problem is that whatever happens to the response (merchant server returns a 500 or 503 error or a  connection timeout), authorize.net still captures the transaction and displays a fairly uninformative message to the user ('An error occurred while trying to report this transaction to the merchant. An e-mail has been sent to the merchant informing them of the error. The following is the result of the attempt to charge your credit card.

      This transaction has been approved.

It is advisable for you to contact the merchant to verify that you will receive the product or service.') They do not even show the transaction id which the user could send to the customer support so they could handle the refund/complete the order correctly!!!

I still can not understand why does the transaction have to be captured prior to checking that the merchant server actually handled the responjse correctly. What is worse, the merchant application has no means of figuring out what happened to the transaction if it never receives the response.

There is the transaction details api which i could potentially query for the list of unsettled transactions and then compare it to what the server received; there is the silent post url feature which can be used to set up a backup server with the sole purpose of marking affected orders as valid for further processing by the merchant. However, i feel that both solutions are quite wrong, complicated and unnecessary, and we are missing something obvious here.

Help anyone?

Thanks,

Nikolay

[TJPride]

The reason the status has to be determined before the relay response is that the status (success or fail) determines which URL the customer is sent to, and I'm afraid there is no merchant system anywhere that can (a) collect the credit card data off-site and (b) guarantee 100% connectivity to your site (especially if your site doesn't necessarily have 100% up-time). About all you can do is create a redundant system using relay response and/or silent post and/or the Transaction Details API (if it were me implementing SIM, I'd use relay response + Transaction Details). Short of that, take the PCI hit and go AIM, which will give you a more direct and therefore slightly more reliable response.

[nikolayv]

Thanks for the reply.

I would reasonably expect the payment gateway to authorize the transaction first and capture it only upon receiving a successful reply to the relay response message (i.e. a two-phase commit).

I also asked the forums earlier about using the auth_only transaction type for SIM/DPM, and then using AIM to post the prior_auth_capture request using transaction id; someone replied that it is indeed a valid combination; however, test environment always returns 0 as transaction id, so the proposed method is impossible to test, thus making it unviable to even consider a POC implementation. 

It is surprising how many different means there are that can ensure proper interaction, but each one falls short due to some limitation in authorize.net apis or implementations

[nikolayv]

Another confusing thing is that i just discovered that the transaction details API does not return any information for test transactions either. Is it really so? In this case, it would be just amazing. How is this functionality supposed to be implemented in any decent-sized application if there is no way to test it?

[stymiee · Accepted solution]

You should be using a developer account to fully test an application. Then you can run transactions normally and use the APIs normally as if the application was live without incurring any fees.

[nikolayv]

Thanks, the last answer was actually very helpful - i never realized that setting x_test_request to FALSE and test mode to false in the web interface for the developer account pointing to test.authorize.net actually makes a difference to the way transactions are registered

[TJPride]

Using SIM for authorization and then AIM for capture sounds like a good workaround. Of course, there's still the problem of getting the transaction ID to your site, since if the relay response page fails, Authorize.net won't know where to send the customer, therefore nothing will get updated unless a silent post page triggers or you catch it via the Transaction Details API. The customer may not get charged, however that money will still sit there reserved until it gets picked up later, so they don't really gain anything overall except the appearance of not being charged immediately.

Unless I'm missing some elegant solution here?

[nikolayv]

AIM for capture could be potentially used to simply ignore the failed transactions (since there are very few of them), since the funds get unblocked after a 30 day (or similar) timeout. Not en elegant solution, i agree.

To continue the discussion, i'm wondering how to use the transaction API to handle such cases properly. The biggest issue here is that there is no option to retrieve transaction details using invoice number (which is generated on merchant server and i know it even if the response is lost). 

The only way to proceed here is to request the list of unsettled transactions and compare the invoice numbers on those to those we have in the database. I'm unsure how much strain would it bring to the system - assuming the list will always contain full 1000 entries on the live system; and at the same time i need to do the query often enough to ensure the missing transaction does not disappear from the last 1000 and the order is processed fast enough so the user has no time to get worried about the false charge.

Is there any hope that the API would be extended with an ability to query transaction details by invoice number in the near future? This would be a perfect solution to the issue described above.

[TJPride]

You'd have to do hundreds of thousands of transactions to seriously inconvenience either your server or Authorize.net, I would guess. Even if you run them from forks or threads and do 10 or more at a time. Here's one thing you could do, however - if a transaction status has already been checked, just update your database to reflect that fact. So next time you load the 1,000, you can skip all the ones you already checked (if I'm understanding what you're saying) and only individually call the new ones. This will result in one call for every new transaction, which should be small enough for any hosting to handle comfortably.