Home
The Toolkit for Online Communities
17599 Community Members, 0 members online, 2686 visitors today
Log In Register
OpenACS Home : Forums : OpenACS Development : ecommerce status?

Forum OpenACS Development: ecommerce status?

Icon of envelope Request notifications

Collapse
Posted by Gilbert Wong on
What's the status of the ecommerce package?  I've done some
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.
Collapse
Posted by Janine Ohmer on
I don't know the porting status of the ecommerce module, but I
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?

Collapse
Posted by Gilbert Wong on

Janine,

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:

  • Auth-Capture
  • Auth-Only
  • Prior-Auth-Capture
  • Capture-Only
  • Credit
  • Void
  • 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?

Collapse
Posted by Bart Teeuwisse on
Cybercash is accepting new accounts till the end of the month (June).
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
todays CashRegister.

- 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
ecommerce-scheduled-procs scripts.

Gilbert and Janine, could we combine our efforts and work together on
a different gateway than CyberCash? Authorize.net seems to be a good
candidate.

Collapse
Posted by Gilbert Wong on
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.

Collapse
6: What about PayPal? (response to 1)
Posted by Sam Snow on
Could PayPal be made to easily work with the ecommerce package? It looks like page 32 of their PDF file explains how to integrate their service with a shopping cart to accept payment for multiple items.

http://www.paypal.com/cgi-bin/webscr?cmd=p/web/index-outside

How do they compare feature and price wise?

Collapse
Posted by Dave Bauer on
I have a working hacked version of 3.2.4 ecommerce that uses paypal. It is a much simplified system that does not support returns.

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.

Collapse
Posted by Bart Teeuwisse on
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.

Collapse
Posted by John Buol on
I've read some pretty harsh things about Pay Pal from former customers/users.

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

Fast X

Collapse
Posted by Gilbert Wong on
Bart,

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.

Collapse
Posted by Gilbert Wong on
Okay.  I just called Authorize.net.  There is no way to get the transaction ID before submitting the credit card info.  I'll have to think about this problem.
Collapse
Posted by Janine Ohmer on
Gilbert,

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
help.

Collapse
Posted by Gilbert Wong on
Sounds good.  I'll post updates here.
Collapse
Posted by Matthew Soldo on
Why is cybercash only accepting new accounts until the end of the month? What is going on over there?
Collapse
Posted by Bart Teeuwisse on
Cybercash/Verisign is only accepting new accounts for CashRegister till the end of the month because Verisign has a competing product (PayFlow). Hence, Verisign is discontinueing CashRegister while they integrate some CashRegister's features into PayFlow. For (a bit) more information read: http://cybercash.com/integration/verisignfaq.html#integrator.
Collapse
Posted by Ben Koot on
Has anybody tried to replace Cybercash with Pay Pal. I am working on the development of an e-commere application for the travel industry, and this would mean a great improvement, since many travel organisations already hae a Pay pal account.

anybody intersted on getting this moving, please let me know.

Collapse
Posted by Don Baccus on
Contact Gilbert Wong, who's done the OpenACS 4 port of ecommerce.  Support for different gateways is a definite goal of his, PayPal in particular.  Click on his name at the top of this page and you'll be given a page with a mailto: for him.
Collapse
Posted by Bart Teeuwisse on

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?

Collapse
Posted by Don Baccus on
Have you been talking to Gilbert?  (I think the answer's "yes" but I want to make sure).

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.

Collapse
Posted by C. R. Oldham on
Greetings,

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.

--cro

Collapse
Posted by David Walker on
Our company is planning to implement PayFlowPro also but we have not
yet begun working on it.  I'd certainly like to see modular support
for many payment gateways.
Collapse
Posted by Gilbert Wong on
Yes, Bart and have exchanged emails.

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.

Collapse
Posted by Don Baccus on
I agree with your assessment regarding the first release.  We don't really have time to do the decoupling now.  I'm assuming, though, that we'll might not have any other payment gateways implemented by our first release.

Kapil has written up some documentation on the service contract package, I believe, and last I heard Neophytos was reviewing it.  Stay tuned...

Collapse
Posted by Bob OConnor on

Another thread on Credit Card Processing is here:

http://openacs.org/bboard/q-and-a-fetch-msg.tcl?msg_id=0002TD

-Bob

Collapse
Posted by Cynthia Kiser on
Any more news on translating the CyberCash payment processing to Verisign? Mostly I am looking for notes on what needed to be changed. If anyone has done the research and would be willing to share that (even if the code migration is not finished), I would be grateful.
Collapse
Posted by Ben Koot on
Can anybody tell me how to scrap the current disfunctional Cybercash application from the core infrastructure so we can at least use teh ACS part to build our sales program, and add the payment module at a later stage. This would be a great help and addition to the functionality of ACS. I assume future users will be adopting localized payment services rather than just one because there is not one payment system in the world that works everywhere. This seems to me a logical approach from end users perspective. It would help find more users, an dat the same time buy time for the deveolpers of the interfaces to systems like Paypal, Versisign, Visa and other solutions in the make.

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.
cheers

Collapse
Posted by Bart Teeuwisse on
Cynthia, Janine and I are working on the specifications for an API to payment processing services. What we have in mind is akin to the OpenFTS based search package.

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.

Collapse
Posted by Bart Teeuwisse on
Ben, thank you for your offer to help devising a payment infrastructure. Help is always welcome. The best thing at this point is to wait for our first technical draft which I will publish here.

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.

Collapse
Posted by Janine Ohmer on
Cynthia,

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.

Good luck!!!

Collapse
Posted by Cynthia Kiser on
Janine, Thanks for the details. You mentioned changing ec_unmarked_transactions to update the settled_date in addition to the marked_date. The Verisign page that you referenced says they will continue to support the query option that the ACS 3.4 ec_unsettled_transactions uses to check if things have settled yet. So I don't really see a reason to change ec_unmarked_transactions. But our migration date is next week so will update this thread if we do end up having to make changes.
Collapse
Posted by Janine Ohmer on
Cynthia,

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.

Collapse
Posted by Janine Ohmer on
Upon further reflection I think what I said above was wrong.  The difference between manual-mark and auto-mark *should* be just that with auto-marking you don't need to explicitly mark before you can settle.  I'm guessing here as I haven't found any good docs from Verisign on this but it seems logical.  Therefore, my problems with settling must have been something else; I'm guessing that query wasn't returning what was expected.

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.

Collapse
Posted by C. R. Oldham on

Janine,

We did build an AOLserver module for Verisign's PayFlow. See

http://www.ncacasi.org/contrib

Hope this helps you.

Collapse
Posted by Janine Ohmer on
Thanks, CR, I will definitely take a look.
Collapse
Posted by Cynthia Kiser on
By the way, Verisign's migration of our existing Cybercash account went very smoothly. All of our marking and settling ran just fine without any changes to the procs. There were some oddities about voiding transactions that we have elected to deal with by just making the voids on Verisign's web site and then updating our order state. If I recall correctly, the void function that we are using is custom to our site. Other ACS 3.4.10 sites may or may not have the same issue with voiding transactions.