Forum OpenACS Development: ecommerce manual payment gateway

Posted by William Byrne on 10/12/02 06:06 AM

I'm trying to set the ecommerce package for manual CC processing. I'd
prefer not to hack up the modules to coerce an "authorized" state
(orders are in "confirmed" state.) To understand the process I traced
into the ecommerce-credit-procs.tcl using ns_log statements. I'm
failing on the expr that includes:

[acs_sc_binding_exists_p "PaymentGateway" $payment_gateway]

I sabatoged my efforts by installing a variety of payment gateways.
My goal was to establish a binding and advance further into the
ec_creditcard_authorization procedure hoping to learn more about the
authorization process.

I think I've reached my limit. Are there 10 easy steps to set up a
mock gateway that will automatically "authorize" transactions
allowing for an internal audit of the orders for manual processing?
Sure, I could poke through the tables and update "confirmed"
to "authorized"; however, I believe there's a better way that would
not require the use of outside merchant services and code hacks. Is
this possible? I'm using v4.6 from CVS sometime around 10/5/02.

2: Response to ecommerce manual payment gateway (response to 1)

Posted by Bart Teeuwisse on 10/12/02 06:34 AM

William,

you will have to write an implementation for the Payment Service Contract and then tell the eCommerce package to use your implementation. E.g. create manual-gateway and set the eCommerce PaymentGateway parameter to manual-gateway.

All financial transactions in the eCommerce package are passed on to the chosen implementation of the Payment Service Contract. The call to acs_sc_binding_exists_p checks to make sure that the specified implementation does exists.

See the Payment Service Contract (payment-gateway) for the definition of the Payment Service Interface. The Authorize.net implementation (authorize-gateway) is a good package to look into for an example of creating a real life Payment Service Contract implementation. And last but not least see the sample gateway (sample-gateway) for an empty shell of an implementation. This package would be a good start for your own manual gateway.

There is no need to muck with the eCommerce code. Just write a manual gateway that authorizes each call to the Authorize operation. Calls to ChargeCard should also return success so that orders can be schipped by the eCommerce administrator. The Void and Return operations come into play in the eCommerce admin section when voiding items/orders or handling customer returns.

The Payment Service Contract is by no means a code hack. Belief it or not it makes life easier rather than more complicated. Should you have more questions then post them here.

/Bart

3: Response to ecommerce manual payment gateway (response to 1)

Posted by William Byrne on 10/12/02 03:43 PM

>> The Payment Service Contract is by no means a code hack
Thank you Bart. Any hacks I was referring to would have been of my doing. I have nothing but good things to say about the OpenACS project and the packages it includes.

A few questions:
Any payment gateway that I install should have an installation process that binds it into the Service Contract architecture, correct?
If so, the next requirement would be for me to specify that gateway in the ecommerce parameter trunk?
Do I need to mount the payment gateway of choice or do I leave it as an unmounted service?

4: Response to ecommerce manual payment gateway (response to 1)

Posted by Bart Teeuwisse on 10/12/02 08:11 PM

william,

service contract implementations are bound to their service contract by way of SQL. Checkout authorize-gateway-sc-create.sql for an example. At the end this script also binds the implementation to the contract.

The Authorize.net implementation is defined as a singleton application so that it is clear that the package can be mounted. Mounting the Authorize.net implementation provides access to the admin pages of the gateway. If your manual gateway doesn't have any user or admin pages, you could make it a service otherwise a (singleton) application would fit the bill better.

/Bart