API Addition for ACH

[Eclarian]

Just thought I'd start a discussion on how to best setup the API for ACH ( e-checks, direct deposit, etc.) transactions.

For my particular implementation I will need to be able to do both CREDIT and DEBIT. I think these should be two separate function calls, even though they are very similar, because it will probably help prevent accidentally giving your money away. :)

Suggested API for ACH

$this->payments->ach_payment($gateway, $required_info);
$this->payments->ach_credit($gateway, $required_info);

Considerations
Even though ACH's will be using existing parameters within the gateway's API and could be mapped accordingly, it does require additional parameters which would not be required for a normal credit card transaction. Because of this, it'd be difficult to set the configuration properly for the gateway. For example, in the oneoff_payment configuration below, it requires cc_number, which would be irrelevant/unavailable in an ACH transaction.

'oneoff_payment' => array(
    'cc_number',
    'cc_code',
    'cc_exp',
    'amt'
)

Another consideration is that all gateways do not support ACH transactions and so the more common scenario will probably be someone who uses one gateway for their credit card processing and another gateway for their ACH processing.

One problem that I see with my proposed method is the inability to do an authorize transaction type for ACH. However, setting up the gateway for authorize_payment would face the same configuration problems that I stated above. Any of the functions that just require the identifier would still be able to function in the same way and wouldn't be a problem.

So that's my thoughts, what do you think?

[calvinfroedge]

These are good points, man.

I think the best way to proceed might be to introduce an OR within the required params (perhaps as an array, called OR, ALTERNATE, or something similar). If the required params are not found and the alternatives array is set, that array could be checked for "substitute" required fields. That's just a suggestion. Exploring the best way to do OR in general I think is preferred here. What we want to shoot for:

1. Code stays backwards compatible (payments breaking would suck)
2. Avoid adding new methods (which I would like to avoid as much as possible, so the interface doesn't get too cluttered).
3. Avoid making configuration / future support too complicated

That being said, if someone came up with a really good reason (and solution) for changing the interface itself, I'd be all ears.

[Eclarian]

A secondary array should work for what we need since the ACH would require different keys than credit cards. Balancing your second and third point is going to be the tricky part with supporting a credit ACH transaction though. The current API is setup to implicitly define the type through the method itself. (e.g. authorize, capture, etc.) How do you think we can support credit functionality?

Required ACH Parameters

array(
    'account_type' => 'checking', // checking OR saving
    'routing_num' => '', // bank routing
    'account_num' => '', // account number
    'doc_type' => '' // examples below
)

Documentation Types for ACH

array(
    'PPD' => 'Indicates you have a personal signed agreement on file for the customer',
    'CCD' => 'Indicates you have a company-signed agreement on file for the customer',
    'WEB' => 'Indicates the customer has agreed to the charges via an internet-based or electronic form',
    'TEL' => 'Indicates you have a recorded telephone call on file with the customer verbally agreeing to be charged',
    'ARC' => 'Indicates you have an actual signed, voided check from the customer'
)

[calvinfroedge]

Hey man,

I really need to read about ACH more and implement it for one gateway to be more educated here on the best practice. I'll touch base with you in a couple days on this.

• Calvin

[Eclarian]

Hey, sounds good! Keep me updated on your progress.

[Eclarian]

Calvin,

Just wondering if you had any progress on this or if there was any way I can help.

Thanks!

[calvinfroedge]

Hey dude,

Working on trying to release a product, so I've been kind of under the gun. Sorry for not getting back with you. If you want to help, how about implementing just the charging feature as part of the oneoff payments interface for now?

We can add some of the other features later.

• Calvin