One of the mini-projects that we worked on during our San Francisco meetup / code sprint was improving the way name and address data is handled during payment transactions (e.g. online contributions, membership signup and event registration). Our goals were:
- Prevent name, email address and postal address information collected during a payment transaction from over-writing existing "non-billing-related" data.
- Store the billing name and address info for EACH transaction - so that it can be retrieved for audit / reconciliation purposes.
- Set a foundation for a more "shopping-cart" style interface where logged in users can select from a set of previously used billing locations.
We iterated through a number of ideas for how to meet these goals - and settled on the idea of creating a "read-only" record of address and billing name for each contribution record in the address table. This required only one simple schema change (adding an address ID to the contribution schema).
We finished a test sequence with our sample contribution page configuration - and I think we accomplished all three goals pretty nicely. That said, we still have a pretty big roadblock in the way of fully implementing the third goal - which we're leaving to 2.3 or later. In order to provide reasonable flexibility for users to create / manage a variety of billing addresses we need to get rid of our reliance on organizing contact email, postal address, phone data by "location type" - particularly the current "rule" that contacts can only have 1 address per location type. We'll be looking at this larger change in an upcoming release.
You can check out
details of the changes for 2.2 in the issue tracker.
Comments
This may be the issues link that was intended for details of the changes for 2.2
Yes indeed. Fixed in the post now. Thx!