Page MenuHomePhabricator

research recurring upsell
Closed, ResolvedPublic

Related Objects

StatusSubtypeAssignedTask
OpenNone
ResolvedEjegg

Event Timeline

DStrine created this task.Feb 5 2019, 8:08 PM
DStrine updated the task description. (Show Details)
DStrine added a project: Recurring-Donations.

Hey David,

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
https://docs.google.com/presentation/d/1u-MPtEhitXNTAHnfRtc0cgR1-u7rSTA3UWx5_LdBGPQ/edit#slide=id.p).
Is it worth integrating the TY page version if this other one is our
preference?

DStrine removed a project: Epic.Feb 5 2019, 9:23 PM
DStrine renamed this task from research changes to the TY page to research recurring upsell.Feb 7 2019, 4:23 PM
Ejegg added a subscriber: Ejegg.Feb 11 2019, 10:19 PM

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'.

@CCogdill_WMF, @MeganHernandez_WMF, @spatton, @Pcoombe, how does that sound? I guess it's less annoying than typing a card number again, and hopefully they'd already be signed in.

Ejegg claimed this task.Feb 11 2019, 11:39 PM
Ejegg triaged this task as High priority.
Ejegg added a comment.Feb 14 2019, 7:22 PM

ping @CCogdill_WMF, @MeganHernandez_WMF, @spatton, @Pcoombe: any thoughts on sending the user back to PayPal to get a second authorization?

Do we know what that looks like on the PP side? It's not ideal but it makes
sense. We could compare it to the CC conversion rate and see if returning
to the payment flow really hurts.

DStrine updated the task description. (Show Details)Feb 19 2019, 8:34 PM

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.

DStrine closed this task as Resolved.Feb 19 2019, 9:17 PM
DStrine moved this task from Doing to Done on the Fundraising Sprint Casino Royale With Cheese board.
Ejegg added a comment.Feb 19 2019, 9:45 PM

@CCogdill_WMF after we send them back to PayPal, the donor would see the same thing they currently see on a recurring donation.