Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-08-08T15:16:15Zhttps://lab.civicrm.org/dev/core/-/issues/4086`processor_id` and `trxn_id` is not properly being set on recurring contribut...2023-08-08T15:16:15Zbrienne`processor_id` and `trxn_id` is not properly being set on recurring contributions with PayPal ProOverview
----------------------------------------
When a user submits a new, recurring payment on a site that uses PayPal Pro, the `processor_id` and `trxn_id` are immediately set to a long alphanumeric string on submission and these val...Overview
----------------------------------------
When a user submits a new, recurring payment on a site that uses PayPal Pro, the `processor_id` and `trxn_id` are immediately set to a long alphanumeric string on submission and these values are not getting updated with the proper format (a shorter, alphanumeric string that starts with 'I-') that is sent back from PayPal.
This causes an immense issue if the user then wants to cancel their recurring contribution because even though it may seem canceled in CiviCRM, the payment is not canceled on PayPal's side, and so the user continues to be charged. This happens because the PayPalPro IPN is no longer being properly set in the CiviCRM database, so when the request to cancel the recurring payment profile goes to PayPal, it does not have the correct `processor_id` needed to cancel it.
Reproduction steps
----------------------------------------
0. If you don't already have one, set up a PayPal Pro Sandbox account that has DPRP enabled for testing recurring payments. Add the API credentials (found in **Activity > API Access > NVP/SOAP API integration**) of this sandbox account to CivCRM as a test payment processor.
* *Fair warning, this set up process with PayPal was not that easy, so if you don't have PayPal Pro, I wouldn't recommend trying this*
1. From your PayPal Pro Sandbox account settings, go to **Notifications**, then click **Update** on **Instant payment notifications**. If your site is not publicly accessible to the internet (i.e. a local dev site for testing), then set up a [webhook.site](https://webhook.site) listening endpoint.
1. Submit a new, recurring contribution (*while not logged in on CiviCRM and using a [PayPal generated credit card for testing](https://developer.paypal.com/tools/sandbox/card-testing/)*) using the PayPal Pro payment processor.
1. On the web UI of webhook.site, take a look at the `recurring_payment_id` for the POST request that has `'recurring_payment_profile_created'` as the `'txn_type'`.
1. In CiviCRM, either with the API explorer or however you look at the data in the databases, look at the `processor_id` and `trxn_id` in the `civicrm_contribution_recur` table.
1. You will find that these strings don't match.
Current behaviour
----------------------------------------
The `processor_id` and `trxn_id` are being set to long alphanumeric strings, such as 'e13d51f14f7fff9fb6923820022ebc77' upon submission of a recurring payment on a CiviCRM installation that is using PayPal Pro. These values are stored in the `civicrm_contribution_recur` table and become problematic for updating or canceling recurring payments.
Expected behaviour
----------------------------------------
The `processor_id` and `trxn_id` should be set to (and stored as) the PayPal Pro IPN that is generated when the `'txn_type'` is `'recurring_payment_profile_created'`. The PayPal Pro IPN is an alphanumeric string that notably starts with 'I-', such as 'I-818V5WCCXF2H'
Additional Info
----------------------------------------
Some backstory - a few years ago, `processor_id` was initially set to `NULL` and was later updated with the IPN. In that scenario, the logic that CiviCRM used (in `/CRM/Core/PaymentPayPalProIPN.php`) made sense, as it checked if that value was set and returned early if it was. However, [PR #21539](https://github.com/civicrm/civicrm-core/pull/21539) added `processor_id` to parameters that get passed to the `recur()` function in PayPalProIPN.php, so the code that sets the value of `processor_id` (and `trxn_id`) to the properly formatted IPN was not being reached.
@JonGold and I currently have a PR with a fix for this in the works, but are doing further testing with a client.
Given that this issue has been going on for a while (9 months, at least), there are many recurring contributions that have a malformed `processor_id`. The PR that will be submitted also includes a check for when `'txn_type'` is `'recurring_payment'` (i.e. subsequent recurring payments) to update the `processor_id` and `trxn_id` to the proper format, if needed.https://lab.civicrm.org/dev/wordpress/-/issues/133WPML URL Integration for CiviCRM2024-02-19T18:33:21ZshaneonabikeWPML URL Integration for CiviCRM## Overview
When using WPML language plugin in conjunction with CiviCRM the generated translated URLs are incorrect. All the translated URLs point to the CiviCRM page rather than the proper translated CiviCRM event, contribution, or oth...## Overview
When using WPML language plugin in conjunction with CiviCRM the generated translated URLs are incorrect. All the translated URLs point to the CiviCRM page rather than the proper translated CiviCRM event, contribution, or other page.
This isn't ideal and confusing for most users as they attempt to navigate to the translated CiviCRM page.
There is already integration for Polylang, but not integration presently for WPML.
WPML handles URLs in three different ways:
+ Attaching a language parameter to the end of the url ```lang=xyz```
+ Attaching a language in the path of the url ```https://test.dev/fr/civicrm/event/info/?reset=1&id=1```
+ Allowing for different domains for each language ```https://fr.test.dev/civicrm/event/info/?reset=1&id=1```
## Before
Viewing the page ```https://test.dev/civicrm/event/info/?reset=1&id=1```, and clicking on the WPML language link will take you to ```https://test.dev/civicrm/```
## After
The new code (I will attach the PR to this ticket shortly) will provide the proper integration for the defined scenarios above.
## Testing
I have tested this in the following scenarios, but maybe others want to test a bit larger?
+ Multiple domains while viewing (Events page)
+ Language placed in the URL (Events page)
+ Language within the proper path
+ Multisite installation with one site using WPML and CiviCRM Events
I don't believe that the path construction is any different for Contribution and other CiviCRM public pages, but I could be wrong.https://lab.civicrm.org/dev/financial/-/issues/203False-positive duplicate detection caused by webform not passing correct par...2024-01-16T19:36:50ZAllenShawFalse-positive duplicate detection caused by webform not passing correct parameters to Authorize.net - it needs to pass contributionID(Joinery internal reference: "Trello#142: Membership Application and Payment Process Not Working")
From what I understand so far, it seems there's a well-thought effort to use propertybag to standardize parameter names in payment proces...(Joinery internal reference: "Trello#142: Membership Application and Payment Process Not Working")
From what I understand so far, it seems there's a well-thought effort to use propertybag to standardize parameter names in payment processors. Here's one area where this effort seems incomplete and easily improved:
There are a few places in `CRM_Core_Payment_AuthorizeNet::doPayment()` where directly accessing `$params` could (and does) cause problems; it seems right to switch these to `$propertybag`. (BTW I think that usage of `propertybag` in the context of alterPaymentProcessorParams hook is still not appropriate, so I'm not suggesting changes to that usage within this method.)
**Specific observable problem:**
(I can create a more detailed and stripped-down recipe if needed, but hoping to avoid the effort.)
- On a site with: D7, civicrm 5.49.5, webform_civicrm.module, and contributiontransactlegacy extension
- We have a webform which accepts membership signups, payable through the core Authorize.net payment processor.
- Payments made through this webform are actually transacted in Authorize.net, but the user is given the error, 'It appears that this transaction is a duplicate. Have you already submitted the form once? If so there may have been a connection problem. Check your email for a receipt from Authorize.net. If you do not receive a receipt within 2 hours you can try your transaction again. If you continue to have problems please contact the site administrator.'
- FWIW I have observed that the below corrective measure fixes this problem for this site.
**Why this error happens:**
- `CRM_Core_Payment_AuthorizeNet::doPayment()` calls `$this->checkDupe($authorizeNetFields['x_invoice_num'], $params['contributionID'] ?? NULL)` (see [line 171](https://github.com/civicrm/civicrm-core/blob/a1278f71bd804c8013600793916a692b4345e4a2/CRM/Core/Payment/AuthorizeNet.php#L171)) to detect a duplicate transaction.
- However, `$params['contributionID']` is undefined. (On the other hand, `$params['contribution_id']` is defined, as is `$propertyBag->getContributionID( )`).
- Since `checkDup()` gets a NULL value for `$contributionId`, it always thinks the contribution is a duplicate, so we get the above error message.
**Corrective measueres**
1. Seems like the intent of `propertybag` is to clear up exctly this kind of naming inconsistency. I suggest changing Line 171 to use `$propertyBag->getContributionID( )` instaed of `$params['contributionID']`.
2. [Line 146](https://github.com/civicrm/civicrm-core/blob/a1278f71bd804c8013600793916a692b4345e4a2/CRM/Core/Payment/AuthorizeNet.php#L146), which tries to read `$params['is_recur']` and `$params['contributionRecurID']`, is probably also a good candidate for similar cleanup?
Should I go head with a PR or is more discussion needed?https://lab.civicrm.org/dev/core/-/issues/2693Remove all calls to BAO_Contribution::completeOrder other than from Payment.c...2023-09-10T15:41:47ZeileenRemove all calls to BAO_Contribution::completeOrder other than from Payment.createThe goal is that we should either
1) call Payment.create to add a payment - which would itself call completeOrder
2) OR call repeatTransaction via the repeattransaction api to create a pending order - which we would then update to cance...The goal is that we should either
1) call Payment.create to add a payment - which would itself call completeOrder
2) OR call repeatTransaction via the repeattransaction api to create a pending order - which we would then update to cancelled or failed if need be or - if completed call payment.create
Note that currently Payment.create calls Contribution.completetransaction - the goal is to reverse this
I'm currently working on removing calls to completeOrder other than from the 2 api calls - at which point we can change the api calls to no longer call completeOrder directlyhttps://lab.civicrm.org/dev/core/-/issues/3325Using separate donation with free membership result into Pending (incomplete ...2023-11-10T01:45:09ZMonish DebUsing separate donation with free membership result into Pending (incomplete transaction) 0$ contributionSteps to replicate:
1. Create a 0$ fixed membership type
2. Configure a new/existing online contribution page, with separate donation and choose 0$ membership type under `Membership Fee`
3. Do a online contribution with $1 separate dona...Steps to replicate:
1. Create a 0$ fixed membership type
2. Configure a new/existing online contribution page, with separate donation and choose 0$ membership type under `Membership Fee`
3. Do a online contribution with $1 separate donation with 0$ membership
Bug:
Two donation are created, one with Completed 1$ contribution and other `Pending (Incomplete Transaction)` 0$ contribution linked with Pending free membership:
![Screenshot_2021-06-22_at_2.06.49_PM](/uploads/0cbd58fb74d7bc9467613571f70bb74a/Screenshot_2021-06-22_at_2.06.49_PM.png)
Expected result:
Complete 0$ membership's donation associated with `new` free membership
cc @eileen @JoeMurrayMonish DebMonish Debhttps://lab.civicrm.org/dev/financial/-/issues/174Partial payment records amount of full contribution disrupting balance2023-06-16T09:36:40Zmagnolia61Partial payment records amount of full contribution disrupting balanceIn https://lab.civicrm.org/dev/financial/-/issues/173 the user dashboard pay now button was enabled for partially paid contributions. When I first tested this it looked fine, as the proper remaining amount was charged for the additional ...In https://lab.civicrm.org/dev/financial/-/issues/173 the user dashboard pay now button was enabled for partially paid contributions. When I first tested this it looked fine, as the proper remaining amount was charged for the additional payment.
On further testing I noticed that it was not recorded properly. Situation was like this:
Contribution Amount = 155
Initial payment = 55
Amount Due = 100
Via the User Dashboard Pay Now button the remaining 100 is paid.
The contribution status is now completed.
But the payment transaction is recorded as being the full 155.
So Civi thinks too much has been paid.
![Screenshot_2021-06-02_Dashboard_-_Testdeel_contribution_Gedeeltelijk_Stichting_Onvergetelijke_Zomerkampen](/uploads/aafe9f5a09dd4a57a4ad39042cf5148d/Screenshot_2021-06-02_Dashboard_-_Testdeel_contribution_Gedeeltelijk_Stichting_Onvergetelijke_Zomerkampen.png)
![Screenshot_2021-06-02_Online_betalen_Stichting_Onvergetelijke_Zomerkampen](/uploads/1905ada9754fb2414871da4197ec45c6/Screenshot_2021-06-02_Online_betalen_Stichting_Onvergetelijke_Zomerkampen.png)
![Screenshot_2021-06-02_Testdeel_contribution_Gedeeltelijk_Stichting_Onvergetelijke_Zomerkampen](/uploads/b5501ee9d40fd6ae41f1a1ae1692bf6c/Screenshot_2021-06-02_Testdeel_contribution_Gedeeltelijk_Stichting_Onvergetelijke_Zomerkampen.png)
The second payment should have been recorded as 100 euro, but is listed as the full contribution amount
![Screenshot_2021-06-02_Testdeel_contribution_Gedeeltelijk_Stichting_Onvergetelijke_Zomerkampen-balance](/uploads/9fbebc447f2cfe1b00dd6d4c9040fc33/Screenshot_2021-06-02_Testdeel_contribution_Gedeeltelijk_Stichting_Onvergetelijke_Zomerkampen-balance.png)https://lab.civicrm.org/dev/financial/-/issues/168Preparing PayPal & 3DS2023-09-15T02:08:57Zjoshjosh@civicrm.orgPreparing PayPal & 3DSIn a recent discussion with PayPal we learned about changes coming to their product line as a result of current 3DS adoption in the UK, EU and expected adoption in the future. This appears to be most relevant to merchants using PayPal Pr...In a recent discussion with PayPal we learned about changes coming to their product line as a result of current 3DS adoption in the UK, EU and expected adoption in the future. This appears to be most relevant to merchants using PayPal Pro.
Currently, merchants in the UK and EU using PayPal Pro will experience an increase in declines as a result of 3DS enforcement. While the absolute number of CiviCRM users in both areas is low to modest, there are several rather large users, so the payment volume is sizable.
PayPal Pro does not support current 3DS parameters (version 1.0) and will not support future versions (version 2.0 arrives in October iirc). In essence, PayPal Pro does not support 3DS. In fact, they are phasing it out in favor of PayPal Commerce (venmo, apple pay, etc.), which is 3DS compliant.
PayPal expects 3DS enforcement to arrive in more countries such as CA and AU next, followed (eventually, ahem) by the US.
PayPal products that do not support direct card payment, i.e. Express and Standard, are not affected.
PayPal is advising partners to notify their merchants of the impending change and is recommending that partners build integrations with PayPal Commerce (or braintree, though they recommend Commerce for nonprofit organizations).https://lab.civicrm.org/dev/financial/-/issues/167Document Support for CiviCRM from payment processors2024-03-07T16:39:04ZJoeMurrayDocument Support for CiviCRM from payment processorsDocument appropriately the support that CiviCRM receives from a variety of payment processors.
- [ ] Payment processing feature page that cites the sponsoring payment processors
- [ ] Individual payment processor pages similar to partn...Document appropriately the support that CiviCRM receives from a variety of payment processors.
- [ ] Payment processing feature page that cites the sponsoring payment processors
- [ ] Individual payment processor pages similar to partner detail pages
- [ ] Update the extension readme.md on extensions in gitlab
- [ ] Update extension pages on c.o (for as long as these will exist)
Josh has started on first two tasks as of Feb 22, 2021.
----
Original description
Document appropriately (after determining what that means ;) ) the support that CiviCRM receives from a variety of payment processors.
This might mean putting something into the info.xml or README.md of each extension, as well as adding something somewhere on c.o.
See https://github.com/agileware/cf-stripe/issues/1
@mattwire any sense of Stripe's compensation arrangements being different in Australia compared to other countries? I like the policy thrust of @justinfreeman 's comment but don't believe it is industry practice.joshjosh@civicrm.orgjoshjosh@civicrm.orghttps://lab.civicrm.org/dev/financial/-/issues/157Proposal - if payment_processor_type does not define url_site_default then do...2020-12-04T08:47:08ZeileenProposal - if payment_processor_type does not define url_site_default then do not present url_site on Processor formWhen you go to create a new processor there is a field for the site_url (& some other urls) which I generally don't think it's good to have users fill in and would rather suppress. I think it should be suppressed based on payment process...When you go to create a new processor there is a field for the site_url (& some other urls) which I generally don't think it's good to have users fill in and would rather suppress. I think it should be suppressed based on payment processor & while I could make a case for using a supportsUserDefinedUrl method I think we could get away with either
1) don't display the field if payment_processor.site_url_default is empty or
2) don't display the field is payment_processor.site_url_default is 'null' or some other magic value
We aren't currently doing any 'supports' checks on the form & it feels like this is probably something used primarily by older processors so I lean towards 1 being enough
@mattwire @KarinG @adixon @artfulrobot @andrewhunt thoughtshttps://lab.civicrm.org/dev/financial/-/issues/153Orange Paypal Pro button not redirecting properly after reCaptcha on Paypal2020-12-09T00:33:53ZStoobOrange Paypal Pro button not redirecting properly after reCaptcha on Paypal#151 related issue @eileen @seamuslee
The javascript errors are fixed but we have been able to reproduce other errors related to the reCaptcha system at Paypal.com. I am not sure if these can be fixed on CiviCRM's side or not but we sh...#151 related issue @eileen @seamuslee
The javascript errors are fixed but we have been able to reproduce other errors related to the reCaptcha system at Paypal.com. I am not sure if these can be fixed on CiviCRM's side or not but we should be aware of the following experience from user testing.
My guess is the from the Civi side we should confirm we are sending Paypal the proper auto-return URL to ensure that Paypal can find its way back to us after hitting us with the reCaptcha on their end.
In *Chrome and Safari* the Javascript errors are fixed -- when you click the Paypal button, there's no validation error requiring the user to input CC fields.
**But** when I go to Paypal, I'm asked to complete a ReCaptcha at this URL: https://www.paypal.com//cgi-bin/webscr?cmd=_express-checkout&token=EC-2JE64037K02097038. Once I complete the challenge, the page does not reload to the log-in screen. Instead it just sits with the challenge results accepted. If I then reload the page, it redirects me to the Paypal log-in page as it should at this URL: https://www.paypal.com//cgi-bin/webscr?cmd=_express-checkout&token=EC-2JE64037K02097038
In *Firefox*, the Javascript errors are fixed -- when I click the Paypal button, there's no validation error requiring the user to input CC fields. When you go to Paypal, I'm asked to complete a ReCaptcha. Once I complete the challenge, the Paypal experience is different page loads the sad dinosaur error screen "hmm we're having trouble finding that site"https://lab.civicrm.org/dev/financial/-/issues/150civicrm/payment/form url got empty currency argument in backoffice live CC form2021-07-07T08:47:08ZMonish Debcivicrm/payment/form url got empty currency argument in backoffice live CC formThis affects iATS Payments ACH/EFT payment processor which renders the payment block based on currency chosen. Here are the steps to replicate:
1. Install and enable [iATS paymentextension](https://github.com/iATSPayments/com.iatspayme...This affects iATS Payments ACH/EFT payment processor which renders the payment block based on currency chosen. Here are the steps to replicate:
1. Install and enable [iATS paymentextension](https://github.com/iATSPayments/com.iatspayments.civicrm)
2. Add and configure an iATS Payments ACH/EFT payment type payment processor.
3. Enable USD and CAD currencies
4. Go to 'Submit Credit Card Contribution' backoffice form
5. Choose payment processor created at step 2
Issue:
1. Payment block renders payment block with check template
2. Switching currency doesn't update the payment block.
For more detail discussion on MM - https://chat.civicrm.org/civicrm/pl/ixxrxhxs43r4mfyjpnf6tnwnnc
ping @KarinG @eileen @JoeMurray @seamuslee5.31.0Monish DebMonish Debhttps://lab.civicrm.org/dev/financial/-/issues/146alterPaymentProcessorParams hook and propertyBag2020-09-15T15:35:00Zmattwiremjw@mjwconsult.co.ukalterPaymentProcessorParams hook and propertyBagSee https://github.com/civicrm/civicrm-core/pull/17507#issuecomment-690213686:
> 1. pass property bag to alterPaymentProcessorParams
>
> - ✔ the hook gets to deal with sensible, known data and does not have to (re-)implement all t...See https://github.com/civicrm/civicrm-core/pull/17507#issuecomment-690213686:
> 1. pass property bag to alterPaymentProcessorParams
>
> - ✔ the hook gets to deal with sensible, known data and does not have to (re-)implement all the quirks of checking different array keys for one thing.
> - ✔ any setting the hook does in a prop bag ensures forward consistency for the next process in the chain (another hook or the main process)
> - ✖ It's possible that the reason for a hook is something pretty darn weird needs doing; in which case the raw array may be more useful.
>
> 2. pass the original array to the hook
>
> - ✖ hook has to do all work arounds
> - ✖ hook is free to implement bad practise in altering the array
> - ✔ hook can do whatever it likes.
>
> I think (1).
And example from Stripe where we're currently passing an array for compatibility (but this should not be used as a model as Stripe ignores the return values from the hook anyway).
https://lab.civicrm.org/extensions/stripe/-/blob/master/CRM/Core/Payment/Stripe.php#L484-489
// @fixme DO NOT SET ANYTHING ON $propertyBag or $params BELOW THIS LINE (we are reading from both)
$params = $this->getPropertyBagAsArray($propertyBag);
// We don't actually use this hook with Stripe, but useful to trigger so listeners can see raw params
$newParams = [];
CRM_Utils_Hook::alterPaymentProcessorParams($this, $params, $newParams);https://lab.civicrm.org/dev/financial/-/issues/145Adding "standard" params to propertyBag2020-09-16T00:42:12Zmattwiremjw@mjwconsult.co.ukAdding "standard" params to propertyBagThis came out of https://github.com/civicrm/civicrm-core/pull/18425 and https://github.com/civicrm/civicrm-core/pull/17595.
Specifically, adding "standard" parameters to propertyBag when they are already in use by a payment processor th...This came out of https://github.com/civicrm/civicrm-core/pull/18425 and https://github.com/civicrm/civicrm-core/pull/17595.
Specifically, adding "standard" parameters to propertyBag when they are already in use by a payment processor that has been converted to use propertyBag is likely to break existing implementations.
Accessing params that are later added as "standard" params to propertyBag when a payment processor is already converted internally to propertyBag (eg. most of the ones written by me Stripe, authnetecheck, Smartdebit).
Example Issues:
- authnetecheck accesses `$params['credit_card_number']` which disappears once mapped to a propertyBag because only the standardised `cardNumber` field is available.
- If authnetecheck was using `$propertyBag->getCustomProperty('credit_card_number')` it would throw an "InvalidArgumentException" because you are not allowed to use `getCustomProperty` for a "standard" property.
Similar issues will apply to any other properties that are already in use by a payment processor.
@eileen @artfulrobot @seamuslee @tottenhttps://lab.civicrm.org/dev/wordpress/-/issues/74IPN/webhook URLs should not be localized2020-09-04T10:33:07Zmattwiremjw@mjwconsult.co.ukIPN/webhook URLs should not be localizedOn a site with polylang enabled Stripe displays an error that the webhook path is not setup correctly because it returns the first, default locale URL.
Example: https://sitename.org/en/civicrm/payment/ipn/1/
But the non-localized https...On a site with polylang enabled Stripe displays an error that the webhook path is not setup correctly because it returns the first, default locale URL.
Example: https://sitename.org/en/civicrm/payment/ipn/1/
But the non-localized https://sitename.org/civicrm/payment/ipn/1/ also works as well as other locales.
Calls to `CRM_Utils_System::url()` generate a localized URL and there doesn't seem to be a way to ask for a specific locale (or default) - see https://lab.civicrm.org/extensions/mjwshared/-/blob/master/CRM/Mjwshared/WebhookTrait.php#L27
Not sure what the solution is here - @haystack @kcristiano - it causes Stripe to display errors about webhook configuration when it doesn't need to. Updating the webhook works too but is not actually necessary.https://lab.civicrm.org/dev/core/-/issues/1931Paypal Standard IPNs not being correctly handled leaving contributions as Pen...2023-06-01T19:13:12ZUpperholmePaypal Standard IPNs not being correctly handled leaving contributions as Pending (incomplete transaction)Overview
----------------------------------------
My client recently reported that payment records in CiviCRM were not being automatically marked as paid/completed despite the fact that they were successfully completed and listed in the ...Overview
----------------------------------------
My client recently reported that payment records in CiviCRM were not being automatically marked as paid/completed despite the fact that they were successfully completed and listed in the Paypal account. On investigating the issue it was clear that the IPNs were failing.
I updated the CiviCRM install to 5.27.0 to see if this would resolve the issue. It didn't. Yesterday I updated again to 5.27.4. Still no change.
The issue appears identical to this case reported on Stackexchange: https://civicrm.stackexchange.com/questions/37277/paypal-standard-payments-are-being-accepted-but-marked-as-incomplete-transaction
I tried adding the patch referred to in Eileen's comment, but it looks like the effect of that has been to remove any information from the log pertaining to the IPN.
I've double checked the IPN URL provided to Paypal. If I point my browser to this URL I get the message:
```
Failure: Missing Parameter
module
```
The CMS is Wordpress 5.3.25.31.1haystackhaystackhttps://lab.civicrm.org/dev/financial/-/issues/133Enhancements to Payment PropertyBag2021-04-12T10:46:20Zmattwiremjw@mjwconsult.co.ukEnhancements to Payment PropertyBagPayment PropertyBag was added in 5.20 but it is only when attempting conversion of payment code/processors that we find things that are missing or still need consideration. I'm adding some things here but would encourage @eileen @artful...Payment PropertyBag was added in 5.20 but it is only when attempting conversion of payment code/processors that we find things that are missing or still need consideration. I'm adding some things here but would encourage @eileen @artfulrobot and others to edit/update this description once we are in agreement.
1. The following parameters should be added:
* trxn_id -> Maps to `transactionID`.
* installments
* recur start/end dates?
2. To support a phased conversion to propertyBag we should allow exporting as an array: https://github.com/civicrm/civicrm-core/pull/17507 or similar. Alternatively we should document using reflection to access the propertyBag array eg.:
```
if ($propertyBag instanceof \Civi\Payment\PropertyBag) {
$reflectionClass = new ReflectionClass($propertyBag);
$reflectionProperty = $reflectionClass->getProperty('props');
$reflectionProperty->setAccessible(TRUE);
$params = $reflectionProperty->getValue($propertyBag)['default'];
}
else {
$params = $propertyBag;
}
```
3. Some parameters should be either be ignored or added to propertyBag in some form during `mergeLegacyInputParams` such as:
* qfKey
* entryURL
* qf_default..
Note that both `qfKey` and `entryURL` can be useful for guessing context though it would be nice if there was a better way to identify the context in which a payment processor was being used.
Eg. see https://lab.civicrm.org/extensions/stripe/-/blob/6.4.1/CRM/Core/Payment/Stripe.php#L1063 for an example of `qfKey` usage which shows that we don't really need `qfKey` but do need a more formal way of obtaining an errorURL or removing the need for it at all.https://lab.civicrm.org/dev/financial/-/issues/130Standardise payment processing2021-05-17T20:44:55ZeileenStandardise payment processingThis is a meta issue for getting more standardisation and clearer best practices in place for payment processing.
Many of our preferred practices are not new but are not clearly & consistently documented and processors that people copy ...This is a meta issue for getting more standardisation and clearer best practices in place for payment processing.
Many of our preferred practices are not new but are not clearly & consistently documented and processors that people copy are not modelling them well.
The key goals at this point are to
1) [model best practices in our core processors](https://lab.civicrm.org/dev/financial/-/issues/132)
2) ensure our docs are up-to-date on best practice
3) build a list of urls of payment processors & create tickets against them to implement the best practices
4) get payment processor writers to subscribe to this meta-issue for updates.
5) start the process of moving the unused core processors to extensions & then entirely out of core.
- done for eway, PayflowPro
6) start to add deprecation notices to functions we do not recommend. Note that these should only show on dev environments as we recommend live sites set appropriate php error level settings. We should make a decent start on 1-4 above in the next 1-2 months and then get more serious about this one
**Best practices to implement in core & promote**
1) All processors should implement doPayment and not doDirectPayment, doTransfer. In order to make this change they need to do 3 things
a) rename the existing function
b) set ```$result['payment_status_id']```
e.g ```$result['payment_status_id'] = CRM_Core_PseudoConstant::getKey('CRM_Contribute_BAO_Contribution', 'contribution_status_id', 'Completed');```
c) handle $params['amount'] == 0 (generally return at that point, setting payment_status_id)
d) throw exceptions on failure - do NOT return CRM_Core_Error
2) Handle the settings bag
Processors should make their code able to handle the settings bag. The settings bag works like an array except that
1) - some array functions don't work - eg array_merge()
2) - it standardises input.
In order to prepare processors should
1) Add the line ``` $propertyBag = PropertyBag::cast($params);``` as the first line it doPayment to ensure that they are consistently working with a propertyBag object
2) replace array functions with functions that work on the property bag - eg replace empty() checks with $params->has('recurProcessorID')
Note that we will add to this as we convert core processors & identify the difficulties.
3) Not extend BaseIPN & work to eliminate that class. currently we recommend processors implement ```handlePaymentNotification()``` rather than have an IPN class per se but the core processors don't do that. We should model 'good behaviour' in our core processors & document. Currently our core processors are a bit nasty - subtasks on this are
- Getting a clear api/ expectations for cancel & failed payments out of BaseIPN
3) Use guzzle not CURL & use GuzzleTestTrait to add tests. Note that we should focus on moving weird ones like FirstData outside of core but it's proven very easy to switch A.net over & we want to model this https://lab.civicrm.org/dev/financial/-/issues/143https://lab.civicrm.org/dev/financial/-/issues/122Offer api support for failed payments2022-10-16T08:10:45ZeileenOffer api support for failed paymentsCurrently the support we have for failed payments is on the BaseIPN class - it should be moved to the BAO / api layer. In general BaseIPN should just call apis ....
I'm thinking about what the api call should look like
I *think* what w...Currently the support we have for failed payments is on the BaseIPN class - it should be moved to the BAO / api layer. In general BaseIPN should just call apis ....
I'm thinking about what the api call should look like
I *think* what we we want is to support the following in Payment.create api/BAO
- status_id = 'Failed'
- 'is_update_contribution_status' = TRUE/ FALSE
This would add a Failed payment to the contribution and optionally (default yes I think) do all the flow on things that currently happen. If the default for is_update_contribution_status then it is closer to the current expectations.
I realise that not everyone thinks we should fail those things in all scenarios - but they feel kinda baked in & like a bigger change to address.
I also thought about using 'is_fail_contribution' - but then if we have status_id = 'Cancelled' we don't want 'is_cancel_contribution' & is a cancel the same as a fail?
As a follow on thought - we should possibly have a message template that could be sent out when a fail occurs.
@JoeMurray @mattwire @monish.debhttps://lab.civicrm.org/dev/financial/-/issues/112Add FormRule to force user to remove "&" from both "Billing First Name" and "...2019-12-19T08:39:04ZKarinGAdd FormRule to force user to remove "&" from both "Billing First Name" and "Billing Last Name" fields**Issue:**
First Name field can be filled out as e.g. "Jon & Mary";
That "&" can cause issues with Payment Processors when it's passed on as part of the Cardholder Name - resulting in rejecting properly entered Credit Card information....**Issue:**
First Name field can be filled out as e.g. "Jon & Mary";
That "&" can cause issues with Payment Processors when it's passed on as part of the Cardholder Name - resulting in rejecting properly entered Credit Card information.
Credit Card Payments with iATS Payments will get a REJ:23 failure code when the Cardholder name contains a "&" - I did some research to see if this is iATS Payments' specific, but I don't think it is.
I found e.g. CartPay -> also has error codes ERROR: 54043: "The Billing Firstname contains invalid characters."
I also found SagePay has such error codes - for every single text field actually:
```
"5037 : The Delivery Address contains invalid characters.","5037 : The Delivery Address contains invalid characters."
"5038 : The Delivery Phone contains invalid characters.","5038 : The Delivery Phone contains invalid characters."
"5039 : The Delivery City contains invalid characters.","5039 : The Delivery City contains invalid characters."
"5040 : The Billing Surname contains invalid characters.","5040 : The Billing Surname contains invalid characters."
"5041 : The Billing Firstname contains invalid characters.","5041 : The Billing Firstname contains invalid characters."
"5042 : The Billing Address1 contains invalid characters.","5042 : The Billing Address1 contains invalid characters."
"5043 : The Billing Address2 contains invalid characters.","5043 : The Billing Address2 contains invalid characters."
"5044 : The Billing City contains invalid characters.","5044 : The Billing City contains invalid characters."
"5045 : The Billing Phone contains invalid characters.","5045 : The Billing Phone contains invalid characters."
"5046 : The Delivery Surname contains invalid characters.","5046 : The Delivery Surname contains invalid characters."
"5047 : The Delivery Firstname contains invalid characters.","5047 : The Delivery Firstname contains invalid characters."
"5048 : The Delivery Address1 contains invalid characters.","5048 : The Delivery Address1 contains invalid characters."
"5049 : The Delivery Address2 contains invalid characters.","5049 : The Delivery Address2 contains invalid characters."
"5050 : The Billing Address contains invalid characters.","5050 : The Billing Address contains invalid characters."
"5051 : The Contact Number contains invalid characters.","5051 : The Contact Number contains invalid characters."
"5052 : The Customer Name contains invalid characters.","5052 : The Customer Name contains invalid characters."
"5053 : The Email Message contains invalid characters.","5053 : The Email Message contains invalid characters."
"5054 : The Cardholder Name contains invalid characters.","5054 : The Cardholder Name contains invalid characters."
"5055 : A Postcode field contains invalid characters.","5055 : A Postcode field contains invalid characters."
"5056 : The Contact Fax contains invalid characters.","5056 : The Contact Fax contains invalid characters."
```
This Image illustrates -> issue (on the left) -> no issue (on the right). Of course the checkbox for My billing address is the same as above is what copies the First Name and Last Name fields down into the Cardholder name bits. The form rule can look for "&" and then tell the user to remove it. Note the user can still leave "Mark & Karin" in the Name and Address Profile. But we would prevent it from going into the Billing details.
![image](/uploads/bd1131f6790be6d085fe3962d4017ffa/image.png)