@OTichonova I have a couple of UI questions:

1

We have an applelogo SFSymbol that I'm able to use for the Settings screen, but it comes with this warning in the SFSymbol's app that has me concerned:

Maybe we should use something else for this?

2

It looks like FR-tech's banners currency conversion reference has a "minimum" section:

frb.amounts.minimums = {
    'USD' : 1,
    'CAD' : 1.24,
    'AUD' : 1.34,
    'NZD' : 1.40,
    'GBP' : 0.73,
    'EUR' : 0.86,
    'DKK' : 6.40,
    'HUF' : 314,
    'ILS' : 3.20,
    'INR' : 10, // T309818
    'JPY' : 114,
    'MYR' : 4.15,
    'NOK' : 8.35,
    'PLN' : 3.96,
    'RON' : 4.25,
    'SEK' : 8.59,
    'UAH' : 26,
    'ZAR' : 15,
    // Latin America
    'BRL' : 5.61,
    'ARS' : 99,
    'CLP' : 812,
    'COP' : 3762,
    'MXN' : 20,
    'PEN' : 3.63,
    'UYU' : 43,
    'CHF' : 1
};

And web seems to use it too:

I think we should add a validation error like this as part of the design.

Hi @Tsevener

1. I changed the icon for this giftcard icon for now. I'll double-check with other designers if this icon is appropriate but I don't think we should stick with the apple logo.

2. I think the validation error text is great. We should use the text/values found on web.

@greg @TSkaff @dkozlowski Note to Greg, Dylan and Thea that the App team will need dev support to get Apple Pay live in the App. Can we get this in the priority queue when Olga gets to that point? @OTichonova Hi Olga, these are the folks than can prioritize what you need from Fundraising Tech to deploy.

Had a meeting with @Ejegg just now, here's a recap:

• FR-tech will need to rework the web's payment certificate to use the less-quick setup (see documentation), due to this callout:

The option to use Adyen's Apple Pay certificate is only available on web. If you have a native mobile integration, you need to use your own Apple Pay certificate.

• The plan for now is for iOS to lean on the Adyen iOS Components SDK and follow their setup doc. We'll need two new endpoints from FR-tech for this. The iOS app will need to send an Adyen clientKey to both of these endpoints:
  1. One endpoint that returns an order number, as well as makes the /paymentMethods call to Adyen and gives us those results.
  2. One endpoint that takes in the apple payment token and donor contact information (contact name & email) and submits to Adyen's /payments endpoint and CiviCRM, respectively.
• Some confusion on both sides about what the countryCode should be...Adyen's /payments documentation for the Apple Pay web component says "The two-letter country code of your merchant account.", but their API explorer for the same endpoint says "The shopper country." Apple docs for basic PKPaymentRequests suggests the it's merchant country code. I have asked about this in an Adyen support ticket but haven't heard back.
• The amount of work on FR-tech side for all of this is not trivial, so it's doubtful FR-tech will get to this work soon given their current high priorities.
• Since this may be a hefty chunk of work, we briefly discussed looping in Android to be sure the new endpoints will work with Google Pay.

Given the last two points, I'm going to pause on my side until we know more.

Just some notes for future technical, product and designs conversations on this iOS flow and possibly transferrable for any future android flow:

We need to

• be able to enter a flow from an announcement

We may want to

• be able to enter a flow from an announcement
• include the form as part of a modal alongside announcement text
• have the form be in a modal but the next step after the presentation of the announcement text
• support multiple currencies for the askstring amounts based on country and language
• support multiple payment methods
• support apple pay and other payments via paymentswiki via the same flow
• support monthly payments
• limit option amount to 2 decimal places
• consider donate.wikimedia.org, the MobileApps extension or meta.wikimedia.org to store some configuration (example)
• consider making the tick boxes bigger
• consider the use of buttons in place of tick box (particularly for communication opt-in)
• support minimum amount validation
• noting the average amount donation

@Tsevener Noting @Ejegg 's etherpad notes

@scblr and @OTichonova are going to refresh the designs on this task to match the API Calls so I am putting this in the design column on the iOS board. Please also consider our Slack conversation in the designs.

Updated the description with this additional step @Tsevener @JTannerWMF @OTichonova

{F37621513}

I did not update the designs with preselection per @Pcoombe’s comment on Slack for now:

We usually find that not prefilling anything and leaving it up to the user is best

It’d be interesting to test its effect on donations if we preselect (future A/B test?)

I updated the task as we discussed last Wednesday @JTannerWMF.

Notes:

• I consolidated the previously discussed variants: "Apple Pay takes users to donatewiki" and "Wrap in Web view completely" in Variant B (see task description). Reasons:
  • We can’t take users to the checkout flow without an amount.
  • The in-app web version does feature Apple Pay when available on the user’s device (see this screenshot).
• Please take a look at the proposed banner variants on Figma based @Dmantena’s comments. It’ll be important for @Tsevener to know which one we’ll move forward with.

Looks good to me. I was able to make multiple donations and step through the flow (including Apply Pay) on 7.4.3 (2811)