Stripe issueshttps://lab.civicrm.org/extensions/stripe/-/issues2023-10-02T14:19:45Zhttps://lab.civicrm.org/extensions/stripe/-/issues/247UX issue with Post Code (aka Zip)2023-10-02T14:19:45ZlsmithgoUX issue with Post Code (aka Zip)When a user works through an Event Registration form, they come to the payment details and the Stripe.js generated box prompts for Card Number, MM / YY and CVC
But then the Postcode is also added as an extra field which is not always ob...When a user works through an Event Registration form, they come to the payment details and the Stripe.js generated box prompts for Card Number, MM / YY and CVC
But then the Postcode is also added as an extra field which is not always obvious
They then continue through the payment form, including entering their full Billing address
When they 'Submit', an error message appears "Your postal code is incomplete". The screen focus jumps to the Billing Address where the user can see their Postcode! However, the post code is needed higher up the screen, which is not at all obvious.
You can test this behaviour on my site here:
https://breinton.com/component/civicrm/?task=civicrm/event/register&reset=1&id=130https://lab.civicrm.org/extensions/stripe/-/issues/241Incorrect Form Validation for checkboxes on profiles2023-04-04T23:23:10ZkcristianoIncorrect Form Validation for checkboxes on profilesCivi 5.28.3, mjwshared 0.8.1, firewall 1.1, sweetalert 1.3
Event Form, profile in use has 1 required field of type checkbox.
If you check none - validation error- OK, Check All - no validation error.
Check 1 Validation error an...Civi 5.28.3, mjwshared 0.8.1, firewall 1.1, sweetalert 1.3
Event Form, profile in use has 1 required field of type checkbox.
If you check none - validation error- OK, Check All - no validation error.
Check 1 Validation error and stripe highlights all options not check and sweetalert displays a message to complete required fields. Switch to another processor, no issues.
![image](/uploads/f00a71ef4337c3f9e31dfb5d99ea7148/image.png)6.5https://lab.civicrm.org/extensions/stripe/-/issues/237Zero '0' payment loads stripe payment block for multiple participant event re...2022-06-11T13:13:19ZtapashZero '0' payment loads stripe payment block for multiple participant event registrationStripe:6.4.2
civicrm: 5.27.4
When register a ZERO payment event for a single participant with a price set, stripe block does not show up. But as soon number of participant is seleceted more than 1, the payment block pops up.Stripe:6.4.2
civicrm: 5.27.4
When register a ZERO payment event for a single participant with a price set, stripe block does not show up. But as soon number of participant is seleceted more than 1, the payment block pops up.https://lab.civicrm.org/extensions/stripe/-/issues/225No credit card display in Internet Explorer 112020-09-21T12:35:01ZDevAppNo credit card display in Internet Explorer 11Internet explorer 11.
Works fine in Chrome and Edge.
JS errors, and user can't enter a credit card number.
![js_error_2](/uploads/cd0000032aff13130fcacc00fa868657/js_error_2.png)
![no_cc](/uploads/f5e9268aedeb850503e28756f6c4eedd/no_cc...Internet explorer 11.
Works fine in Chrome and Edge.
JS errors, and user can't enter a credit card number.
![js_error_2](/uploads/cd0000032aff13130fcacc00fa868657/js_error_2.png)
![no_cc](/uploads/f5e9268aedeb850503e28756f6c4eedd/no_cc.png)
![js_error](/uploads/cd34d96b3fa28d869661c33fd14092e2/js_error.png)6.5https://lab.civicrm.org/extensions/stripe/-/issues/222Selecting Pay Later after Stripe behaves wrongly on Webforms2024-01-12T05:01:04ZTony Maynard-SmithSelecting Pay Later after Stripe behaves wrongly on WebformsOn a Drupal webform, if you select Stripe, then select Pay Later and Submit the form, it goes back to the previous page rather than submitting correctly.
This is because selecting Stripe adds Event Listeners to the Submit button (severa...On a Drupal webform, if you select Stripe, then select Pay Later and Submit the form, it goes back to the previous page rather than submitting correctly.
This is because selecting Stripe adds Event Listeners to the Submit button (several places in js/civicrm_stripe.js, but the critical one appears to be submitButtonClick on Line 389), but these are not removed when a different PP is selected (should be in function notStripe(), line 265 ?). For non-Stripe PPs submitButtonClick has the effect of disabling the Submit button after it is clicked; this means that the name of the submit button is not included in the POST data sent to the server; and the webform code deliberately treats this as a click on the first button on the page, which is 'Previous Page' (for browser compatibility in other circumstances).
I suggest that this Listener should be removed when a non-Stripe PP is detected.6.4https://lab.civicrm.org/extensions/stripe/-/issues/213Only Stripe card errors should ever be shown to the user2020-09-28T10:02:08ZBradley TaylorOnly Stripe card errors should ever be shown to the userStripe has several types of error, and in the PHP library these are identified through different Exception classes:
`\Stripe\Exception\CardException`
`\Stripe\Exception\RateLimitException`
`\Stripe\Exception\InvalidRequestException`
`\S...Stripe has several types of error, and in the PHP library these are identified through different Exception classes:
`\Stripe\Exception\CardException`
`\Stripe\Exception\RateLimitException`
`\Stripe\Exception\InvalidRequestException`
`\Stripe\Exception\AuthenticationException`
`\Stripe\Exception\ApiConnectionException`
`\Stripe\Exception\ApiErrorException`
Stripe's documentation states that only CardException messages are suitable to be shown to customers, and for all other errors a generic message should be shown. (although with the exception logged for developers). This tallies with my experience - in the case of other exception types the error messages can be very technical and not user friendly.
Currently this library does not look at the type of Exception and the message is always passed to `CRM_Core_Error::statusBounce` (via `MJWTrait::handleError`).
We have noticed that this can lead to undesirable warnings being shown to the user. For example, if the paymentIntent is cancelled (by the scheduled job or manually) before the user clicks confirm, they will get a warning that the the paymentIntent could not be updated, along with a couple of sentences of technical detail about why. It would be better if a generic message was shown indicating that the payment had expired and that they should try again. Ideally different generic messages would be shown for each error type. (Although this specific case of the PaymentIntent being cancelled possibly wants its own checks too - i.e. ensure the Intent is active before trying to interact with it).
More details of error handling in Stripe can be found here: https://stripe.com/docs/api/errors/handlinghttps://lab.civicrm.org/extensions/stripe/-/issues/207Stripe payments using webforms do not record fee_amount and net_amount2023-10-02T14:11:59ZTomCrawshawStripe payments using webforms do not record fee_amount and net_amount@mattwire Hi, Don't know if this is related to #54 (closed), but we use Drupal webforms for all stripe payments, and the fee_amount and net_amount has never been calculated and stored, although everything works correctly for (test) payme...@mattwire Hi, Don't know if this is related to #54 (closed), but we use Drupal webforms for all stripe payments, and the fee_amount and net_amount has never been calculated and stored, although everything works correctly for (test) payments using a Civi contribution page. By trial and error, I found that adding the following 2 lines to CRM/Core/Payment/Stripe.php at the end of "function doPayment" worked and fee_amount and net_amount were correctly written to civicrm_contribution table.:
$params\['fee_amount'\] = $newParams\['fee_amount'\];
$params\['net_amount'\] = $params\['amount'\] - $params\['fee_amount'\];
On Drupal 7.59, Civi 5.24.2, Stripe 6.3 (and about to upgrade all 3)https://lab.civicrm.org/extensions/stripe/-/issues/193how to manage stripe notifications for regular contributions2020-10-23T14:58:16Zjamiehow to manage stripe notifications for regular contributionsI see there is a similar issue regarding recurring contributions and receipts (#160).
This one relates to regular donations and the stripe notifications. Rather then putting the customer email or name on the receipts, we are seeing the ...I see there is a similar issue regarding recurring contributions and receipts (#160).
This one relates to regular donations and the stripe notifications. Rather then putting the customer email or name on the receipts, we are seeing the name of the organization receiving the donation. This is not so helpful:
![stripe-pi](/uploads/35c1420315b69cbf6de7c99ac3a00bed/stripe-pi.png)
The group experiencing this problem had a lengthy back and forth with stripe. I'll spare us all the curt, wrong and unhelpful responses. Here as the last response which seems to get at what we might be able to do for this to go differently:
> Hope you are doing well today - Thanks for reaching out about the changes in your payment notifications. I'm happy to assist getting you pointed in the right direction and give a bit of information.
>
> First of all, I just spoke with one of my upper tier team members about your issue. He tells me that issue is when new payment intents are being made as opposed to charges, the descriptions aren't added until later.The description that you see on your emails are the charge descriptions. Since the previous charges were being made with the description in the same request, the email we sent out had a description to include in our charge notification email.
>
> Now with payment intents, when they're being made, there's no description, so when the email goes out, it just shows the payment intent ID. The description isn't added until after the email is sent out.
>
> The only real solution to this is to ask your platform integration or developer to make it so that the descriptions are added to payment intents upon creation instead of being added later.
I am having a really hard time understanding what exactly they are saying.
It sounds a little like they mean we should put the customer name in the description when creating the intent ([here?](https://lab.civicrm.org/extensions/stripe/-/blob/master/js/civicrm_stripe.js#L99) but then I would expect the name of the contribution page to be on the notification not the name of the organization.
If anyone can help decipher what Stripe means I'd be happy to take a stab at fixing it.https://lab.civicrm.org/extensions/stripe/-/issues/190Membership signup with 100% discount not passing data to confirmation2021-05-09T19:12:35ZtwjordanMembership signup with 100% discount not passing data to confirmationI have a WP + CiviCRM setup using CiviContribute to sign up members taking payment with Stripe. I have a 100% discount code for members with financial hardships.
I recently discovered that when a potential member uses the 100% discount ...I have a WP + CiviCRM setup using CiviContribute to sign up members taking payment with Stripe. I have a 100% discount code for members with financial hardships.
I recently discovered that when a potential member uses the 100% discount and tries to continue with registration, the confirmation page doesn’t contain any of their information other than email address and they cannot register. The data missing even includes the membership type.
Our form has an additional contribution option and I found that I could put $1 into that field and a valid credit card in, go to confirmation and see my data there, then “GO BACK” to the form, clear out the $1 and I would be able to finish registration with no fee.
This leads me to suspect that there is some sort of handoff that doesn’t occur when the Stripe CC entry and billing address information are not present on the form.
Any assistance would be welcome. The form is at https://parkingreform.org/join/https://lab.civicrm.org/extensions/stripe/-/issues/188Persistent PaymentIntent issue; $200 added to every transaction2020-06-20T15:56:53Zy2HYToUyPersistent PaymentIntent issue; $200 added to every transaction**CiviCRM 5.24.4/Wordpress 5.4**
I'm getting the standard system warnings about webhook API versions. Following the normal procedure (which also requires a cache refresh), I delete the current hook on the Stripe dashboard and automatica...**CiviCRM 5.24.4/Wordpress 5.4**
I'm getting the standard system warnings about webhook API versions. Following the normal procedure (which also requires a cache refresh), I delete the current hook on the Stripe dashboard and automatically create a new one. This restarts the cycle. I've attached the storyboard version for reference.
Payments either don't go through at all (literally nothing happens, as when a webhook isn't set) or, more insidiously,
* return a "paymentIntent" error
* **add exactly $200 to every amount charged**
* remain unconfirmed in Stripe![storyboard](/uploads/0f89c660aed51b702850a84a6dd5c85e/storyboard.png)https://lab.civicrm.org/extensions/stripe/-/issues/170Webhooks of type "invoice.payment_failed" failing after upgrade to CiviCRM 5....2020-06-20T15:57:59ZLsThreeWebhooks of type "invoice.payment_failed" failing after upgrade to CiviCRM 5.21.2Hi all, we ran into the issue in the title while trying to debug a separate issue where after multiple failed payments, a contribution gets a payment date of the first payment attempt upon a successful payment.
Our dev environment with ...Hi all, we ran into the issue in the title while trying to debug a separate issue where after multiple failed payments, a contribution gets a payment date of the first payment attempt upon a successful payment.
Our dev environment with the Stripe extension 6.2 was upgraded to CiviCRM 5.21.2 from 5.7.x ESR, and that's when the webhook failures began. We see the webhooks failing in the Stripe dashboard, and in the CiviCRM log, we see entries such as:
`Feb 26 00:03:26 [debug] Stripe Exception: Event: invoice.payment_failed Error: Cannot find recurring contribution for subscription ID: sub_Ex8RD6j5wj3C4f. Expected one ContributionRecur but found 0`
We believe it's due to [this change in CiviCRM 5.20](https://lab.civicrm.org/dev/financial/issues/72). Would appreciate any suggestions!6.4https://lab.civicrm.org/extensions/stripe/-/issues/167Feature: Sofort integration?2023-10-02T17:43:48ZmarkuskFeature: Sofort integration?is there any work done towards the other payment options supported by stripe? - specifically it's "[Sofort](https://stripe.com/docs/sources/sofort)" i'd be longing for (for our non-profit) and actually was the main reason why i supported...is there any work done towards the other payment options supported by stripe? - specifically it's "[Sofort](https://stripe.com/docs/sources/sofort)" i'd be longing for (for our non-profit) and actually was the main reason why i supported the make-it-happen.
any timeframe - if planned at all? otherwise i'd need to find different options..
tia,
markus.https://lab.civicrm.org/extensions/stripe/-/issues/166Payment Description - Charge vs Intent2020-06-20T15:59:00ZthirdsunPayment Description - Charge vs IntentI'm not sure if this is a bug or an enhancement, and I'm also not sure it matter to most. However, my client doesn't like that when they download a report under Reports - Balance Change from Activity, under the description field the pay...I'm not sure if this is a bug or an enhancement, and I'm also not sure it matter to most. However, my client doesn't like that when they download a report under Reports - Balance Change from Activity, under the description field the payment description doesn't show.
According to Stripe's support:
------------------
"The description field in the reports from the Reports section pulls from the charge object, and not the payment intent object.
If you were to pull an export of payments from say the main Payments section of the Dashboard, the descriptions would show as it would pull the description you had set on the payment intents when creating the payments. In order to have a description show in a report downloaded from the Reports section, you'll want to have your developer(s) run API calls to update the charge IDs[0] that would show in the event data for a payment_intent.succeeded event inside of your account.
If you have your developers list[1] out successful payment intents, they'd be able to get the ch_XXXX ID that would need to be updated for the description to then show on a report as you're expecting to see."
----------------------
So, is this working as intended, a configuration issue, or can it be updated to run the API calls needed here to translate the description from the Payment Intent to the Charge.
I barely understand what I am asking, but happy to try and provide clarification if needed. I've also informed the client that this may be an enhancement that requires funding. https://lab.civicrm.org/extensions/stripe/-/issues/159Does this extension support the credit card updating service?2021-05-09T19:11:32ZandyburnsDoes this extension support the credit card updating service?From Stripe support:
> If you want to allow customers to make future purchases without having to re-enter their information, or if you’d like to delay charging a customer for a product, you can save their card details to charge later.
>...From Stripe support:
> If you want to allow customers to make future purchases without having to re-enter their information, or if you’d like to delay charging a customer for a product, you can save their card details to charge later.
>
> In order to save a card to charge later, you’ll need to use the token Stripe generates from your customer’s card details to create a customer object instead of a one-off charge. You can then charge that customer by passing the customer ID in the charge request. If this is something that you’d like to explore further, you can find out more here:
>
> https://stripe.com/docs/saving-cardshttps://lab.civicrm.org/extensions/stripe/-/issues/147Stripe Authorises payment before form validation causing problems2021-05-09T19:10:55ZJoeMurrayStripe Authorises payment before form validation causing problems> Lot's of improvements have been made in 6.3.2 and (not yet released) 6.4. But we still need to do a lot more to make this work reliably.
> #### **MJW need funding to work on this issue - [Please contribute now to help us continue worki...> Lot's of improvements have been made in 6.3.2 and (not yet released) 6.4. But we still need to do a lot more to make this work reliably.
> #### **MJW need funding to work on this issue - [Please contribute now to help us continue working on this!](https://www.mjwconsult.co.uk/en/civicrm/pcp/info/?reset=1&id=1)**
Seems like this might be an issue. Please close immediately if it is intended behaviour. https://civicrm.stackexchange.com/questions/34012/stripe-authorises-payment-before-form-validation-causing-problems6.4jamiejamiehttps://lab.civicrm.org/extensions/stripe/-/issues/136Feature: Stripe Checkout2023-10-02T14:11:27ZverbletFeature: Stripe CheckoutMy organisation is extremely interested in the potential for CiviCRM to be integrated with Stripe Checkout.
Is this something other orgs have expressed interest in, and does that fit into the existing Stripe extension roadmap?My organisation is extremely interested in the potential for CiviCRM to be integrated with Stripe Checkout.
Is this something other orgs have expressed interest in, and does that fit into the existing Stripe extension roadmap?https://lab.civicrm.org/extensions/stripe/-/issues/134Membership + donation fails2023-12-19T21:54:55Zaydunsaidan.saunders@squiffle.ukMembership + donation failsCreate a Contribution Page for Membership with 'Contribution Amounts section enabled' ticked, and on the Membership tab 'Separate Membership Payment' ticked.
If the user purchases membership only, payment works. If they add a donation ...Create a Contribution Page for Membership with 'Contribution Amounts section enabled' ticked, and on the Membership tab 'Separate Membership Payment' ticked.
If the user purchases membership only, payment works. If they add a donation it fails with:
"This PaymentIntent's amount could not be updated because it has a status of requires_capture. You may only update the amount of a PaymentIntent with one of the following statuses: requires_payment_method, requires_confirmation.",
Tested with 6.3.alpha1 & mjwshared 0.6.beta1https://lab.civicrm.org/extensions/stripe/-/issues/123civicrm_stripe.js tries to process payment made by non-stripe processor, resu...2020-06-25T01:58:02ZFrancis (Agileware)civicrm_stripe.js tries to process payment made by non-stripe processor, results in IntegrationError- CiviCRM 5.18.4
- stripe 6.2
- mjwshared 0.5
Steps to reproduce:
1. Create a contribution page with multiple payment processors, one of them stripe
2. Load the contribution page
3. Select Stripe payment processor
4. Change your mind a...- CiviCRM 5.18.4
- stripe 6.2
- mjwshared 0.5
Steps to reproduce:
1. Create a contribution page with multiple payment processors, one of them stripe
2. Load the contribution page
3. Select Stripe payment processor
4. Change your mind and select a different one (we discovered issue with Paypal Standard)
5. Attempt to submit the form
6. → Apparently the form does nothing
In the console, you get an integration error off a message event handler by Stripe which is a bit of pain to debug (Element is not mounted), but the overall issue seems to be that civicrm_stripe.js is still handling clicks on the submit button when it shouldn't anymore.
Agileware ref CIVICRM-13496.3https://lab.civicrm.org/extensions/stripe/-/issues/112Uncaptured payment made even though form fails validation2020-01-10T22:35:50ZmikantchapUncaptured payment made even though form fails validationUncaptured payments appear in the Stripe back end even though a form fails validation in CiviCRM. These payments appear as a negative on the end users' balances for 4 working days possibly preventing further use (depending on available f...Uncaptured payments appear in the Stripe back end even though a form fails validation in CiviCRM. These payments appear as a negative on the end users' balances for 4 working days possibly preventing further use (depending on available funds).
The purchase doesn't happen in CiviCRM leading to confusion - some users see a negative on their balance and assume they have purchased successfully. If they repeat the form submission with validation error again, another uncaptured payment happens.
To reproduce, make a contribution page with at least one payment option of £0.30 (min. Stripe payment). Try to submit the form with say City and Surname fields empty. You get the usual red validation errors at the top but a Stripe payment has already happened.https://lab.civicrm.org/extensions/stripe/-/issues/104Successful Event Contribution returns to home page instead of Thank you page.2019-12-16T16:51:46ZrturnerSuccessful Event Contribution returns to home page instead of Thank you page.An event contibution is successfully saved but doesn't show the thankyou page, it skips directly to the site's home page.
Tests to compare on CiviCRM 5.16.1 didn't have the same problem.
Drupal 7.67 / CiviCRM 5.17.4 & stripe 6.1.4 - MJW...An event contibution is successfully saved but doesn't show the thankyou page, it skips directly to the site's home page.
Tests to compare on CiviCRM 5.16.1 didn't have the same problem.
Drupal 7.67 / CiviCRM 5.17.4 & stripe 6.1.4 - MJWShared 0.4.3