fix(maestro/pay-tests): adapt KYC flows to redesigned /collect inline IC form

[ignaciosantise]

Part A — adapt native Maestro KYC flows to the redesigned /collect IC form

WalletConnect/buyer-experience PR #914 redesigns the hosted KYC webview (the /collect route that sample wallets open in a WebView). The redesign changes the strings/flow that the native Maestro pay flows in this repo rely on:

Step	Before	After #914
Page title	"Add your personal details"	unchanged ✅
Submit button	"Add"	"Confirm"
Confirmation dialog	"Confirm your details" popup	removed — Confirm submits directly
Consent	tapped Terms link string	inline checkbox consent-checkbox / aria-label "I agree"; Confirm disabled until checked

Changes

• pay_multiple_options_kyc.yaml — replace the Add → dialog → consent-link → Confirm chain with: tick consent-checkbox, then tap identity-form-confirm-button.
• pay_cancel_from_kyc.yaml — same replacement (server-side cancel + result-screen assertions unchanged).
• pay_kyc_back_navigation.yaml — not touched (only waits for the unchanged title; never submits).

⚠️ Sequencing — do not merge until #914 is deployed

The new steps only pass against an environment where buyer-experience #914 is already deployed to the env the sample wallets load their /collect webview from. The old steps pass only against the old form — they are mutually exclusive.

1. Merge & deploy buyer-experience #914.
2. Verify the new /collect form is live (open it manually).
3. Merge this PR.
4. Bump the pinned SHA in the 4 consumer repos (kotlin / swift / flutter / react-native-examples).

⚠️ Selector uncertainty (verify on a real WebView run)

Maestro matches WebView elements via the accessibility tree; data-testid is not guaranteed to surface as a Maestro id. Validate on a real run:

• Consent: prefer id: "consent-checkbox". Fallback is labeled "I agree" — but do not use a bare text: "I agree" (the consent paragraph also contains "I agree" in quotes; disambiguate with index/longer substring). Keep retryTapIfNoChange: true.
• Confirm: prefer id: "identity-form-confirm-button"; fallback text: "Confirm" (now unambiguous).

Draft until the selectors are validated on a real run against a #914-deployed env.

🤖 Generated with Claude Code

[claude]

Claude finished @ignaciosantise's task in 1m 28s —— View job

---

Code Review

• Gather context
• Read changed files
• Analyze changes
• Post review findings

Found 2 issue(s)

Issue 1: Dangling comment reference with no corresponding note

ID: pay-multiple-options-kyc-dangling-comment-ref-b3f1
File: maestro/pay-tests/.maestro/pay_multiple_options_kyc.yaml:54
Severity: LOW
Category: code_quality

Context:

• Pattern: Comment reads # See VERIFY note below re: selector choice but no "VERIFY note" exists below in the file
• Risk: Misleads readers into searching for documentation that isn't there
• Impact: Confusing to future maintainers; the actual guidance lives in the PR description, not the file

Recommendation: Either remove the comment or replace it with the actual guidance inline:

# Selector note: id: "consent-checkbox" preferred; fallback text "I agree" is ambiguous
# (appears in consent paragraph) — disambiguate with index if needed. Verify on real WebView.

---

Issue 2: No extendedWaitUntil before tapping consent-checkbox

ID: pay-kyc-flows-no-wait-consent-checkbox-7c2e
File: maestro/pay-tests/.maestro/pay_cancel_from_kyc.yaml:50, pay_multiple_options_kyc.yaml:55
Severity: LOW
Category: code_quality

Context:

• Pattern: Both flows wait for the page title "Add your personal details" to be visible, then immediately tapOn id: "consent-checkbox" with no explicit wait for the checkbox element itself
• Risk: If the form's consent checkbox renders asynchronously after the page title appears (common in React/web views), the tap fires before the element is interactable; retryTapIfNoChange: true only retries on no-change, not on element-not-found
• Impact: Intermittent test failures, particularly on slower devices or cold-load scenarios

Recommendation: Add an explicit wait for the checkbox before tapping:

- extendedWaitUntil:
    visible:
      id: "consent-checkbox"
    timeout: 10000
- tapOn:
    id: "consent-checkbox"
    retryTapIfNoChange: true

---

The core logic of the change — replacing the old Add → dialog → terms-link → Confirm chain with a direct checkbox + confirm-button flow — looks correct and aligns with the redesign described in the PR. The cancel flow ordering (server-side cancel → form submit → result screen) is preserved from the old code. Fix this →