# Two-factor verification — task #32

Use a SXCHNGE-designed challenge page: themed security icon, clear purpose,
operation summary when moving money, one labeled six-digit input, Verify and
continue, contextual delivery recovery and Cancel. Avoid six separate focus
boxes, automatic submission, repeated banners and raw service error text.

Email is the initial service fixture. Method is carried in settings and challenge
DTO/model contracts. Authenticator/TOTP challenges use their own instruction and
have no email target or resend controls. The reusable shared page accepts labels
and an optional summary, so clients supply their own localization and context.
Authenticator enrollment/secret provisioning is a future backend capability;
it is not offered as a working setting without that contract. No Sendico UI or
code is copied. Its pending-login concept informed the separation of steps.

Profile shows current protection status and verified enable/disable actions.
Cancel changes nothing. No optimistic protection toggle: the service result
must confirm the new setting. The existing stub has one account and resets on
reload. Production settings must be account-scoped and authenticated.

Login first validates credentials. A pending result is not a session or login
success; complete it only after consuming a matching approval. Clear the password
before opening the challenge. Cancel returns to login without successful state.

All top-ups, exchanges and payouts request a factor when service policy requires
it. The challenge binds to the quote ID; its one-use grant is checked by the
operation adapter before money moves. Editing, expired quotes, mismatched grants
and reuse cannot authorize a different transaction. Existing idempotency and
unknown-outcome reconciliation remain authoritative. Cancel returns to the review
with the draft preserved. Expired quotes require fresh review and confirmation.

Invalid code preserves context; retry stays in the same challenge. Email resends
have service-owned cooldowns and replace the previous challenge. Expired code,
rate limiting and unavailable service have localized recovery. Verification and
resend disable duplicate actions, clean up timers/controllers on disposal, and
ignore late results. Pasted codes, keyboard submission, live errors and EN/RU
mobile layouts must work.

Measurement extends existing typed journeys with factor delivery/verification and
settings outcome steps. Login completion waits for the final login result;
transaction completion still waits for settlement. Cancelled challenges do not
claim success. No code, email target, challenge ID, grant, secret, amount or
recipient enters analytics or route URLs. Events retain the simulated flag.
Actual MFA enforcement, OTP delivery/validation, enrollment and recovery must run
on the backend before production use.

## Measurement and review evidence

- The existing login/transaction attempt owns verification and retries. A factor
  success is an intermediate step; only completed login, confirmed settings save
  or transaction settlement can complete its parent journey.
- `factor_challenge` measures settings/transaction policy checks and challenge
  creation failures. `factor_delivery` measures email resends;
  `factor_verification` measures code checks and explicit cancellation;
  `factor_settings` measures the confirmed setting update. Login's existing
  credential step includes initial challenge creation and its failures.
- Product/support can compare failure and resend rates by typed step, and measure
  completion/duration per distinct parent journey. Retries remain in that journey;
  its existing timeout/explicit-navigation rules close abandoned attempts. Pending
  money operations continue through the existing settlement recorder.
- Browser review: desktop 1280×720 and mobile 390×844; theme roles, heading, input,
  buttons, invalid-code recovery, keyboard submission and confirmed setting status.
  Widget tests additionally cover Russian at 320px and 1.6× text scale, all money
  entry points, cancellation, service errors and missing route context.
- Analytics tests check correlation, one terminal login outcome, cancellation,
  challenge creation failure and absence of codes in event payloads. Stub policy
  remains simulated even if a credentials adapter returns a non-simulated result.
  Backend/cross-device outcomes remain unavailable until services are integrated.