While it would be ideal to be able to implement the entire flow within the donor portal, this would involve re-implementing some logic that lives on donatewiki (for showing the available donation methods) and expanding the PCI scope to include the donor portal, plus complicating our configuration with payment processors to allow additional javascript origins and IP addresses. Logging, queues, and monitoring would have to be adjusted to accommodate additional origin points for processor API calls, and we would have to re-implement the payments forms in VueJS.
Proposed solution: link to donatewiki with amount, currency, and country of existing donation plus additional parameters: contact_id, checksum, and contribution_recur_id. Donatewiki displays available recurring methods for the country / currency as usual and passes parameters along to payments-wiki. Payments-wiki shows the usual donation form and passes the extra parameters through to CiviCRM, which uses them to cancel the old donation when the new one is started.
Pros: Simple to implement, no architectural changes needed
Cons:
- Donor needs to enter name + email again
- payment with new method is made immediately and the monthly cycle day is reset to current day, regardless of the next scheduled donation date
- could be mitigated if we showed the available methods for the country/currency on donor portal and linked directly to paymentswiki with the name + email on the URL
- could be mitigated with changes to the DonationInterface charge logic that let us store a payment method without making the initial payment. Need to verify that we can do that for all methods. We would trigger this based on the presence of the contribution_recur_id parameter, then start the new recurring donation with the same next scheduled contribution date as the old one.
