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:... Read more
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...
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...Read more
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...Read more
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.
The installation is more involved than other...Read more
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:
I would love to get feedback from anyone who would like to participate or later use the new module.
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.
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.... Read more
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...Read more
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.