A financial interface can look simple on the surface: a wallet, a card, and a few actions such as Top Up, Details, or Freeze. But each action may involve a different object, a separate state, and an asynchronous process.
For developers, the challenge is to understand how these parts should work together before implementation and testing begin.
This article uses 67 (SixSeven) as a product context for discussing that challenge. It is a UX and state-modeling case study, not an integration tutorial.
Scope note: The available materials for this analysis do not include exported Mini App screens, a detailed interaction brief, or API documentation. Therefore, the flows below are proposed analytical models based on the action labels in the brief. They should not be read as verified descriptions of SixSeven's actual interface or backend behavior.
1. Start with the available evidence
When analyzing a product without access to its implementation, the first task is to separate facts from assumptions.
For a Mini App, useful evidence may include:
Public product descriptions.
Terms of use and information about service providers.
Available interface labels and action names.
Platform documentation.
Product requirements, if they are available.
These sources answer different questions.
Public product information helps establish what the service offers. Terms of use can clarify which parties provide particular services and where responsibilities lie. Platform documentation explains the environment in which the interface runs.
None of these sources automatically reveals the internal architecture, API endpoints, request formats, or exact sequence of UI transitions.
That distinction matters. A developer can propose a reasonable state model without claiming that the product already implements it.
2. Separate the wallet, card, and top-up states
A common modeling mistake is to treat the wallet and card as two views of the same balance.
They should be considered separate financial objects until the product documentation confirms how they are connected.
Wallet
The wallet represents a balance or a set of funds managed within the product. Its interface may need to distinguish between:
Available funds.
Pending funds.
A balance that is temporarily unavailable.
A balance that has not yet been refreshed.
These are possible UI states to consider, not confirmed SixSeven balance categories.
Card
The card represents a payment instrument. Its state is different from the wallet's balance state.
For example, a card could be active, frozen, or awaiting activation. Its displayed information may also update independently from the wallet.
A card being frozen does not necessarily mean that the wallet balance has changed. The interface should communicate these objects separately.
Top-up operation
Top Up should be modeled as an operation with its own lifecycle, rather than as an immediate change to the wallet balance.
A useful analytical model includes:
Initiated – the user has started the operation.
Pending – the result has not yet been confirmed.
Processing – the operation is being handled.
Completed – the operation has a confirmed successful result.
Failed – the operation could not be completed.
Cancelled – the operation was stopped before completion.
The exact statuses depend on the payment provider and product design. The list above is a proposed model for UX and QA planning.
Illustrative UX model based on available action labels, not a verified SixSeven implementation.
3. Map the main user actions
Without screenshots, it would be inaccurate to describe exact screens or claim that a particular button opens a specific page. We can still use the action labels from the brief to identify the questions a developer should resolve.
Top Up: from user intent to confirmed balance
A top-up flow should answer three basic questions:
What amount is the user trying to add?
Has the operation been accepted for processing?
When can the user see the funds in the wallet?
A possible high-level flow is:
Wallet → Top Up → Amount and payment method → Processing → Result → Updated balance
This is a proposed scenario, not a verified SixSeven navigation path.
The most important UX decision is how the interface behaves while the operation is pending. If the user sees the old balance without an explanation, they may try to repeat the payment.
A clear pending state should explain that the operation has not yet reached a confirmed result. The interface should also prevent accidental duplicate submissions where appropriate.
Details: make the financial context visible
A Details action should help users understand what they are looking at.
For a wallet, useful information might include the balance, currency, and recent activity. For a card, users may need to see its status and relevant card information.
The key design question is whether Details refers to the wallet, the card, or a specific transaction.
These contexts should not be mixed. A user opening card details should not have to guess whether the displayed amount represents the wallet balance, a card balance, or a transaction amount.
Freeze: separate card status from account status
Freeze is a particularly useful example of why financial objects need independent states.
A possible card-state model is:
Active → Freeze requested → Frozen
And, if the product supports it:
Frozen → Unfreeze requested → Active
The interface should distinguish a user action from its confirmed result. If the user taps Freeze, the card should not necessarily be shown as frozen before the system confirms the change.
The product should also explain what freezing affects. Does it block new card payments? Are recurring payments affected? Can pending transactions still be completed?
These are product and provider questions. They cannot be answered from the button label alone.
4. Account for the Telegram Mini App environment
A Mini App is not simply a website displayed inside a messaging app. Telegram provides a specific environment with its own interface behavior and platform capabilities.
The official Telegram Mini Apps documentation describes several implementation considerations:
Mini Apps should use responsive, mobile-first layouts.
The interface can receive the user's current Telegram color theme.
The app should respect safe areas and content safe areas.
The visible viewport can change as the Mini App expands or collapses.
Data received through initData must be validated on the bot's server before it is trusted.
These details affect both UX and testing.
For example, a confirmation button placed near the bottom of a screen should remain accessible when the viewport changes. A balance or card status should remain readable in both light and dark themes.
The security point is especially important: Telegram's documentation warns developers not to trust initDataUnsafe and recommends validating the raw initData on the server.
This is a platform-level requirement. It does not tell us how SixSeven implements authentication or handles financial requests.
5. What should be tested?
A useful test plan should cover more than the successful path.
For a wallet-to-card scenario, the following questions are worth checking.
Wallet and balance
Does the displayed balance update after a confirmed top-up?
What happens while the operation is pending?
Does the interface distinguish an unavailable balance from a zero balance?
What happens if the balance refresh fails?
Top Up
Can the user submit the same operation twice?
What happens if the user closes the Mini App during processing?
Is an error message shown when the operation fails?
Does the interface handle a delayed confirmation?
Card and Freeze
Is the card status updated only after confirmation?
Is the user told what freezing changes?
What happens if the status update fails?
Can the user distinguish a frozen card from a card that is temporarily unavailable?
Telegram environment
Does the layout adapt to different viewport heights?
Are controls visible in light and dark themes?
Are important actions still accessible on smaller screens?
Is user-provided initialization data validated on the server?
To run these tests against a real product, a team would need more than UI labels. Useful inputs include screen specifications, expected state transitions, test accounts, provider responses, error cases, and a documented source of truth for balances and card status.
Without those materials, the team can prepare a test matrix, but it cannot verify the actual backend behavior.
6. What we can conclude without API access
A limited evidence set does not make UX analysis impossible. It changes what kind of conclusions are appropriate.
For a wallet-to-card Mini App, developers can still:
Identify separate financial objects.
Propose independent state models.
Map expected user intentions.
Define loading, pending, success, and error states.
Prepare questions for product and backend teams.
Build a QA checklist for later implementation testing.
What they cannot responsibly do is invent endpoint names, request payloads, authentication flows, or claim that a proposed transition matches the production application.
For this SixSeven case study, Top Up, Details, and Freeze are useful starting points for modeling the user journey. The next step toward a verified flow would be access to the actual screens, interaction requirements, and technical documentation.
The practical lesson: when API access is unavailable, model what the user needs to understand and what the interface must communicate. Keep confirmed product facts separate from proposed behavior. That gives designers, developers, and QA engineers a shared starting point without pretending that undocumented implementation details are known.
References
Top comments (0)