03-14-2013 02:19 PM
Our company uses one of the simpler Authorize.net integration methods. As we start seeing more credit card transactions, I am noticing that when a user enters the wrong zipcode, we get a response from Authorize.net that just says "credit card declined", while when I log into the Authorize.net portal, I see an instant message for that transaction that says "declined because a different zipcode was entered than the one on file with the bank for this credit card". Obviously, I want to surface this information to the user, so they can correct the zipcode and process the transaction.
I called Authorize.net customer support and the rep recommended the AIM method. However, before I decide whether or not to spend the dev time and effort to migrate us from one end of the spectrum to the other (and buy SSL certificates, etc), I want to ask the following question:
Is there a method that's less involved than AIM to obtain the following functionalities:
1. Instant callback with information on why the card was declined (if it's "zipcode" or other user error, we'll handle the display of a user message and prompt them to re-enter the wrong information, if it's "declined by bank", we'll display appropriate messaging. I'm not relying on Authorize.net for the messaging, we can handle that, I just want the server ping with the info).
2. Recurring billing with no end date (for some reason our recurring billing terminates after 12 months)
3. Being able to do micro-transactions of different or same amounts out of a credit card on file, so that the user is not prompted to re-enter their full billing info everytime they decide to do a microtransaction.
4. Being able to flag whether or not someone is trying to enter a card that is tied to an existing recurring subscription (we'll handle messaging, I only care about this flag).
Can you guys let me know if any of the above functionalities are avaiable by using any of the less-involved methods than AIM, and if so, which method provides the best options.