[Experiment] Card payments facade/adaptors with UI

[joshheald]

trafficstars

Description

Builds on #12735 to add the onboarding and payments UI.

This adapts and reuses the existing payments code and, as much as possible, the UI.

Onboarding UI is presented without the UIKit wrapper used in the existing app.

Connection and Payments UI is reimplemented, but relies on wrapped versions of the existing view models. The wrappers only exist to make the VMs identifiable, and otherwise wouldn't be required.

TODOs

These reimplemented UIs don't have buttons yet, so you can't go all the way through the flow unless it wouldn't require a button tap.

At the moment, we're using a fake order so the payment doesn't actually work.

I'll work on those tomorrow to fully prove the concept.

Screenshots

https://github.com/woocommerce/woocommerce-ios/assets/2472348/584a44c7-641e-425d-95de-2b05f4e27e64

[dangermattic]

	1 Warning
:warning:	This PR is larger than 500 lines of changes. Please consider splitting it into smaller PRs for easier and faster reviews.

	1 Message
:book:	This PR is still a Draft: some checks will be skipped.

Generated by :no_entry_sign: Danger

[iamgabrielma]

Looking great. Any idea where we should handle the differences between app and pos regarding, for example, reader types, supported country, supported plugins, etc, ... ? Perhaps this should be done in the adaptor, where we can initiate or exit/cancel the process early based on eligibility/limitations?

[joshheald]

Any idea where we should handle the differences between app and pos regarding, for example, reader types, supported country, supported plugins, etc, ... ? Perhaps this should be done in the adaptor, where we can initiate or exit/cancel the process early based on eligibility/limitations?

No, I don't think it should be in the adaptor – ideally we'll be able to use the adaptor from both the app and pos code that needs to take payments, and make them both use SwiftUI so we can improve the app uses as well. That's all well outside POS MVP scope, and subject to whether we keep the app uses of card payments. But if we do it, refactoring the payments code in future becomes way easier.

The adaptor's job is adapting from the UIKit-focus and store/action usage of the existing code, to a SwiftUI and async/await friendly API for card present payments.

So we should handle the differences elsewhere. The gate between the app and POS experiences is one option. Another is the code which actually shows the UI and uses the adaptor (PointOfSalePaymentsTestView and ViewModel in this PR) – e.g. not showing the Enable Pay in Person onboarding step might be done here.

Another way is to have two different CardPresentPaymentsConfiguration for each country, one for POS and one for App. These could be passed in to collectPayment and used accordingly – though that may need some validation of whether it would result in an unsupported reader being disconnected when we move from App to POS, for example. (From our discussion the other day though, we probably don't actually need to do that, it'll just work, so let's allow the other readers if they're supported.)

[wpmobilebot]

📲 You can test the changes from this Pull Request in WooCommerce iOS by scanning the QR code below to install the corresponding build.

	App Name	WooCommerce iOS
	Build Number	pr12760-ff82cc7
	Version	18.6
	Bundle ID	com.automattic.alpha.woocommerce
	Commit	ff82cc707f2fc25aebcc539db5ce060db282933e
	App Center Build	WooCommerce - Prototype Builds #9153

Automatticians: You can use our internal self-serve MC tool to give yourself access to App Center if needed.

[malinajirka]

Closing as this PR is not active anymore.