Hi,
It it possible to automate the auth_only - prior_auth_capture transaction submission method using SIM?
Here is what i am thinking about:
1. the merchant server submits the payment info to the hosted form with auth_only transaction type specified
2. the user enters credit card data on the authorize.net server
3. authorize.net hits the merchant relay response url, shows the relay response page in user browser, at the same time, order is saved in the merchant server database
4. the relay response page does a client-side redirect to the order confirmation page on merchant server
5. Once the user sees the confirmation page, the merchant server sends another request to authorize.net to capture the transaction
You see, the point #5 is needed for the cases when either authorize.net fails to hit the relay response page (f.e. network issues/timeout), or there is any kind of error when processing the order on the merchant server
the current set up for us is essentially the same, but with auth_capture, so in very rare cases the issues described above cause customers to be charged, while the order is not registered on the merchant server
is it possible to use AIM to post the prior_auth_capture request? I'm unsure since the documentation for AIM states credit card number is always required, and obviously the merchant server does not/should not have it when using SIM
Thanks,
Nikolay
Solved! Go to Solution.
09-05-2011 10:12 AM
Just to confirm, it is a fairly common practice to run an auth_only transaction with SIM and prior_auth_capture with AIM. SIM does not have native prior_auth_capture functionality because there is no way that a hosted payment form would be involved when you are performing the capture.
09-08-2011 12:21 PM
There's an AIM method called priorAuthCapture that just requires transaction ID and amount. Maybe that would work? Or you could set up a callback page and have it actually do the updates in your database - that way you don't have to rely on the customer hitting your site again for the order the register.
09-05-2011 11:22 AM - edited 09-05-2011 11:23 AM
Yes, i should try that aim method today, was just hoping for a support response if the proposed algorithm is actually a valid practice.
As for the relay response page doing the database update, it still does not solve the issue:
1) If an error happens while submitting the database update the customer will still get charged
2) The development guidelines for SIM advise against doing any database interaction on relay response page as it could cause timeouts (and the live timeout policy is very strict, the manual says 10 seconds but it is actually even more demanding sometimes, probably it takes network data exchange time into account)
09-06-2011 02:33 AM
1) Even if the charging is on the exact same page as the database interaction, you can't guarantee 100% that the database will be updated after the charge, if you assume for the sake of argument an unreliable database. The only alternative is to update the database first, process the charge, and then undo the update if the charge doesn't go through, but that seems a rather messy and convoluted way to go about it.
2) I really don't care. If your database takes more than a fraction of a second, then you need a new database. On the other hand, I suppose you could wrap the database call in something that times it out if it isn't done in a few seconds, then log the okayed transaction ID's to a text file and have an automated process run every few minutes that loads the transaction ID's and okays them in the database. This way if your database is down temporarily, you don't lose the updates.
In terms of elegance, I would personally prefer something wired into the callback. There are many reasons why the customer might not get to your relay response page, and the more steps you make them go through to order, the more orders you're going to lose.
09-06-2011 06:57 AM
Just to confirm, it is a fairly common practice to run an auth_only transaction with SIM and prior_auth_capture with AIM. SIM does not have native prior_auth_capture functionality because there is no way that a hosted payment form would be involved when you are performing the capture.
09-08-2011 12:21 PM
pls try the following URL.. Hope this would be helpful
- Arun
Like my post?
10-03-2011 10:51 AM