neighborly/neighborly — pull request #245 by Irio (2014-05-06 15:06:02+00:00)
Title: Generate matched contribution

- [x] Generate matched contributions for each active match
- [x] Keep matched contributions' state updated with parent contribution

Also, I've been thinking about payment attributes in the matched contribution. Should we keep them equal to Match object? Or leave them empty, since we already have this information in matches table? So far, this does not seem to be a case for denormalization, just a way (maybe not a good one) to skip some rewriting, mostly in our database views. I am starting a review to check how having contributions without these fields filled will affect use cases and reports.

```
payment_token
payment_id
payer_name
payer_email
payer_document
payment_choice
payment_service_fee
payment_service_fee_paid_by_user
```