... | ... | @@ -52,11 +52,11 @@ Reviewing the APIs for refunds listed above shows that multiple refunds can usua |
|
|
|
|
|
Payment information is stored in civicrm_financial_trxn. The payment processor for a payment (https://github.com/civicrm/civicrm-core/blob/master/xml/schema/Financial/FinancialTrxn.xml#L211) provides a trxn_id (https://github.com/civicrm/civicrm-core/blob/master/xml/schema/Financial/FinancialTrxn.xml#L173) which generally needs to be passed back in order to do a refund.
|
|
|
|
|
|
We will have a core BAO function that is not overridable by payment processors, payRefund(). It will be responsible for:
|
|
|
We will have a core BAO function that is not overridable by payment processors, doRefund(). It will be responsible for:
|
|
|
1. [ ] Determining if the relevant payment processor supports refunds and raising an error if it doesn't.
|
|
|
1. [ ] Invoking a pre hook to allow amount to be altered or for refund action to be cancelled.
|
|
|
1. [ ] Confirming that contribution status is Refund pending, and that the $amount to be refunded is less than the currently paid amount on the payment minus any refunds that have been processed to completion. (We'll allow repeated attempts to refund an amount if the status of these attempts is pending, failed, etc.)
|
|
|
1. [ ] Calling payment processors to do the refund payment via a CRM_Core_Payment:payRefundPayment() function defined below after marshalling the appropriate arguments.
|
|
|
1. [ ] Calling payment processors to do the refund payment via a CRM_Core_Payment:doRefundPayment() function defined below after marshalling the appropriate arguments.
|
|
|
1. [ ] If the refund payment succeeds then
|
|
|
1.1 [ ] Recording appropriate financial transaction similar to https://wiki.civicrm.org/confluence/display/CRM/CiviAccounts+Data+Flow#CiviAccountsDataFlow-Extension:ProcessPendingRefundPayment(RecordpaymentforAccountsPayableoutstanding).
|
|
|
1.1 [ ] The determination of an appropriate status for the contribution is getting very difficult. We will stipulate that if the status will be as follows:
|
... | ... | @@ -73,12 +73,12 @@ The calling code is responsible for higher level business logic, such as dealing |
|
|
```php
|
|
|
/**
|
|
|
*
|
|
|
* payRefund
|
|
|
* doRefund
|
|
|
* ....
|
|
|
* @return \CRM_Financial_DAO_FinancialTrxn
|
|
|
* @throws \CRM_Core_Exception
|
|
|
*/
|
|
|
function payRefund($financial_trxn_id, // https://github.com/civicrm/civicrm-core/blob/master/xml/schema/Financial/FinancialTrxn.xml#L10
|
|
|
function doRefund($financial_trxn_id, // https://github.com/civicrm/civicrm-core/blob/master/xml/schema/Financial/FinancialTrxn.xml#L10
|
|
|
$amount, // decimal to number of significant digits for currency (default 2)
|
|
|
$currency // https://github.com/civicrm/civicrm-core/blob/master/xml/schema/Financial/FinancialTrxn.xml#L134
|
|
|
) {
|
... | ... | @@ -95,12 +95,12 @@ function payRefund($financial_trxn_id, // https://github.com/civicrm/civicrm-cor |
|
|
|
|
|
/**
|
|
|
*
|
|
|
* payRefundPayment
|
|
|
* doRefundPayment
|
|
|
* ....
|
|
|
* @return \CRM_Financial_DAO_FinancialTrxn
|
|
|
* @throws \CRM_Core_Exception
|
|
|
*/
|
|
|
public function payRefundPayment(
|
|
|
public function doRefundPayment(
|
|
|
$financial_trxn_id, // https://github.com/civicrm/civicrm-core/blob/master/xml/schema/Financial/FinancialTrxn.xml#L10
|
|
|
$amount, // decimal to number of significant digits for currency (default 2)
|
|
|
$currency, // https://github.com/civicrm/civicrm-core/blob/master/xml/schema/Financial/FinancialTrxn.xml#L134
|
... | ... | @@ -163,12 +163,10 @@ Then: |
|
|
|
|
|
* [ ] Create permission 'CiviContribute: pay refund'
|
|
|
* [ ] Add fn ```supportRefund()``` to CRM_Core_Payment that will be overriden by Payment Processor class wrapper to return TRUE, if the Payment Processor supports refund
|
|
|
* [ ] Add BAO function ```payRefund()```.If ```supportRefund()``` return TRUE, processor will call its ```payRefundPayment(...)``` fn.
|
|
|
* [ ] Add BAO function ```doRefund()```.If ```supportRefund()``` return TRUE, processor will call its ```doRefundPayment(...)``` fn.
|
|
|
* [ ] Register Offline and Online Refund reciept template. Handle is install and upgrade.
|
|
|
* [ ] Implement ```Pay Refund``` feature as explained in **Paying Refund/Online Form**
|
|
|
* [ ] Modify 'Record Refund' backoffice form to support refund via PP (this involves adding 'Payment Processor' field - select field to show PPs of same type that support refund)
|
|
|
* [ ] Support 'Pending Refund' in Membership backoffice form.
|
|
|
* [ ] Extend Order and Payment APIs to handle refunds.
|
|
|
* [ ] Implement ```Pay Refund``` feature as explained above
|
|
|
* [ ] Extend Payment API to handle refunds.
|
|
|
* [ ] Add Unit tests
|
|
|
|
|
|
----------
|
... | ... | @@ -182,7 +180,7 @@ Should we include no hooks, an alterParams hook, a pre hook to allow cancel, a p |
|
|
* MJW: {some stuff removed as incorporated above} We should be very clear what parameters are passed, and if possible pass all relevant IDs, eg. contribution_id, contribution_recur_id, membership_id, participant_id, pledge_id. That will make future use-cases far easier to implement*
|
|
|
> Monish: Agree. I have added a $params which will contain additional info.
|
|
|
|
|
|
* MJW: It would also be really nice to see a hook that could be triggered at the beginning of payRefund() (and later extended to all payment processor methods) - see for example in the Smartdebit extension: `CRM_Smartdebit_Hook::alterVariableDDIParams($recurParams, $smartDebitParams, 'cancel');` https://github.com/mattwire/org.civicrm.smartdebit/blob/master/CRM/Core/Payment/Smartdebit.php#L1108
|
|
|
* MJW: It would also be really nice to see a hook that could be triggered at the beginning of doRefund() (and later extended to all payment processor methods) - see for example in the Smartdebit extension: `CRM_Smartdebit_Hook::alterVariableDDIParams($recurParams, $smartDebitParams, 'cancel');` https://github.com/mattwire/org.civicrm.smartdebit/blob/master/CRM/Core/Payment/Smartdebit.php#L1108
|
|
|
This allows for extensions to do other things such as modify amounts, add/remove parameters when a payment processor action is happening.
|
|
|
> Monish: I have modified the function definition which now calls ```CRM_Utils_Hook::alterPaymentProcessorParams``` at the beginning of the fn.
|
|
|
|
... | ... | |