Forum OpenACS Development: ecommerce status?
preliminary work to interface with the Authorize.net payment
gateway. I'm going to make the Authorize.net interface a service so
that the ecommerce (or any package) can use it. Please let me know
if you have any suggestions for the interface. Thanks.
am curious about Authorize.net. Do they provide all the same
actions as Cybercash? I created a Tcl library which would
substitute for the Cybercash module to use a service with an
https interface, but abandoned it when I realized that "auth" with
success or failure is not enough. Without the ability to query
status and do returns and voids, too much of the functionality of
the ecommerce module is lost. This particular service allowed
me to get under the hood and talk directly to Cybercash, so that's
what I did.
However, if new Cybercash accounts will not be created we
*must* have an alternative to Verisign-borg, for matters of
principle if nothing else! So the question is, who provides the
most complete API?
I am not familiar with Cybercash's API. Are there specific actions that are required for the ecommerce module? For Authorize.net, you can perform the following:
All of these actions except for Capture-Only are keyed off of a transaction ID (I'm still trying to figure out if the transaction ID is generated by Authorize.net or by the client). The Capture-Only action uses an authorization code from an outside source, not from Authorize.net.
What do you mean by querying the status?
I have some test code which can send to and receive data from the Authorize.net payment gateway. Authorize.net requires you to do a HTTPS POST to send and receive data. So to do this, you need to run TLS and OpenSSL and you can write the code in TCL using the HTTP and TLS modules.
How does your TCL library work? Is it an abstraction layer above the CC API?
Existing CashRegister accounts can continue to use the current API.
The CashRegister API is the only API that I have found that can query
transactions *and* identintifies transactions by merchant issued order
IDs. The latter is very important as it allows the merchant to track
orders from the start. All other services (Authorize.net, Intellipay,
Goemerchant, etc) track transactions by a transaction code issued by
the gateway. The disadvantage is that when -for whatever reason- your
site did not receive a response to the 'Auth' fase, manual
intervention is required. You the merchant did not receive the
transaction code and you can not query the service by your order ID.
I've looked at several credit card gateways and found that:
- Intellipay can *not* void transactions or credit customers who have
been over charged. See the documentation
(http://www.intellipay.com/Docs/ExpertLink.htm) for more details.
- Goemerchant's API documentation (www.goemerchant.com/guide.htm) is
very skimpy and doesn't even describe the transaction types it
accepts. Despite the fact that there is no setup fee, Goemerchant is
a quite expensive gateway in the long run thanks to a monthly base
fee of 39.99.
- Verisign's PayFlow is the most expensive of the bunch at 59.99 a
month yet doesn't offer a significantly better API. Although one can
query PayFlow for transactions, PayFlow too refers to transactions by
an ID issued by Verisign at the time of authorization. As a result
PayFlow suffers from the same short coming as all other gateways.
However, Verisign (who bought the CyberCash service) is going to
integrate their own PayFlow service with CashRegister so it is likely
that in the long term there will be a new service with the features of
- Authorize.net seems to be the gateway that strikes a balance between
functionality and price. The many resellers of this service drive the
cost down to a minimum. As Gilbert pointed out, the API handles all
transaction types required by the ecommerce module. The workflow has
to change in places but the basic functionality is there. The biggest
challenge is the lack of referencing transactions by merchant
generated order IDs. Authorize.net has decent documentation at
http://www.authorizenet.com/support/docs.php. I belief that
Authorize.net could work well with the ecommerce module but that it
does require revising the ecommerce-credit and the
Gilbert and Janine, could we combine our efforts and work together on
a different gateway than CyberCash? Authorize.net seems to be a good
The CashRegister API is the only API that I have found that can query transactions *and* identintifies transactions by merchant issued order IDs. The latter is very important as it allows the merchant to track orders from the start. All other services (Authorize.net, Intellipay, Goemerchant, etc) track transactions by a transaction code issued by the gateway. The disadvantage is that when -for whatever reason- your site did not receive a response to the 'Auth' fase, manual intervention is required. You the merchant did not receive the transaction code and you can not query the service by your order ID.
This is interesting. I was playing around with a site that currently uses Authorize.net. When you "check out", they send you over to the Authorize.net gateway. Authorize.net generates a transaction ID for the customer and it passes that information back to the server after you fill out the credit card info. For the ecommerce package, I won't use this method of communication. The server will handle the communication with Authorize.net's gateway. Since a transaction ID is created before processing the credit card info, my guess is that there might be a way to grab the transaction ID for the direct connection method.
I'll call up Authorize.net to find out if I can grab a transaction ID from the server before asking the customer for the credit card number. If it is possible, then we can grab the transaction ID first and use that number to track the transaction. It won't be a merchant generated transaction ID, but it should work.
How do they compare feature and price wise?
I use the OpenACS shopping cart and just send a order total with the order id to paypal.
WOW. I just read that document. They have changed the API a little and actually documented it. When I started a while ago, there was no documentation available.
I will be cleaning up the code this week.
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.
For the low end side, ProPay.com, might be a better solution. There is no set up or monthly fee and your customer isn't forced to set up an account, as with Pay Pal. And I've read some very positive reports as well. Downside is the merchant fees are high (3.5%+.35 per transaction). But for low volume sales, this is might be more cost effective.
The Website Tools are at: http://www.propay.com/website_tools.html
Yes, I completely understand what you are saying. What I was suggesting was that there might be a way to get a transaction ID before submitting the customer's credit card information. If you use the WebLink method, the gateway server generates a transaction ID for the customer form (ie before the credit card info is transferred). That is the reason I think we might be able to get a transaction ID from the ADC direct response method. If we can get the transaction ID before the sending the credit card info, you can easily map the ecommerce package's order ID to the unprocessed transaction code/ID from the gateway server before sending the credit card data. If you don't get a response from the gateway server, you can always requery it.
I'll call Authorize.net later today to get more information.
I think Bart has said everything I would say. The Tcl library I was
working on was for Goemerchant, but their interface only allows
auths, nothing else, and it was too limiting. I abandoned that
effort and used the CyberCash module, since the Cybercash
gateway was available to me. Apparently it will not be available
for the next site. :(
In general I think the more different interfaces we can support,
the better it will be for the user base as a whole. To that end, I
think the thing to do is to parameterize the credit card functions.
That is, allow the site developer to specify via entries in the
parameters file which actions are supported by the gateway s/he
is using, and then use if statements to turn on and off the various
pieces of functionality which depend on those actions.
I can't offer to help with this; I have too much on my plate already.
But I will attempt to answer questions via e-mail if you need any
anybody intersted on getting this moving, please let me know.
While PayPal could be integrated with the ecommerce package I wouldn't recommend it for most sites. PayPal has a very limited API which is fine for basic transactions. That is a transaction for an order that doesn't require modifications once the order has been placed.
E.g. payments for software downloads fit the PayPal feature set well. The visitor pays for the license and receive access to the software download area.
Orders consisting of several physical items that need to be shipped and could be out of stock are a different matter. The consumer might also want to change the order before the items are shipped.
Take a good look at the PayPal API before making a decission. There are other credit card gateways that might fit your needs better. And not every one likes to setup a PayPal account just to pay for their order.
The ecommerce module requires quite a bit of work to interface to another payment gateway then CyberCash. I am currently working on a gateway to authorize.net. CyberCash had a unique workflow that is different from every other payment gateway that I have looked at. The current ecommerce module doesn't handle returns and voided items well either. I think that this is an issue that justifies a team approach. Any one interested?
The new, modernistic way to provide a service such as Gilbert suggests in his very first post in this thread is to hook into the new service contract mechanism. Make the cybercash, authorize.net and PayPal (despite its limitations there will be users who want to use it) packages that fulfill the contract requirements of e-commerce. Assuming this is generalized sufficiently then other packages could use the same contract and use any of the given gateways without our needing to rework them.
Our lead programmer is working on an AOLserver module to interface with Verisign's PayFlowPro system. We are considering releasing it as open source. We're also making changes to the ACS 3.4 ecommerce system to work with it, and would like to roll those changes into OpenACS 4, but may not have enough time.
Can't give you timelines on this as of yet. I'll try to remember to keep everyone posted.
yet begun working on it. I'd certainly like to see modular support
for many payment gateways.
I've done some tests with the search contract on some test packages. The implementation is straight forward. The only issue is the active_p indicator in the ec_products table. I'm not sure how to handle that yet.
Anyway, is there any documentation on how to implement a service contract? It's going to take a lot of work decouple cybercash from the current ecommerce package, but I don't think we need to provide that decoupling for the first release. I think it makes sense to define the inputs/outputs to the payment gateways and to create these as separate services which we can hook in later.
Any thoughts? Thanks.
Kapil has written up some documentation on the service contract package, I believe, and last I heard Neophytos was reviewing it. Stay tuned...
Another thread on Credit Card Processing is here:
I would also like to suggest to set up a working party to coordinate the efforts to ad payment infrastructure into ACS so we can bear the burden together of getting this part of the system operational. Right now it seems everbody is trying to invent the wheel and knowledge is spread around the globe. If we talk we might be able to find answers a bit faster. The bboard is not always the answer for this and we could do with a more formal project approach way of exchanging ideas. I spend about 10 years ferreting about international payment problems, and volonteer to set up the working party, and coordinate efforts.
A first draft of the definition of the API should be available in January. I'll post a note in this thread when it is ready.
Janine and I have just started to kick around some ideas. Janine will be using the infrastructure we come up with to implement an interface to Verisign while I'll be working on an Aiuthorize.net interface.
The infrastructure we are considering is similar to the OpenFTS based search package. We are currently evaluating the use of acs-service-contract for our purposes.
Although it will take some time for the infrastructure to be created I do have a package that mimicks the old CyberCash gateway. With this package in place you can evaluate the current state of the ecommerce package. The ecommerce package is fully functional to a large extent, the major missing link being the credit card gateway.
Ben, drop me a line if you are interested and I'll give you a copy of the CyberCash simulator. I'll can place a copy in the OpenACS file storage should there be more interest from the community.
As with most things in life, it mostly works, but the details will get you every time. :)
First of all, take a look at http://www.verisign.com/support/cyberCash/mckManager.html, which has a pretty good summary of what functionality you're losing. There are two important points: no more retry, and you are about to go into auto-mark mode (CyberCash was manual-mark).
Not having retry just means not using it; there isn't much of a substitute. I have to admit that I did this work in a tearing hurry (our client was moved with very little notice) and I didn't put much effort into thinking about the ramifications of just dropping out retry, but so far we have not had any problems from having done so.
Going into auto-mark mode means that transactions are settled right away when they're marked. To handle this, there are two places in www/finalize-order.tcl where ec_financial_transactions is updated to set the marked date; if you also set the settled date, then you are all set. You also need to do this in tcl/ecommerce-scheduled-procs.tcl, in ec_unmarked_transactions.
The biggest headache is the transition itself. Any orders which were preauth'd on Cybercash have to be manually completed via the Verisign Manager, since they don't move over any of your transaction data. Any order which was fulfilled while on Cybercash has to be manually processed to do returns, for the same reason.
The problem, as I recall, was that the scheduled proc which checks for unsettled transactions thinks the transaction has not been settled and tries to do it. Since it already has been done, this is unnecessary and results in an extra transaction id being assigned. Setting the settled date at the time the transaction is marked seemed like the easiest way to fix this. Perhaps there is a better way; as I said, we were in a tearing hurry to fix a live site when this all happened.
I will look into this in more detail when I build a payment module for Verisign's PayFlow, which I'll be doing after Bart and I finish defining the payment contract.
We did build an AOLserver module for Verisign's PayFlow. See
Hope this helps you.