Change Details

The idea of allowing members to pay their membership fees via PayPal came up quite some time ago. The API we currently use was never considered sufficient to implement this, as it lacked the ability to delay payments, which is a crucial feature to reflect the organisation's member admission process. PayPal has introduced a newer API that is more flexible and allows us to finally offer the use of PayPal for membership fee payments. A thorough evaluation of how the newer PayPal API works and if our use cases can be realised with it was done in T304821. Current status (2024-01-12): ### Work done We have prepared the Payment Bounded context to use the PayPal API when creating a payment. This has impacted the order of calls in the donation and membership bounded contexts, since the calls to the API need data from higher levels (e.g. donation/membership ID, authentication tokens from the app). The parameter passing from higher levels is abstracted behind value objects with generic names (`DomainSpecificContext`) or interfaces (`URLAuthenticator`). Currently, the Payment bounded context supports both the "legacy" parameter passing (via URL) and API. The FunFunFactory contains a feature flag method (`useLegacyPayPalUrlGenerator`) that toggles the behavior. We did not use the API method for the 2023 campaign. ### Work to to **Support one-time-payments in the application** Depending on the payment interval, we either create //Subscriptions// (recurring payments) or //Orders// (one-time-payments) with the PayPal API. These payment types have different requirements on how the application handles them when the user returns from the Paypal page: - For Subscriptions, PayPal will redirect the user to the confirmation page. - For Orders, we need to call the API again to "[capture](https://developer.paypal.com/docs/api/orders/v2/#orders_capture)" the payment before redirecting to the confirmation page. We need to implement the business business logic for this in the payment bounded context and a "capture" route in the fundraising application. Tickets: - {T354963} - {T354964} **Support receiving IPN for legacy //and// API payments** We use IPN (Instant Payment Notifications) where PayPal calls a HTTP notification route on our server to notify us about payment state changes. The IPN logic needs to be extended to handle both "legacy" IPNs (of recurring payments created before we switch to the API and of the one-time-payments) and API payments. The API payments also need to determine (via the payment ID) if they should dispatch to the donation or membership notification use case Ticket: {T329162} **Prepare application configuration** Before deploying to production, we also need to create the subscription items, using the right language strings (it's hard to change them after the initial setup). ### PayPal for memberships The "Paypal for memberships" feature is not implemented at all. We need - A clear description of the process/user journey from the campaigns team, in cooperation with our third party data warehousing solution. Open questions: - Do we need to export the recurring payments like we do with donations? What format should we export the recurring payments in? Do they want to get exported "memberships" for followup bookings? - How do we calculate the delay between applying and starting the payments? - Implement the "Book Membership" use case. It needs to call the BookPayment use case and mark the membership as booked. Call the use case from the general IPN end point in the App. - Implement the export payments?

The idea of allowing members to pay their membership fees via PayPal came up quite some time ago. The API we currently use was never considered sufficient to implement this, as it lacked the ability to delay payments, which is a crucial feature to reflect the organisation's member admission process. PayPal has introduced a newer API that is more flexible and allows us to finally offer the use of PayPal for membership fee payments. A thorough evaluation of how the newer PayPal API works and if our use cases can be realised with it was done in T304821. Current status (2024-01-12): ### Work done We have prepared the Payment Bounded context to use the PayPal API when creating a payment. This has impacted the order of calls in the donation and membership bounded contexts, since the calls to the API need data from higher levels (e.g. donation/membership ID, authentication tokens from the app). The parameter passing from higher levels is abstracted behind value objects with generic names (`DomainSpecificContext`) or interfaces (`URLAuthenticator`). Currently, the Payment bounded context supports both the "legacy" parameter passing (via URL) and API. The FunFunFactory contains a feature flag method (`useLegacyPayPalUrlGenerator`) that toggles the behavior. We did not use the API method for the 2023 campaign. ### Work to to **Support one-time-payments in the application** Depending on the payment interval, we either create //Subscriptions// (recurring payments) or //Orders// (one-time-payments) with the PayPal API. These payment types have different requirements on how the application handles them when the user returns from the Paypal page: - For Subscriptions, PayPal will redirect the user to the confirmation page. - For Orders, we need to call the API again to "[capture](https://developer.paypal.com/docs/api/orders/v2/#orders_capture)" the payment before redirecting to the confirmation page. We need to implement the business business logic for this in the payment bounded context and a "capture" route in the fundraising application. Tickets: - {T354963} - {T354964} **Support receiving IPN for legacy //and// API payments** We use IPN (Instant Payment Notifications) where PayPal calls a HTTP notification route on our server to notify us about payment state changes. The IPN logic needs to be extended to handle both "legacy" IPNs (of recurring payments created before we switch to the API and of the one-time-payments) and API payments. The API payments also need to determine (via the payment ID) if they should dispatch to the donation or membership notification use case Tickets: - {T329162} **Prepare application configuration** - Before deploying to production, we also need to create the subscription items, using the right language strings (it's hard to change them after the initial setup). - Put the item IDs in the PayPal production configuration file in the infrastructure repository - We also need to adapt the existing PayPal configurations (prod and uat in the infrastructure repository) to use `return_url_recurring` (donation confirmation page route) and `return_url_one_time` (capture route from {T354964}) instead of just using `return_url` ### PayPal for memberships The "Paypal for memberships" feature is not implemented at all. We need - A clear description of the process/user journey from the campaigns team, in cooperation with our third party data warehousing solution. Open questions: - Do we need to export the recurring payments like we do with donations? What format should we export the recurring payments in? Do they want to get exported "memberships" for followup bookings? - How do we calculate the delay between applying and starting the payments? - Implement the "Book Membership" use case. It needs to call the BookPayment use case and mark the membership as booked. Call the use case from the general IPN end point in the App. - Implement the export payments?

