[Mobile Payments] Add badges leading to Set up Tap to Pay

[joshheald]

Part of: #9582

Description

To inform merchants about Tap to Pay being available, we are adding badges to lead merchants to the Set up Tap to Pay on iPhone screen.

These will be shown to merchants whose phone and site could support Tap to Pay, but who have not used it yet.

The badges are added to:

• The Menu tab item
• The Payments row in the Hub Menu
• The Set up Tap to Pay on iPhone row in the Payments Menu

All badges will remain until the merchant opens the Set up Tap to Pay on iPhone screen – after this, they will be removed, regardless of whether the merchant goes through the flow. Alternatively, if they take a Tap to Pay payment without going through the Set up flow, the badges will also be removed.

This PR adds the badges, and some of the removal logic, but is missing three key bits of logic

1. The badges will be shown on any store or device, regardless of Tap to Pay support or previous activity.
2. After removal, the badges will return the next time you open the app.
3. Taking a Tap to Pay payment will not remove the badges

These items will be done in a future PR. This work is feature flagged by featureFlagService.isFeatureFlagEnabled(.tapToPayBadge)

Testing instructions

Open the app
Observe that the badge is shown on the Menu tab
Navigate to Menu
Observe that the badge is shown on the Payments row
Navigate to Payments
Observe that the badge is shown on the Set up Tap to Pay on iPhone row
Tap Set up Tap to Pay on iPhone
Tap Cancel
Observe that the badges are removed, on the Menu tab and the Set up Tap to Pay on iPhone row
Tap <
Observe that the badge is removed on the Payments row.

Screenshots

badge-set-up-tap-to-pay.mp4

(n.b. I fixed the slight delay in badging the row when the In Person Payments Menu is loaded after recording this video, in 6c81716)

---

• I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

[wpmobilebot]

You can test the changes from this Pull Request by:

• Clicking here or scanning the QR code below to access App Center
• Then installing the build number pr9801-7fea486 on your iPhone

If you need access to App Center, please ask a maintainer to add you.

[iamgabrielma]

Tests well. LGTM! 🚢

[iamgabrielma]

Just wondering: Wouldn't inherit like class BadgedLeftImageTableViewCell: LeftImageTableViewCell remove the need to declare leftImage, labelText, ... and we could have only the extensions to setup this view?

[iamgabrielma]

That's convenient! 💯

[joshheald]

Yep. Notifications need to be used with care, but I think it's appropriate here.

[iamgabrielma]

Just to clarify if I understood correctly why this method call: This is basically a configuration method, right? We're not adding it to the viewmodel's init because we don't want to rely on the viewModel's lifecycle, and wait for this to be initialized to trigger this configuration. And at the same time, we want the config logic to be testable, so we extract it from the view to the model.

[joshheald]

IIRC, we're not using the init because the view model is created optimistically, the user may not actually open the screen. We use this viewModel.viewDidAppear to trigger the notification, which we respond to in other places by removing all the badges... so we only want to do that when it actually appears.

[iamgabrielma]

I don't think is necessary as we're already weakifying self, but should we add a guard just to remove optionality?

Suggested change

	viewModel.$shouldBadgeTapToPayOnIPhone.sink { [weak self] _ in
	self?.configureSections()
	// ensures that the cell will be configured with the correct value for the badge
	DispatchQueue.main.async {
	self?.tableView.reloadData()
	}
	}.store(in: &cancellables)
	viewModel.$shouldBadgeTapToPayOnIPhone.sink { [weak self] _ in
	guard let self = self else { return }
	self.configureSections()
	DispatchQueue.main.async {
	self.tableView.reloadData()
	}
	}.store(in: &cancellables)

[joshheald]

I don't think there's a benefit to removing the optionality here, but thanks for the suggestion 😊