As part of the Google Grants program for non-profits, Google offers their Google Checkout service to qualifying non-profits at no-charge with no processing fees. Depending on the fees you would pay with a competing processor this represents an instant 3% jump in your organization's fundraising efforts just by using Google Checkout.

The only limitation has been recurring donations. To address this Google launched Google Subscriptions and now we need to get support into CiviCRM so we can enjoy a single free processing fee payment gateway.

A new Make it Happen iniative was launched to get this going in 4.1 or even 3.4 if we meet the campaign goal soon! A donation to this iniative will easily pay itself back by the savings in processing fees. This initiative is already 70% there with donations from Powered by Action and the International Mountain Bicycling Association (IMBA):

    http://civicrm.org/mih#google

Check the forum discussion for more info:

    http://forum.civicrm.org/index.php/topic,18290.0/topicseen.html

We've just started a make it happen for UK direct debit integration - something that lots of UK non profits have been asking for and we are happy to provide :)

The fabulous Eileen will be carrying out the work and we are aiming to raise the total amount needed by August 15 in time for her trip to the UK so we can spend some time kick starting it all.

So if direct debit is important to you or your clients, please step up and help us reach the goal amount.

The requirements and specification are being developed on the wiki.  The spec. will be finalised before work commences based on requirements expressed by contributors and we can't garuntee to fulfill all requirements so please discusss any specific questions you have with us before adding requirements to the page and contributing to this MIH.

We have a couple of customers who have been asking to be able to set-up recurring contributions against pledges. This seems to be a possibly contentious improvement so I'm looking for feedback on it.

These organisations in question deal with lots of pledges (they solicit them by phone) and they record them in CiviCRM. Some of them are paid off by cheques, & some by credit card. Usually they try to get a commitment to set up a recurring credit card contribution & here's where they are struggling with CiviCRM. CiviCRM won't let you record a recurring credit card contribution against a pledge.

We have hacked out CiviCRM 3.4.7 / 4.0.7 install to meet their needs but obviously if we are going to move to 4.1 then we want to know we have a way to manage that.

There are 2 main reasons why they want recurring payments against pledges:

1) Because they want the same reporting for all their pledges no matter how they are paid
2) Because the pledge may be paid by different mechanisms over it's lifetime.

The scenario we have is

Someone pledges to pay $20 for month for 3 years. They agree to set up a recurring contribution against it for the first 6 months (until the credit card expires). At that point they send in a cheque for the next couple of months & one the following one they provide a new credit card for the rest of the pledge.

We have removed the code that hides recurring payment options when submitting a pledge payment. This means that the first payment is recorded against the pledge & is a trivial tpl tweak.

We've also tweaked the BaseIPN code so that when each payment comes in IF another payment in that recurring payment subscription has been treated as a pledge payment then the new one is treated as a payment against that pledge too. This seems to make sense as we are looking at a situation where there might be more than one recurring payment subscription for a single pledge but a recurring payment subscription only ever goes against one pledge.

