64 lines
4.0 KiB
Markdown
64 lines
4.0 KiB
Markdown
# SXCHNGE wallet
|
|
|
|
Shared Flutter domain, injectable services and providers for accounts, quotes,
|
|
operations, limits synchronization and account language. Web and mobile clients
|
|
consume the same models; widgets do not call transport APIs.
|
|
|
|
`WalletService` returns mapped domain models. `DummyWalletService` is an in-memory
|
|
backend stand-in; `WalletProvider` owns snapshots and pending-operation refresh,
|
|
`TransferProvider` owns draft/review/submission/reconciliation, and
|
|
`WorkspaceLimitsProvider` refetches the separate `LimitsService` projection when
|
|
wallet state changes. The adapter reuses the KYC package's limit DTO and mapper.
|
|
|
|
## Demo behavior
|
|
|
|
- Opening balances: EUR 75, USD 0, GBP 0. No invented historical transactions.
|
|
- Fixed demo ratios: EUR/USD 1.1; GBP uses weight 1300 vs EUR 1100 and USD 1000.
|
|
- Top-up fee zero; exchange fee 0.5% rounded down, minimum one minor unit;
|
|
payout fee 100 minor units. Quote expiry is 60 seconds.
|
|
- Top-ups credit only after settlement. Outgoing total debit includes the fee;
|
|
it leaves available balance on acceptance. Failed outgoing operations restore
|
|
that exact total. Exchange destination credits only on completion.
|
|
- Outgoing usage, including fees, is converted upward to EUR minor units.
|
|
Basic caps: EUR 100/day and 500/month; verified: 2500/day and 10000/month.
|
|
Top-ups do not consume outgoing capacity. Windows follow the stub's local clock.
|
|
Policy, usage and remaining are returned by the service, not set in widgets.
|
|
- Submission rechecks balance, limits and expiry, is idempotent by request key,
|
|
and permits a quote to execute only once. Unknown outcomes reconcile before
|
|
any resubmission. `nextError`, `loseNextResponse`, `failNextOperation`, injectable
|
|
clock/delays support deterministic failure testing.
|
|
- Everything resets on application reload. Recipient values are demo text only;
|
|
no bank details, payment provider, storage or real money movement is connected.
|
|
|
|
## Integration boundary
|
|
|
|
Backend mode now uses `BackendWalletService` and `WalletFactorService` with the
|
|
authenticated BFF; `BackendLimitsService` supplies the reviewed platform projection.
|
|
See [payment provisioning and rollout](../../../docs/payments.md). The backend must provide authorization, authoritative quotes/balances,
|
|
atomic limits enforcement, durable idempotency and operation reconciliation.
|
|
Add supported payment methods and validated recipients from that contract, rather
|
|
than interpreting the demo input as production bank validation. Replace profile
|
|
storage with the signed-in account endpoint. No authorization is supplied by
|
|
public demo routes or an available balance.
|
|
|
|
Analytics use the shared typed recorder: draft, quote, submission and authoritative
|
|
settlement. Retried submissions keep a journey; each accepted operation closes
|
|
once on success/failure. Closing the app while pending does not count as draft
|
|
abandonment. No amounts, account IDs or recipient data enter events. All demo
|
|
signals are simulated. Cross-session outcomes require backend event delivery;
|
|
client-only analytics are not production accounting or conversion evidence.
|
|
|
|
## Saved destinations — #54
|
|
|
|
The injectable `DestinationService` adds canonical crypto, secure-card capture and
|
|
Russian bank models, saved/one-time input, independent metadata/execution revisions,
|
|
stable created/duplicate outcomes, contextual eligibility and management providers.
|
|
`DummyDestinationService` is customer-scoped and process-local. It has isolated
|
|
fixtures for directory/capture/recovery states, not live banking or card collection.
|
|
The demo wallet binds immutable destination snapshots to quotes and rechecks at its
|
|
synchronous acceptance boundary. Production must enforce those checks atomically
|
|
in the backend. Live mode currently advertises no new destination capabilities and
|
|
preserves explicit selection of the already provisioned wallet method. It never
|
|
uses a demo store. See [the UX/service contract](../../../docs/ux/payout-destinations.md)
|
|
for integration, security, retention, localization and acceptance requirements.
|