T2853 recurring payment methods integration postfinance

[SamBachmann]

Related PR: T2853

Description:

This PR implements the secure addition and tokenization of modern payment methods (Credit/Debit cards, etc.) for recurring sponsorships on the MyCompassion 2.0 portal. It finalizes the work started in T2534 by connecting the frontend payment selection to the backend payment acquirer logic.

Key Changes:

• Architectural Separation:

  • Compassion-website/my_compassion (Generic): Implements the generic flows for adding payment methods and handling user feedback (loading states, success/error messages), ensuring no region-specific logic leaks into the core module.

  • Compassion-switzerland/my_compassion (Specific): Contains the specific implementation for PostFinance Checkout, including API integrations for iframe embedding and transaction handling.

• Payment Integration:

  • Iframe Integration: Integrates PostFinance Checkout to allow sponsors to add new payment methods via a secure iframe.

  • Token Management: Handles callback processing to create the payment token. Includes deduplication logic that queries the PostFinance API to prevent creating multiple tokens for the same payment instrument.

  • Contract Linking: Automatically creates or updates the partner's recurring.contract.group upon successful tokenization.

• Recurring Billing & Invoicing:

  • Implements the backend logic to automatically charge the stored token for future invoices generated by the recurring contract groups.
  • Invoice Logic: Overrides _process_invoice_generation in the Swiss module to ensure correct payment terms and due dates are applied to automatically generated invoices.

⚠️ Still to be checked:

I got some changes requested by David the day I left, so I couldn't achieve to implement them / test them:
When a user change its payment method for a contract from a BVR/Recurring payment method to a tokenized one verify / implement the following

• (Implement) : Warn the user that the not paid invoices previously emitted will be charged on the added card
• (Verify): Check the code and test that there's the necessary logic in the code for that

Result :

Add Payment Methods Modal	Add Payment Method List
Enter card data	Success adding a card

Documentation:

As the processes are quite complex, I wrote some docs detailing the frontend-backend interactions and data flow.

[gemini-code-assist]

Code Review

This pull request introduces a significant and well-architected feature for managing recurring payment methods with PostFinance. The separation of concerns, use of modern Odoo frontend patterns for AJAX updates, and robust backend logic are commendable. My review focuses on removing debug artifacts that pose a security risk in a production environment, along with minor suggestions to improve code style, consistency, and maintainability. Overall, this is a solid implementation.

[SamBachmann]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces significant enhancements to the 'My Donations' portal page, primarily focusing on managing payment methods for sponsorships. Key changes include adding new UI components for payment method selection and management, such as modals for updating, changing, and adding payment methods. The backend now supports grouping sponsorships by payment method, fetching payment method details, and new API endpoints for modifying contract groups and individual contracts' payment methods. It also integrates with external payment providers like PostFinance via iframes for adding new online payment methods. Additionally, the definition of 'active' sponsorships has been expanded to include the 'mandate' state across various models and controllers. Review comments highlight potential N+1 query issues in fetching payment icons and payment modes, suggest refining broad exception handling, and recommend improving the user experience by using the existing toast service instead of native alerts and avoiding full page reloads as a primary UI update mechanism. There's also a suggestion to dynamically fetch manual payment options instead of hardcoding them in templates.

[gemini-code-assist]

The options for manual payment methods ("Permanent Order" and "BVR") are hardcoded directly in the QWeb template. If the available manual payment methods change or new ones are introduced in the future, this template will require manual modification.

For better maintainability and flexibility, consider fetching these options dynamically from the backend. This would allow administrators to manage payment methods without code changes.

[SamBachmann]

/gemini review

[NoeBerdoz]

Putting this back in draft, won't be merged in 14.0, but will be a reference for implementing the set of functionalities in 18.0 (It will be a lot easier in 18.0 as well)