I had some thoughts about how to deal with validation (ie. rules for when payments don't match) but the concern the core team has is actually whether it's a good idea at all.

As Dave put it "we're a bit hesitant about this because in prior discussions folks indicated that Pledges and Recurring Contributions were different animals and should be kept separate due to differences in how they're supposed to be "accounted".

So, I guess the question I want to ask is whether there is good reason not to go down this path in CiviCRM core (our customers are committed to the path so that's not in question).

As an aside, Authorize.net supports payments with a future start date when you are using recurring payments - even if there is only one installment. The tpl tweak allows us to set-up post-payday payments against a pledge.

Direct Debit, is easy, convenient and safe. It is the UK’s favourite way to make payments automatically, and there has been a Make It Happen for Direct Debit Integration.

Notice to non-developers: This post is about how some functionality in 4.2 will be implemented in code and in the database, with very minor changes to anything visible through a browser. If you're not a developer, it probably won't interest you.

Simplifying the Codebase

As part of the CiviAccounts project we are looking to redo some of the implementation of the configuration and processing of payments for contributions, memberships, and events. Currently the processing for each of these three types of objects has two paths: one for a simple configuration of the objects, and one using price sets. This means there is more code, more complexity, more possibility of errors, more work when making changes, and more need for testing.

As we refactor the existing code we're looking at keeping the simplified UI for configuration and administration, but implementing everything under the hood using price sets. Before going ahead with that, we wanted some feedback from developers in the community.

Price sets are now supported for contributions, events, and memberships. You can use them to sell individual or multiple tickets at a time, items along with memberships and subscriptions, or allow contributors to determine how much to give / buy using text/numeric fields, select widgets, radio buttons, or checkboxes. Support for contributions on the same form the same as ticket purchases, and for contributions along with membership purchases is facilitated with price sets. They will be a good way to implement a page that allows people to get a discount on their annual membership if they buy a ticket to an event, though I haven't seen that yet.

One change that CiviAccounts will be making to price sets is allowing each option to be associated with a different general ledger account. This would allow, for example, revenue for one type of ticket to go into one account while revenue for a different type of ticket would go into a second account in your bookkeeping system.

The downside of price sets is that they are time consuming to create, and can be confusing for non-techies or new admins. First the price set needs to be created; then each of the fields within it; and within some file types, options can be specified. Lots of steps, clicks, page refreshes, and not intuitive how it will turn out for many CiviCRM admins.

By contrast, it's possible to enter the Fixed Contribution Options directly on the Contribution Amounts tab when configuring a Contribution Page, or select the Membership Types to sell on a page in the Membership Settings tab.

The Regular Fees section on the Fees tab when configuring an Event is just as simple. These simple configuration pages are equivalent to specifying a radio widget option field in a price set, without the complexity or flexibility provided by certain options.

We think it would be good to allow admins to continue to use the simplified interfaces and have the option of the power and flexibility that comes with the complexity of the full price set UI.

Proposed UI Change

In addition, we think it _might_ make sense to allow admins to switch from the simple configuration of a page to editting that information via the more complex price set configuration forms. But not the other way - going from complex to simple.

What's this mean in practical terms? Once any change has been saved to a configuration as a price set, even one that includes only one radio button field, the simple configuration approach for the contribution page or event would not be available for editting it. This would prevent confusion in various ways, e.g. from not seeing in the simplified form a change on the complex forms that was changing the behaviour of the field behaviour. Of course, you could turn off the price set you just created, and go back to the simplified UI and start configuring it from scratch again.

Proposed API

We would expect the price set api to follow our existing structure with an API to get, delete, create each of the Price set entities – Price sets, fields, values and for hooks to be called PRE & POST the main CRUD functions on these entities. The buildForm hook & validate hook are already available for editing price sets. We would probably discontinue the buildAmount.
For API users the change is beneficial with regards to interacting with events. At the moment it is extremely difficult to create events through the api as you also have to create an option group & option values to go with it. More problematically you can’t re-use the same event prices to create a new event via the api so this makes api creation of events much easier (and the eventual implementation of a front end event import option.) It is also currently hard to GET event prices through the API. This is likely to still require the use of API chaining but the chain will be a little more intuitive. Contribution Pages do not yet have an API & the issues are likely to be similar but most sites seem to create many events but only a few contribution page so the relevance is more for events.

Feedback?

Comments or concerns about these change would be appreciated.

A member sends several separate payments to cover outstanding dues on a single purchase, like an expensive membership or a table at an event. How are you going to record this?

A conference participant selects “Pay Later” on several different event registrations, and later wants to pay them all in a single credit card transaction.  How are you going to support this?

Current versions of CiviCRM don't offer a way to record multiple payments against a single obligation, or to split one payment among multiple obligations, but the CiviAccounts project is working to allow this flexibility.  Work on data structure improvements has been going on for some time; it's part of a broad effort to help CiviCRM's financial data to be more compatible with QuickBooks and other accounting software packages, and it lays the groundwork for lots of possibilities, including more flexible payment processing.

Over at the CiviAccounts “Flexibile User Payments” wiki page, we're discussing UI improvements for both end-users/constituents and staff/back-office users.

If your clients or your organization have a use for these features, please chime in and voice your opinion on ways to improve what we're proposing.

Areas of improvement:

1. Configuration:

Any contribution page or event registration page can be configured to allow partial payment. This replaces the current “Pay Later” option, basically allowing configuration of a minimum initial payment, down to $0.00. If partial payments are not allowed, the user will need to pay the full amount upon submitting the contribution/registration.

2. Submitting partial payments in the back-office forms:

When staff record a new event registration / membership / contribution, they'll be able to record a partial initial payment, and then later record subsequent payments until the total amount has been paid. We're debating the notion of using one form for the initial record and for subsequent payments, vs. using an entirely separate interface for applying subsequent payments to outstanding obligations.

3. Splitting payments among multiple unpaid contributions, in the back-office:

Any time staff record a payment received in the back-office, they'll have the option of applying it to one or more outstanding obligations, such as partially paid memberships or event registrations.

4. For the end-user, paying down my unpaid contributions:

The end-user needs a way to see her own unpaid obligations, and then to submit payment against one or more of them. We're proposing to add a new “My unpaid contributions” section to the user dashboard, listing all the contributions where the total paid amount is less than the total contribution amount. From this section, the user can select any one item to pay, or can select a link to make one online payment that will be split among multiple items.

Some ideas you may want to opine upon:

1. How important is it to support a configuration option to enable/disable these features sitewide, so as to simplify the workflow for organizations that don't need them? And would such a configuration default to enabling or disabling these features?

2. Is it better to have one form for back-office staff to enter both new payments and payments against outstanding obligations (namely, the “New/Edit Contribution” form), or instead to add an additional form dedicated to applying payments against outstanding obligations?

3. Naturally, all the stuff we may have forgotten, especially if you have specific use cases that will not be well covered by these changes.

The CiviAccounts Flexible User Payments wiki page is waiting for your visit. Please give it a moment and let us know (prefereably in the wiki comments, or else on this blog page) how well these changes meet your needs.

My name is Mark, I run a small consulting Firm in Vancouver Canada. I have been working with CiviCRM since 2009 and have implemented customized solutions with it for 7+ clients. I have several clients who use CiviCRM and CiviContribute and at the end of each year there is always a moment where they mention their wish list to be able to generate a CRA [Canada Revenue Agency] compliant tax receipt for each of their Contributors. The benefit of CiviCRM is that it brings together all the appropriate information for a contact to be mailed/emailed and contributions for any given year. What CiviCRM could not do was:

• Give an aggregate of all a contacts contributions for any given year in a receipt form.
• Provide a PDF export in a fashion that was compliant with federal tax standards.
• Print a letter addressed to the donor with the tax reciept attached
• Email a link to the donor with thier reciept available for download.

We turned to Hershel from CiviHosting as he is our host and primary developer and asked for assistance. He provided us with a custom Drupal module called CiviReceipts. CiviReceipts gives us the ability to list all donors within a given year and then send each a tax compliant receipt. We can do this via email or print out the PDFs locally and snail mail them. It also gives the ability to customize the letterhead and content of the letter attached to the receipt. So each year we are able to add any appropriate notations to the donors. We also have the ability to sort donors by those who received a receipt by email or PDF. The module has some other functions as well, that we aren't using. What we are hoping to develop in the future

1. A secondary report that can record the receipt numbers used for submission to CRA
2. A way of classifying NON-Tax Receiptable donations in CiviReceipts as thank you's only.

The module is now available publicly here and it requires also the TCPDF module here.  Both of these modules are open source but come with no warranty of any sort, nor any guaranteed support. I hope however that they will be of use to someone and if any other developers are able to generalize this module and share it further, please feel free to and keep us updated.

I am starting a project that will allow CiviCRM to support the needs of an Australian non-profit. This non-profit is subject to the Australian Goods & Services Tax rules (GST) for some but not all transactions.

The GST requirements apply whenever the non-profit provides a tangible good or service in exchange for a payment. This is most common with their dinners, selling DVDs, and items from their gift shop. 

 I have written up the requirements and possible approaches on the CiviCRM wiki at:

http://wiki.civicrm.org/confluence/display/CRMDOC41/Taxes+and+Fees+for+CiviCRM

I would love to get feedback from anyone who would like to participate or later use the new module. 

- Sarah

Vanco Payment processor

BackOffice Thinking is pleased to release the Vanco payment processor to the CiviCRM community.  Today we are releasing versions for 3.4x and 4.1x and hope to have a 4.2x version shortly.

This processor allows single payment and recurring for credit cards and ACH (electronic check)

The Vanco payment processor is quite popular among religious organizations and we have been utilizing this processor for past 2 years with many of our clients.  Thanks for all the support from the Vanco team along way.

The files, including detailed instructions, can be downloaded here.

Vanco 3.3 and 3.4

Vanco 4.1

The installation is more involved than other processors because of ACH capabilities.  We look forward to your feedback.

If you are using Authorize.net as your payment processor (or your clients are) for either one-time payments or automated recurring payments, then my guess is that like me you probably dread the phone call from a bookkeeper such as

"I found some Authorize.net transactions that went through and the money is in the bank, BUT there is no record of the contribution in CiviCRM.  What happened?"

Researching these types of issues is very challenging because Authorize.net will never resend a Silent Post URL message, and the logging in CiviCRM about each message ( processed normally, or in error) is rather thin.     As a tool to help research these issues, Pogstone Inc. created an enhanced logging feature where every silent post URL message is immediatly logged to a database table and a text file, before the message is processed.    We also created a new custom search to query the new table.  You can download the files needed HERE.     You will need to use the SQL file to create the new database table, then put the file "AuthorizeNetIPN.php" in the folder "CRM/Core/Payment" in your custom civicrm code folder. And you will need to register the new custom search.

Warning: The message from Authorize.net includes the last 4 digits of the credit card number and the card type (such as Visa/Mastercard/Amex).  I have no idea if this is allowed to be stored according to PCI rules. If you do not want this data stored, make sure you do NOT log "x_account_number" or "x_card_type" anywhere.

What I have noticed based on the data logged so far:  

- When there is a failed one-time transaction, Authorize.net does send the message. However, this is not recorded as a "contribution" by CiviCRM.

- Authorize.net usually sends the CiviCRM contact ID, but not always.  

What I am thinking as next steps:

 - Creating a scheduled job that processes this new log file, and creates a contribution record for each transaction where one does not already exist in CiviCRM. (If the transaction failed, then the contribution status will be failed.)  This would include transactions associated with subscriptions.

- If its allowable under PCI rules, store the card type and last 4 digits of the credit card on the contribution record. This info is extremely helpful for the bookkeeping staff for bank reconciliation and communicating with members/donors about credit card issues.

Would like to hear from anyone else using Authorize.net about what issues they have, and thoughts on next steps.

Once this is done, it seems like the current CiviCRM code in "AuthorizeNetIPN" that processes each message could be eliminated, as its now redundant.     Also, this new approach will be MUCH easier to debug and troubleshoot, and have as part of an automated regression testing suite.

SEPA stands for “Single Euro Payment Area”: Mix in a little bit of Standardisation, a pinch of Europe and a truck load of Bank processes; add a bit of XML, stir for decades and don't forget to pour in copious amounts of meetings full of white middle aged men all wearing grey suits. What you get is a scrumptious recipe guaranteed to insure that almost no one in the NGO community is going to be remotely involved or interested.

Until now that is. Because SEPA might be the solution you are looking for:

• allows your members to automatically pay their fees on time

• get more donors contributing small monthly amounts

• makes it easy to let donors give an extra contribution when they like

• makes it easier to raise money from supporters in other European countries (more than 30 countries use it)

All the while you are paying much lower fees to the credit card providers and spending less of your precious admin time on dealing with payments.

With SEPA, it's so cheap to set up a direct debit that you can afford to do it even for an amount as low as a few euros per month.

Four providers in Germany, France and Belgium have teamed up to integrate SEPA into CiviCRM and we have already found enough users to cover the cost of most of the development.

Project60, as our group is called, is working on:

• Creating a new SEPA Payment Processor (allowing both single and recurring contributions)

• Generating the SEPA mandate (the document that your supporter needs to sign to authorise the direct debit)

• Storing all the needed information (IBAN, BIC...)

• Generating the needed files in the proper format to transmit to the bank to process the debits.

In short, all you need to benefit from cheap direct debit.

Detlev Sieber from digitalcourage told me than more than 80% of all member fees and donations come through the existing EVL Direct Debit System in Germany. This system is extremely easy to handle and associated with very low fees - for non-profits, most german banks even process the regular transactions free of any charge. By February 2014, the current system will be replaced by SEPA Direct Debit. This will extend the advantages of Direct Debit all over Europe, but forces many german organisations to upgrade their fundraising systems... or would give them the opportunity to switch to CiviCRM.

German users have a deadline to migrate to SEPA but banks all around Europe are ready to use it today. If you are a CiviCRM user, you should consider contributing financially to the make it happen to fund its integration with CiviCRM.

In order to get their CiviCRM implementations ready for this change, the association "Software für Engagierte", which was founded by 7 German NGO's, takes part in the implementation of the CiviCRM extensions for SEPA DD and banking import. Their president, Ronald Pabst from Democracy International “If enough additional funding comes in, we want to create a solution which not only fits for our special requirements, but can be published as an extension usable for any CiviCRM user“

We have started to work on it already, we will have a first version ready before the summer and if enough of you contribute, a fully fledged extension and a handbook to make it easier for you to set up all the complete SEPA Direct Process with your bank and civicrm will be available on Q4.

Sebastian Baijard explained "At wikimedia France, we contributed to fund SEPA integration with civicrm to be able to offer our supporters an option to contribute monthly. Beside a more sustainable and predictable income, the processing costs are going to be vastly reduced. If you are in Europe and do fundraising, you should contribute to this make it happen too".

I suggest you to estimate how much monthly donations of a few euros you could get and add that to how much you spend processing your membership fees. That's how much money your organisation isn't getting.

Each year.

Consider giving a small percentage of this amount to the make it happen so you can finally handle in a cost efficient way these contributions. You'll make civicrm stronger in Europe, not to mention making your organisation more sustainable.

With the introduction of CiviAccounts in CiviCRM 4.3 the ground work to allow CiviCRM to cater for Tax against contributions has been laid.

During the week-long sprint in northern California following CiviCon, we've been working through the design and amendments required to complete the implementation of Tax within CiviCRM.

The specification can be found on the wiki

In short we've tried to ensure basic but powerful tax rules are to be built into CiviCRM Core, with additional hooks for users who need to implment specific rules.

Core functionality will include

• Different tax rules per financial type
• Multiple Taxes being applied to a single transaction e.g. State Tax and City Tax
• Ledger lines produced representing the break down in tax charged

So out of the box you'll be able to

• Charge Tax(s) on memberships
• Charge Tax(s) on Events
• Control Tax(s) at item level i.e. Event Fee 20% Tax, Meal for event 10% Tax, Child Care for event 0% Tax
• Export Liability ledger transactions to your finance system

Using Hooks you'll be able to

• Change the tax rules based on contact region
• Change the tax rules based on any other information

Please take a look at the wiki page and provide any feedback.

Thanks

Parvez

I have previously blogged (http://civicrm.org/blogs/sarahgladstone/fun-and-joy-authorizenet-code-attached) and chatted about (http://forum.civicrm.org/index.php/topic,29234.0.html)  about the fun and joy related to supporting automated recurring transactions in a production environment, and started the process of restructuring that portion of the code.   I have made much more progress and have been using the code attached on production for about 2 weeks now.   I think this approach (which I have implemented for Authorize.net) makes a good model for any payment processor that offers automated recurring contributions.  You can download the code (works with version 4.3.4) HERE

My primary goals were as follows:

1) Auditability.   In a production environement it is essential to have a history of all key communication with a third-party system.  This should be easily searchable by an administrator or other authorized person.  

2) Testability.  It must be possible to test the core functionality without involving the third-party payment processing system or a web browser. 

3) Repeatable, For example: If a message gets handled improperly (such as a bug in the API, some other issue that messes up the resulting contribution) it should be possible to delete the generated contribution record, and re-create it based on the data from the payment processor message log table. 

