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 (from the legacy payment URLs) can be processed by our application.
- Payment notifications for recurring payments (both from legacy and API) 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 transaction type (`txn_type`) for recurrring payments will be `cart`
- ~~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 paypal.log data for a recurring payment - it should contain a `recurring_payment_id` that will allow us to determine if a recurring payment is for a membership or a donation.~~
- ~~look at the paypal.log for a one-time payment - it should contain a some id (referenced as `<TBD>``txn_id` in the following steps) that will allow us to match the payment with a donation.
- Check if the IPN has a `custom` field,`txn_type` (for the values outlined above) that indicates that the IPN was issued from an API-Generated payment. if yesnot, you can use the donation ID and security token from the `custom` field
If the IPN has no custom fieldcomes from the API, you need to look for a payment(`PaypalOrder` or `PaypalSubscription` (see T343846) with the right external id (joiningdoing a UNION select of the membership //and//and donation table to find out what the payment is for). Create a new service class for this - it should receive the IPN data, look at the transaction type to determine the name of the ID field (`recurring_payment_id` for `recurring_payment`, `txn_id` for `cart` ) , request membership id and donation id from the database and return a use case with a "lenient" authorizer implementation that always returns `true` for `systemCanModifydonation`.
- Add test cases for the routein `HandlePayPalPaymentNotificationRouteTest` that check the new payment data
- ~~`recurring_payment` & matching `recurring_payment_id` for donations should be handled ~~
- `recurring_payment` & non-matching `recurring_payment_id` should be dropped (and logged)
- `web_accept`- `cart` without `custom` field and matching `<TBD>``txn_id` field should be handled
- `web_accept`- `cart` without `custom` field and non-matching `<TBD>``txn` field should be dropped (and logged) - TODO discuss timing issues, if the lookup fails, we may wait for a few seconds and try again. This is because the flow be: a) call "capture payment" PPL API, get transaction id b) write transaction Id to database. The call to the API might trigger the IPN request before we had a chance to write to the DB. A highly unlikely case, but should still be considered.