Idea for extension Someone Else Pays - any feedback?
Here's how we get someone else to pay! This is an Example of an Event Registration:


Primary Contact -> and 4 Participants; Key is: register each Contact separately;





Use Conditionals to help with how many # participants fields you need - and configure the Events webform elements - to be a checkbox for the Primary Contact; 
End result: if Primary Contact (in this example often a Director of a ChildCare program) is simply registering and paying for Staff to attend a Conference -> the Director pays and all the Participants are added. 
Example: KarinG will register Karin G:
KarinG has paid - but has no Events:

Karin G is the Participant but has no Contributions:

Receipting? Does it work? Almost -> the person who paid (KarinG) gets a transaction receipt showing those who have been registered (Karin G) [triggered via the API - sendConfirmation to be exact)
And what about sending a Confirmation to the Participants that their Director has signed them up. That works too - with a little help from... CiviRules! Trigger: participant add; All I needed to do was write a small custom module to generate some participant tokens; 





Ok what does not work as well yet -> CiviCRM native is a bit confused about Payments; and the invoicing is a bit off -> it should really look much like the receipt that you can get at with sendConfirmation - but you can't. It's not clear at all that KarinG paid for Karin G to go to the Conference - Fuzion has helped make this work - by adding a Participant Name to the LineItem before webform_civicrm uses the lineItem API to create the lineItems: 
What really does not work is -> if you sign up more than 1 Participant -> their Event Participant View -> shows the total $ for all the participants - not just for their lineItem (so CiviCRM native thinks that each single participant is owed a refund);
If I were tasked to do this in an Extension -> use the APIs that webform civicrm uses to get this registered by functionality up and running; no extra table required; use the registered_by -> to properly link payments and event registrations; Extend the registered_by at the Event level to the Membership level -> (that would be a gift membership e.g.);