CiviCRM Community Forums (archive)

Those of us who grew up before MineCraft & Facebook & selfies had to delight ourselves with low-tech pursuits like making mud-pies and as we got older we got to do the spot-the-difference in the local newspaper. Oh the good old days. And now we only have copy and paste code to take us back to that delightful pursuit so ... spot the difference....

    if (!$first) {
      //check if this contribution transaction is already processed
      //if not create a contribution and then get it processed
      $contribution = new CRM_Contribute_BAO_Contribution();
      $contribution->trxn_id = $input['trxn_id'];
      if ($contribution->trxn_id && $contribution->find()) {
        CRM_Core_Error::debug_log_message("returning since contribution has already been handled");
        echo "Success: Contribution has already been handled<p>";
        return TRUE;
      }

      $contribution->contact_id = $recur->contact_id;
      $contribution->financial_type_id  = $objects['contributionType']->id;
      $contribution->contribution_page_id = $ids['contributionPage'];
      $contribution->contribution_recur_id = $ids['contributionRecur'];
      $contribution->currency = $objects['contribution']->currency;
      $contribution->payment_instrument_id = $objects['contribution']->payment_instrument_id;
      $contribution->amount_level = $objects['contribution']->amount_level;
      $contribution->honor_contact_id = $objects['contribution']->honor_contact_id;
      $contribution->honor_type_id = $objects['contribution']->honor_type_id;
      $contribution->campaign_id = $objects['contribution']->campaign_id;
      $objects['contribution'] = &$contribution;
    }
    //load new contribution object if required.
    if (!$first) {
      // create a contribution and then get it processed
      $contribution = new CRM_Contribute_BAO_Contribution();
      $contribution->contact_id = $ids['contact'];
      $contribution->financial_type_id  = $objects['contributionType']->id;
      $contribution->contribution_page_id = $ids['contributionPage'];
      $contribution->contribution_recur_id = $ids['contributionRecur'];
      $contribution->receive_date = $now;
      $contribution->currency = $objects['contribution']->currency;
      $contribution->payment_instrument_id = $objects['contribution']->payment_instrument_id;
      $contribution->amount_level = $objects['contribution']->amount_level;
      $contribution->address_id = $objects['contribution']->address_id;
      $contribution->honor_contact_id = $objects['contribution']->honor_contact_id;
      $contribution->honor_type_id = $objects['contribution']->honor_type_id;
      $contribution->campaign_id = $objects['contribution']->campaign_id;

      $objects['contribution'] = &$contribution;
    }
Yes, there are a few - do they have any significance? And, yes this is 4.4 so someone got to update both those places for 4.5 & presumably fix them to point to soft credits. But, I'd prefer NOT to copy this again to the extension I am working on. And it doesn't really meet the needs of an alternate flow

We have 2 recurring flows

1) recurring contribution is processed automatically & an IPN hits CiviCRM
2) recurring contribution triggered by a scheduled job

In both cases a contribution should be created. The recurring contribution should be updated and any related objects (membership, soft credit) should be updated. So in the second case the flow is
1) create a pending contribution with a linkage to other entities as appropriate
2) process (in the case of tokens, just get result otherwise)
3) update pending contribution, recurring contribution & related entities to reflect success or failure.

We don't need to go through this 3 step process for IPNs although if we did we would be able to re-use the code and save ourselves from having to maintain 2 sets of permutations.

So, I'm thinking
1) CRM_Contribute_BAO_RecurringContribution::prepareNewRecurringTransaction($params);
- creates pending contribution, links it with objects - required is the recurring contribution id & any params that would override a direct copy of the previous one (note that date could reasonably default to next_sched_date )

2) $paymentProcessor->createPayment($params);
- performs a token transaction

3) use existing civicrm_api3('contribution', 'completetransaction', array('id' => x);

4) wrap all the above in an api like
api_payment_create($params) {
  CRM_Contribute_BAO_RecurringContribution::prepareNewRecurringTransaction($params);
  $attempt = $paymentProcessor->createPayment($params);
  if (is_successful($attempt)) {
    civicrm_api3('contribution', 'completetransaction', array('id' => x);
  }
  else {
    // this doesn't really exist at the moment - completetransaction could potentially take a status
    civicrm_api3('contribution', 'fail',  array('id' => x);
  }
}

5) the IPNs could call
CRM_Contribute_BAO_RecurringContribution::prepareNewRecurringTransaction($params);

  CRM_Contribute_BAO_RecurringContribution::prepareNewRecurringTransaction($params);
  $attempt = $paymentProcessor->normaliseInput($params);
  if (is_successful($attempt)) {
    civicrm_api3('contribution', 'completetransaction', array('id' => x);
  }
  else {
    // this doesn't really exist at the moment - completetransaction could potentially take a status
    civicrm_api3('contribution', 'fail',  array('id' => x);
  }
}


Although I suggested the CRM_Contribute_BAO_RecurringContribution as the right place for the first function - realistically that won't work unless it is added to 4.4.8 & 4.5.1 (or 4.5.2) - so I guess this will need to live within extension classes for a while (if I go to a sprint next year I can work into core). However, since I intend to use omnipay extension for most processors (not this one sadly) going forwards I can build this into that.

PaypalProIPN & Authorize.netIPN

Well - as I pointed out this gives us the joy of playing spot the difference :-)

By moving them to the parent class we would score points on the line-added-vs-removed-scoring-system by moving to the parent class (unless we got silly & added a comment block) I think we still have a gap on how to deal with token-based recurring payments (which are kind of the main area of development these days.)