What are the technical considerations and/or limitations of streamlining donor flow for donors coming in via DonateWiki by running paymentsWiki in an iFrame.
What would be involved in implementing this feature? What size of project is it? Are there any technical blockers?
*combowiki
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | Feature | None | T417039 [Epic] ComboWiki | ||
| Resolved | None | T351168 Investigation: Reduce number of clicks in donation flow through DonateWiki |
quick notes from our sprint planning: https://etherpad.wikimedia.org/p/paymentsindonate
Some thoughts (copied to etherpad):
Noting this task exists with some of Andy's thinking: T320735: Initial investigation: improved flow options for wallet payment types (PayPal, Apple Pay, GPay, Amazon and, soon, Venmo) - and this request from Evelyn: T321616: Solution for new payment integrations requiring us to run scripts on Wikipedia
One big thing to resolve came up in a meeting today. We currently have a clear dividing line between the site where our general privacy policy applies (main cluster + donate-wiki first-step forms) and the site where our donor privacy policy applies (payments-wiki). This makes it clear exactly when we can load the third-party scripts that are needed to render a button for Apple Pay / Google Pay / Venmo that responds immediately.
Ideally we could show a logo on a first-step form that would directly initiate a payment action, but that seems hard without loading all the scripts up front.