My secondary goals:

4) Standardize core behavior accross various payment processors that offer automated recurring payments.  Simpilfy creation of new payment processors. 

5) Eliminate what my clients consider odd accounting for automated recurring payments in light of 4.3.x.   In 4.3, any "pending/pay later" status contributions  show as a tranaction in the "Accounts Receivable" Financial Account. When this contribution status is updated to "completed" another transaction is created to represent the movement from Accounts Receivable to the Asset Financial Account. (In this case the Payment Proccessing Account).   With a one-off contribution,this is the proper and expected behavior.  However, with automated recurring contributions this creates oddness for the bookkeeper. For example: They set up an automated recurring contribution of $200 per month for 12 months. (From the bookkeeper's point of view, the person "owes" $2400. ) After the first 6 payments are completed, the bookkeeper will observe that the first installment of $200. was handled as a "receivable" (because of the result of it switching from pending to completed) but none of the other installments are treated that way.  So in the code I wrote ALL installments are treated uniformly: As a contribution that started out in the "completed" status. What I do is create a brand-new completed contribution for the first installment, then delete the original pending contribution.  ( The other option I thought about was treating the entire $2400 as a receivable, then reducing the Accounts Receivable by $200 each month. But this idea seemed much more complex to implement) 

Looking forward to getting feedback on the code and ideas here. 

Direct Debit, is easy, convenient and safe. It is the UK’s favourite way to make payments automatically, and there has been a Make It Happen for Direct Debit Integration.

Notice to non-developers: This post is about how some functionality in 4.2 will be implemented in code and in the database, with very minor changes to anything visible through a browser. If you're not a developer, it probably won't interest you.

Simplifying the Codebase

As part of the CiviAccounts project we are looking to redo some of the implementation of the configuration and processing of payments for contributions, memberships, and events. Currently the processing for each of these three types of objects has two paths: one for a simple configuration of the objects, and one using price sets. This means there is more code, more complexity, more possibility of errors, more work when making changes, and more need for testing.

As we refactor the existing code we're looking at keeping the simplified UI for configuration and administration, but implementing everything under the hood using price sets. Before going ahead with that, we wanted some feedback from developers in the community.

Price sets are now supported for contributions, events, and memberships. You can use them to sell individual or multiple tickets at a time, items along with memberships and subscriptions, or allow contributors to determine how much to give / buy using text/numeric fields, select widgets, radio buttons, or checkboxes. Support for contributions on the same form the same as ticket purchases, and for contributions along with membership purchases is facilitated with price sets. They will be a good way to implement a page that allows people to get a discount on their annual membership if they buy a ticket to an event, though I haven't seen that yet.

One change that CiviAccounts will be making to price sets is allowing each option to be associated with a different general ledger account. This would allow, for example, revenue for one type of ticket to go into one account while revenue for a different type of ticket would go into a second account in your bookkeeping system.

The downside of price sets is that they are time consuming to create, and can be confusing for non-techies or new admins. First the price set needs to be created; then each of the fields within it; and within some file types, options can be specified. Lots of steps, clicks, page refreshes, and not intuitive how it will turn out for many CiviCRM admins.

By contrast, it's possible to enter the Fixed Contribution Options directly on the Contribution Amounts tab when configuring a Contribution Page, or select the Membership Types to sell on a page in the Membership Settings tab.

The Regular Fees section on the Fees tab when configuring an Event is just as simple. These simple configuration pages are equivalent to specifying a radio widget option field in a price set, without the complexity or flexibility provided by certain options.

We think it would be good to allow admins to continue to use the simplified interfaces and have the option of the power and flexibility that comes with the complexity of the full price set UI.

Proposed UI Change

In addition, we think it _might_ make sense to allow admins to switch from the simple configuration of a page to editting that information via the more complex price set configuration forms. But not the other way - going from complex to simple.

What's this mean in practical terms? Once any change has been saved to a configuration as a price set, even one that includes only one radio button field, the simple configuration approach for the contribution page or event would not be available for editting it. This would prevent confusion in various ways, e.g. from not seeing in the simplified form a change on the complex forms that was changing the behaviour of the field behaviour. Of course, you could turn off the price set you just created, and go back to the simplified UI and start configuring it from scratch again.

Proposed API

We would expect the price set api to follow our existing structure with an API to get, delete, create each of the Price set entities – Price sets, fields, values and for hooks to be called PRE & POST the main CRUD functions on these entities. The buildForm hook & validate hook are already available for editing price sets. We would probably discontinue the buildAmount.
For API users the change is beneficial with regards to interacting with events. At the moment it is extremely difficult to create events through the api as you also have to create an option group & option values to go with it. More problematically you can’t re-use the same event prices to create a new event via the api so this makes api creation of events much easier (and the eventual implementation of a front end event import option.) It is also currently hard to GET event prices through the API. This is likely to still require the use of API chaining but the chain will be a little more intuitive. Contribution Pages do not yet have an API & the issues are likely to be similar but most sites seem to create many events but only a few contribution page so the relevance is more for events.

Feedback?

Comments or concerns about these change would be appreciated.

A member sends several separate payments to cover outstanding dues on a single purchase, like an expensive membership or a table at an event. How are you going to record this?

A conference participant selects “Pay Later” on several different event registrations, and later wants to pay them all in a single credit card transaction.  How are you going to support this?

Current versions of CiviCRM don't offer a way to record multiple payments against a single obligation, or to split one payment among multiple obligations, but the CiviAccounts project is working to allow this flexibility.  Work on data structure improvements has been going on for some time; it's part of a broad effort to help CiviCRM's financial data to be more compatible with QuickBooks and other accounting software packages, and it lays the groundwork for lots of possibilities, including more flexible payment processing.

Over at the CiviAccounts “Flexibile User Payments” wiki page, we're discussing UI improvements for both end-users/constituents and staff/back-office users.

If your clients or your organization have a use for these features, please chime in and voice your opinion on ways to improve what we're proposing.

Areas of improvement:

1. Configuration:

Any contribution page or event registration page can be configured to allow partial payment. This replaces the current “Pay Later” option, basically allowing configuration of a minimum initial payment, down to $0.00. If partial payments are not allowed, the user will need to pay the full amount upon submitting the contribution/registration.

2. Submitting partial payments in the back-office forms:

When staff record a new event registration / membership / contribution, they'll be able to record a partial initial payment, and then later record subsequent payments until the total amount has been paid. We're debating the notion of using one form for the initial record and for subsequent payments, vs. using an entirely separate interface for applying subsequent payments to outstanding obligations.

3. Splitting payments among multiple unpaid contributions, in the back-office:

Any time staff record a payment received in the back-office, they'll have the option of applying it to one or more outstanding obligations, such as partially paid memberships or event registrations.

4. For the end-user, paying down my unpaid contributions:

The end-user needs a way to see her own unpaid obligations, and then to submit payment against one or more of them. We're proposing to add a new “My unpaid contributions” section to the user dashboard, listing all the contributions where the total paid amount is less than the total contribution amount. From this section, the user can select any one item to pay, or can select a link to make one online payment that will be split among multiple items.

Some ideas you may want to opine upon:

1. How important is it to support a configuration option to enable/disable these features sitewide, so as to simplify the workflow for organizations that don't need them? And would such a configuration default to enabling or disabling these features?

2. Is it better to have one form for back-office staff to enter both new payments and payments against outstanding obligations (namely, the “New/Edit Contribution” form), or instead to add an additional form dedicated to applying payments against outstanding obligations?

3. Naturally, all the stuff we may have forgotten, especially if you have specific use cases that will not be well covered by these changes.

The CiviAccounts Flexible User Payments wiki page is waiting for your visit. Please give it a moment and let us know (prefereably in the wiki comments, or else on this blog page) how well these changes meet your needs.

My name is Mark, I run a small consulting Firm in Vancouver Canada. I have been working with CiviCRM since 2009 and have implemented customized solutions with it for 7+ clients. I have several clients who use CiviCRM and CiviContribute and at the end of each year there is always a moment where they mention their wish list to be able to generate a CRA [Canada Revenue Agency] compliant tax receipt for each of their Contributors. The benefit of CiviCRM is that it brings together all the appropriate information for a contact to be mailed/emailed and contributions for any given year. What CiviCRM could not do was:

• Give an aggregate of all a contacts contributions for any given year in a receipt form.
• Provide a PDF export in a fashion that was compliant with federal tax standards.
• Print a letter addressed to the donor with the tax reciept attached
• Email a link to the donor with thier reciept available for download.

We turned to Hershel from CiviHosting as he is our host and primary developer and asked for assistance. He provided us with a custom Drupal module called CiviReceipts. CiviReceipts gives us the ability to list all donors within a given year and then send each a tax compliant receipt. We can do this via email or print out the PDFs locally and snail mail them. It also gives the ability to customize the letterhead and content of the letter attached to the receipt. So each year we are able to add any appropriate notations to the donors. We also have the ability to sort donors by those who received a receipt by email or PDF. The module has some other functions as well, that we aren't using. What we are hoping to develop in the future

1. A secondary report that can record the receipt numbers used for submission to CRA
2. A way of classifying NON-Tax Receiptable donations in CiviReceipts as thank you's only.

The module is now available publicly here and it requires also the TCPDF module here.  Both of these modules are open source but come with no warranty of any sort, nor any guaranteed support. I hope however that they will be of use to someone and if any other developers are able to generalize this module and share it further, please feel free to and keep us updated.

I am starting a project that will allow CiviCRM to support the needs of an Australian non-profit. This non-profit is subject to the Australian Goods & Services Tax rules (GST) for some but not all transactions.

The GST requirements apply whenever the non-profit provides a tangible good or service in exchange for a payment. This is most common with their dinners, selling DVDs, and items from their gift shop. 

 I have written up the requirements and possible approaches on the CiviCRM wiki at:

http://wiki.civicrm.org/confluence/display/CRMDOC41/Taxes+and+Fees+for+CiviCRM

I would love to get feedback from anyone who would like to participate or later use the new module. 

- Sarah

Vanco Payment processor

BackOffice Thinking is pleased to release the Vanco payment processor to the CiviCRM community.  Today we are releasing versions for 3.4x and 4.1x and hope to have a 4.2x version shortly.

This processor allows single payment and recurring for credit cards and ACH (electronic check)

The Vanco payment processor is quite popular among religious organizations and we have been utilizing this processor for past 2 years with many of our clients.  Thanks for all the support from the Vanco team along way.

The files, including detailed instructions, can be downloaded here.

Vanco 3.3 and 3.4

Vanco 4.1

The installation is more involved than other processors because of ACH capabilities.  We look forward to your feedback.

If you are using Authorize.net as your payment processor (or your clients are) for either one-time payments or automated recurring payments, then my guess is that like me you probably dread the phone call from a bookkeeper such as

"I found some Authorize.net transactions that went through and the money is in the bank, BUT there is no record of the contribution in CiviCRM.  What happened?"

Researching these types of issues is very challenging because Authorize.net will never resend a Silent Post URL message, and the logging in CiviCRM about each message ( processed normally, or in error) is rather thin.     As a tool to help research these issues, Pogstone Inc. created an enhanced logging feature where every silent post URL message is immediatly logged to a database table and a text file, before the message is processed.    We also created a new custom search to query the new table.  You can download the files needed HERE.     You will need to use the SQL file to create the new database table, then put the file "AuthorizeNetIPN.php" in the folder "CRM/Core/Payment" in your custom civicrm code folder. And you will need to register the new custom search.

Warning: The message from Authorize.net includes the last 4 digits of the credit card number and the card type (such as Visa/Mastercard/Amex).  I have no idea if this is allowed to be stored according to PCI rules. If you do not want this data stored, make sure you do NOT log "x_account_number" or "x_card_type" anywhere.

What I have noticed based on the data logged so far:  

- When there is a failed one-time transaction, Authorize.net does send the message. However, this is not recorded as a "contribution" by CiviCRM.

- Authorize.net usually sends the CiviCRM contact ID, but not always.  

What I am thinking as next steps:

 - Creating a scheduled job that processes this new log file, and creates a contribution record for each transaction where one does not already exist in CiviCRM. (If the transaction failed, then the contribution status will be failed.)  This would include transactions associated with subscriptions.

- If its allowable under PCI rules, store the card type and last 4 digits of the credit card on the contribution record. This info is extremely helpful for the bookkeeping staff for bank reconciliation and communicating with members/donors about credit card issues.

Would like to hear from anyone else using Authorize.net about what issues they have, and thoughts on next steps.

Once this is done, it seems like the current CiviCRM code in "AuthorizeNetIPN" that processes each message could be eliminated, as its now redundant.     Also, this new approach will be MUCH easier to debug and troubleshoot, and have as part of an automated regression testing suite.