Currently, when an existing contact submits a contribution or event registration transaction - the contact name is updated with the "billing name" entered for that transaction. This is not expected behavior for the user, especially if they are using a "third party" payment instrument (e.g. their spouse's or organization's credit card etc.).
Chris Mott has listed several solutions for this:
"As a user interface principle it should be explicit when you are changing your primary account details. Possible solutions to improve this problem with the user interface on registration/transaction pages include:
1. Load editable email, name and addresses form fields with default values from the primary account.
a. Present a check box allowing option to update account (e.g. 'Update account with with email address');
b. Use values just for the transaction/registration and do not update primary account details;
c. Show explanatory note indicating that these values will update primary account where it's not otherwise explicit; OR
d. Add new secondary fields in the account to hold typical registration/transaction values (e.g. in the same way addresses for transactions are stored in additional 'Billing Address' fields, a 'Billing Name' field could be added).
2. Present email, name, and address as fixed text with values from the primary account
a. Present a button to change fixed text into editable fields (e.g. 'Edit details');
b. Present a button to link to My Account page to edit values (e.g. 'Edit details on My Account'); OR
c. Do not present a link to edit (e.g. if third party billing was to be discouraged, then leave billing name fixed as account name).
Some combination of these should be tailored to each instance of account info occurring in CiviCRM forms outside MyAccount pages. "
I think we need to allow "third-party billing" - but I'm not sure we need to save that info. I also think making the fields read-only by default for logged in users - with the option to make them editable via "Edit Details" button - seems like a good simplification of the UI.
From an input/processing point of view, there are two cases:
1. PayPal Pro (and other processors which collect billing name and address on our contribution form).
2. PayPal Std, Google Checkout and other processors which collect all payment info on their server and send us back the info.
In both cases, we should change the post process rules as follows:
- IF the contributing contact MATCHES an existing contact - and the first, middle, last name fields are NOT NULL - then do NOT update those fields (i.e. ignore input from billing name/address form OR payment processor)
- IF we are creating a new contact record, then USE the name fields to populate the contact record.
— Original Post from dave hansen-lange ------------
If a contact uses their spouse's credit card to make a contribution, they are asked to enter the name and address that matches the card (the billing name and address). In this case they would enter their spouse's name. When the form is processed, their name is then changed to that of the spouse.
I can see two possible sollutions.
1) Simply don't save the name if one already exists in civicrm.
2) Also add fields for "real" name.
Also I wonder what will happen if you add a profile to the contribution page that has the names in it. Which will win out?