9
Stripe Checkout is not implemented at this time, but I would love to add it in the future.
Source: I am the maintainer of CiviCRM Stripe integration.
5
Getting your site back online, in phpmyadmin:
In table civicrm_extension, enable stripe (change 0 to 1)
In table payment_processor, disable any using stripe (change 1 to 0)
This should allow your site to load.
Deleting stripe (warning: stripe may be related to some transactions, check before doing this):
Make sure none of your donation pages are using ...
5
You need to login to the stripe dashboard and disable the webhook. It has nothing to do with the CiviCRM side.
5
Yes, The new webhook url should be https://www.example.com/civicrm/payment/ipn/1 where 1 is the payment processor ID.
Cheers
Pradeep
5
I think the new version tries to create the webhook automatically. Maybe if it already exists in the Stripe account it can't create it -- have you tried deleting the webhooks in the Stripe account and then using the "Fix Stripe Webhook" (civicrm/stripe/fix-webhook) page in CiviCRM to regenerate it?
4
As promised, here are our experiences with Stripe Version 1.9.1 | CiviCRM 4.6.8 | Drupal 7:
We are using it on CiviCRM contribution pages for memberships
In order for the pay later option to work we needed to fix an issue
Afaik the fix has not been integrated with the Stripe master branch - our version can been found here.
Apart from the pay later problem ...
4
We use Stripe with CiviCRM 4.6.4 on Drupal 7's latest rev and are not having issues. We grabbed the latest Civi Stripe library from github.
So far we have only processed event registrations, not membership payments or other contributions. We haven't tried processing payments via WebForms, only regular civicrm event registration pages.
We had one ...
4
We are using Stripe with 4.4.14 and had problems accepting payments for memberships using a webform. With investigation though, our developer installed a version of Stripe 1.9.1 from the github and the latest dev build of webform and it is now working for us.
Whether anything within 4.5/4.6 has changed to make our experience irrelevant, that I can not ...
4
I am not sure if CiviCRM Stripe pp extension supports ACH(https://github.com/drastik/com.drastikbydesign.stripe/issues/124). They might have beta version which is not released yet.
4
I would follow the instructions on screen:
Log in to your Stripe account, go to the Webhooks section
Delete the existing webhook (on live and testing sides)
Come back to CiviCRM and use the "Update/Create Webhook" button
3
I had a similar issue, not sure if it's the same but I applied this patch to correct:
https://github.com/drastik/com.drastikbydesign.stripe/pull/249/files
3
There is a long thread at https://github.com/drastik/com.drastikbydesign.stripe/issues/76 on this issue. It was for earlier versions but might give you some clues. I have a site using Stripe successfully with webforms on Civi 4.6
3
I found out there is a fork of the Stripe payment plugin for Civi 5.X. This fixed my issue. Can be found here:
https://github.com/mattwire/com.drastikbydesign.stripe
3
Many of these "lost session" issues (which stem mainly from redirect_canonical correcting CiviCRM's malformed URLs) are solved in more recent versions of CiviCRM. All I can really do is suggest you upgrade. FWIW, you can pick through the PRs that deal with URLs here:
https://github.com/civicrm/civicrm-core/pulls?q=is%3Apr+author%3Achristianwach+is%3Aclosed
...
3
The answer is that I had pasted one of the Stripe API keys with a trailing blank, so when I looked at Firefox's web developer console there was a message 'Your key is invalid as it contains whitespace' Working consistently now, but how I previous managed to make a couple of contributions successfully I don't understand!
3
Turned out to be a problem with my Resource URL paths. Changed from the relative CiviCRM URL variables to absolute paths.
3
You would need to reach out to Paypal and Stripe directly to ask them about how to initiate the process of transferring your recurring giving. I would suggest inventorying your existing recurring records in Paypal first, to see how complex the data is; in a recent transition to Stripe, we encountered some challenges with constituents who had multiple ...
3
This was due to an unused Payment Processor which had no API key.
Deleting this Payment Processor fixed the issue.
3
There's a new requirement listed in the Stripe CiviCRM documentation for version 6.0. You also need the MJWShared extension.
3
I believe this is correct behaviour.
The flow with Stripe is slightly opaque due to the complexity of maintaining a level of PCI compliance while using a CiviCRM form for payment.
The credit card part of the form is actually an iframe hosted with Stripe (that's what allows for the PCI compliance trick), which will take the credentials and test them by ...
3
The most common approach to reconciliation is to update contributions within the CRM with the identifier from the payment processor. For Stripe we have a few approaches, our most recent is the payout reference from Stripe is automatically pulled back into CiviCRM. This allows the finance departments to run a payout report from both systems and reconcile. ...
3
In general, auto-recurring memberships are generated via an auto-recurring payment, whose mechanism depends on the payment processor, and most especially on whether the recurring payment schedule is managed by CiviCRM or the processor.
When the schedule is managed by CiviCRM, you have more direct control and could for example use some sql to just push ...
2
This seems to be a long-standing issue with the Stripe processor, and from what I can tell (and from what I have experienced), in some cases this extension doesn't play well with other payment processors (including the "pay later" option).
Try disabling Paypal (and Pay Later, if applicable) and then test Stripe again.
See also:
https://github.com/drastik/...
2
This has been fixed now. If you get the latest version of the Stripe extension's code from Github, you will have email receipts for recurring contributions.
2
CRM-15629 produces similar symptoms with certain configurations of PayPal. Also, please update your question with a CiviCRM version?
2
I think Stripe through the Omnipay extension is not working at the moment. We are looking into Stripe as well and will wait for the regular extension to be updated like Parvez mentioned.
2
You can not use the checkout option for stripe if you are using it with CiviCRM.
As far as I'm concerned, you can use only direct payment option in stripe while making payment in CiviCRM.
Please refer a function doTransferCheckout() from link: https://github.com/drastik/com.drastikbydesign.stripe/blob/4.6-dev/CRM/Core/Payment/Stripe.php#L665
it says, ...
2
Have you looked at this extension: Stripe Payment Processor?
I haven't used it myself so perhaps others can comment on how well it works.
There is also this related post: Has anyone tried Stripe payments through OmniPay?
2
It was a Stripe Payment Extension issue. I thought I was on the latest version but must have been a few commits back. Updating the files to the latest 4.6-dev version and then visiting the Manage Extensions page to run database updates was all I needed.
2
Hi I can confirm the same behaviour. We are on Drupal 7, CiviCRM 5.19.4 and the problem is that the Billing address profile seems to be ignored for the dedupe rules. You must create a new profile with all fields needed for dedupe rule and include it in page. The billing address name and first name is not used.
Only top voted, non community-wiki answers of a minimum length are eligible
