As I'm sure you are learning, PCI compliance is a complicated business. The payment processor (I discuss eWay below) and your own operations play the biggest role in PCI compliance. Some of the issues on the organization's end are:
your own server's security protocols (including, but not limited to, SSL)
how the payment information is transferred to the ...
I ran into this problem today, and found my solution.
Folks who are saying that you can change the IPN URL on an existing Paypal recurring payment are incorrect; you can't, you can only change the IPN URL for future notifications.
I was able to use a rewrite to redirect from Drupal to Wordpress, as follows:
No, PayPal state that SSL will not required for IPN. I contacted PayPal MTS to confirm and got the responses below:
PayPal seem to be saying
if you have SSL yourself, your certificate and its chain need SHA-256 not SHA-1 both for PayPal and modern browser support,
when you connect to their server, your webserver must accommodate their SHA-256 certificate. ...
This was removed before CiviCRM moved to git, so I browsed the old Subversion repo. I can see that revision 44887 removed it. It's present if you click the first link but not the second:
I then attempted to view the SVN log, ...
We developed the Vanco payment processor several years back and it's working through version 4.4. We are talking with Vanco about updating it; I'm fairly positive it will not work for 4.6. We should have a plan next week.
Our general strategy with payment processors is to get most of them out of core and into extensions, where they can be better maintained, so no, this is not going back into core. In fact, it's because Moneris didn't ever respond to the license questions about their mpgClasses.php file that it started falling out of core ...
I'd be happy to work with you to ...
If I'm looking at the right site, it looks like the second page of your event registration has a consistent 60 second delay added on top of the usual page generation times, and that the delay is introduced before the user is asked for payment.
Unless your payment processor requires communication before the transaction, this suggests that the issue is within ...
Omnipay should work with the latest version - but is only relevant if a processor you wish to use is currently offered through it.
If you want recurring in the US you should probably consider
in that order.
IATS is most actively developed & IATS has been investing in Civi development itself & the other 2 have the most ...
CiviPledges can be set up so that
- a logged in contact can see their upcoming Pledges on their dashboard
- a contribution page can be set up as a self-service payments page
I set one up on the Drupal demo site so it should be there for a few hours before it flushes.
Dashboard is here
Setting up a pledge is here
The self-service payment is here but ...
In CRM/Contribute/Form/ContributionBase.php(349) the system is not able to determine the name of your payment processor. Please check:
that you at least one payment processors configured
that all payment configured processors have a 'name' defined and not empty
that at least one of your payment processors is set as 'default'
since the chosen payment ...
Mike, that URL is not needed. Just complete the top 4 lines (userID, password, site URL, API URL)
You do need to send Vanco the URL of the VancoHistory.php file so that they can send recurring notifications on that URL.
Hope this helps
The issue is that the SSL certificate provided by your transaction processor is untrusted by your OS (or by the certs available to cURL).
The solution for a missing CA is -
to ensure the presence of correct CA certificates to cURL by installing system CA updates, or
to retrieve an old copy of the correct CA and make it available to cURL if the one used by ...
PayPal stores these URLs so there is no way to change this in CiviCRM, nor any other application in fact.
There is a way to change the URL via PayPal's site, however. For details how to do that, refer to Change the IPN url on existing subscription
It looks like there is experimental code available on Github for a Worldpay processor, which might need further development.
You may also want to explore the Omnipay extension. It doesn't list Worldpay on the extension page yet, but there is a driver for Worldpay with Omnipay that may just need some testing and/or minor tweaks to get running with CiviCRM ...
Could you create a new contact with just a first and last name (no address, phone, or anything else that might go in a separate table somewhere) and then change that new contact's ID in the database to 1212? Then you could merge again, making sure to keep the new contact and transfer all of the other information over during the merge. (Try on a copy of the ...
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 ...
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 ...
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 ...
Partial payment from the front end is not yet available in CiviCRM, but it can be done through the extension described in this CiviCON presentation "Front End Partial payments"
It's avaialble in Github.
Your use case is similar to this situation:
What will be the way to give user public access to check their contribution?
There are many ways to do this. 2 easiest
1) Change the name of the payment processor in /civicrm/admin/paymentProcessor
The problem with this approach is it becomes less clear to you the administrator.
2) A *hack*, go to your current registration page where the radio buttons to choose payment processor appear. Find the < div > tag that encompasses ...
You can commission an extension, using the Core-Team or a Partner/Contributor. I suggest you set up a issue in the issue tracker first to see if the Core Team can give you an estimate.
You should also look at the other payment processor extensions, the folks who wrote them are most likely to be able do another, they should also be rewarded for their ...
Unless William has addressed your "Bank Transfer" question, and you actually mean you want users to pay by entering their bank details, often known as ACH transfer.
You will need a merchant that allows that, an example post on this: https://civicrm.org/blogs/adixon/iats-next-generation-payment-processor-acheft
The link William provided indicate IATS and ...
I don't think there is a payment processor the will do what you want, it needs to be handled on the CiviCRM side.
If you create a price set with the membership fee as one field and the contribution amount as second field, you assign different financial types to each component of the transaction. So although it looks like one contribution, the amount for ...
This is likely to be a resource URL issue - the way these fields are calculated has changed in CiviCRM 4.7.
Please look at Administer menu » System Settings » Resource URLs and Administer menu » System Settings » Directories. Please ensure that both of these look correct. Note that you might see a token (e.g. [cms.root]) as part of your URLs and paths - ...