CiviCRM Community Forums (archive)

I have a customer who needs to pass some custom parameters to their payment processor.  It's a political group, and in order to comply with US federal law, certain information needs to be sent on to the FEC.  For this customer, the way they need to do this is by passing a custom parameter containing the required information to the processor (in their case, Authorize.net).   The folks that actually prepare the federal reports then work directly with Authorize.net to pull down the needed information.

I can see that the processor widgets get invoked by (for instance) a doDirectPayment(&$params) method, which gets the parameters using their canonical CiviCRM names.  The problem is that the $params get pretty heavily filtered, and in effect, the parameters passed to the back ends are hard coded, since CRM_Contribute_Form_Contribution_Confirm->postProcess() does not take any parameters, and constructs the $params array itself.

What's the cleanest way to to make sure a custom key/value pair gets passed to the payment processor?

I'd be happy to do that.  I'm assuming that 3.0 won't differ too much from 2.2 in this respect, so it makes sense to do exactly that.

A couple questions relevant to this.

There are several places one could inject additional information into the stream.  The simplest (and the first one I looked at) is using hook_civicrm_validate, which gets passed a writable &$fields parameter.  It would be simple enough to "bless" certain field names, and have the code pass them down.  It would be very simple, say, if a field name like "_user_custom" went to an associative array, allowing code to pass down parameters from the validate hook (or different hook if you think it's saner) all the way down to the payment processor code.

From there, whether or not it makes sense to use these custom fields depends a lot on the payment processor, so I think we'd make it an option for a payment processor implementation to call a custom hook with a signature like this:

/**
 * Hook definition for altering payment parameters before talking to a payment processor back end.
 *
 * @param string $processor_name
 *    name of the payment processor invoked ('Dummy', 'AuthorizeNet', etc.)
 * @param string $mode
 *    'test' or 'live'
 * @param array $payment_params
 *    array of params as passed to
 * @param string $op
 *    what operation we are doing on the back end ('direct', 'recurring', etc....)
 * @return void
 */
function hook_civicrm_payment_params($processor_name, $mode, &$payment_params, $op='direct');


This seems flexible enough to handle most cases, and would certainly solve my problem.

If this seems like a reasonable approach, I can implement it against the trunk and back-port it to 2.2 for my own purposes.  I'd be happy to implement the hook calls for Dummy and Authorize.net so we have some reference implementations.

It is, a bit, but I'm not sure your approach would work.

The problem is that:

• You need to call the hook _before_ the upstream code has filtered out the information you need to make it.  I'm pretty sure my custom fields are long gone by the time the processor is called
• You probably need to call that hook _after_ the processor has translated the parameters into its own key names.

In any case, the sort of things you need to do are very specific to which payment processor is called, and whether the processor is called in live or test mode.

I'll do some quick tests to see if I can get around these constraints with your approach.  If enough of the original data is still around when the processor is called, then the hook can do the calculations I'm doing at validate time, and it'll be fine.  Otherwise, we'll need to protect the additional data somehow (perhaps by preserving the raw, unprocessed params in the the Contribution object, and passing them along with the "cooked" params).

I'll take a look at that; I've been looking in the $fields parameter, which gets cleaned up pretty well.   If the $form object is available and still has the info, then I'll make use of it.

where does this hook get invoked from a civicrm code perspective. i.e. what file(s) and what are the parameters sent

from what little i know of FEC regulations, u basically need name/address/employer info  recorded. I assume u r collecting this via a profile on the contribution page. All this is data is then part of the form object till the transaction is complete. So i'm a bit confused here. maybe a chat on IRC might help clarify things

lobo

Lobo,

I've done a trial implementation (for Dummy.php, for now).  I wrote it up on my site, partly to show what I'm thinking of, and partly to explain how to get CiviCRM to call a new hook, which I suspect other developers will be interested in.

I'll put the post up on the CiviCRM blog once you and I agree what this hook needs to look like.  I've implemented it for 2.2, but would be happy to roll a patch for the trunk as well.

It would be better if it would work.  But it won't, unless the PPs are rewritten to allow it.   Also:  each PP handles its parameters at the back end in a different fashion.  You can't do this in a general way for all PP.  I'm not sure if you can do it for _any_ that way.   What I'm doing with Authorized simply cannot be done at the form level, but it's trivial with the hook.

Problem is that a good deal of code in the chain wants to clean up the parameters passed, so what you do at the form level will get removed rather rudely by one level of code or another.  And I suspect that some processors may actually need to remove some parameters, or would behave unpredictably if things were not cleaned up.  So the hook certainly needs to be "processor aware".

dmccarney's use case appears to be very similar to ours (in fact, I'm looking at almost exactly his use case down the line). 

We need this hook, it's simple, and it works, now.  It can easily be ported to 3.x.  Will you take it?

They are different in one significant aspect:  if you call before you invoke the processor, then you are invoking the hook before the processor code has the opportunity to do its own parameter translation between your parameter names and its parameter names (which are set by the back end you need to call).  The needed data structure will not exist that early.

Where exactly this occurs depends on the back end you are calling.  If your back end does not support this, then there is also no reason to call the hook at all.

Passing the form object might make sense, since it carries a lot of state information that would be hard for the processor code to get at otherwise.   But you'd still need the have this after translation occurs, so you'd need to change the calling conventions for the processors.  This isn't hard to do for all of the processors in the tree, since none of the processors need to _use_ the extra parameter; they only need it defined.

Take a look at the enclosed patch, which is on tonight's trunk.  I've patched CRM_Utils_Hook,  the dummy and Authorized processors, and the civitest sample.  The example implementation is essentially identical to what was needed for my application.