Event confirmation code could be 'tightened'

HI there,

The way the event code interacts with the payment processor in participant.php lends itself to the person writing a payment processor making a mistake which would result in an unsuccessful transaction being confirmed as successful (specifically regarding the doDirectPayment method). Basically the way it works is that the code relies on an error being returned for an unsuccessful transaction - no error and the transaction will be confirmed. I believe it would be more robust if the $param[trxn_id] had to be set for it to be considered successful.

The 'code' below is an example of how
> a developer could let a transaction pass through their code as a
> success that shouldn't be a success. Obviously they can avoid it if
> they understand what's going on but I think it's a mistake that could be
> made
>
> function doDirectPayment( &$params )
> compile transaction & send to gateway
> get $response from gateway
> If error_that_the_developer_has_thought_of
> CRM_Core_Error::fatal( ts( '$paymentProcessor - blah blah'
> ) );### error message is returned and
> transaction is not completed in civi
> end if
>
> if $reponse = failed
> CRM_Core_Error::fatal( ts( '$paymentProcessor - blah blah'
> ) );### error message is returned and
> transaction is not completed in civi
> elseif $reponse = success
> $params(whatever) = whatever
> $return $params
> ##params array values edited and returned.
> ##Transaction completed in civi
>
> end if
>
> ####eventuality that the developer hasn't thought of which does
> not fit into things tested for above.
> #### as long as an error message is not returned by this function
> the transaction is treated as a success by civi
> #### transaction is incorrectly completed in civi
>
> end