Moving the payment with reference system aside for basic actions
Setup a hierarchy for our api connection, depending on what we need
Making notes about statuses that come back for payment with reference
Refactored our doPaymentWithReference call to make other hashing easier
Roughed in a non-working version of our credit card SOAP model
Extracting some of our payment ideas into the superclass

So that we can re-use them for credit card purchases
Added in the basic SOAP request to purchase via credit card
Super rough version of the credit card capture action
Added a rough status action - no real work has been done here
Fixed bugs with our PaymentCaptureAction
replacing old vars
Shifted our connections / clients into a hierarchy format

Franchesco, this may be too complicated long-term, but it's
what immediately occurs to me when I see what we're starting to
need to do.
Cleaned up how we retrieve client objects
Shifted to testing reference capture action
Using status message returned and we'll get our last response

If we need to retrieve more information
Shifted to a simpler XML handling setup

Not sure we need to use the XML lastResponseStuff for our client
Cleaned out our connection / client hierarchy

Looks like we can handle that through our SOAP Api
stuff and returning the appropriate status information
directly.
First steps to setting up credit card action for dineromail
Fixed additional API bugs, at this point, we're talking to DineroMail
Fixed namespacing bugs that were causing issues when running `supports`