[freeside] Void payment problem with batch-card invoice event

[ivan]

On Thu, Mar 03, 2005 at 09:27:43PM -0500, Gilbert Rebeiro wrote:
> Hi again,
> 
> I am using batch-card to send "pre-authorized-payments" to my bank for
> processing. (they provide me with a void check specimen)
> I use realtime for credit-card transactions.
> 
> When I run freeside-daily it populates the cust_pay_batch table (I've
> enlarged the cardnum field to accommodate the account number and aba routing
> information, and removed some of the verification logic for credit cards).

Sounds like cust_pay_batch could use some work in general - perhaps
separate fields (or tables?) for card and ACH batching?  Please consider
contributing your work back to the project rather than just telling us
about it when you have a problem.  :)

> I then run a simple script that reads through the cust_pay_batch table and
> creates a text file that conforms to the banks' specification and upload the
> file.

It would be great if you would contribute this code as well so the this
download format could be available to other users as well.

> They process the file and accept it with no errors, this doesn't mean that
> nobody will NSF, it just means that my bank will forward me the total
> amount.
> 
> I then create a file from the original table that conforms to the "CSV
> results from TD Canada TrustMerchant PC Batch" format and process all the
> payments in the batch.

Ugh... there's nothing special about that format.  Please consider 
adding support for the _actual_ format you receive back.

> All the clients in the batch get a receipt via email.
> 
> Sometimes a few days (5 in some circumstances) the NSF information arrives.
> 
> I don't mind doing the development, but, how should an NSF be handled so
> that it can be included in the next batch card run?
> 
> I am not sure that a refund is what I am looking for.

A refund is not what you're looking for.  You want an (manual or
automatic) "void".  Use the "void" link on the or see
FS::cust_pay::void.

You also probably want followup invoice events, or if you're ambitious,
modify FS::cust_pay::void so it modifies the status of the invoice event
that triggered it - tricky, need to add a table linking events to
payments (cust_bill_event and cust_pay) so you know which 
cust_bill_event records to go back and change status to failed on.

Did I mention the batch code is suffering from a bad case of bitrot?

Unfortunately, like MySQL support, batching has far more interest from
the community than from my customers.  Certainly contributions and
maintenance would be most welcome from the folks actually using it.  I'm
happy to help where I can. 

-- 
_ivan


> 
> I hope this is clear.
> 
> Thanks in advance,
> Gilbert.
> 
> -----Original Message-----
> From: ivan [mailto:ivan at 420.am] 
> Sent: Thursday, March 03, 2005 7:40 PM
> To: ivan-freeside at sisd.com
> Subject: Re: [freeside] Void payment problem with batch-card invoice event
> 
> "voiding" a payment removes it from your records.  It doesn't send anything
> to a processor.
> 
> "refunding" a payment sends a reversal for the payment to your processor (it
> cancels the transaction if it hasn't been settled yet, or issues a credit if
> it has).  This functionaltiy requires support for "credit"
> (and optionally, "void") actions from the specific underlying
> Business::OnlinePayment::Processor module. 
> 
> This functionality is only available when using a real-time processor.  
> Batch processing only batches payments (IIRC credit card only, not ACH).  
> 
> I've barely worked on the batch processing in years.  All of my current
> installs except one use real-time processing. 
> 
> --
> _ivan
> 
> 
> On Thu, Mar 03, 2005 at 07:58:10AM -0500, Gilbert Rebeiro wrote:
> > Hi,
> >   I am using freeside 1.5.0pre6
> >   after I void a payment for a customer with payment type of  Electronic
> > check (automatic) 
> >   the payment doesn't get into the cust_pay_batch table after running
> > freeside-daily on the next billing run.
> > 
> >   Am I missing a step?
> > Thanks,
> > Gilbert.
> >   
> > 
> 
> -- 
> _ivan
> 

-- 
_ivan