StripeCryptoOnramp SDK: Better Cancellation Signaling

[Twigz]

Summary

• Adds new didSelectPaymentOption Bool to signal from Link to Onramp that a payment option was selected or not. This helps CryptoOnramp know if a payment option was selected as part of collection, or was just preserved as part of a previous selection.
• Adds new state property paymentSourceBeforeApplePay to track an existing payment source during the Apple Pay flow, so that we can preserve the accuracy of selectedPaymentSource if the multi-step apple pay flow is not completed.

Motivation

Making iOS payment collection more in line with how Android handles cancellation.

Testing

1. Login.
2. Go to collect a card.
3. Cancel, make sure it receives a cancellation result.
4. Collect a card, and successfully collect one.
5. Go to collect a card, cancel, make sure you receive a cancellation result, but preserve previously selected card.
6. Make sure checkout still works.
7. Run these steps again, but with Apple Pay
8. Run these steps again, but switch back and forth between Link and Apple Pay.

[jeanregisser]

Thanks, I'll finish reviewing tomorrow,
Note that there's also this proposition: #6354
We can discuss during our sync meeting.

[jeanregisser]

Nice, this is a clean fix. One thought on the Apple Pay state. ✨

[jeanregisser]

Have we considered flipping the direction here? Instead of saving what we had before and restoring on cancel, we could use a pendingApplePayPaymentSource that only gets promoted to selectedPaymentSource in didCompleteWith(.success) - leaving it untouched on cancel/error, with nothing to restore. It'd also make cleanup symmetric: just pendingApplePayPaymentSource = nil at the end of didCompleteWith in all cases.

[mliberatore]

Good idea, hadn't thought about it that way. It reduces the overall management of that state. I‘ve implemented the suggestion in 73a636f.

[jeanregisser]

🚀