Forum OpenACS Q&A: New Ecommerce and Payflow Link

You can take a look at the implementations for Authorize.net and Payflow Pro for examples how to create an implementation of the payment service contract.

If they follow the usual model of taking your information via https and returning the answer back via a URL you specify, then your service contract implementation will have to split the Authorize functionality into two pieces - send off the request in the Authorize procedure and write a new Tcl script which gets the response and stores it in the database.  There won't be any way of returning a status directly from Authorize, unfortunately...

The existing contract could be modified to have Authorize always store the result in the database, and to never expect immediate responses, but then we lose backward compatability with sites that are using the service contract as it is now.

This is really a procedural issue as much as anything else - is it better to make a major change to an existing service contract, or to write a second service contract which is similar but different?  This issue will come up again, so we should decide now how to handle it.

Personally, although changing the existing contract is preferable to me in most respects I think we are stuck with writing a new one, because of the backward compatability issue.  But that's just my opinion.

This option is more expensive because in addition to payflow link you will need to acquire SSL as the store front gathers payment information and posts it to verisign.

Other than that your analysis looks good. I think for the standard toolkit option 1 makes the most sense. Option 2 seems less attractive for the standard toolkit though it could be attractive for individual site builders.

If clients are asking for this as their preferred solution, you may counsel that it takes the wrong approach.

Recurring billing will not work this way at all (unless Verisign has an option there to let the customer specify recurrent billing)

Every 'good design for ecommerce' analysis[1] I've read  says to keep the credit card number somewhere so the next time the customer does not have to type it in again (the Amazon standard behaviour).

[1] and my own usually skeptical 'experts, ha!' reaction is not TOO bad on this point

Hi Don,

Sorry, about that I really meant the site certificate when I wrote SSL back there.

If clients are asking for this as their preferred solution, you may counsel that it takes the wrong approach.

Hi Sanjeev,

I am very inclined to agree. The payment gateway for the ecommerce module works beautifully the way it is. However, I beleive it boils down to "security vs. cost vs. customer convenience". Sometimes trying to strike a balance between the three can be a nightmare for us developers. Nevertheless, experience tells me that this is what forces us to push the envelope a little further. Who knows, maybe after all this discussion, we may come up with a good way to integrate payflowlink as an alternative payment gateway for the ecommerce module without sacrificing customer convenience.

.... can you describe how you would modify the service contract for Option 1?

Hi Janine,

After consulting with colleagues in the office and after I finished reading the payflow link user guide in detail. I have realized that a service contract for PayflowLink is overkill. At this point I am studying the code for the checkout process in the ecommerce module, I believe the key to getting payflowlink to work with ecommerce is there. I can send you the user guide in pdf via email if you'd like to take a look, I'm sure you'll come to the same conclusion after reading it. I will also be honored to send you and Bart the additions/modifications I make.

Hi Jun,

I believe I may already have the answer. Will discuss it with you tomorrow.

Best Regards,

now that I have taken a closer look at the Payflow Link documentation, I'm afraid that the ecommerce module is a poor fit for Payflow Link.

The ecommerce module handles financial transactions in 2 stages: an authorization step and a capture step. Authorization is obtained when the customer submits the order. Items that require shipping will not be captured untill those goods are shipped. Soft goods like course registration or software will be captured immediately after authorization has been obtained.

Payflow Link on the other hand authorizes and captures financial transactions in 1 step. You should consider the following use cases in your design:

- Should items be out of stock can the ecommerce administrator refund the customer from the ecommerce admin pages? Or can refunds only be given from the Payflow Link administration site?

- Fulfilling orders from the ecommerce admin pages relies on the 2 step process, you will have to modify this process to accept the 1 step Payflow Link transactions.

- Be sure to pass the customer information collected by Payflow Link to the ecommerce package. The ecommerce checkout process that you bypass with Payflow Link collects shipping and billing information that is later used when fulfilling orders.

I also urge to take a look at Authorize.net as this might be very price competative. Yes, you have to get a SSL certificate but that should cost more than $100/year. The monthly fees for Authorize.net are very modest. They can be as low as $10/month depending on the reseller. Transaction fees are around $0.30/transaction, which -with competative discount rates- can be cheaper than competing discount rates.

I'm not convinced that the low price of Payflow Link outweights the work required to modify the ecommerce package to work with Payflow Link. After all, the ecommerce package already offers merchants a turn-key ecommerce solution, including a shopping cart, order fulfilling and billing. All that the ecommerce package requires is a payment processing service to send the billing information to. With the ecommerce package there is no need to use the Payflow Link checkout pages instead.

Have you tried the ecommerce package with a Payflow Pro test account? You'll notice how no programming experience is required to set up a store once Payflow Pro has been installed.

I'd have to agree with Jun that a shopping cart (not just a product catalog as Payflow Link can only handle the total order amount) would be a better fit for Payflow Link.

Feel free to contact me directly if you have any questions. You can reach my by e-mail or on the OpenACS IRC channel.

/Bart