Implement mobile payment send validation layer

[El-swaggerito]

Description

Difficulty: Expert

Type: Feature

Summary

Implement a validation layer for mobile payment send flows.

Current Behaviour

The send flow may not consistently validate recipient, amount, memo, network state, balance availability, and submission readiness.

Expected Behaviour

The mobile app should validate payment inputs before transaction submission and show clear errors.

Suggested Implementation

Create validation utilities, screen integration, error states, tests, and documentation.

Files or Areas Likely Affected

• src/payments/
• src/screens/
• src/components/
• src/transactions/
• tests/
• docs/

Acceptance Criteria

• Payment validation layer is implemented.
• Recipient and amount validation are included.
• Memo and network readiness are handled where applicable.
• User-facing error states are clear.
• Tests cover valid and invalid send inputs.
• Docs explain validation behaviour.

Additional Notes

This should include real implementation and tests.

[jrcity]

Hello Maintainer,

I’d like to take on this issue because payment validation is a part of the send flow where correctness matters before a transaction ever reaches the signing/submission stage. I have experience building React/TypeScript applications and transaction-oriented flows, and I’m particularly interested in approaching this as a proper validation layer rather than adding scattered checks directly inside the UI.

I would first trace the existing send flow across src/payments/, src/screens/, and src/transactions/ to understand the current transaction and network abstractions. I’d then centralize validation for recipient format, amount/balance constraints, memo rules, network readiness, and submission readiness, returning predictable validation results that the UI can translate into clear, actionable errors.

I’ll also cover both valid and invalid paths with focused tests, including boundary cases, and document the validation rules so future changes don’t introduce inconsistent behavior. Given the financial nature of the feature, I’ll be especially careful about preventing invalid amounts, insufficient balances, incorrect recipient data, and submission attempts while the network/wallet is not ready.

I’ll keep the implementation aligned with the existing architecture, avoid duplicating transaction logic, and validate the complete flow with tests, lint/type checks, and the project’s existing tooling before opening the PR.