Two components in CiviCRM are addressed solely to fundraising matters: CiviContribute, which handles donations, and CiviPledge, which is designed for pre-authorized payments or promises to make future payments. This section describes how to configure them.
As CiviContribute supports the financial aspects of the CiviEvent and CiviMember components, you will need to configure it to record or accept payments for event registrations, memberships, and subscriptions, even if your organization does not accept pure contributions but only payments in exchange for such things.
The first task in configuring CiviContribute is to turn on the component if it is not yet enabled:
Next, make sure that information about contributions is displayed in appropriate places throughout the system:
Each contribution in CiviCRM has a contribution type associated with it. The main benefit is identifying and aggregating contributions for reporting, and for entry or importing into your accounting system. Secondarily, they assist in tracking which of the funds received are deductible for tax purposes.
In order to configure it, click on Administer | CiviContribute | Contribution Types. Review the list of contribution types to see if they match your needs for reporting and accounting, then take one or more of the following actions:
Check with your bookkeeping and accounting personnel to get their perspective on what types they would like. The chart of accounts in your accounting system will have one or more revenue accounts or sub-accounts to handle the money tracked in CiviCRM. Use the Accounting Code field to match contribution types to your accounts; this is particularly important if you plan to export from CiviCRM and import into your accounting software.
As of version 3.2, only a single contribution type is associated with a payment page, unless you are including membership options and have a payment processor that supports multiple transactions. In this case, the membership fee will be recorded based on the contribution type configured with the membership type, and any additional contributions will be recorded using the contribution type associated with the page.
If you expect to set up more complex pages that accept and record payments for different types of funds, you will not be able to separate revenue associated with one of these payments into different sub-accounts. For example, an event signup page has only a single contribution type that is used for all paid items, including optional items like meals and special sessions. While your bookkeeper may need to separate these funds into different accounts for bookkeeping purposes perhaps because the meal and optional donation may not be deductible while the event fee is, CiviCRM will not natively track it as such.
If this level of fine-grained accounting separation is required by your bookkeeping, you might consider creating a contribution type to "catch" those payments that must be segmented at a later time. If you are not yet certain what your needs are, you can always leave the defaults for now, discuss it with your bookkeeper, and return at a later time to add new contribution types.
CiviCRM is also currently limited in the fact that it can only attribute a single contribution payment to memberships or event registrations. However, work is currently being done to extend the data model to accommodate partial payments and other bookkeeping and accounting enhancements. This could potentially be used to record multiple distinct payments, each with their own contribution type, against a single "purchase", such as an event registration. Watch the CiviCRM blog for more information as this functionality is developed.
CiviCRM stores information about how payments are made as payment instrument information. Payment instruments are the method of payment, such as checks, cash, EFTs (electronic funds transfers), credit cards, and debit cards. Your organization most likely does not support all of these default instruments for accepting payments.
To review and adjust payment instruments:
There is a separate interface for specifying what credit cards may be accepted (for example, Visa, Amex). Do not confuse payment instruments with individual types of credit cards. In particular, do not create a separate payment instrument for each one. Instead, do the following:
Be sure to review your payment processor options and limitations when setting up your system to confirm which card types they accept.
In order to accept payments online, CiviCRM requires you to configure a payment processor, as discussed earlier in this chapter. Different payment processors have different parameters, options, and setup instructions. To determine how to set up and test your account with specific payment processors, visit http://wiki.civicrm.org/confluence/display/CRMDOC32/CiviContribute+Payment+Processor+Configuration, click on the name of your payment processor, and follow the relevant instructions, or contact the processing company for more guidance.
In future versions, payment processor integration will be handled through an extension mechanism. You may need to search elsewhere on http://wiki.civicrm.org for the name of your payment processor as that system is implemented.
For configuring CiviCRM to work with the payment processor, follow these steps:
If you have chosen a payment processor that requires your site to have an SSL certificate, you will need to purchase and install one. If you are using a hosting provider, they are likely to suggest preferred certificates and offer installation services for a fee. If you do not have a managed hosting arrangement that provides this service, you will need to have someone with system administration skills and sufficient server access install it. The technical procedures vary between operating systems and by certificate issuing authority, and are non-trivial for those lacking system administration experience.
Low cost and mid-range SSL certificates support only a single domain or sub-domain. This includes distinguishing between the root and www form of a domain. For example, a certificate for https://www.mydomain.org
will not work for https://mydomain.org
and vice-versa. You can purchase and install certificates for both domains, or buy a higher priced wildcard certificate that covers both.
However, we highly recommend redirecting all of your website traffic to one or the other domain names and using that form consistently in your marketing materials. It can also help with session management in your CMS. You or your hosting technical people should redirect all traffic to one of the two addresses (refer them to the bottom of http://www.nurdletech.com/https.html for ideas on how to do this with two IPs on Apache servers). The redirection will mean people visiting https://www.mydomain.org
will be seamlessly redirected to https://mydomain.org
. This also works if they have a longer URL with something after the domain name, such as https://www.mydomain.org/section/page
, which will redirect to https://mydomain.org/section/page
.
Committing to a single domain form and using it consistently is important for three other reasons: it presents a more consistent branding for your organization, it improves search engine rankings by consolidating results for all ways of referring to a page, and it improves browser session management. When a user logs in to your website, they create a session which recognizes who they are to the system. That session is stored based on the website URL. If the URL changes (for example, from www
to the root form) the session may be lost. That can disrupt multi-step form processing, such as an event registration. Forcing a single "canonical" domain form will improve the reliability of session handling.
In either case, after the request for a certificate has been created and submitted, an e-mail will be sent to an address associated with the domain to be secured asking for approval to issue the certificate. Sometimes, setting up e-mail for these addresses or getting access to them can be a hassle that delays the issuance of the certificate. Check with your hosting provider or certificate issuing authority to determine the list of e-mail addresses that can be used to approve the issuance. Cheaper SSL certificates often have greater restrictions on the e-mails that can approve the certificate.
If your payment processor is not external and thus relies on your site's SSL certificate for secure transmission of sensitive account information, it is essential that you prevent non-secure access to your contribution pages that accept sensitive data like credit card numbers. Once you have tested your SSL certificate and confirmed it is working properly by accessing your site with https://mydomain.org
, you must do the following:
At this point, CiviContribute is configured and you can use it to accept online payments for donations, memberships, or events. We strongly encourage you to carry out the following:
Note that PayPal and some other payment processors have sandboxes that are more difficult to use than their production systems, so it can be faster and less problematic to just configure and test using real payments against their live servers.
It is also a good idea to have your bookkeeper review things at this point to make sure they can properly integrate online payments into your accounting procedures. Sometimes, there are issues with how payment processors batch transactions from online payments with those from point of sale terminals that can make things difficult to track. You may need to review how specific transactions stored in CiviCRM can reliably be correlated with deposits in your bank account and vice-versa. To review a report that may prove helpful in this regard, click on Reports | Bookkeeping Transactions Report.
Premiums are thank-you gifts that may be provided to donors to encourage them to donate. They are often used as an incentive to give more. For example, anyone giving $50 can receive a coffee mug with your organization's logo, while those giving $100 can choose to get a T-shirt with the logo. All premiums are specified on a site-wide basis before being enabled for particular CiviContribute pages. Constituents donating through premium-enabled contribution pages will always have the option of declining premiums. By making these gifts optional, you reduce wasted resources on unwanted premiums.
There is no need to configure premiums in order to use CiviCRM for fundraising, and if you are just getting started, you should likely focus on more essential basic functions. As particular appeals begin to make use of premiums or new premiums, you will need to configure or reconfigure your site-wide premium options before they can be enabled for particular pages. Here is how to add a premium:
You can return to add, modify, disable, or delete premiums at any time. If premiums are shared across multiple contribution pages, be sure to understand the impact of any modifications before you begin editing them.
Price sets are used to construct more complex sets of donation-level options. In most cases, you will create a simple list of donation levels and include the option for donors to enter their own custom amount. However, if you require multiple sets of options, or quantity-based purchasing, price sets can be used.
Price sets can also be used for events, which is the more common application. We will review their use in that context in a later chapter.
Price sets are also convenient for contributions when you have suggested donation levels that are re-used on different pages. For example, a Humane Society may have pages devoted to funds for different species (since cat lovers may give more if they know it will go to caring for cats and not dogs). Annual campaigns to increase donations may have price sets for different segments that get re-used from year to year. They also provide a way to increase the gift amount by offering a benefit for an additional amount. When you don't want the more complicated optional user interface of premiums, such as when selling sponsorships with different levels of included advertising and publicity opportunities, price sets may be more appropriate.
To configure a price set for contributions, follow these steps:
You are now presented with a form to add a field to the price set:
The text/numeric Quantity Input Field Type is appropriate when the user may purchase more than one of something, such as tickets for an event. Once selected, you must specify the unit Price.
If Select is specified as the Input Field Type, you are presented with rows into which you can enter the label and amount for option rows for the select drop-down box. You can also indicate which option is the Default value, uncheck rows you do not want Active, and use Weight values to indicate the order of the options. Click on another choice to display another row to enter data for additional options.
Radio and Checkbox have the same interface as Select for entering options. In addition, you can enter a value greater than 1 into options per line in order to have several options appear horizontally beside each other.
The -none- option on the radio type disappears when Required is checked for the field.
If you are using price sets on contribution pages, we recommend using the first field to lay out suggested donation levels, and additional fields to up-sell additional benefits to donors. Be sure to preview and test your price set thoroughly, paying attention to what fields are marked Required? and how the field types impact the display and flow of the form.
Much of what we have just covered will be better understood when we walk through the configuration of contribution pages near the end of this chapter. You will see how all of the tools and options described in this chapter are combined into a publicly accessible form used to solicit contributions.
CiviPledge is a CiviCRM component that supports non-enforceable commitments for recurring payments. This is different from recurring contributions that are also supported by CiviCRM, but which actually create an authorization record with the payment processor to automatically transfer funds on a recurring basis. In contrast, pledges are promises to pay a fixed amount through multiple periodic payments.
For example, your organization might encourage existing donors to increase their total annual contribution by committing to a monthly payment which you associate with a corresponding monthly need. A homeless shelter might create a campaign to "provide five meals a month" for the year. The total annual donation is $240, consisting of $20 monthly payments.
When a pledge record is created, it consists of the total committed donations and the terms of payment, that is, number of payments and frequency (12 payments of $20). It is, however, only a promise to pay. CiviCRM provides useful tools for tracking payments, sending out reminders, and providing online payment forms. As the constituent fulfills their commitment through periodic contributions, you log the payment against the pledge record and track their progress. Once all payments are received, the pledge record can be closed.
Before implementing pledge signups, you must enable the component (it is disabled by default). Click on Administer | Configure | Global Settings | Enable CiviCRM Components and move CiviPledge from the left column to the right.
You may configure automated pledge reminder e-mails that will be sent to constituents prior to the due date for their next payment. Enabling this feature is done through the Contribution Page setup, where you also indicate the form that will be used for pledges. However, you must also configure a cron job to periodically check the status and due date of individual pledge records, and trigger the e-mail. See Chapter 3, Installation, Configuration, and Maintenance for a full discussion of configuring cron jobs.