Thanks for the task! I think our ideal version of the upsell happens on
payments, or before the TY page loads (see slide 1 here
Is it worth integrating the TY page version if this other one is our
So we'll have to go through this one processor by processor to see which support a one-time payment with the option to set up recurring afterward without having to re-enter card details.
Ingenico Connect at least allows us to tokenize a payment that was created with the existing one-time-donation flow. We have to experiment more to determine if that token can be used to make more payments even though the first was not marked as recurring.
Work would involve:
- rendering a form on the resultswitcher for processors supporting the upsell
- making the appropriate API calls to get the token or establish the subscription
- sending messages to the recurring queue to indicate a new subscription starting in a month's time.
- updating crm code that handles token insertion to work from the new recurring queue messages rather than just from donation messages
- updating recurring Ingenico Civi extension code to handle the case when it rather than payments-wiki makes the first payment in the subscription
- would probably want to copy the order ID from the parent one-time contribution and increment the sequence # so the right banner / campaign / etc gets linked to the subscription
For PayPal, it looks like we need to explicitly have the donor agree to recurring payments on PayPal's site. So we would have to bounce them back to PayPal for another authorization once they clicked 'yes'.
Agree with @CCogdill_WMF that it's not a blocker to have to bounce users back to paypal. Our donors show a lot of resilience re: navigating complicated forms, particularly when it's necessary, and if a donor is making the decision to respond to this upsell, I think they'll be inclined to complete the task.