Forum OpenACS Q&A: Preferred Way to do Credit Card Payments from OpenACS

1: Preferred Way to do Credit Card Payments from OpenACS

Posted by Peter Marklund on 06/15/04 05:06 PM

We are about to build a site that will have paid membership. There will be two different membership types and a handful of membership durations to choose from. We need to charge the user with credit card upon sign up and also allow for extensions of the membership period and upgrades to the deluxe membership variant.

I was browsing the forums and found a post by Bart suggesting that we might want to use the payment-gateway and the authorize-gateway packages. I also found the list of OSCommerce supported gateways.

Maybe people with experience with building ecommerce sites on OpenACS could comment on what would be appropriate packages and gateway to use for our needs? Looking at the ecommerce package it looks like an overkill for us. It seems like the only tables we really need from that package are ec_addresses, ec_creditcards. However, I'm inexperienced in this field and may have easily overlooked something.

If somebody has code snippets illustrating the usage of the authorize-gateway that would be very helpful.

Many thanks in advance!

2: Re: Preferred Way to do Credit Card Payments from OpenACS (response to 1)

Posted by Bart Teeuwisse on 06/15/04 07:14 PM

Peter,

the payment-gateway is a service contract for processing credit card transactions. There used to be 2 implementations of the contract, one for Authorize.net and one for Payflow Pro, of which only authorize-gateway remains these days. The sample-gateway can be used as a template for new implementations.

The payment-gateway contract has been designed by Janine Sisk and myself while implemented by Janine. Unfortunately, the payment-gateway lacks documentation. However, the authorize-gateway is well documented.

The contract defines an interface for the basic credit card operations: authorize, chargecard, return and void. Authorize, authorizes a request to charge a card for a certain amount, chargecard performs a previously authorized transaction, return deposits a previously charged amount back to the card and void nullifies the transaction.

No state information is maintained by the payment gateway or any of its implementations. Calling packages -like ecommerce- have to maintain state and take appropriate actions. E.g. authorize a transaction when an order is being submitted, chargecard when the order is being shipped and retry an operation when the payment gateway implementation reports a temporal failure (failure-retry).

The Authorize gateway does record all responses from Authorize.net to a table for logging purposes but this information is not being used for state maintenance. The ecommerce package maintains state in ec_transactions.

The current payment gateway service contract handles credit card transactions only, eChecks are not supported. Neither are credit card processors who use forms to be filled out by the user to complete the credit card operation. All required information is to be gathered by the calling package prior to invoking the service contract.

The ecommerce package is the only package that I'm aware of that is in the OpenACS CVS repository to use the payment-gateway. The exact implementation to use is a parameter of the ecommerce package. Set PaymentGateway to authorize-gateway in order to use the Authorize.net implementation. However, you will need to get a (test) account w/ Authorize.net to test the gateway.

Alfred, Torben, maybe you can add your experiences too?

/Bart

3: Re: Preferred Way to do Credit Card Payments from OpenACS (response to 1)

Posted by Torben Brosten on 06/15/04 08:49 PM

Bart has pretty much covered the payment-gateway description.

An EZIC payment-gateway also exists[1], but not in the CVS yet, as it will be a few weeks or so before it gets upgraded from working with OpenACS 4.6.3 to 5.x (and put into CVS contrib). Feel free to do that. ;)

EZIC has responded well to open-source development for use of their services[2]. Their direct-mode documentation[4] was outdated in Jaunary, now is on par with other services.

Here are some advantages and limitations of the EZIC and Authorize gateways that I have encountered:

Operations perspective:

EZIC offers flexible permissions access from multiple websites, with the capability of setting different user accounts for each.[3] Each EZIC user-account can set a different description that shows in the credit card holder's bill. ie. mywebsite1.com mywebsite2.com etc.

Authorize.net offers 1 user-account per merchant account.

An EZIC merchant account can have up to 4 different active merchant banks connected to it. The merchant switches banks via the web.

Authorize.net offers connection to 1 merchant bank per merchant account.

Authorize.net provides direct support to merchants.

EZIC requires merchants to direct *all* customer support through their EZIC resellers.

Technical perspective:

EZIC requres separate first_names and last_name for validation processing, whereas Authorize.net uses a single name field for both. This problem was reconciled by adding a 3 space delimiter between first_names and last_name in ec_addresses.attn. The change has no effect on the authorize-gateway package, while allowing other payment-gateways, such as ezic, to parse separate fields.[5]

authorize-gateway requires installing dqd_utils, ezic-gateway does not use it.

----

1. http://dekka.net/openacs/ezic-gateway.tar
2. http://www.ezic.com/Alliances/Alliances.htm
3. http://ezic.com/resellerSolutions/featursAndBenefits.htm
4. https://secure.ezic.com/public/docs/merchant/public/directmode/
5. https://openacs.org/bugtracker/openacs/com/ecommerce/bug?bug_number=1385

4: Re: Preferred Way to do Credit Card Payments from OpenACS (response to 1)

Posted by Torben Brosten on 06/15/04 08:53 PM

corrected ref. 3. http://ezic.com/resellerSolutions/featuresAndBenefits.htm

5: Re: Preferred Way to do Credit Card Payments from OpenACS (response to 1)

Posted by Guan Yang on 06/15/04 11:11 PM

Peter, some notes:

There are a ton of different ways the payment gateways interface to commerce apps. Some examples:

Straightforward API calls through HTTPS GETs or POSTs typically with authorize, capture and cancel calls.
A form is displayed whose action attribute is a URL located on the gateway interface. After verification, user is redirected back to the originating site, which has to make a separate API call for capture.
Same as above, but the server makes a request to originating server to confirm that the payment is valid.

The first method is widely available in the US. It's a bit expensive when implemented in Denmark because it requires special certification from PBS.

For recurring payments, you need special permission (at least in Denmark) to store credit card information, but this is not hard to get if you follow the security requirements. When you're doing an interactive transaction the user should be required to enter the 3-digit CVC code. This code must not be stored, so a subsequent recurring billing is code without CVC (which is always possible if the application requests it).

Subscriptions require some bits of policy to be set. For example, when does renewal occur? On the first day of each month or 30 days after the subscription started? If it occurs on the first day of a month, how much does the subscriber pay for the "first month" which may be shorter than 30 days? If it occurs 30 days after subscription started, what happens when the user upgrades the subscription in the middle of a subscription period? Plus, what happens when the site decides to change any of these choices?