Answers.Body: <p>When you say registration, do you mean "of membership"?</p>
  
  <p>If it's just registration of being part of your organisation, perhaps attach it to an activity of type "Registration" on the contact.</p>
  
  <p>However, your message concerned me. In general CiviCRM isn't used for credit card information - there are a lot of laws surrounding how that information is stored. Tangentially, you should also read: <a href="https://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standard" rel="nofollow">https://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standard</a></p>
  
  <p>In general we would advocate using a dedicated payment processor extension and only storing transaction Ids in Civi.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-13T12:09:18.257Z
Answers.Text: Event registration - CiviEvent. Registering for an event.
  
  No, of course we don't store credit card details.
Answers.UserDisplayName: GHolmes
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-13T12:09:36.370Z
Answers.Text: When people *don't* pay by credit card, we capture *billing* details - billing contact person, email, address, fax - to invoice them.  We've been capturing that in a profile - which doesn't make much sense for multiple registrations, in my opinion (since it is a profile and attaches to registrant #1).
Answers.UserDisplayName: GHolmes
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-13T12:09:45.790Z
Answers.Text: Not to mention it causes the email address to be overwritten on registrant #1 if you use a contact email field - and I'm not seeing (probably just missing it?) how to use any other email field in this profile, because when I add a new custom field to the profile an email address type doesn't seem to be an option, so we had to replace it with a text field that isn't validated for email. 
  
  We were hoping there is a better way?  To capture billing information for a group registration?
Answers.UserDisplayName: GHolmes
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-13T20:48:43.993Z
Answers.Text: Greg - I guess I am not following, but do you have your Billing profile set so that it only shows on Participant 1, or the subsequent ones as well?
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-09-23T12:59:46.837Z
Answers.Text: I see I never came back to this ... sorry :)  The idea was that one organization might register four (say) of their people for an event. If they did not pay by credit card, then we needed to collect information for a billing contact - one person, one point of contact to send an invoice to, call with questions/problems, and so forth. And the billing person might not be a registrant.
Answers.UserDisplayName: GHolmes
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-09-23T12:59:53.070Z
Answers.Text: We were using a profile form for that. AFAIK, the profile form submission has to attach to a contact, right? Are you saying that it could attach to *all* of the registrant contacts somehow, in that group registration? Or am I misunderstanding you?
Answers.UserDisplayName: GHolmes
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-11T22:11:03.043Z
Answers.LastActivityDate: 2016-03-11T22:21:08.017Z
Answers.LastEditDate: 2016-03-11T22:21:08.017Z
Answers.UserDisplayName: JohnFF
Answers.Body: <p>I would suggest making the Contact 1 an organization profile and then the billing info attached to that profile with a contact name. Then additional profiles could be individuals that would collect whatever info for them. </p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-12-08T23:00:31.180Z
Answers.LastActivityDate: 2016-12-08T23:00:31.180Z
Answers.UserDisplayName: frTommy
Body: <p>I may be missing something obvious, but what is the best way to capture billing information for an event registration, including for a registration of multiple people?</p>
  
  <p>What I mean is, in addition to providing a credit card option, we allow optionally providing billing name, address, fax, and email. </p>
  
  <p>Currently we are using a profile for the additional billing information (billing name, address, fax, and email), which gets attached to registrant #1. This caused a problem at first - an email address supplied for billing would overwrite the email address on registrant #1. "Solved" by replacing the email field in the billing profile with a new text field that is just for the profile (but unfortunately is not an email field, so is not validated for email).</p>
  
  <p>Is there a better way, to collect this information and have it attached to the event registration itself, not to one of the contacts?</p>
  
Tags: <civievent>
Title: CiviEvent - capturing billing information, interaction (or not) with contacts
ThreadText: # CiviEvent - capturing billing information, interaction (or not) with contacts
  
  (Asked by: username_0 on 2016-03-11)
  
  I may be missing something obvious, but what is the best way to capture billing information for an event registration, including for a registration of multiple people?
  
  What I mean is, in addition to providing a credit card option, we allow optionally providing billing name, address, fax, and email.
  
  Currently we are using a profile for the additional billing information (billing name, address, fax, and email), which gets attached to registrant #1. This caused a problem at first - an email address supplied for billing would overwrite the email address on registrant #1. "Solved" by replacing the email field in the billing profile with a new text field that is just for the profile (but unfortunately is not an email field, so is not validated for email).
  
  Is there a better way, to collect this information and have it attached to the event registration itself, not to one of the contacts?
  
  **Tags:** civievent
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2016-03-11. Score: 1
  
  When you say registration, do you mean "of membership"?
  
  If it's just registration of being part of your organisation, perhaps attach it to an activity of type "Registration" on the contact.
  
  However, your message concerned me. In general CiviCRM isn't used for credit card information - there are a lot of laws surrounding how that information is stored. Tangentially, you should also read: <https://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standard>
  
  In general we would advocate using a dedicated payment processor extension and only storing transaction Ids in Civi.
  
  > **Comments:**
  > **username_0**: Event registration - CiviEvent. Registering for an event.  No, of course we don't store credit card details.  
  > **username_0**: When people *don't* pay by credit card, we capture *billing* details - billing contact person, email, address, fax - to invoice them.  We've been capturing that in a profile - which doesn't make much sense for multiple registrations, in my opinion (since it is a profile and attaches to registrant #1).  
  > **username_0**: Not to mention it causes the email address to be overwritten on registrant #1 if you use a contact email field - and I'm not seeing (probably just missing it?) how to use any other email field in this profile, because when I add a new custom field to the profile an email address type doesn't seem to be an option, so we had to replace it with a text field that isn't validated for email.   We were hoping there is a better way?  To capture billing information for a group registration?  
  > **username_2**: Greg - I guess I am not following, but do you have your Billing profile set so that it only shows on Participant 1, or the subsequent ones as well?  
  > **username_0**: I see I never came back to this ... sorry :)  The idea was that one organization might register four (say) of their people for an event. If they did not pay by credit card, then we needed to collect information for a billing contact - one person, one point of contact to send an invoice to, call with questions/problems, and so forth. And the billing person might not be a registrant.  
  > **username_0**: We were using a profile form for that. AFAIK, the profile form submission has to attach to a contact, right? Are you saying that it could attach to *all* of the registrant contacts somehow, in that group registration? Or am I misunderstanding you?  
  
  ---
  
  ### Answer by username_3 on 2016-12-08. Score: -1
  
  I would suggest making the Contact 1 an organization profile and then the billing info attached to that profile with a contact name. Then additional profiles could be individuals that would collect whatever info for them.
  
  
  ---
  
  