My current thought is to offer a Business::OnlinePayment driver that
maps data extracted from the track information into that API. Note
that using it would result in increased processing fees, of course,
but it would allow for some flexibility. My customers need this now,
and I don't want to be s
On Fri, 2006-10-13 at 09:50 -0700, Chris Travers wrote:
> Currently the CreditCard.pm is a rediculously simple file that does
> nothing more than import a couple of functions from the drivers. The
> drivers are specified using a configuration file as these are not
> expected to change regularly.
I have just come across a cool little utility that may make Quickbooks
import a possibility. For read-only operations it is free of charge
though not open source.
http://www.qodbc.com/qodbc.htm
Best Wishes,
Chris Travers
-
Some further thoughts on this topic:
Currently the CreditCard.pm is a rediculously simple file that does
nothing more than import a couple of functions from the drivers. The
drivers are specified using a configuration file as these are not
expected to change regularly.
Certainly it would be poss
I am going to have to rewrite the template section for the upcoming
release. However, here is the scenario that one could use:
Suppose we only want to print tax on the invoice if tax is applicable.
The $form->{tax} variable is set if tax is included, so we might use
the construct (formerly <%if
On page 47 of the manual I find:
<%if not varname%> tells the parser to ignore include the next block
only if varname was posted by the submitting form (or set via the form
hash elsewhere in the scripts).
...
<%if varname%> tells the parser to ignore the block if varname was not
