The transaction notifications sent by PayPal will slightly change. We need to adapt our application to be able to process them. Please refer to the [investigation documentation](https://docs.google.com/document/d/1UzOKLG9mk9kWO3wRKZKGBMevnVJc3qdVYNNY9nb-u8o/edit#heading=h.qeqkx356gbyr) for more details.
**Acceptance Criteria**
- Payment notifications for one-time payments can be processed by our application.
- Payment notifications for recurring payments can be processed by our application.
**Implementation Notes**
- ~~The transaction types (`txn_type`) for recurrring payments will be:~~
- `recurring_payment_profile_created`
- `recurring_payment`
- ~~The Fundraising Application needs to be changed to handle those new transaction types.~~
- The notification `recurring_payment_profile_created` should be accepted, but ignored for donation payments.
- ~~Deploy the changed application to test and make a payment. Wait for the IPN to arrive~~
- ~~Look at the booking data for a recurring payment - it should contain a `product_name` that will allow us to determine if a recurring payment is for a membership or a donation. If `product_name` is the only key we have, then we'll need to do a lookup by product name, because the names are localized.~~
- Check if the IPN has a `custom` field, if yes, you can use the donation ID and security token from the custom field
If the IPN has no custom field, you need to look for a payment with the right external id (joining the membership //and// donation table to find out what the payment is for). Dispatch to the right use case (bookDonation/bookMembership). In this case we don't have a security token and need to inject a `DonationAuthorizer` implementation that just says "ok" to `systemCanModifydonation`.
- Add test cases for the route that check the new payment data
- `recurring_payment` & matching `product_name` for donations should be handled
- `recurring_payment` & non-matching `product_name` should be dropped