Add Amazon Pay API binding

[amk-stripe]

Summary

Add Amazon Pay API bindings

Motivation

https://jira.corp.stripe.com/browse/MOBILESDK-1679

I set shouldRefreshIfIntentRequiresAction to true for the AmazonPay payment type. This is because we will need this set when we remove the redirect trampoline from AmazonPay and setting it now means that that change will be backwards compatible (i.e. old SDK versions will be work properly even when the redirect trampoline is removed).

Testing

• Added tests
• Modified tests
• Manually verified

Also manually verified (via debugger) that we do not currently refresh even when shouldRefreshIfIntentRequiresAction=true

Screenshots

• amazon pay works.webm
• amazon pay works - failed payment.webm

Changelog

[Added]8028 Added support for Amazon Pay to API bindings.

[github-actions]

Diffuse output:

OLD: paymentsheet-example-release-master.apk (signature: V1, V2)
NEW: paymentsheet-example-release-pr.apk (signature: V1, V2)

          │           compressed           │         uncompressed         
          ├───────────┬───────────┬────────┼───────────┬───────────┬──────
 APK      │ old       │ new       │ diff   │ old       │ new       │ diff 
──────────┼───────────┼───────────┼────────┼───────────┼───────────┼──────
      dex │   3.9 MiB │   3.9 MiB │ +107 B │   8.6 MiB │   8.6 MiB │ +8 B 
     arsc │   2.5 MiB │   2.5 MiB │    0 B │   2.5 MiB │   2.5 MiB │  0 B 
 manifest │   5.1 KiB │   5.1 KiB │    0 B │  25.4 KiB │  25.4 KiB │  0 B 
      res │ 970.6 KiB │ 970.6 KiB │    0 B │   1.5 MiB │   1.5 MiB │  0 B 
   native │   2.6 MiB │   2.6 MiB │    0 B │     6 MiB │     6 MiB │  0 B 
    asset │     3 MiB │     3 MiB │   -2 B │     3 MiB │     3 MiB │ -2 B 
    other │ 211.5 KiB │ 211.5 KiB │   -7 B │ 472.5 KiB │ 472.5 KiB │  0 B 
──────────┼───────────┼───────────┼────────┼───────────┼───────────┼──────
    total │  13.1 MiB │  13.1 MiB │  +98 B │    22 MiB │    22 MiB │ +6 B 

 DEX     │ old   │ new   │ diff      
─────────┼───────┼───────┼───────────
   files │     1 │     1 │ 0         
 strings │ 42674 │ 42674 │ 0 (+1 -1) 
   types │ 14550 │ 14550 │ 0 (+0 -0) 
 classes │ 12296 │ 12296 │ 0 (+0 -0) 
 methods │ 60748 │ 60748 │ 0 (+0 -0) 
  fields │ 40163 │ 40163 │ 0 (+0 -0) 

 ARSC    │ old  │ new  │ diff 
─────────┼──────┼──────┼──────
 configs │  328 │  328 │  0   
 entries │ 7269 │ 7269 │  0

APK

    compressed     │   uncompressed   │                               
──────────┬────────┼───────────┬──────┤                               
 size     │ diff   │ size      │ diff │ path                          
──────────┼────────┼───────────┼──────┼───────────────────────────────
  3.9 MiB │ +107 B │   8.6 MiB │ +8 B │ ∆ classes.dex                 
 68.2 KiB │   -4 B │ 153.6 KiB │  0 B │ ∆ META-INF/CERT.SF            
  7.2 KiB │   -2 B │   7.1 KiB │ -2 B │ ∆ assets/dexopt/baseline.prof 
 54.7 KiB │   -2 B │ 153.5 KiB │  0 B │ ∆ META-INF/MANIFEST.MF        
  1.2 KiB │   -1 B │   1.2 KiB │  0 B │ ∆ META-INF/CERT.RSA           
──────────┼────────┼───────────┼──────┼───────────────────────────────
    4 MiB │  +98 B │   8.9 MiB │ +6 B │ (total)

DEX

STRINGS:

   old   │ new   │ diff      
  ───────┼───────┼───────────
   42674 │ 42674 │ 0 (+1 -1) 
  + ~~R8{backend:dex,compilation-mode:release,has-checksums:false,min-api:21,pg-map-id:17d4df2,r8-mode:full,version:8.2.47}
  
  - ~~R8{backend:dex,compilation-mode:release,has-checksums:false,min-api:21,pg-map-id:e286369,r8-mode:full,version:8.2.47}

[amk-stripe]

This activity is a more complex than necessary in that it supports selecting different payment intent types, but there's only one option (Payment) right now. This is because we'll soon be adding some other payment intent types and it will be easier to add them later on if I just keep this a little extra complicated for now.

[jaynewstrom-stripe]

Would it make sense/be possible to refactor all of the LPMs to have a shared architecture? Obviously not on this PR, but just wondering if it's possible or makes sense.

[amk-stripe]

Yes, it would make sense and be possible. Maybe not for all of the LPMs, but for many of them.

A lot of the LPM example activities are of the form:

• (optionally) some number of radio buttons to select which payment type to use
• a pay button

And I think all of those activities could fairly easily use the same architecture.

Some of the LPM example activities (e.g. iDEAL) have more complex forms and I'm not sure it'd be worth the effort to generalize those ones (it seems harder and there are fewer of them, so the ROI of sharing the architecture seems lower)

[jaynewstrom-stripe]

Makes sense, especially for the examples. Definitely worth keeping this idea in our back pocket.

[jaynewstrom-stripe]

I thought there was also something we needed to do to remove the next actions from LUXE. (in lpms.json).

[jaynewstrom-stripe]

Can you add this under a ### Payments header?

[amk-stripe]

done -- thanks for reminding me about this!

[jaynewstrom-stripe]

Would it make sense/be possible to refactor all of the LPMs to have a shared architecture? Obviously not on this PR, but just wondering if it's possible or makes sense.