Answers.Body: <p>when you create the "non main" participants, do you link them with the main participant registration? </p>
  
  <p>As written, try to register multiple participants via the normal web interface and use it as a template, but it seems that you need to set participant_registered_by_id to the id of the first participant (BAO/Participant.php getAdditionalParticipantIds function should give you more hints)</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-05-04T23:59:22.483Z
Answers.Text: Using the front end, the primary registrant can't have a $0 fee while giving the additional registrants a non-zero fee. We also can't have multiple events in the transaction (to set which participants will attend which events). The end goal is to bring these disparate items into a single order/invoice; I think I am at a point where Civi doesn't yet have the business logic or db schema design to handle this concept.
Answers.UserDisplayName: Nicholai
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-05-05T13:51:25.767Z
Answers.Text: Out of the box, you won't get it indeed, the point of using the UI was to verify how the link between additional registrations and the main one, as it seems to be the bit missing to display properly the registrations with the amount
Answers.UserDisplayName: Xavier
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-05-05T14:21:25.917Z
Answers.Text: I've now seen how the DB saves it; primary record has registered_by_id set to null and additional records have registered_by_id set to the primary. We're going to change the approach to creating each participant individually as Pay Later, use a participant custom field where all participants created by the form share one php uniqid(), then create a custom token to pull them together for display.
Answers.UserDisplayName: Nicholai
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-05-05T15:03:35.837Z
Answers.Text: you might be able to use the source or card_id to group them too. Not sure why you can't promote one of the participant as the main one and use the "standard" multi-participants still ;)
Answers.UserDisplayName: Xavier
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-05-05T16:06:10.000Z
Answers.Text: In that setup, we are essentially asking a parent to choose their favorite child (or we are choosing it for them). The "primary" and "additional" concepts and workflows just won't work for this organization. I considered Source initially, but they are considering using that to determine which email/event/staff member/etc brought in the participant.
Answers.UserDisplayName: Nicholai
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-05-04T13:16:00.070Z
Answers.LastActivityDate: 2015-05-04T13:16:00.070Z
Answers.UserDisplayName: Xavier
Body: <p>I've been working on a camp registration page where an adult registers one or more children for one or more events, with a single Pending contribution to tie it all together (per <a href="https://civicrm.stackexchange.com/a/898/83">Xavier's advice here</a>). My API calls successfully create the adult, contribution, children, relationships, participants, and participant payments (a connection to my contribution) without error. However the participants still don't seem to be connected to the payment. When I view a participant record, the total paid shows the full amount with a balance of $0, even though the contribution is $0. When I click View Payments from here, there are no payments to display. When I click Record Payment, I get the error "No payment information found for this record".</p>
  
  <p><a href="https://gist.github.com/narayanis/fc6f688fb149481d9969#file-civi_student_registration-php-L56" rel="nofollow noreferrer">Here is a Gist</a> showing just the relevant parts of my code. Any advice is greatly appreciated.</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-05-04T12:56:25.680Z
Comments.Text: Hi, not sure I understand, are they for the additional participants that you have 0? Try to register multiple participants with a single payment via the UI and examine the differences with what you have created via the api
Comments.UserDisplayName: Xavier
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-05-04T13:06:02.787Z
Comments.Text: I'm not setting a registered_by_id value for any of the participants, since the adult fills out the form (but is not attending). As best I can tell by looking at the participant BAO code, this should make it so that none of them are "additional participants", but are all considered primary.
Comments.UserDisplayName: Nicholai
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-05-04T13:20:55.477Z
Comments.Text: Hi, The logic seems to be there is always the main participant, that is the one "paying", the other participants are linked to the main one (per the UI and BAO).
Comments.UserDisplayName: Xavier
Tags: <civievent><api>
Title: Error "No payment information found for this record" when connecting multiple participants to a single payment via API
ThreadText: # Error "No payment information found for this record" when connecting multiple participants to a single payment via API
  
  (Asked by: username_0 on 2015-05-03)
  
  I've been working on a camp registration page where an adult registers one or more children for one or more events, with a single Pending contribution to tie it all together (per [username_1's advice here](https://civicrm.stackexchange.com/a/898/83)). My API calls successfully create the adult, contribution, children, relationships, participants, and participant payments (a connection to my contribution) without error. However the participants still don't seem to be connected to the payment. When I view a participant record, the total paid shows the full amount with a balance of $0, even though the contribution is $0. When I click View Payments from here, there are no payments to display. When I click Record Payment, I get the error "No payment information found for this record".
  
  [Here is a Gist](https://gist.github.com/narayanis/fc6f688fb149481d9969#file-civi_student_registration-php-L56) showing just the relevant parts of my code. Any advice is greatly appreciated.
  
  **Tags:** civievent, api
  
  > **Comments:**
  > **username_1**: Hi, not sure I understand, are they for the additional participants that you have 0? Try to register multiple participants with a single payment via the UI and examine the differences with what you have created via the api  
  > **username_0**: I'm not setting a registered_by_id value for any of the participants, since the adult fills out the form (but is not attending). As best I can tell by looking at the participant BAO code, this should make it so that none of them are "additional participants", but are all considered primary.  
  > **username_1**: Hi, The logic seems to be there is always the main participant, that is the one "paying", the other participants are linked to the main one (per the UI and BAO).  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2015-05-04. Score: 1 | Accepted answer
  
  when you create the "non main" participants, do you link them with the main participant registration?
  
  As written, try to register multiple participants via the normal web interface and use it as a template, but it seems that you need to set participant\_registered\_by\_id to the id of the first participant (BAO/Participant.php getAdditionalParticipantIds function should give you more hints)
  
  > **Comments:**
  > **username_0**: Using the front end, the primary registrant can't have a $0 fee while giving the additional registrants a non-zero fee. We also can't have multiple events in the transaction (to set which participants will attend which events). The end goal is to bring these disparate items into a single order/invoice; I think I am at a point where Civi doesn't yet have the business logic or db schema design to handle this concept.  
  > **username_1**: Out of the box, you won't get it indeed, the point of using the UI was to verify how the link between additional registrations and the main one, as it seems to be the bit missing to display properly the registrations with the amount  
  > **username_0**: I've now seen how the DB saves it; primary record has registered_by_id set to null and additional records have registered_by_id set to the primary. We're going to change the approach to creating each participant individually as Pay Later, use a participant custom field where all participants created by the form share one php uniqid(), then create a custom token to pull them together for display.  
  > **username_1**: you might be able to use the source or card_id to group them too. Not sure why you can't promote one of the participant as the main one and use the "standard" multi-participants still ;)  
  > **username_0**: In that setup, we are essentially asking a parent to choose their favorite child (or we are choosing it for them). The "primary" and "additional" concepts and workflows just won't work for this organization. I considered Source initially, but they are considering using that to determine which email/event/staff member/etc brought in the participant.  
  
  ---
  
  