Stripe issueshttps://lab.civicrm.org/extensions/stripe/-/issues2021-05-09T19:12:35Zhttps://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/189mix of getElementId and input[name=...] causes error on membership contributi...2020-05-04T15:17:50Zjamiemix of getElementId and input[name=...] causes error on membership contribution page with autorenew set to automaticThe error is:
`TypeError: document.getElementById(...) is null`
And the culprit seems to be in this block:
```
else if ($('input[name="auto_renew"]').length !== 0) {
if ($('input[name="auto_renew"]').prop('checked')) {
isRe...The error is:
`TypeError: document.getElementById(...) is null`
And the culprit seems to be in this block:
```
else if ($('input[name="auto_renew"]').length !== 0) {
if ($('input[name="auto_renew"]').prop('checked')) {
isRecur = true;
}
else if (document.getElementById('auto_renew').type == 'hidden') {
isRecur = (document.getElementById('auto_renew').value == 1);
}
else {
isRecur = Boolean(document.getElementById('auto_renew').checked);
}
}
```
Specifically this line: `else if (document.getElementById('auto_renew').type == 'hidden') {`
The page in question does not have any elements with `id=auto_renew` but does have ones with `input[name="auto_renew"]` (and it's a hidden field) so the first if condition fails (not a checkbox) and the second condition throws the error.
I think the answer is to use `input[name="auto_renew"]` throughout the block. Unless there is a situation in which the input name exists but we have to use the element id to get the value? I know CiviCRM sometimes does weird things to allow people to de-select radio buttons which involve hidden fields. Thoughts? We could keep both the getElementById and the name business if we carefully wrap them to check for non null values.6.4https://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/1872x copy of receipt sent for recurring payments.2020-06-01T12:00:10Ztapash2x copy of receipt sent for recurring payments.It appears that the receipt for a recurring payment is sent to donors twice with the latest version of the extension. Is there a quick fix?It appears that the receipt for a recurring payment is sent to donors twice with the latest version of the extension. Is there a quick fix?6.4https://lab.civicrm.org/extensions/stripe/-/issues/186Support for Stripe API 2020-03-02?2020-04-27T15:39:59ZKeith NunnSupport for Stripe API 2020-03-02?I have a client who is a little slow in their upgrade cycle and is still on Stripe API 2018-07-27. That version is, of course, not supported by the most recent Stripe extension to CiviCRM. No problem, except that I can't get Stripe to le...I have a client who is a little slow in their upgrade cycle and is still on Stripe API 2018-07-27. That version is, of course, not supported by the most recent Stripe extension to CiviCRM. No problem, except that I can't get Stripe to let me use 2019-12-03. My only choices are their most recent API version 2020-03-02 or the old version they were on.
Just wondering if support for the latest version is in the cards? Reading their changelog seems to suggest they didn't change much, but the Stripe extension is pretty unhappy right now whichever way I go.6.4https://lab.civicrm.org/extensions/stripe/-/issues/185Check Stripe Webhook Endpoint Signatures2020-06-20T15:56:39ZcapoCheck Stripe Webhook Endpoint SignaturesAs of today, a call can be made to the IPN url posting information about a given payment to attempt completing it. But there is an easy way to increase security by checking Stripe keys.
> Stripe can optionally sign the webhook events it...As of today, a call can be made to the IPN url posting information about a given payment to attempt completing it. But there is an easy way to increase security by checking Stripe keys.
> Stripe can optionally sign the webhook events it sends to your endpoints by including a signature in each event’s Stripe-Signature header. This allows you to verify that the events were sent by Stripe, not by a third party.
Source: [Verify the events that Stripe sends to your webhook endpoints](https://stripe.com/docs/webhooks/signatures#verify-official-libraries)
## How To Implement It
Actually, the Stripe PHP library already includes Stripe public keys, so in principle, the roadmap would be:
1. **Store the webhook secret as a payment processor paramenter**
The Stripe API returns a `secret` when a webhook endpoint is created but only during its creation:
> The endpoint’s secret, used to generate webhook signatures. Only returned at creation.
Source: [The webhook endpoint object](https://stripe.com/docs/api/webhook_endpoints/object)
This means that when the webhooks are registered by the extension itself, we could automatically configure the webhook endoint secret and therefore activate checking the signature.
If the webhook isn't registered by the extension, it could still be as easy as adding the endpoint secret to the payment processor settings.
2. **Add at a call like this one at the beginning of the IPN main method**
```php
// Set $endpoint_secret (whsec_...) from the payment processor
$endpoint_secret = $this->getEndpointSecret($paymentProcessorID);
// Check the signature
try {
$event = \Stripe\Webhook::constructEvent(
@file_get_contents('php://input'),
$_SERVER['HTTP_STRIPE_SIGNATURE'],
$endpoint_secret
);
} catch(\Stripe\Exception\SignatureVerificationException $e) {
$this->exception('Invalid Stripe signature');
}
```
## Benefits
A part from the obvious security improvement, checking signatures would also allow us trusting the information that comes with every Stripe event and, therefore, we could apply policies such as creating missing data entities where we are currently throwing exceptions (for instance: no [contribution |payment | subscription] found, etc).https://lab.civicrm.org/extensions/stripe/-/issues/184Stripe won't process the payment if total amount is modified by any other hook.2020-09-28T10:08:19ZjitendraStripe won't process the payment if total amount is modified by any other hook.This all relates to the paymentintent submitted by the stripe extension within the js code https://lab.civicrm.org/extensions/stripe/-/blob/master/js/civicrm_stripe.js#L96
So if total amount submitted by the contribution page is modifie...This all relates to the paymentintent submitted by the stripe extension within the js code https://lab.civicrm.org/extensions/stripe/-/blob/master/js/civicrm_stripe.js#L96
So if total amount submitted by the contribution page is modified by any other hook in any extension, stripe won't process the payment as it will mismatch with the amount submitted by the js code.
The error returned by the processor is
>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."
Should stripe be able to handle that situation? Since other extensions follow the valid process of using civicrm hooks(postprocess etc) => modify the amount submitted by the contribution page and expect it to work fine.https://lab.civicrm.org/extensions/stripe/-/issues/183Recurring webhooks are failing - 400 (Bad Request)2020-06-20T15:55:09ZlarynRecurring webhooks are failing - 400 (Bad Request)I was notified that webhooks on a small site are failing. It appears to be only recurring webhooks that are failing with a **400 Bad Request**. I'm not sure if it may be related to the firewall extension as this seems a different issue (...I was notified that webhooks on a small site are failing. It appears to be only recurring webhooks that are failing with a **400 Bad Request**. I'm not sure if it may be related to the firewall extension as this seems a different issue (but I do see **400 Bad Request** in the screenshot): https://lab.civicrm.org/extensions/stripe/-/issues/179https://lab.civicrm.org/extensions/stripe/-/issues/182Failed subscription payment, receipt sent, but contribution not updated when ...2021-03-02T09:40:24ZtapashFailed subscription payment, receipt sent, but contribution not updated when retriedAlthough a subscription payment fails, a receipt gets sent to the donor as if its completed. Which becomes confusing for donor.Although a subscription payment fails, a receipt gets sent to the donor as if its completed. Which becomes confusing for donor.6.5https://lab.civicrm.org/extensions/stripe/-/issues/181Would there be an option for customer to update their card details when it ex...2020-09-28T10:09:38ZtapashWould there be an option for customer to update their card details when it expires?@mattwire When subscription payment created using a card, at some point that card will expires, as a result there will be repeated failed payments? I haven't seen any option in the receipt either. Would stripe send a notification to the...@mattwire When subscription payment created using a card, at some point that card will expires, as a result there will be repeated failed payments? I haven't seen any option in the receipt either. Would stripe send a notification to the customer to update the card details when it nearest to expiring date? Otherwise, a lot of manual adjustments, call etc would be involved if there are many subscriptions.
I remember, with paypal pro there was options for customer to update their card details using a link on the receipt. Is there a plan to implement something like this in near future? Thanks.https://lab.civicrm.org/extensions/stripe/-/issues/180Postal code always disabled2020-04-26T21:10:09ZfinalfreqPostal code always disabledIf a user is trying to use a card that isn't associated with their address, they can't seem to edit the zip code, it always appears as a disabled text input. Is there a way to make the field editable.
![image](/uploads/c4d2da8c326fbdae...If a user is trying to use a card that isn't associated with their address, they can't seem to edit the zip code, it always appears as a disabled text input. Is there a way to make the field editable.
![image](/uploads/c4d2da8c326fbdaec9a6e9dda785ee5d/image.png)6.4https://lab.civicrm.org/extensions/stripe/-/issues/179Firewall Extension is blocking payment2022-07-01T09:38:56ZtapashFirewall Extension is blocking payment@mattwire Follwoing up from issue https://lab.civicrm.org/extensions/firewall/-/issues/3#note_33673
I have updated to 6.4 b3 and Mjwshared 0.7b2 and still not able to proceed to donation confirmation page with the following error on Chr...@mattwire Follwoing up from issue https://lab.civicrm.org/extensions/firewall/-/issues/3#note_33673
I have updated to 6.4 b3 and Mjwshared 0.7b2 and still not able to proceed to donation confirmation page with the following error on Chrome when firewall extension was enabled.
![Screenshot_2020-03-26_at_08.20.36](/uploads/bf4e175635bcb0037fb9982bd7143f02/Screenshot_2020-03-26_at_08.20.36.png)https://lab.civicrm.org/extensions/stripe/-/issues/178Register recurring contribution(subscription) in webform with a specific freq...2020-05-30T15:54:57ZrubofvilRegister recurring contribution(subscription) in webform with a specific frequency- Give the possibility to add recurring contribution(subscription in Stripe) including the frequency in Drupal webform.
- Image configuring the "Contribution" tab in webform
![image](/uploads/78d7850f08eb0cfbb09ff979995d551d/image.png)
...- Give the possibility to add recurring contribution(subscription in Stripe) including the frequency in Drupal webform.
- Image configuring the "Contribution" tab in webform
![image](/uploads/78d7850f08eb0cfbb09ff979995d551d/image.png)
- Currently is available with "Installments" but not with interval "Interval of Installments"
https://lab.civicrm.org/extensions/stripe/-/blob/6.4/js/civicrm_stripe.js#L6096.4https://lab.civicrm.org/extensions/stripe/-/issues/177Webhooks created for earlier API?2020-03-26T00:04:00ZdgbdgbWebhooks created for earlier API?I'm using Stripe Payment Processor 6.3.2, MJWShared 0.6 on Civicrm 5.23.2 with Wordpress Multisite.
I've used the Wizard to instal webhooks in Stripe.
I'm now getting a warning in CiviCRM System Status "Webhook API version is set to 20...I'm using Stripe Payment Processor 6.3.2, MJWShared 0.6 on Civicrm 5.23.2 with Wordpress Multisite.
I've used the Wizard to instal webhooks in Stripe.
I'm now getting a warning in CiviCRM System Status "Webhook API version is set to 2020-03-02 but CiviCRM requires 2019-12-03. To correct this please delete the webhook at Stripe and then revisit this page which will recreate it correctly. Webhook path is: https://xxx.xxxx,com/?page=CiviCRM&q=civicrm/payment/ipn/2."
If I delete the webhooks on the Stripe Dashboard, the Wizard can again be used to instal webhooks, but the same warning message comes up.6.4https://lab.civicrm.org/extensions/stripe/-/issues/176Refund of a contribution is recorded twice, results in contact owing money2020-03-22T00:40:23ZrichardsplaygroundRefund of a contribution is recorded twice, results in contact owing moneyI am cancelling many events and having to refund lots of contributions. When I open a contribution record in order to deal with it, initially I just see a contribution with its associated Stripe unique id. So far, so good.
![1](/upload...I am cancelling many events and having to refund lots of contributions. When I open a contribution record in order to deal with it, initially I just see a contribution with its associated Stripe unique id. So far, so good.
![1](/uploads/1f8f07ed0e728c349b3d5f46a1447523/1.png)
Now I go into the Stripe dashboard, search for that unique ID and refund it. Back in CiviCRM, it looks like the Stripe extension has noticed that a refund was made, because it shows up in a line item. But the contribution record itself is still marked "Completed". So it is basically active in CiviCRM even though in Stripe and in my bank account the money is gone.
![2](/uploads/af69ce1a4a323c58579958476e0325da/2.png)
So now I mark the contribution as "Refunded". Now when you look in CiviCRM, the contribution record is properly marked as refunded and no longer shows in the user's contributions year-to-date totals, but there are 3 rows for the contribution: one original contribution and two refunds.
![3](/uploads/3267978659c92d45e366dc12d310c346/3.png)
This seems to be a problem, because after doing this, the event registration shows the participant owing double, instead of zero. Marking the registration as cancelled does not change this.
![4](/uploads/db2089be18073d5208a507386de301ca/4.png)
Civi 5.21.1 with Stripe Extension 6.32 and MJW Shared 0.6.
Thank youhttps://lab.civicrm.org/extensions/stripe/-/issues/175conflict with CiviRules causes "Expected one Contribution but found 0" ?2020-03-18T15:39:32ZAllenShawconflict with CiviRules causes "Expected one Contribution but found 0" ?This is cross-posted with the CiviRules issue [conflict with Stripe causes "Expected one Contribution but found 0" ?](https://lab.civicrm.org/extensions/civirules/issues/68), as I'm not sure who should "claim" this problem.
This site ha...This is cross-posted with the CiviRules issue [conflict with Stripe causes "Expected one Contribution but found 0" ?](https://lab.civicrm.org/extensions/civirules/issues/68), as I'm not sure who should "claim" this problem.
This site has been running CiviRules and Stripe for a good while now, including a CiviRule on the trigger "Contribution is added", with no issues.
However, when using a rule on the trigger "Recurring Contribution is added" and the action "Set the Financial Type for a Contribution", we have problems: When a user submits a recurring contribution using Stripe, the below-provided error and backtrace is given. (And if we disable the CiviRule, users can successfully submit recurring contributions through that same contribution page.)
Do you have any idea what's going here?
```
CiviCRM_API3_Exception: "Expected one Contribution but found 0"
#0 /var/www/domains/redacted.example.com/html/wp-content/uploads/civicrm/ext/mjwshared/CRM/Core/Payment/MJWTrait.php(500): civicrm_api3("Contribution", "create", (Array:3))
#1 /var/www/domains/redacted.example.com/html/wp-content/uploads/civicrm/ext/stripe/CRM/Core/Payment/Stripe.php(627): CRM_Core_Payment_Stripe->endDoPayment((Array:72), (Array:2))
#2 /var/www/domains/redacted.example.com/html/wp-content/uploads/civicrm/ext/stripe/CRM/Core/Payment/Stripe.php(506): CRM_Core_Payment_Stripe->doRecurPayment((Array:72), 97, Object(Stripe\Customer), Object(Stripe\PaymentMethod))
#3 /var/www/domains/redacted.example.com/html/wp-content/plugins/civicrm/civicrm/CRM/Contribute/BAO/Contribution/Utils.php(173): CRM_Core_Payment_Stripe->doPayment((Array:71))
#4 /var/www/domains/redacted.example.com/html/wp-content/plugins/civicrm/civicrm/CRM/Contribute/Form/Contribution/Confirm.php(2311): CRM_Contribute_BAO_Contribution_Utils::processConfirm(Object(CRM_Contribute_Form_Contribution_Confirm), (Array:71), "28876", "60", 0, "1")
#5 /var/www/domains/redacted.example.com/html/wp-content/plugins/civicrm/civicrm/CRM/Contribute/Form/Contribution/Confirm.php(692): CRM_Contribute_Form_Contribution_Confirm->processFormSubmission("28876")
#6 /var/www/domains/redacted.example.com/html/wp-content/plugins/civicrm/civicrm/CRM/Core/Form.php(479): CRM_Contribute_Form_Contribution_Confirm->postProcess()
#7 /var/www/domains/redacted.example.com/html/wp-content/plugins/civicrm/civicrm/CRM/Core/StateMachine.php(144): CRM_Core_Form->mainProcess()
#8 /var/www/domains/redacted.example.com/html/wp-content/plugins/civicrm/civicrm/CRM/Core/QuickForm/Action/Next.php(45): CRM_Core_StateMachine->perform(Object(CRM_Contribute_Form_Contribution_Confirm), "next", "Next")
#9 /var/www/domains/redacted.example.com/html/wp-content/plugins/civicrm/civicrm/packages/HTML/QuickForm/Controller.php(203): CRM_Core_QuickForm_Action_Next->perform(Object(CRM_Contribute_Form_Contribution_Confirm), "next")
#10 /var/www/domains/redacted.example.com/html/wp-content/plugins/civicrm/civicrm/packages/HTML/QuickForm/Page.php(103): HTML_QuickForm_Controller->handle(Object(CRM_Contribute_Form_Contribution_Confirm), "next")
#11 /var/www/domains/redacted.example.com/html/wp-content/plugins/civicrm/civicrm/CRM/Core/Controller.php(335): HTML_QuickForm_Page->handle("next")
#12 /var/www/domains/redacted.example.com/html/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php(268): CRM_Core_Controller->run((Array:3), NULL)
#13 /var/www/domains/redacted.example.com/html/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php(68): CRM_Core_Invoke::runItem((Array:15))
#14 /var/www/domains/redacted.example.com/html/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php(36): CRM_Core_Invoke::_invoke((Array:3))
#15 /var/www/domains/redacted.example.com/html/wp-content/plugins/civicrm/civicrm.php(1449): CRM_Core_Invoke::invoke((Array:3))
#16 /var/www/domains/redacted.example.com/html/wp-content/plugins/civicrm/includes/civicrm.basepage.php(349): CiviCRM_For_WordPress->invoke()
#17 /var/www/domains/redacted.example.com/html/wp-includes/class-wp-hook.php(288): CiviCRM_For_WordPress_Basepage->basepage_handler(Object(WP))
#18 /var/www/domains/redacted.example.com/html/wp-includes/class-wp-hook.php(312): WP_Hook->apply_filters(NULL, (Array:1))
#19 /var/www/domains/redacted.example.com/html/wp-includes/plugin.php(544): WP_Hook->do_action((Array:1))
#20 /var/www/domains/redacted.example.com/html/wp-includes/class-wp.php(742): do_action_ref_array("wp", (Array:1))
#21 /var/www/domains/redacted.example.com/html/wp-includes/functions.php(1255): WP->main("")
#22 /var/www/domains/redacted.example.com/html/wp-blog-header.php(16): wp()
#23 /var/www/domains/redacted.example.com/html/index.php(17): require("/var/www/domains/redacted.example.com/html/wp-blog-header.php")
#24 {main}
Sorry, due to an error, we are unable to fulfill your request at the moment. You may want to contact your administrator or service provider with more details about what action you were performing when this occurred.
Expected one Contribution but found 0
```https://lab.civicrm.org/extensions/stripe/-/issues/174Is it possible to create a subscription payment on stripe dashboard manually ...2020-05-30T16:49:00ZtapashIs it possible to create a subscription payment on stripe dashboard manually connected to a civicrm contact?Like the title says,
Is it possible to create a subscription payment on stripe dashboard manually and connect that to a CiviCRM contact, so a payment is created CiviCRM and receipt is sent?
I was thinking by adding metadata on the strip...Like the title says,
Is it possible to create a subscription payment on stripe dashboard manually and connect that to a CiviCRM contact, so a payment is created CiviCRM and receipt is sent?
I was thinking by adding metadata on the stripe dashboard?
Thankshttps://lab.civicrm.org/extensions/stripe/-/issues/173Unable to complete payment! Missing paymentIntentID.2020-07-17T08:18:11ZstevenphamUnable to complete payment! Missing paymentIntentID.Hello,
We have a donation page running CiviCRM 5.22.1 and Stripe 6.3.2
Currently, Live Payment is not working, but Test Payment is working normally.
Every time we submit a donation, we receive a message "Unable to complete payment! Miss...Hello,
We have a donation page running CiviCRM 5.22.1 and Stripe 6.3.2
Currently, Live Payment is not working, but Test Payment is working normally.
Every time we submit a donation, we receive a message "Unable to complete payment! Missing paymentIntentID" and in the backend, its status is "Pending (Incomplete Transaction)".
I'm testing it in chrome in incognito mode, "Stripe Javascript debugging" is ON
Please give advice about what I need to do to solve this problem. Thankshttps://lab.civicrm.org/extensions/stripe/-/issues/172Card element doesn't get destroyed when an anonymous session changes payment ...2020-06-25T01:58:02ZcapoCard element doesn't get destroyed when an anonymous session changes payment processor## Steps to reproduce
This issue is related but not the same as #123, and the steps to reproduce it are similar:
1. create a contribution page with a Stripe payment processor by default and at least another one of a different type,
2. ...## Steps to reproduce
This issue is related but not the same as #123, and the steps to reproduce it are similar:
1. create a contribution page with a Stripe payment processor by default and at least another one of a different type,
2. open the contribution page with an anonymous session,
3. switch to the other payment processor and try to complete the payment.
This was reproduced in a system that was using Stripe 6.3.2 and MJWShared 0.6 over CiviCRM 5.16.3. The additional payment processor was Smart Debit 1.35.
### The issue
The issue is related with permissions to run the API `PaymentProcessor` from an anonymous session, in particular, [here](https://lab.civicrm.org/extensions/stripe/-/blob/a09be1f5420eda4b1b317f1464e53809e7ca0278/js/civicrm_stripe.js#L182):
```js
CRM.api3('PaymentProcessor', 'getvalue', {
"return": "user_name",
"id": paymentProcessorID,
"payment_processor_type_id": CRM.vars.stripe.paymentProcessorTypeID,
})
```
#### The expected behaviour
When switching to the alternative payment processor, if JavaScript debugging is enabled, this messages are expected to be shown:
```
civicrm_stripe.js: payment processor changed to id: 5
civicrm_stripe.js: New payment processor is not Stripe, clearing CRM.vars.stripe
civicrm_stripe.js: destroying card element
```
#### The unexpected behaviour
If the test form is sent with an administrative session, the previous messages are shown. But if the form is sent with an anonymous session, only the first of them is shown, as the process gets stopped when the API call is done:
```
civicrm_stripe.js: payment processor changed to id: 5
```
### A proposal
I've prepared a [pull request](https://lab.civicrm.org/extensions/stripe/-/merge_requests/100) where the public keys of active Stripe payment processors are directly published as JavaScript variables as `CRM.vars.stripe_keys`.
The change also includes a change in `civicrm_stripe.js` son the API call described above is removed as it's no longer needed.6.4https://lab.civicrm.org/extensions/stripe/-/issues/171Translating this extension2020-05-30T16:53:46ZlarnoultTranslating this extensionHello! Thanks for this great extension :smile:
I was wondering if it was possible to translate it (in French for exemple). Thanks.Hello! Thanks for this great extension :smile:
I was wondering if it was possible to translate it (in French for exemple). Thanks.