Gilbert, I would certainly use the same method of communication. When
a user checks out the shopping card the ecommerce module would contact
authorize.net using the ADC (Authorize Direct Communication) for
authorization. At this point the ecommerce module only has a unique
order ID. If the authorization is succesfull the ecommerce module
receives back the unique transaction code that Authorize.net uses to
refer to the transaction. From this point on there is a common unique
identifier for the transaction.
As always it becomes more complicated when things don't go the way
they should. Suppose the connection between the ecommerce site and
authorize.net breaks before the ecommerce module could record the
transaction code. Or a roling black-out hits our server before the
transaction code has been stored in our database. Or we didn't know
that the connection to the gateway is temporarily broken and we end up
summiting the authorazation request into cyberspace. At that point we
don't know if Authorize.net authorized the transaction or not.
If we assume it didn't and try again later where in fact it had
authorized the transaction only the ecommerce module didn't know that,
we would introduce a new transaction. We have now introduced an orphan
on the authorize.net gateway. One would see this transaction in the
virtual terminal and could void it there. The virtual terminal is a
secure web site of Authorize.net where one can enter and administer
manual credit card transactions. Transactions entered through the ADC
are accessible through the virtual terminal too.
If the virtual terminal of Authorize.net does show the transaction
code for transactions authorized through the ADC one could flag the
aforementioned transaction in the ecommerce module. Lookup the
transaction code in the virtual terminal and enter the code in the
ecommerce module through an admin page. The transaction can then be
completed as usual.
Not all gateways have virtual terminals that show the transaction
code. Intellipay for example doesn't and there is thus no otherway
than to create orphans.
The above scenario is an example of why the
ability to query and to refer to an transaction by a merchant
generated ID is so important.
One could reduce the risk of sending requests for authorazation into
cyberspace by first checking if the authorize.net gateway is
available. The request is only submitted if the service is available
immediately prior to the request it self.
If all submissions to the gateway are logged it is easy to avoid the
introduction of orphans on the gateway site.
Once a transaction code has been optained there is no real need to
query the authorize.net gateway. That is, from the response to
PRIOR_AUTH_CAPTURE and VOID one can infer the state of the transaction.
Most of these thoughts need to tested more.