The idea of allowing members to pay their membership fees via PayPal came up quite some time ago. The API we currently use was never considered sufficient to implement this, as it lacked the ability to delay payments, which is a crucial feature to reflect the organisation's member admission process. PayPal has introduced a newer API that is more flexible and allows us to finally offer the use of PayPal for membership fee payments. A thorough evaluation of how the newer PayPal API works and if our use cases can be realised with it was done in T304821. Current status (2024-01-12): ### Work done We have prepared the Payment Bounded context to use the PayPal API when creating a payment. This has impacted the order of calls in the donation and membership bounded contexts, since the calls to the API need data from higher levels (e.g. donation/membership ID, authentication tokens from the app). The parameter passing from higher levels is abstracted behind value objects with generic names (`DomainSpecificContext`) or interfaces (`URLAuthenticator`). Currently, the Payment bounded context supports both the "legacy" parameter passing (via URL) and API. The FunFunFactory contains a feature flag method (`useLegacyPayPalUrlGenerator`) that toggles the behavior. We did not use the API method for the 2023 campaign. ### Work to to **Support one-time-payments in the application** Depending on the payment interval, we either create //Subscriptions// (recurring payments) or //Orders// (one-time-payments) with the PayPal API. These payment types have different requirements on how the application handles them when the user returns from the Paypal page: - For Subscriptions, PayPal will redirect the user to the confirmation page. - For Orders, we need to call the API again to "[capture](https://developer.paypal.com/docs/api/orders/v2/#orders_capture)" the payment before redirecting to the confirmation page. We need to implement the business business logic for this in the payment bounded context and a "capture" route in the fundraising application. Tickets: - {T354963} - {T354964} **Support receiving IPN for legacy //and// API payments** We use IPN (Instant Payment Notifications) where PayPal calls a HTTP notification route on our server to notify us about payment state changes. The IPN logic needs to be extended to handle both "legacy" IPNs (of recurring payments created before we switch to the API and of the one-time-payments) and API payments. The API payments also need to determine (via the payment ID) if they should dispatch to the donation or membership notification use case Ticket:s: - {T329162} **Prepare application configuration** - Before deploying to production, we also need to create the subscription items, using the right language strings (it's hard to change them after the initial setup). - Put the item IDs in the PayPal production configuration file in the infrastructure repository - We also need to adapt the existing PayPal configurations (prod and uat in the infrastructure repository) to use `return_url_recurring` (donation confirmation page route) and `return_url_one_time` (capture route from {T354964}) instead of just using `return_url` ### PayPal for memberships The "Paypal for memberships" feature is not implemented at all. We need - A clear description of the process/user journey from the campaigns team, in cooperation with our third party data warehousing solution. Open questions: - Do we need to export the recurring payments like we do with donations? What format should we export the recurring payments in? Do they want to get exported "memberships" for followup bookings? - How do we calculate the delay between applying and starting the payments? - Implement the "Book Membership" use case. It needs to call the BookPayment use case and mark the membership as booked. Call the use case from the general IPN end point in the App. - Implement the export payments?