diff options
Diffstat (limited to 'design-documents')
113 files changed, 1064 insertions, 403 deletions
diff --git a/design-documents/014-merchant-backoffice-ui.rst b/design-documents/014-merchant-backoffice-ui.rst index eaf435a4..1f744a15 100644 --- a/design-documents/014-merchant-backoffice-ui.rst +++ b/design-documents/014-merchant-backoffice-ui.rst @@ -139,11 +139,3 @@ Story #4: Manage inventory - change product description / price / etc. - delete products from inventory - - -Story #5: Manage rewards ------------------------- - -- set up reward reserve - -- check reward reserve status diff --git a/design-documents/020-backoffice-rewards-management.rst b/design-documents/020-backoffice-rewards-management.rst index 1eef39b1..8345a3b9 100644 --- a/design-documents/020-backoffice-rewards-management.rst +++ b/design-documents/020-backoffice-rewards-management.rst @@ -1,4 +1,4 @@ -DD 20: Backoffice Rewards Management +XX 20: Backoffice Rewards Management #################################### Summary diff --git a/design-documents/023-taler-kyc.rst b/design-documents/023-taler-kyc.rst index 4d8f2cbc..01e3ec7f 100644 --- a/design-documents/023-taler-kyc.rst +++ b/design-documents/023-taler-kyc.rst @@ -19,7 +19,7 @@ Requirements The solution should support fees to be paid by the user for the KYC process (#7365). -Taler needs to run KYC checks in the following circumstances: +Taler needs to take *measures* based on the following primary *triggers*: * Customer withdraws money over a monthly threshold @@ -40,24 +40,161 @@ Taler needs to run KYC checks in the following circumstances: * key: IBAN (encoded as payto:// URI) -* Reserve is "opened" for invoicing or rewards. +* Reserve is "opened" for invoicing. * key: reserve (=KYC account) long term public key per wallet (encoded as payto:// URI) +* Import of new sanctions lists and triggering of measures against matches of existing + customer records against the list + + +For the different *measures*, there are various different possible KYC/AML *checks* +that could happen: + +* In-person validation by AML staff +* Various forms to be filled by AML staff +* Validation involving local authorities and post-office +* Online validation, sometimes with multiple options (like KYC for multiple people): + + * Forms to be supplied by user (different types of ID) + * Interactive video + * Documents to be supplied (business register) + * Address validation (e-mail or phone or postal) + +Additionally, the process is dynamic and conditional upon various decisions: + +* Individual vs. business +* PEP or non-PEP +* Hit on sanctions list +* Type of business (trust, foundation, listed on stock market, etc.) +* Need for plausibilization (via documents by user or staff research) +* Periodic updates (of customer data, of sanction lists) and re-assessment + +There are also various *outcomes*: + +* normal operation (with expiration date) +* normal operation but with AML staff investigating (new measure) +* held, requesting customer documentation (new measure) +* held, AML staff reviewing evidence for plausibilization (new measure) +* automatically frozen until certain day (due to sanctions) +* institutionally frozen until certain day (due to order by state authority) + +The outcome of a *check* can trigger further *measures* (including +expiration of the outcome state). + + +Finally, we need to produce statistics: + +* number of incidents reported (voluntarily, required) +* number of business relationships at any point in time +* number of risky business relationships (PEP, etc.) +* number of frozen transactions (authority vs. sanction) with start-date and end-date +* start-data and end-date of relationships (data retained for X years after end of relationship) + +For this high-level monitoring, we need certain designated critical events to +be tracked in the system statistics: + + * account opened + * set to high risk + * set to low risk + * suspicious activity report filed with authority + * account frozen + * account unfrozen + * account closed + +As a result, we largely end up in a large state machine where the AML staff has +serious flexibiltiy while the user needs guidance as to the possible next moves +and/or to the current state of their account (where some information must not be +disclosed). Proposed Solution ================= +We allow certain *conditions* to *trigger* a single specific *measures*. +For the different *measures*, we define: + +* Who has to do something (AML staff, user, nobody) +* Contextual input data to be provided (with templating, e.g. amount set dynamically based on the *trigger*) +* A *check* to be performed +* A *program* that uses data from the *check* as well as *context* data + to determine an *outcome* which is the specific operational state + (normal, held on staff, held on user, frozen, etc.) the account is to transition to +* What information about the state to show to the user (normal, information required, pending, etc.) + +* For user-interactive checks: + + * Web page template with instructions to render (with either a form to fill or links to external checks); + here the context could provide an array of choices! + * Possibly an external check to set up (if any); for cost-reasons, we should only do one at a time, + and probably should then always redirect the browser to that check. + * A *measure* to take on failure of the external check + +* For (AML) staff-interactive checks: + + * UI to file forms and upload documentation (without state transition) + * UI to decide on next measure (providing context); here, the exchange needs + to expose the list of available *measures* and required *context* for each + +* Non-interactive measures (normal operation, account frozen) need: + + * Expiration time (in context) + * Measure to trigger upon expiration, again with context + (renew documents, resume normal operation, etc.) + + +We need some customer-driven interactivity in KYB/KYC process, for example the +user may need to be given choices (address vs. phone, individual vs. business, +order in which to provide KYC data of beneficiaries). As a result, the +exchange needs to serve some "master" page for measures where the user is +shown the next step(s) or choices (which person to collect KYC data on, +whether to run challenger on phone number of physical address, etc.). +That page should also potentially contain a form to allow the customer to +directly upload documents to us (like business registration) instead of to +some KYC provider. This is because KYC providers may not be flexible +enough. + +Similarly, the AML staff will need to be able to trigger rather complex +KYB/KYC processes, like "need KYC on X and Y and Z" or "phone number or +mailing address" or "please upload form A/T/S". Here in particular it +should be possible to request not only filled forms, but arbitrary +documents. + + +Documentation +^^^^^^^^^^^^^ + +* We must define risk-profile (902.4, 905.1) +* We must document the specific setup, likely not just the INI file +* We probably should have some key AMLA file attributes, such as: + + * File opened, file closed (keep data for X years afterwards!) + * low-risk or high-risk business relationship + * PEP status + * business domain + * authority notification dates (possibly multiple) with + voluntary or mandatory notification classification + +* There must be a page with an overview of AMLA files with opening + and closing dates and an easy way to determine for any day the + number of open AMLA files + +* Technically, we also need a list of at-risk transactions and of + frozen transactions, but given that we can really only freeze + on an account-basis, I think there is nothing to do here + + Terminology ^^^^^^^^^^^ -* **Check**: A check establishes a particular attribute of a user, such as their name based on an ID document and lifeness, mailing address, phone number, taxpayer identity, etc. +* **Check**: A check establishes a particular attribute of a user, such as their name based on an ID document and lifeness, mailing address, phone number, taxpayer identity, etc. Checks may be given *context* (such as whether a customer is an individual or a business) to run correctly. Checks can also be AML staff inserting information for plausibilization. Checks result in an *outcome* being decided by an external AML *program*. * **Condition**: A condition specifies when KYC is required. Conditions include the *type of operation*, a threshold amount (e.g. above EUR:1000) and possibly a time period (e.g. over the last month). * **Configuration**: The configuration determines the *legitimization rules*, and specifies which providers offer which *checks* at what *cost*. +* **Context**: Context is information provided as input into a *check* and *program* to customize their execution. The context is initially set by the *trigger*, but may evolve as the *account* undergoes *measures*. For each *check* and *program*, the required *context* data must be specified. + * **Cost**: Metric for the business expense for a KYC check at a certain *provider*. Not in any currency, costs are simply relative and non-negative values. Costs are considered when multiple choices are allowed by the *configuration*. * **Expiration**: KYC legitimizations may be outdated. Expiration rules determine when *checks* have to be performed again. @@ -66,8 +203,14 @@ Terminology * **Logic**: Logic refers to a specific bit of code (realized as an exchange plugin) that enables the interaction with a specific *provider*. Logic typically requires *configuration* for access control (such as an authorization token) and possibly the endpoint of the specific *provider* implementing the respective API. +* **Measure**: Describes the possible outgoing edges from one state in the state machine (including how to show the current state). Each edge is given some *context* and a *check* to be performed as well as a *program* to decide the *outcome* and the next *measure*. + +* **Outcome**: Describes the account state that an account ends up in due to the result of a *check*. Outcomes can be that an account is frozen (no transactions possible until freeze expires), held (no transactions possible until another *measure* has been taken), or operating normally. + * **Provider**: A provider performs a specific set of *checks* at a certain *cost*. Interaction with a provider is performed by provider-specific *logic*. +* **Program**: An AML helper *program* is given *context* about the current state of an account and the data from a *check* to compute the *outcome*. For example, a *program* may look at the "PEP" field of a KYC check and decide if the outcome is to put the account into ``normal`` or ``held-for-manual-review`` state. A *program* operating on an AML form filed by AML staff will likely be trivial and directly apply the explicit decision taken by the staff member. + * **Type of operation**: The operation type determines which Taler-specific operation has triggered the KYC requirement. We support four types of operation: withdraw (by customer), deposit (by merchant), P2P receive (by wallet) and (high) wallet balance. @@ -103,8 +246,9 @@ Access is ``authenticated`` by also passing the hash of the payto://-URI. initiate a KYC process are not very sensitive.) Given this triplet, the ``/kyc-check/`` endpoint returns either the (positive) KYC status or redirects the client (202) to the next required stage of the KYC process. The -redirection must be for an HTTP(S) endpoint to be triggered via a simple HTTP GET. As this endpoint is involved in every KYC check at the beginning, this is also the place where we can -integrate the payment process for the KYC fee. +redirection must be for an HTTP(S) endpoint to be triggered via a simple HTTP +GET. As this endpoint is involved in every KYC check at the beginning, this +is also the place where we can integrate the payment process for the KYC fee. The specific KYC provider to be executed depends on the configuration (see below) which specifies a ``$PROVIDER_SECTION`` for each authentication procedure. @@ -183,21 +327,14 @@ Configuration Options The configuration specifies a set of providers, one per configuration section: [kyc-provider-$PROVIDER_ID] -# How expensive is it to use this provider? -# Used to pick the cheapest provider possible. -COST = NUMBER # Which plugin is responsible for this provider? LOGIC = PLUGIN_NAME -# Which type of user does this provider handle? -# Either INDIVIDUAL or BUSINESS. -USER_TYPE = INDIVIDUAL -# Which checks does this provider provide? -# List of strings, no specific semantics. -PROVIDED_CHECKS = SMS GOVID PHOTO +# Which check does this provider provide? +PROVIDED_CHECK = SMS # Plus additional logic-specific options, e.g.: AUTHORIZATION_TOKEN = superdupersecret FORM_ID = business_legi_form -# How long is the check considered valid? +# How long is the data from this check considered valid? EXPIRATION = DURATION The configuration also specifies a set of legitimization @@ -208,10 +345,8 @@ requirements, one per configuration section: # Must be one of WITHDRAW, DEPOSIT, P2P-RECEIVE # or WALLET-BALANCE. OPERATION_TYPE = WITHDRAW -# Required checks to be performed. -# List of strings, must individually match the -# strings in one or more provider's PROVIDED_CHECKS. -REQUIRED_CHECKS = SMS GOVID +# Required measure to be performed. +REQUIRED_MEASURE = SWISSNESS # Threshold amount above which the legitimization is # triggered. The total must be exceeded in the given # timeframe. Can be 'forever'. @@ -222,6 +357,29 @@ THRESHOLD = AMOUNT TIMEFRAME = DURATION +Finally, the configuration specifies a set of measures, +one per configuration section: + +[aml-measure-$MEASURE_NAME] +# Program to run on the context and check data to +# determine the outcome and next measure. +PROGRAM = /bin/true +# Check to run as part of this measure. Optional. +CHECK = CHECK_NAME +# Form to show to the user as part of this measure. +FORM = FORM_NAME + +For each FORM_NAME, there then must be + +* A HTML template (Mustach) that is instantiated with the + JSON form context to produce a page to be shown to the user +* A helper program (named after the form) that can: + + * Generate a list of required context attributes + for the helper (!) + * Validate and convert an input JSON with context + attributes into the JSON form context + Exchange Database Schema ^^^^^^^^^^^^^^^^^^^^^^^^ diff --git a/design-documents/024-age-restriction.rst b/design-documents/024-age-restriction.rst index 280a4f39..0445aa6d 100644 --- a/design-documents/024-age-restriction.rst +++ b/design-documents/024-age-restriction.rst @@ -247,7 +247,7 @@ changed since the given timestamp. // Similar as for ``.denoms``, if the query parameter ``last_issue_date`` // was provided by the client, the exchange will only return the keys that // have changed since the given timestamp. - age_restricted_denoms: Denom[]; + age_restricted_denoms: DenomCommon[]; //... } @@ -600,9 +600,9 @@ The object ``ContractTerms`` is extended by an optional field ``minimum_age`` that can be any integer greater than 0. In reality this value will not be smaller than, say, 8, and not larger than, say, 21. -.. ts:def:: ContractTerms +.. ts:def:: DD24ContractTerms - interface ContractTerms { + interface DD24ContractTerms { ... // If the order requires a minimum age greater than 0, this field is set diff --git a/design-documents/031-invoicing.rst b/design-documents/031-invoicing.rst index cfe776ed..0fcc88fd 100644 --- a/design-documents/031-invoicing.rst +++ b/design-documents/031-invoicing.rst @@ -4,9 +4,7 @@ DD 31: Invoicing Summary ======= -This document proposes new endpoints to support invoicing, -that incidentally also address the long-standing rewards -reserve expiration problem. +This document proposes new endpoints to support invoicing. Motivation @@ -36,10 +34,7 @@ Requirements * Reasonable UX and overall design impact. * Wallets may want to pay for the reserve with coins - (reserve fresh, not created via bank transfer), while - rewarding merchants likely want to pay from the reserve - balance itself. So both styles of payment should be - supported. + (reserve fresh, not created via bank transfer). Unclear in the current proposal are: @@ -62,12 +57,10 @@ charge the ``account_fee``, bump the number of open purses threshold in the ``reserves`` table and stop auto-closing of the reserve. This will ensure that the users can withdraw the reserve balance into their wallet even after a longer time period. This helps if the invoice is paid after a significant -delay, and also addresses the unwanted reward reserve closure -problem. Introduce a way to force an immediate closure of a reserve, allowing +delay. Introduce a way to force an immediate closure of a reserve, allowing P2P reserve from invoices to be send to a bank account (this allows a wallet to be used for convenient invoicing and not strictly require the wallet to -receive the funds) and also allowing the user to recover funds from a reward -reserve after rewards are no longer issued. +receive the funds). The solution needs three new tables for: diff --git a/design-documents/035-regional-currencies.rst b/design-documents/035-regional-currencies.rst index 0b4553e6..3d62dcc3 100644 --- a/design-documents/035-regional-currencies.rst +++ b/design-documents/035-regional-currencies.rst @@ -30,6 +30,11 @@ Requirements * Regional currencies should be easy to use as well * It must be easy to integrate regional/official currencies with the existing Taler auditor/exchange structure +* Wallet users should be able to see disagregated balance between global currencies + and regional currencies supported by different exchanges even if the currency + name is equal. +* Merchants should be able to accept regional and global currencies based on the + supported exchange list. Proposed Solution ================= @@ -144,6 +149,16 @@ The last part should probably be hidden by default. There might be nicer ways t this, such as some hoverable (?) icon after the amount that shows details about what currencies the merchant accepts. +Wallet-core API for scope management +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* ``listGlobalCurrencyExchanges`` lists all ``(currency, exchangeUrl, exchangePub)`` triples + where funds are considered to be in global scope (i.e. non-regional). +* ``listGlobalCurrencyAuditors`` lists all ``(currency, auditorUrl, auditorPub)`` triples + where funds are considered to be in global scope (i.e. non-regional). +* ``addGlobalCurrencyExchange`` and ``removeGlobalCurrencyExchange`` adds/removes a ``(currency, exchangeUrl, exchangePub)`` +* ``addGlobalCurrencyAuditor`` and ``removeGlobalCurrencyAuditor`` adds/removes a ``(currency, auditorUrl, auditorPub)`` + Implementation Breakdown ^^^^^^^^^^^^^^^^^^^^^^^^ diff --git a/design-documents/037-wallet-transactions-lifecycle.rst b/design-documents/037-wallet-transactions-lifecycle.rst index 9d749595..7a8cfacd 100644 --- a/design-documents/037-wallet-transactions-lifecycle.rst +++ b/design-documents/037-wallet-transactions-lifecycle.rst @@ -525,64 +525,6 @@ the same as if the double-spending transaction had been deleted by the user. .. image:: ../images/transaction-refresh-states.png - -Transaction Type: Reward ------------------------- - -* ``pending(user)`` - - We have downloaded the metadata for the reward. This is the initial state for a - reward transaction. The user needs to accept/refuse the reward. - - * ``[reward-expired] => expired`` - * ``[action:accept] => pending(pickup)`` - -* ``pending(pickup)`` - - We are picking up the reward. - - * ``[failure] => failed``: any type of failure, including expiration. - * ``[processed-kyc-required] => pending(kyc-required)`` - * ``[success] => done`` - * ``[action:suspend] => suspended(pickup)`` - -* ``suspended(pickup)`` - - The user suspended the operation while the reward was being picked up. - - * ``[reward-expired] => failed`` - * ``[action:resume] => pending(pickup)`` - -* ``pending(kyc)`` - - The user needs to perform a KYC check to continue. This usually should only - happen if the wallet balance exceeds some threshold. - - * ``[poll-success] => pending(pickup)`` - * ``[action:suspend] => suspended(kyc)`` - -* ``suspended(kyc)`` - - The user suspended the KYC operation. Note that we do not time out here if - the reward expires, as the wallet balance threshold KYC likely applies even - without the reward. - - * ``[action:resume] => pending(kyc)`` - -* ``done`` - - The reward operation completed. - - * ``[action:delete] => deleted`` - -* ``deleted`` - - All memory of the reward operation is lost, but of course the resulting fresh - coins are preserved. - -.. image:: ../images/transaction-reward-states.png - - Transaction Type: Deposit ------------------------- diff --git a/design-documents/039-taler-browser-integration.rst b/design-documents/039-taler-browser-integration.rst index 71feb1c6..980f3f25 100644 --- a/design-documents/039-taler-browser-integration.rst +++ b/design-documents/039-taler-browser-integration.rst @@ -54,13 +54,7 @@ The problems with individual browsers are: either. Another issue is that Websites can't easily find out whether a browser -extension handling the ``taler://`` protocol is installed. To avoid using this -information for fingerprinting, anchors could provide an alternative ``href`` -in case the main one is not handled, such as: - -.. code:: html - - <a href="taler://pay/..." handler-unavailable-href="https://wallet.taler.net/">...</a> +extension handling the ``taler://`` protocol is installed. Requirements ============ @@ -81,32 +75,87 @@ Requirements should work smoothly with future browsers that have native, built-in support for Taler payments. +Proposed Solution +================= -Alternatives -============ +.. note:: + + As of 2023-01-23, we've decided to go ahead with the approach + described in this section. + +Overview +^^^^^^^^ + +The following integration approaches between Websites and the Taler Wallet webextension +are provided: + +1. Directly triggering a ``taler://...`` URI on page load (via a meta tag). +2. Overriding ``<a href="taler://..." onclick=...>`` tags to trigger the wallet. + The onclick handler (which must call preventDefault) can implement behavior + that happens only when the webextension is not available. +3. Future (possibly post-1.0): A ``window.taler`` JavaScript API that is injected + into every page that requests it via a meta tag. This is useful for SPAs that + want to programmatically trigger the Taler wallet. + + +Usage +^^^^^ + +To directly trigger the handling of a ``taler://`` URI on page load, the following meta tag can be used: + +.. code:: + + <meta name="taler-uri" content="taler://..."> + + +To enable additional communication features between a website and the GNU Taler Wallet webextension, the page must +include the following meta tag: + +.. code:: + + <meta name="taler-support" content="$features"> -* JavaScript API: The WebExtension could inject a JavaScript API into Websites - that allow interacting with the Taler wallet. This is the approach taken by - the MetaMask crypto wallet. It requires excessive permissions, may break - some Websites (https://github.com/brave/browser-laptop/issues/13711) and - requires merchants to include extra JavaScript. - - * This type of interaction is useful for Single Page Apps and - might be provided by the GNU Taler wallet reference implementation, - at least when the user grants additional permissions. - * Unfortunately, browsers currently do not provide a safe way - for the communication between a WebExtension and the page - without excessive permissions. This especially applies - if the Website does not know the extension's ID. Hard-coding - the extension IDs would violate the "no vendor lock-in requirement". - -* Handling ``taler://`` URIs by overriding the onclick handler of ``a`` HTML elements. - This requires excessive permissions but would be a viable work-around, - at least on pages that opt in with a special ``<meta name="taler-support" content="uri">`` tag. - It does not work in all use-cases, for example when a navigation +where ``$features`` is a comma-separated list of features. + +The following features are supported: + +* ``uri`` will hijack anchor elements (``<a href="taler://..." onclick=...>``) and replace their onclick handler + with a different handler that lets the webexension wallet handle the ``taler://`` URI. + +* (future): ``api`` will inject the ``window.taler`` API into the page + + +Caveats and Comments +^^^^^^^^^^^^^^^^^^^^ + +* Anchor tag hijacking does not work in all use-cases, for example when a navigation to a ``taler://`` URI is initiated programmatically or by pasting the URI in the browser's address bar. +* The ``window.taler`` API injection may break some websites + (https://github.com/brave/browser-laptop/issues/13711). + +* All these approaches require excessive permissions, as unfortunately, + browsers currently do not provide a safe way for the communication between a + WebExtension and the page without excessive permissions. This especially + applies if the Website does not know the extension's ID. Hard-coding the + extension IDs would violate the "no vendor lock-in requirement". + +* A neat feature of the anchor hijacking is that the ``taler://`` URI can be always be copied + in the browser (via "copy link address"). Clicking the link always results in either: + + * The native URI handler, if no Taler Wallet webextension is installed and no onclick handler is defined + * The execution of the websites onclick handler if no Taler Wallet webextension is installed + * Triggering the webextension wallet to handle the ``taler://`` URI. + +* Future ``window.taler`` injection should be based on user preferences on + sites where the user has explicitly accepted to disclose that is owner of a + Taler wallet. + +Other Alternatives +================== + + * Triggering interactions with the ``taler://`` URI in a ``Taler:`` HTTP header. This approach would allow browsers with native Taler support (or a WebExtension) to handle payment/withdrawal initiations directly, @@ -133,6 +182,10 @@ Alternatives the Web Payments API would not support the withdrawal flow (``taler://withdraw`` URIs). +* Browsers could provide anchor elements with a fallback when the protocol isn't supported, such as + ``<a href="taler://pay/..." handler-unavailable-href="https://wallet.taler.net/">...</a>``. + + Related Work and References =========================== diff --git a/design-documents/041-wallet-balance-amount-definitions.rst b/design-documents/041-wallet-balance-amount-definitions.rst index 1c89d634..9943d482 100644 --- a/design-documents/041-wallet-balance-amount-definitions.rst +++ b/design-documents/041-wallet-balance-amount-definitions.rst @@ -245,20 +245,6 @@ REFUND Is there a way that the merchant can initiate a refund of purchase + refund_fee so the wallet will get the same effective_amount? -REWARD - raw amount is the amount that the merchant send as reward - - ``instructed_amount`` = reward.amount - - ``raw_amount`` = instructed_amount + withdrawal_fee - - ``effective_amount`` = instructed_amount - - .. note:: - We should not show fee for rewards in the wallet since the merchant is the one choosing - the exchange and we can assume that those rewards are paid by the merchant. - So the wallet only care about the effective. - Coin selection algorithm ------------------------ diff --git a/design-documents/046-mumimo-contracts.rst b/design-documents/046-mumimo-contracts.rst index 5bc3d25a..714b5822 100644 --- a/design-documents/046-mumimo-contracts.rst +++ b/design-documents/046-mumimo-contracts.rst @@ -62,8 +62,6 @@ We want Taler to support various interesting use-cases: acquired (i.e., not brought from home or stolen from a stack of dirty items) and incentivizes return after use. -TODO: add more use-cases here! - Proposed Solution ================= @@ -145,6 +143,33 @@ The contract terms v1 will have the following structure: // More info about the merchant (same as in v0). merchant: Merchant; + // Human-readable description of the contract. + summary: string; + + // Map from IETF BCP 47 language tags to localized summaries. + summary_i18n?: { [lang_tag: string]: string }; + + // URL that will show that the order was successful after + // it has been paid for. Optional. When POSTing to the + // merchant, the placeholder "${ORDER_ID}" will be + // replaced with the actual order ID (useful if the + // order ID is generated server-side and needs to be + // in the URL). + // Note that this placeholder can only be used once. + // Either fulfillment_url or fulfillment_message must be specified. + fulfillment_url?: string; + + // Message shown to the customer after paying for the order. + // Either fulfillment_url or fulfillment_message must be specified. + fulfillment_message?: string; + + // Map from IETF BCP 47 language tags to localized fulfillment + // messages. + fulfillment_message_i18n?: { [lang_tag: string]: string }; + + // List of products that are part of the purchase (see `Product`). + products: Product[]; + // After this deadline has passed, no refunds will be accepted. refund_deadline: Timestamp; @@ -184,83 +209,27 @@ The contract terms v1 will have the following structure: // signing the deposit confirmation. choices: ContractChoice[]; + // Map from authority labels to meta data about the + // respective token authority. + token_types: { [authority_label: string]: TokenAuthority }; + // Extra data that is only interpreted by the merchant frontend. // Useful when the merchant needs to store extra information on a // contract without storing it separately in their database. extra?: any; - // Fee limits and wire account details by currency. - limits: { [currency:string] : CurrencyLimit }; - } - -.. ts:def:: CurrencyLimit - - interface CurrencyLimit { - - // The hash of the merchant instance's wire details. - h_wire: HashCode; - - // Wire transfer method identifier for the wire method associated with ``h_wire``. - // The wallet may only select exchanges via a matching auditor if the - // exchange also supports this wire method. - // The wire transfer fees must be added based on this wire transfer method. - wire_method: string; - // Maximum total deposit fee accepted by the merchant for this contract. max_fee: Amount; - // Maximum wire fee accepted by the merchant (customer share to be - // divided by the ``wire_fee_amortization`` factor, and further reduced - // if deposit fees are below ``max_fee``). Default if missing is zero. - max_wire_fee: Amount; - - // Over how many customer transactions does the merchant expect to - // amortize wire fees on average? If the exchange's wire fee is - // above ``max_wire_fee``, the difference is divided by this number - // to compute the expected customer's contribution to the wire fee. - // The customer's contribution may further be reduced by the difference - // between the ``max_fee`` and the sum of the actual deposit fees. - // Optional, default value if missing is 1. 0 and negative values are - // invalid and also interpreted as 1. - wire_fee_amortization: number; - // Exchanges that the merchant accepts for this currency. exchanges: Exchange[]; } - .. ts:def:: ContractChoice interface ContractChoice { - // Human-readable description of the choice. - summary: string; - - // Map from IETF BCP 47 language tags to localized summaries. - summary_i18n?: { [lang_tag: string]: string }; - - // URL that will show that the order was successful after - // it has been paid for. Optional. When POSTing to the - // merchant, the placeholder "${ORDER_ID}" will be - // replaced with the actual order ID (useful if the - // order ID is generated server-side and needs to be - // in the URL). - // Note that this placeholder can only be used once. - // Either fulfillment_url or fulfillment_message must be specified. - fulfillment_url?: string; - - // Message shown to the customer after paying for the order. - // Either fulfillment_url or fulfillment_message must be specified. - fulfillment_message?: string; - - // Map from IETF BCP 47 language tags to localized fulfillment - // messages. - fulfillment_message_i18n?: { [lang_tag: string]: string }; - - // List of products that are part of the purchase (see `Product`). - products: Product[]; - // List of inputs the wallet must provision (all of them) to // satisfy the conditions for the contract. inputs: ContractInput[]; @@ -269,17 +238,13 @@ The contract terms v1 will have the following structure: // once the contract is paid. outputs: ContractOutput[]; - // Map from authority labels to meta data abou the - // respective token authority. - token_types: { [authority_label: TokenAuthority }; - } .. ts:def:: ContractInput type ContractInput = - | ContractInputRation - | ContractInputToken; + ContractInputRation | + ContractInputToken; .. ts:def:: ContractInputRation @@ -305,9 +270,9 @@ The contract terms v1 will have the following structure: type: "token"; - // Hash over the public key used to sign the - // type of subscription token required. - h_issuer: HashCode; + // Label of the token authority in the + // 'token_types' map on the top-level. + authority_label: string; // Number of tokens of this type required. // Defaults to one if the field is not provided. @@ -318,17 +283,17 @@ The contract terms v1 will have the following structure: .. ts:def:: ContractOutput type ContractOutput = - | ContractOutputCurrency - | ContractOutputTaxReceipt - | ContractOutputToken; + ContractOutputCoin | + ContractOutputTaxReceipt | + ContractOutputToken; -.. ts:def:: ContractOutputCurrency +.. ts:def:: ContractOutputCoin - interface ContractOutputCurrency { + interface ContractOutputCoin { - type: "currency"; + type: "coins"; - // Amount of currency that will be yielded. + // Amount of coins that will be yielded. // This excludes any applicable withdraw fees. brutto_yield: Amount; @@ -360,24 +325,21 @@ The contract terms v1 will have the following structure: // 'token_types' map on the top-level. authority_label: string; - // Must a wallet understand this token type to - // process contracts that consume or yield it? - critical: boolean; + // Number of tokens to be yelded. + // Defaults to one if the field is not provided. + number?: Integer; - // Information about the class of token that will - // be yielded. - details: OutputTokenClass; } -.. ts:def:: OutputTokenClass +.. ts:def:: TokenClass - type OutputTokenClass = - | OutputTokenClassSubscription - | OutputTokenClassDiscount + type TokenClass = + TokenClassSubscription + | TokenClassDiscount -.. ts:def:: OutputTokenClassSubscription +.. ts:def:: TokenClassSubscription - interface OutputTokenClassSubscription { + interface TokenClassSubscription { class: "subscription"; @@ -396,9 +358,9 @@ The contract terms v1 will have the following structure: }; -.. ts:def:: OutputTokenClassDiscount +.. ts:def:: TokenClassDiscount - interface OutputTokenClassDiscount { + interface TokenClassDiscount { class: "discount"; @@ -433,6 +395,13 @@ The contract terms v1 will have the following structure: // When will tokens signed by this key expire? token_expiration: Timestamp; + // Class-specific information of the token + details: TokenClass; + + // Must a wallet understand this token type to + // process contracts that consume or yield it? + critical: boolean; + // Number of tokens issued according to ASS authority // FIXME: this is still rather speculative in the design... ass?: Integer; @@ -452,8 +421,8 @@ The contract terms v1 will have the following structure: .. ts:def:: TokenSignerPublicKey type TokenSignerPublicKey = - | DenomGroupRsa - | DenomGroupCs; + DenomGroupRsa | + DenomGroupCs; TODO: may want to do a deep copy and rename DenomGroup* to TokenSignerPublicKey* here. @@ -472,10 +441,7 @@ consumes an available discount token, that contract should be moved up in the list. Which specific alternative contract was chosen by the user is indicated in the -subcontract index field of the :ref:`TALER_DepositRequestPS`. - -FIXME-DOLD: Should we also sign over this in the -:ref:`TALER_DepositConfirmationPS`? +subcontract index field of the :ref:`TALER_DepositRequestPS <taler_depositrequestps>`. Output Commitments @@ -483,8 +449,9 @@ Output Commitments When a contract has outputs, the wallet must send an array of blinded tokens, coins or tax receipts together with the payment request. The order in the -array must match the order in the outputs field of the contract. For currency outputs, one array element must include all of the required planchets for a batch withdrawal, -but of course not the reserve signature. +array must match the order in the outputs field of the contract. For currency +outputs, one array element must include all of the required planchets for a +batch withdrawal, but of course not the reserve signature. .. note:: @@ -492,10 +459,7 @@ but of course not the reserve signature. batch-withdraw API to only use a single reserve signature. This array of blinded values is hashed to create the output commitment hash -(``h_outputs``) in the :ref:`TALER_DepositRequestPS`. - -FIXME-DOLD: Should we also sign over this in the -:ref:`TALER_DepositConfirmationPS`? +(``h_outputs``) in the :ref:`TALER_DepositRequestPS <taler_depositrequestps>`. diff --git a/design-documents/053-wallet-ui.rst b/design-documents/053-wallet-ui.rst index 5891eb37..99640ceb 100644 --- a/design-documents/053-wallet-ui.rst +++ b/design-documents/053-wallet-ui.rst @@ -4,7 +4,7 @@ DD 53: Wallet UI Design Summary ======= -This document proposes designs wallet UI. It defines what Android, iOS and +This document proposes designs wallet UI. It defines what Android, iOS and WebExtension should follow in order to have a coherent UI between platforms. Motivation @@ -12,8 +12,8 @@ Motivation We want user to be able to help each others independent of the implementation they are using. -We want user to be able to capitalize the effort of learning how to use one -wallet and be able to use a different one without the need to learn +We want user to be able to capitalize the effort of learning how to use one +wallet and be able to use a different one without the need to learn anything new. Currently development of different platform specific implementation are independent and every developer needs to choose the layout, texts and buttons and navigation. @@ -25,7 +25,7 @@ Every screen MUST be defined in a document with the following information: * **Identifiable UI screens**: every UI should have an unique identifier that will be use for development discussion and bug reports. There should be an option - in the application to enable an active rendering of the id. + in the application to enable an active rendering of the id. * **Description**: the reason to be of the screen, should help to define what will be included into, what is going to left for other screens and when and from @@ -40,25 +40,29 @@ Additionaly the document COULD defined the components of the UI. If one of this properties is defined in the spec the implementation must implement it. The specification should be minimal to achieve the objective in the description. -* **Info**: Spec of information that the user should have access. The type of info - could be a field (id and value) or a banner (information and instructions). - The spec will help to reuse the text for i18n across apps and defined +* **Info**. Spec of information that the user should have access. The type of info + could be a field (id and value) or a banner (information and instructions). + The spec will help to reuse the text for i18n across apps and defined -* **Inputs**: Spec of information need to provide in current screen. The type of input, +* **Inputs**. Spec of information need to provide in current screen. The type of input, range of values and validation should be defined if necessary. -* **Actions**: Spec of buttons and interactable elements that will have a significant +* **Actions**. Spec of buttons and interactable elements that will have a significant change in the current state. It should also mention navigation when applicable. - -* **Layout**: Spec position of elements when needed. The spec should be "soft" in a sense - that elements should be easy to find following directions like "close to X" or + +* **Layout**. Spec position of elements when needed. The spec should be "soft" in a sense + that elements should be easy to find following directions like "close to X" or "at the start/end of the screen". -Screen should be defined using the most relaxed definition that are good enough to +* **Screenshots**. Should be provided for all wallet implementations and kept + up to date, to ensure that they can be used to aid in UI/UX and QA + discussions. + +Screen should be defined using the most relaxed definition that are good enough to be clear for the user. Platform will use this definition and adapt to the differences on the platform taking advantange of platform API and screen sizes. -When a screen have multiple uses for the same purpose, a substate section should be +When a screen have multiple uses for the same purpose, a substate section should be included with the difference with the main definition. Part of the screens that are reused shoud also be defined in this document as screen. @@ -70,194 +74,589 @@ Common definition: Proposed Solutions ================== -List of dall screens with the defined properties +List of all screens with the defined properties. + +.. _balance-list-ref: + +balance-list +------------ + +This screen shows a currency-scoped list of the balances stored in the wallet, +and includes information about the total, incoming, and outgoing amounts, as +well as the currency scope information for each item. + +Info +^^^^ + +* List of balances in the wallet, where each item contains: + + * Total amount with currency (see :doc:`051-fractional-digits`). + * Incoming amount (money pending to arrive). + * Outgoing amount (money pending to leave). + * Currency scope information (see :doc:`035-regional-currencies`). + +Actions +^^^^^^^ + +* **View transactions**. Clicking on a balance item should take you to the + transaction list (:ref:`transaction-list-ref`) associated with that balance. + +Screenshots +^^^^^^^^^^^ + ++-----------+----------------------------------------------------------------+ +| Platform | Screenshot | ++===========+================================================================+ +| WebEx | .. image:: ../screenshots/balance-list-firefox-latest.png | ++-----------+----------------------------------------------------------------+ +| Android | .. image:: ../screenshots/balance-list-android-latest.png | +| | :width: 30% | ++-----------+----------------------------------------------------------------+ +| iOS | .. image:: ../screenshots/balance-list-1-ios-latest.png | +| | :width: 30% | +| | .. image:: ../screenshots/balance-list-2-ios-latest.png | +| | :width: 30% | ++-----------+----------------------------------------------------------------+ + + +.. _transaction-list-ref: + +transaction-list +---------------- + +This screen shows a list of all the transactions associated with a given +currency scope. + +Info +^^^^ + +* Total amount and currency (see :doc:`051-fractional-digits`). +* List of transactions associated with the currency scope, with pending + transactions on top, and where each item contains the following: + + * **Title**. It depends on the transaction type. It can be the exchange URL + (e.g. exchange.demo.taler.net), a description of the type of transaction + (e.g. Deposit, Invoice, Payment, etc.), the name of the merchant paid + (e.g. Essay Shop), etc. + * **Summary**. It provides complementary information about the transaction + for the user, such as the status of the transaction (e.g. “Waiting for + confirmation,” “KYC required,” an error message, etc.). (The summary is + provided by wallet-core, along with internationalized versions.) + * **Timestamp**. The moment when the transaction was created. Ideally, it + should be shown with minimal precision, only showing the minutes, hours or + days that have elapsed. + * **Amount**. The positive or negative impact that the transaction has in + the total balance of the currency scope. It should be made clear whether + the amount of the transaction is positive or negative, ideally with a sign + (+/-) and a color (green/red). + * **Pending**. It should be indicated whether the transaction is pending or + finished. This can be done with a small badge and with different colors, + however, it should be always clear and communicate the message + effectively. + +Actions +^^^^^^^ + +* **Send**. The transaction list should include a button that allows the user + to initiate transactions that result in money being sent, such as deposits + and peer push payments. +* **Receive**. The transaction list should also include a button that allows + the user to initiate transactions that result in money being received, such + as withdrawals and peer pull payments. +* **View transaction details**. When clicking on a transaction, the user + should be taken to its corresponding transaction details depending on the + type of the transaction clicked. +* **Select transaction(s)**. The user should be able to select one or more + transactions to perform specific bulk actions, such as deleting. The + interaction that triggers this action might differ across platforms. For + example, in Android this would be achieved by double pressing a transaction + (to activate selection mode) and then clicking other transactions to be + selected. On iOS, this could be achieved using an “Edit” button in the + toolbar that reveals checkboxes that allow the user to select the desired + transactions. +* **Delete transaction(s)**. This could be achieved in bulk via selection + mode, or individually for each transaction via a menu or a button. Either + way, performing a deletion should always show a confirmation menu before + doing the actual deletion. + +Screenshots +^^^^^^^^^^^ + ++-----------+----------------------------------------------------------------+ +| Platform | Screenshot | ++===========+================================================================+ +| WebEx | .. image:: ../screenshots/transaction-list-firefox-latest.png | ++-----------+----------------------------------------------------------------+ +| Android | .. image:: ../screenshots/transaction-list-android-latest.png | +| | :width: 30% | ++-----------+----------------------------------------------------------------+ +| iOS | .. image:: ../screenshots/transaction-list-ios-latest.png | +| | :width: 30% | ++-----------+----------------------------------------------------------------+ + + +.. _cta-withdraw-ref: cta-withdraw ------------ -``Description``: this screen is used for the confirmation of a manual withdrawal, -bank-integrated witdrawals and exchange withdrawals. -the success of this operation will be an increase of the balance in the wallet. -fee, restrictions and ETA should be clear for the user. +This screen is used for the confirmation of a manual withdrawal, +bank-integrated witdrawals and exchange withdrawals. the success of this +operation will be an increase of the balance in the wallet. fee, restrictions +and ETA should be clear for the user. -``Info``: - * exchange to be used showing the URL - * table of details of the operation: use the ``operation-table-details`` screen - * starting currency: if the exchange has the currency conversion service enabled user should be able to the details based on the wire transfer currency - * taler URI: show copy button or QR to complete the operation with another device +Info +^^^^ -``Inputs``: - * age restriction: allow the selection of the restriction in the age group possible by the exchange - * service provider: allow the selection of different exchange +* exchange to be used showing the URL +* table of details of the operation: use the :ref:`operation-table-details-ref` screen +* starting currency: if the exchange has the currency conversion service enabled user should be able to the details based on the wire transfer currency +* taler URI: show copy button or QR to complete the operation with another device -``Actions``: - * confirm operation: on success will be redirected to the ``transaction-details`` screen where the detail of the current transaction will be displayed - * review and confirm ToS: if the current selected exchange has a version of ToS that the user didn't yet accepted, use the ``accept-tos`` screen - * cancel: user will be redirected to ``balance`` +Inputs +^^^^^^ + +* age restriction: allow the selection of the restriction in the age group possible by the exchange +* service provider: allow the selection of different exchange + +Actions +^^^^^^^ + +* **confirm operation**: on success will be redirected to the ``transaction-details`` screen where the detail of the current transaction will be displayed +* **review and confirm ToS**: if the current selected exchange has a version of ToS that the user didn't yet accepted, use the :ref:`accept-tos-ref` screen +* **cancel**: user will be redirected to ``balance`` .. attention:: User should be able to play with the amount, not possible in the current design +Screenshots +^^^^^^^^^^^ + ++-----------+----------------------------------------------------------------+ +| Platform | Screenshot | ++===========+================================================================+ +| WebEx | .. image:: ../screenshots/cta-withdraw-firefox-latest.png | ++-----------+----------------------------------------------------------------+ +| Android | .. image:: ../screenshots/cta-withdraw-2-android-latest.png | +| | :width: 30% | ++-----------+----------------------------------------------------------------+ +| iOS | .. image:: ../screenshots/cta-withdraw-ios-latest.png | +| | :width: 30% | ++-----------+----------------------------------------------------------------+ + + +.. _cta-wire-transfer-ref: + +cta-wire-transfer +----------------- + +This screen is used to show the user the information for the wire transfer to +complete a manual withdrawal operation. + +Info +^^^^ + +* wire transfer subject to be used (first, most important) +* target bank account to transfer funds to (e.g. IBAN) +* total amount to transfer in the wire transfer currency +* button to copy ``payto://`` URI with the information to clipboard + +Actions +^^^^^^^ + +* **abort**: aborts the withdrawal operation +* **menu**: go back to the main balances list (operation continues in background) +* **automatic**: screen changes to "cta-withdraw-done" upon completion + +Screenshots +^^^^^^^^^^^ + ++-----------+------------------------------------------------------------------+ +| Platform | Screenshot | ++===========+==================================================================+ +| WebEx | .. image:: ../screenshots/cta-wire-transfer-firefox-latest.png | ++-----------+------------------------------------------------------------------+ +| Android | .. image:: ../screenshots/cta-wire-transfer-1-android-latest.png | +| | :width: 30% | +| | .. image:: ../screenshots/cta-wire-transfer-2-android-latest.png | +| | :width: 30% | ++-----------+------------------------------------------------------------------+ +| iOS | .. image:: ../screenshots/cta-wire-transfer-1-ios-latest.png | +| | :width: 30% | +| | .. image:: ../screenshots/cta-wire-transfer-2-ios-latest.png | +| | :width: 30% | +| | .. image:: ../screenshots/cta-wire-transfer-3-ios-latest.png | +| | :width: 30% | ++-----------+------------------------------------------------------------------+ + + +.. _cta-withdraw-done-ref: + +cta-withdraw-done +----------------- + +This screen is used to show the user the information for a completed withdraw +operation (bank-integrated or manual) + +Info +^^^^ + +* amount wired (hidden if no fees) +* fees paid (hidden if no fees) +* total amount withdrawn into wallet (effective balance change) +* exchange base URL +* date + +Actions +^^^^^^^ + +* **delete**: deletes information about the withdrawal operation + +Screenshots +^^^^^^^^^^^ + ++-----------+------------------------------------------------------------------+ +| Platform | Screenshot | ++===========+==================================================================+ +| WebEx | .. image:: ../screenshots/cta-withdraw-done-firefox-latest.png | ++-----------+------------------------------------------------------------------+ +| Android | .. image:: ../screenshots/cta-withdraw-done-android-latest.png | +| | :width: 30% | ++-----------+------------------------------------------------------------------+ +| iOS | .. image:: ../screenshots/cta-withdraw-done-ios-latest.png | +| | :width: 30% | ++-----------+------------------------------------------------------------------+ + + +.. _cta-url-entry-ref: + +cta-url-entry +------------- + +This screen allows the user to scan a QR code, scan an NFC tag, or enter a +taler://-URL. Its implementation may differ significantly between +platforms. For example, scanning NFC tags may be fully automated, scanning QR +codes may involve some system applications, and maybe the dialog only allows +the URL entry *or* the camera but not both at the same time, depending on +implementation specifics. + +Info +^^^^ + +* camera with current image to enable user to focus on QR code +* current URL, with information if it is not well-formed for GNU Taler +* possibly status information on NFC reader (if available) + +Actions +^^^^^^^ + +* **open**: if entered manually, open URL as-entered (otherwise open is automatic) +* **back**: return to previous view + +Screenshots +^^^^^^^^^^^ + ++-----------+------------------------------------------------------------------+ +| Platform | Screenshot | ++===========+==================================================================+ +| WebEx | .. image:: ../screenshots/cta-url-entry-firefox-latest.png | ++-----------+------------------------------------------------------------------+ +| Android | .. image:: ../screenshots/cta-url-entry-1-android-latest.png | +| | :width: 30% | +| | .. image:: ../screenshots/cta-url-entry-2-android-latest.png | +| | :width: 30% | ++-----------+------------------------------------------------------------------+ + + +.. _cta-payment-ref: + cta-payment ------------- +----------- + +This screen is used for the confirmation of a payment to a merchant. the +success of this operation will be an decrease of the balance in the wallet and +save a ticket/invoice of the purchase. fee, restrictions and ETA should be +clear for the user. + +Info +^^^^ + +* merchant offering the order showing the URL +* order summary +* table of details of the operation: use the :ref:`operation-table-details-ref` screen +* receipt: order id +* payment deadline: absolute time before the claimed order expires +* taler URI: show copy button or QR to complete the operation with another device +* cant pay desc: if the user has enough balance but unable to use it +* payment status: if the + +Actions +^^^^^^^ + +* **confirm operation**: if the payment is possible, on success will be redirected to the ``transaction-details`` screen where the detail of the current transaction will be displayed +* **get more cash**: if there is not enough balance, it will be redirected to :ref:`cta-withdraw-ref` +* **cancel**: user will be redirected to ``balance`` + +Screenshots +^^^^^^^^^^^ + ++-----------+------------------------------------------------------------------+ +| Platform | Screenshot | ++===========+==================================================================+ +| WebEx | .. image:: ../screenshots/cta-payment-firefox-latest.png | ++-----------+------------------------------------------------------------------+ +| Android | .. image:: ../screenshots/cta-payment-android-latest.png | +| | :width: 30% | ++-----------+------------------------------------------------------------------+ +| iOS | .. image:: ../screenshots/cta-payment-ios-latest.png | +| | :width: 30% | ++-----------+------------------------------------------------------------------+ -``Description``: this screen is used for the confirmation of a payment to a merchant. -the success of this operation will be an decrease of the balance in the wallet -and save a ticket/invoice of the purchase. -fee, restrictions and ETA should be clear for the user. - -``Info``: - * merchant offering the order showing the URL - * order summary - * table of details of the operation: use the ``operation-table-details`` screen - * receipt: order id - * payment deadline: absolute time before the claimed order expires - * taler URI: show copy button or QR to complete the operation with another device - * cant pay desc: if the user has enough balance but unable to use it - * payment status: if the - -``Actions``: - * confirm operation: if the payment is possible, on success will be redirected to the ``transaction-details`` screen where the detail of the current transaction will be displayed - * get more cash: if there is not enough balance, it will be redirected to ``cta-witddraw`` - * cancel: user will be redirected to ``balance`` + +.. _cta-payment-paid-ref: + +cta-payment-paid +---------------- + +This screen is used to show information with details about a historic payment. + +Info +^^^^ + +* merchant offering the order showing the URL +* order summary +* table of details of the operation: use the :ref:`operation-table-details-ref` screen +* receipt: order id +* payment status: if the order was refunded + +Actions +^^^^^^^ + +* **delete**: delete information about the transaction +* **back**: user will be redirected to ``balance`` + +Screenshots +^^^^^^^^^^^ + ++-----------+------------------------------------------------------------------+ +| Platform | Screenshot | ++===========+==================================================================+ +| WebEx | .. image:: ../screenshots/cta-payment-paid-firefox-latest.png | ++-----------+------------------------------------------------------------------+ +| Android | .. image:: ../screenshots/cta-payment-paid-android-latest.png | +| | :width: 30% | ++-----------+------------------------------------------------------------------+ +| iOS | .. image:: ../screenshots/cta-payment-paid-1-ios-latest.png | +| | :width: 30% | +| | .. image:: ../screenshots/cta-payment-paid-2-ios-latest.png | +| | :width: 30% | ++-----------+------------------------------------------------------------------+ + + +.. _cta-deposit-ref: cta-deposit ------------ -``Description``: this screen is used for the confirmation of a deposit. -the success of this operation will be an decrease of the balance in the wallet -and save a deposit ticket for reference. -fee, restrictions and ETA should be clear for the user. +This screen is used for the confirmation of a deposit. the success of this +operation will be an decrease of the balance in the wallet and save a deposit +ticket for reference. fee, restrictions and ETA should be clear for the user. -``Info``: - * bank account where the money is going to - * table of details of the operation: use the ``operation-table-details`` screen +Info +^^^^ -``Actions``: - * confirm operation: on success will be redirected to the ``transaction-details`` screen where the detail of the current transaction will be displayed - * cancel: user will be redirected to ``balance`` +* bank account where the money is going to +* table of details of the operation: use the :ref:`operation-table-details-ref` screen + +Actions +^^^^^^^ + +* **confirm operation**: on success will be redirected to the ``transaction-details`` screen where the detail of the current transaction will be displayed +* **cancel**: user will be redirected to ``balance`` .. attention:: User should be able to play with the amount, not possible in the current design +Screenshots +^^^^^^^^^^^ + ++-----------+------------------------------------------------------------------+ +| Platform | Screenshot | ++===========+==================================================================+ +| WebEx | .. image:: ../screenshots/cta-deposit-firefox-latest.png | ++-----------+------------------------------------------------------------------+ +| Android | .. image:: ../screenshots/cta-deposit-android-latest.png | +| | :width: 30% | ++-----------+------------------------------------------------------------------+ +| iOS | .. image:: ../screenshots/cta-deposit-1-ios-latest.png | +| | :width: 30% | +| | .. image:: ../screenshots/cta-deposit-2-ios-latest.png | +| | :width: 30% | ++-----------+------------------------------------------------------------------+ + + +.. _cta-peer-pull-initiate-ref: + cta-peer-pull-initiate ---------------------- -``Description``: this screen is used for the confirmation of the creation of -a peer pull transaction or invoice to request money from another wallet. -the success of this operation will not change the balance immediately in the wallet -and allow the user to share a taler URI to the payer. -fee, restrictions and ETA should be clear for the user. +This screen is used for the confirmation of the creation of a peer pull +transaction or invoice to request money from another wallet. the success of +this operation will not change the balance immediately in the wallet and allow +the user to share a taler URI to the payer. fee, restrictions and ETA should +be clear for the user. -``Info``: - * exchange to be used showing the URL - * table of details of the operation: use the ``operation-table-details`` screen +Info +^^^^ -``Inputs``: - * subject: short description of the transaction - * expiration: absolute time/date after which the invoice is not valid anymore - * service provider: allow the selection of different exchange +* exchange to be used showing the URL +* table of details of the operation: use the :ref:`operation-table-details-ref` screen -``Actions``: - * confirm operation: on success will be redirected to the ``transaction-details`` screen where the detail of the current transaction will be displayed - * review and confirm ToS: if the current selected exchange has a version of ToS that the user didn't yet accepted, use the ``accept-tos`` screen - * cancel: user will be redirected to ``balance`` +Inputs +^^^^^^ + +* **subject**: short description of the transaction +* **expiration**: absolute time/date after which the invoice is not valid anymore +* **service provider**: allow the selection of different exchange + +Actions +^^^^^^^ + +* **confirm operation**: on success will be redirected to the ``transaction-details`` screen where the detail of the current transaction will be displayed +* **review and confirm ToS**: if the current selected exchange has a version of ToS that the user didn't yet accepted, use the :ref:`accept-tos-ref` screen +* *cancel*: user will be redirected to ``balance`` .. attention:: Is the invoice creation always free of charge or does the exchange have a mechanism to impose a fee to pay on creation? +Screenshots +^^^^^^^^^^^ + ++-----------+----------------------------------------------------------------------+ +| Platform | Screenshot | ++===========+======================================================================+ +| WebEx | .. image:: ../screenshots/cta-peer-pull-initiate-firefox-latest.png | ++-----------+----------------------------------------------------------------------+ +| Android | .. image:: ../screenshots/cta-peer-pull-initiate-android-latest.png | +| | :width: 30% | ++-----------+----------------------------------------------------------------------+ +| iOS | .. image:: ../screenshots/cta-peer-pull-initiate-ios-latest.png | +| | :width: 30% | ++-----------+----------------------------------------------------------------------+ + + +.. _cta-peer-pull-confirm-ref: cta-peer-pull-confirm --------------------- -``Description``: this screen is used for the confirmation of the payment of -a peer pull transaction or invoice to send money from another wallet. -the success of this operation will be an will decrease the balance in the wallet. -fee, restrictions and ETA should be clear for the user. +This screen is used for the confirmation of the payment of a peer pull +transaction or invoice to send money from another wallet. the success of this +operation will be an will decrease the balance in the wallet. fee, +restrictions and ETA should be clear for the user. + +Info +^^^^ + +* exchange to be used showing the URL +* subject: short description of the transaction +* table of details of the operation: use the :ref:`operation-table-details-ref` screen +* expiration: absolute time/date after which the invoice is not valid anymore -``Info``: - * exchange to be used showing the URL - * subject: short description of the transaction - * table of details of the operation: use the ``operation-table-details`` screen - * expiration: absolute time/date after which the invoice is not valid anymore +Actions +^^^^^^^ -``Actions``: - * confirm operation: if the payment is possible, on success will be redirected to the ``transaction-details`` screen where the detail of the current transaction will be displayed - * get more cash: if there is not enough balance, it will be redirected to ``cta-witddraw`` - * cancel: user will be redirected to ``balance`` +* **confirm operation**: if the payment is possible, on success will be redirected to the ``transaction-details`` screen where the detail of the current transaction will be displayed +* **get more cash**: if there is not enough balance, it will be redirected to :ref:`cta-withdraw-ref` +* **cancel**: user will be redirected to ``balance`` cta-peer-push-initiate ---------------------- -``Description``: this screen is used for the confirmation of the creation of -a peer push transaction or transfer money to another wallet. -the success of this operation will reduce the balance immediately in the wallet -and allow the user to share a taler URI to the receiver. -fee, restrictions and ETA should be clear for the user. +This screen is used for the confirmation of the creation of a peer push +transaction or transfer money to another wallet. the success of this +operation will reduce the balance immediately in the wallet and allow the user +to share a taler URI to the receiver. fee, restrictions and ETA should be +clear for the user. -``Info``: - * table of details of the operation: use the ``operation-table-details`` screen +Info +^^^^ -``Inputs``: - * subject: short description of the transaction - * expiration: absolute time/date after which the transfer is not valid anymore +* table of details of the operation: use the ``operation-table-details`` screen -``Actions``: - * confirm operation: on success will be redirected to the ``transaction-details`` screen where the detail of the current transaction will be displayed - * cancel: user will be redirected to ``balance`` +Inputs +^^^^^^ -cta-peer-push-confirm ---------------------- +* **subject**: short description of the transaction +* **expiration**: absolute time/date after which the transfer is not valid anymore -``Description``: this screen is used for the confirmation of the acceptance of -a peer push transaction or transfer money to this wallet. -the success of this operation will be an will decrease the balance in the wallet. -fee, restrictions and ETA should be clear for the user. +Actions +^^^^^^^ -``Info``: - * subject: short description of the payment - * expiration: absolute time/date after which the invoice is not valid anymore - * table of details of the operation: use the ``operation-table-details`` screen +* **confirm operation**: on success will be redirected to the ``transaction-details`` screen where the detail of the current transaction will be displayed +* **cancel**: user will be redirected to ``balance`` -``Actions``: - * confirm operation: on success will be redirected to the ``transaction-details`` screen where the detail of the current transaction will be displayed - * review and confirm ToS: if the current selected exchange has a version of ToS that the user didn't yet accepted, use the ``accept-tos`` screen - * cancel: user will be redirected to ``balance`` +Screenshots +^^^^^^^^^^^ -cta-reward ------------ ++-----------+----------------------------------------------------------------------+ +| Platform | Screenshot | ++===========+======================================================================+ +| WebEx | .. image:: ../screenshots/cta-peer-push-initiate-firefox-latest.png | ++-----------+----------------------------------------------------------------------+ +| Android | .. image:: ../screenshots/cta-peer-push-initiate-android-latest.png | +| | :width: 30% | ++-----------+----------------------------------------------------------------------+ +| iOS | .. image:: ../screenshots/cta-peer-push-initiate-ios-latest.png | +| | :width: 30% | ++-----------+----------------------------------------------------------------------+ + + +.. _cta-peer-push-confirm-ref: + +cta-peer-push-confirm +--------------------- -``Description``: this screen is used for the confirmation of the acceptance of -a reward from a merchant. -the success of this operation will be an will decrease the balance in the wallet. -fee, restrictions and ETA should be clear for the user. +This screen is used for the confirmation of the acceptance of a peer push +transaction or transfer money to this wallet. the success of this operation +will be an will decrease the balance in the wallet. fee, restrictions and ETA +should be clear for the user. -``Info``: - * amount: effective amount to receive - * exchange: from where this money comes from - * merchant: offering the reward +Info +^^^^ -``Actions``: - * confirm operation: on success will be redirected to the ``transaction-details`` screen where the detail of the current transaction will be displayed - * review and confirm ToS: if the current selected exchange has a version of ToS that the user didn't yet accepted, use the ``accept-tos`` screen - * cancel: user will be redirected to ``balance`` +* subject: short description of the payment +* expiration: absolute time/date after which the invoice is not valid anymore +* table of details of the operation: use the ``operation-table-details`` screen +Actions +^^^^^^^ + +* **confirm operation**: on success will be redirected to the ``transaction-details`` screen where the detail of the current transaction will be displayed +* **review and confirm ToS**: if the current selected exchange has a version of ToS that the user didn't yet accepted, use the :ref:`accept-tos-ref` screen +* **cancel**: user will be redirected to ``balance`` + +.. _operation-table-details-ref: operation-table-details ----------------------- -``Description``: with the table it should be clear how much the operation will cost, -the initial amount and the final amount with all the items related to the operations (like fee) +With the table it should be clear how much the operation will cost, the +initial amount and the final amount with all the items related to the +operations (like fee) + +Labels +^^^^^^ -``labels``: initial amount of the operation, and final amount are always shown. -Fee should be shown as an extra row in the table if it is non-zero. -Converted amount should be shown as an extra row if initial amount currency is not the same -as the final amount currency. +Initial amount of the operation, and final amount are always shown. Fee should +be shown as an extra row in the table if it is non-zero. Converted amount +should be shown as an extra row if initial amount currency is not the same as +the final amount currency. Initial amount label by operation: - * payment -> Price + * payment -> Price * deposit -> Send * peer-pull-credit -> Invoice * peer-pull-debit -> Invoice @@ -267,23 +666,45 @@ Initial amount label by operation: * refund -> Refund +.. _accept-tos-ref: + accept-tos ---------- -``Description``: this screen can be use everytime that the user is going to interact -with an exchange. since at any moment wallet may find that ToS changed the user needs -to be prevented from continue before reading/accepting new rules. If possible, this -screen should be used inplace of other actions and hidden if not required (for example, -user already accepted ToS) +This screen can be use everytime that the user is going to interact with an +exchange. since at any moment wallet may find that ToS changed the user needs +to be prevented from continue before reading/accepting new rules. If possible, +this screen should be used inplace of other actions and hidden if not required +(for example, user already accepted ToS) + +Inputs +^^^^^^ -``Inputs``: - * format: allow the selection of a ToS format - * languange: allow the selection of a languange different from system lang +* **format**: allow the selection of a ToS format +* **languange**: allow the selection of a languange different from system lang + +Actions +^^^^^^^ + +* **accept tos**: will mark this version as accepted in wallet core and redirect the user to the screen from where it was invoked +* **save/print tos**: will save the ToS outside of the wallet + +Screenshots +^^^^^^^^^^^ + ++-----------+------------------------------------------------------------------+ +| Platform | Screenshot | ++===========+==================================================================+ +| WebEx | .. image:: ../screenshots/cta-accept-tos-firefox-latest.png | +| | :width: 30% | ++-----------+------------------------------------------------------------------+ +| Android | .. image:: ../screenshots/cta-accept-tos-android-latest.png | +| | :width: 30% | ++-----------+------------------------------------------------------------------+ +| iOS | .. image:: ../screenshots/cta-accept-tos-ios-latest.png | +| | :width: 30% | ++-----------+------------------------------------------------------------------+ -``Actions``: - * accept tos: will mark this version as accepted in wallet core and redirect the user to the screen from where it was invoked - * save/print tos: will save the ToS outside of the wallet Q / A ===== - diff --git a/design-documents/054-dynamic-form.rst b/design-documents/054-dynamic-form.rst index 6ff84d41..d93b3684 100644 --- a/design-documents/054-dynamic-form.rst +++ b/design-documents/054-dynamic-form.rst @@ -51,7 +51,7 @@ readOnly (flag to disable input), onUpdate (callback on form data update), and computeFormState (function to derive the form state based on current data). -.. code-block:: javascript +.. code-block:: typescript interface FormType<T extends object> { value: Partial<T>; @@ -82,7 +82,7 @@ The field type ``AmountJson`` and ``AbsoluteTime`` are opaque since field is use The form can be instanciated using -.. code-block:: javascript +.. code-block:: typescript import { FormProvider } from "@gnu-taler/web-util/browser"; @@ -90,7 +90,7 @@ The form can be instanciated using Then the field component can access all the properties by the ``useField(name)`` hook, which will return -.. code-block:: javascript +.. code-block:: typescript interface InputFieldHandler<Type> { value: Type; @@ -116,10 +116,10 @@ A set of common form field exist in ``@gnu-taler/web-util``: and should be used inside a ``Form`` context. -.. code-block:: javascript +.. code-block:: none function MyFormComponent():VNode { - return <FormProvider > + return <FormProvider> <InputAmount name="amount" /> <InputText name="subject" /> <button type="submit"> Confirm </button> @@ -132,7 +132,7 @@ Example Consider a form shape represented by the TypeScript type: -.. code-block:: javascript +.. code-block:: typescript type TheFormType = { name: string, @@ -148,7 +148,7 @@ Consider a form shape represented by the TypeScript type: An example instance of this form could be: -.. code-block:: javascript +.. code-block:: typescript const theFormValue: TheFormType = { name: "Sebastian", diff --git a/design-documents/055-wallet-problem-report.rst b/design-documents/055-wallet-problem-report.rst new file mode 100644 index 00000000..2fd7a221 --- /dev/null +++ b/design-documents/055-wallet-problem-report.rst @@ -0,0 +1,114 @@ +DD 55: Wallet Problem Reports +############################# + +.. note:: + + **Status**: Early work in progress / DD number reservation. + +.. warning:: + + We concluded that we don't need the problem reports feature right now, + as all cases we care about are already covered by something else. + +Summary +======= + +This design document specifies global error reports generated/managed by wallet-core +and rendered by the wallet UIs. + +Motivation +========== + +Sometimes the wallet encounters issues that go beyond the scope of single transaction. + +Requirements +============ + +* problem reports must have a clear lifecycle +* problem reports must have some type of identification that allows to + easily find out if a new problem report needs to be created when an + error happens or whether an existing one has been created + +Proposed Solution +================= + +Report identification +--------------------- + +The report identifier serves multiple purposes: + +1. Usage as a reference in wallet-core APIs +2. De-duplication. The report ID should allow easy identification of an already existing report for a particular problem. + +New wallet-core requests +------------------------ + +* ``listProblemReports`` +* ``acknowledgeProblemReport``: Mark a problem report as read. +* ``deleteProblemReport``: Delete the problem report. + +New wallet-core notification type +--------------------------------- + +* ``problem-report`` to notify clients about status changes or an error report + (including creation!) + + +Types of reports +---------------- + +(Currently we don't have any good examples where this is actually needed.) + +Examples of what should NOT be a report +--------------------------------------- + +* money lost due to the exchange stopping to offer a denomination + + * => Should be a transactions item + +* money locked behind a (long) pending refresh + + * => Should be a pending transaction + +* money lost due to a permanently failing refresh + + * => pending or final transaction item + +* money lost due to expired denominations (auto-refresh wasn't done fast enough) + + * => transaction item + +* a denomination changed its info (expiration, fees) + + * => exchange entry state + +* Important information about the exchange changed (master pub, accounts, keys) + + => exchange entry state + + +Definition of Done +================== + +TBD. + +Alternatives +============ + +* Report problems with an API specific to each resource (exchange entry, transaction, ...) +* Have an *alerts* API that returns alerts to the client that the client can show to to the user, + but that a user can't interact with. + +Drawbacks +========= + +TBD. + +Discussion / Q&A +================ + +* When is a report amended vs a new report created? + + * example: Exchange stops offering denomination D1. Later, it stops offering D2. + Are two reports generated or is the first report changed? + diff --git a/design-documents/index.rst b/design-documents/index.rst index 91bfce4c..454564d0 100644 --- a/design-documents/index.rst +++ b/design-documents/index.rst @@ -66,4 +66,5 @@ Design documents that start with "XX" are considered deprecated. 052-libeufin-bank-2fa.rst 053-wallet-ui.rst 054-dynamic-form.rst + 055-wallet-problem-report.rst 999-template diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/CHF/cta-withdraw-sheet130-withdraw-confirm.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/CHF/cta-withdraw-sheet130-withdraw-confirm.png Binary files differnew file mode 100644 index 00000000..11dd9db0 --- /dev/null +++ b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/CHF/cta-withdraw-sheet130-withdraw-confirm.png diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/CHF/cta-withdraw-sheet130-withdraw.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/CHF/cta-withdraw-sheet130-withdraw.png Binary files differnew file mode 100644 index 00000000..d46f0e5c --- /dev/null +++ b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/CHF/cta-withdraw-sheet130-withdraw.png diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/CHF/cta-withdraw-sheet133-withdraw-confirm-bank.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/CHF/cta-withdraw-sheet133-withdraw-confirm-bank.png Binary files differnew file mode 100644 index 00000000..5d7dd8cd --- /dev/null +++ b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/CHF/cta-withdraw-sheet133-withdraw-confirm-bank.png diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/CHF/cta-withdraw-view22-balances.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/CHF/cta-withdraw-view22-balances.png Binary files differnew file mode 100644 index 00000000..473621e8 --- /dev/null +++ b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/CHF/cta-withdraw-view22-balances.png diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-bank-confirm.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-bank-confirm.png Binary files differnew file mode 100644 index 00000000..4441777a --- /dev/null +++ b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-bank-confirm.png diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-bank-confirmed.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-bank-confirmed.png Binary files differnew file mode 100644 index 00000000..c356eb13 --- /dev/null +++ b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-bank-confirmed.png diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-bank-register.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-bank-register.png Binary files differnew file mode 100644 index 00000000..e7b7c1f9 --- /dev/null +++ b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-bank-register.png diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-bank-send-money.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-bank-send-money.png Binary files differnew file mode 100644 index 00000000..788ae7ab --- /dev/null +++ b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-bank-send-money.png diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-bank-withdraw.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-bank-withdraw.png Binary files differnew file mode 100644 index 00000000..74e1efff --- /dev/null +++ b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-bank-withdraw.png diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-sheet130-withdraw-confirm.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-sheet130-withdraw-confirm.png Binary files differnew file mode 100644 index 00000000..22c57d66 --- /dev/null +++ b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-sheet130-withdraw-confirm.png diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-sheet130-withdraw.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-sheet130-withdraw.png Binary files differnew file mode 100644 index 00000000..4f893fd4 --- /dev/null +++ b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-sheet130-withdraw.png diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-sheet131-tos.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-sheet131-tos.png Binary files differnew file mode 100644 index 00000000..1aafc03e --- /dev/null +++ b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-sheet131-tos.png diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-sheet133-withdraw-confirm-bank.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-sheet133-withdraw-confirm-bank.png Binary files differnew file mode 100644 index 00000000..94ad63b1 --- /dev/null +++ b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-sheet133-withdraw-confirm-bank.png diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-view10-empty-wallet.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-view10-empty-wallet.png Binary files differnew file mode 100644 index 00000000..a6737b9f --- /dev/null +++ b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-view10-empty-wallet.png diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-view22-balances.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-view22-balances.png Binary files differnew file mode 100644 index 00000000..bd83cb8f --- /dev/null +++ b/design-documents/wallet-screenshots/ios-wallet/withdraw-bankIntegrated/cta-withdraw-view22-balances.png diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet-amount.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet-amount.png Binary files differnew file mode 100644 index 00000000..9a51cb78 --- /dev/null +++ b/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet-amount.png diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet-wireTransfer-CHF-1.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet-wireTransfer-CHF-1.png Binary files differnew file mode 100644 index 00000000..1d9fdbfd --- /dev/null +++ b/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet-wireTransfer-CHF-1.png diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet-wireTransfer-CHF-2.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet-wireTransfer-CHF-2.png Binary files differnew file mode 100644 index 00000000..3ea5b9ca --- /dev/null +++ b/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet-wireTransfer-CHF-2.png diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet-wireTransfer-CHF-3.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet-wireTransfer-CHF-3.png Binary files differnew file mode 100644 index 00000000..c15f9a5e --- /dev/null +++ b/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet-wireTransfer-CHF-3.png diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-amount.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-amount.png Binary files differnew file mode 100644 index 00000000..4db97e7c --- /dev/null +++ b/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-amount.png diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-amount2.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-amount2.png Binary files differnew file mode 100644 index 00000000..8c0d7f2a --- /dev/null +++ b/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-amount2.png diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-tos.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-tos.png Binary files differnew file mode 100644 index 00000000..b71d7dcf --- /dev/null +++ b/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-tos.png diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-wireTransfer-CHF.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-wireTransfer-CHF.png Binary files differnew file mode 100644 index 00000000..8a467161 --- /dev/null +++ b/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-wireTransfer-CHF.png diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-wireTransfer-CHF2.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-wireTransfer-CHF2.png Binary files differnew file mode 100644 index 00000000..24bb4881 --- /dev/null +++ b/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-wireTransfer-CHF2.png diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-wireTransfer-NETZ.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-wireTransfer-NETZ.png Binary files differnew file mode 100644 index 00000000..7423411a --- /dev/null +++ b/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-wireTransfer-NETZ.png diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-wireTransfer-NETZ2.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-wireTransfer-NETZ2.png Binary files differnew file mode 100644 index 00000000..80843838 --- /dev/null +++ b/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-wireTransfer-NETZ2.png diff --git a/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-withdraw-tos.png b/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-withdraw-tos.png Binary files differnew file mode 100644 index 00000000..21056f08 --- /dev/null +++ b/design-documents/wallet-screenshots/ios-wallet/withdraw-exchange/cta-withdrawExchange-sheet135-withdraw-tos.png diff --git a/design-documents/wallet-screenshots/webex-wallet/READE b/design-documents/wallet-screenshots/webex-wallet/READE new file mode 100644 index 00000000..597fa22e --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/READE @@ -0,0 +1,22 @@ +Wallet Web Extension screenshots +-------------------------------- + +Screenshoots are organized by common use case using +the happy path to ilustrate the user flow: + + * withdrawal: starts from an empty wallet and performs + a manual withdrawal with demo exchange. + * payment: starts from demo shop and pay for an article. + also showing how a refund looks. + * transfer: performs a p2p push debit and credit. + * invoice: performs a p2p pull credit and debit. + * deposit: starts from a wallet with some balance + and deposit into a bank account new yet + known by the wallet. + * add-exchange: add the test exchange into the wallet. + +In this root folder there are some additionals screen for +settings, dev tools and others. + +Screenshot starting with "store-*" are used in chrome webstore +and firefox addon store. diff --git a/design-documents/wallet-screenshots/webex-wallet/add-exchange/1-balance.png b/design-documents/wallet-screenshots/webex-wallet/add-exchange/1-balance.png Binary files differnew file mode 100644 index 00000000..1041e2ee --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/add-exchange/1-balance.png diff --git a/design-documents/wallet-screenshots/webex-wallet/add-exchange/10-testkudos-in-the-list.png b/design-documents/wallet-screenshots/webex-wallet/add-exchange/10-testkudos-in-the-list.png Binary files differnew file mode 100644 index 00000000..12a53026 --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/add-exchange/10-testkudos-in-the-list.png diff --git a/design-documents/wallet-screenshots/webex-wallet/add-exchange/11-select-test-kudos.png b/design-documents/wallet-screenshots/webex-wallet/add-exchange/11-select-test-kudos.png Binary files differnew file mode 100644 index 00000000..43e18c89 --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/add-exchange/11-select-test-kudos.png diff --git a/design-documents/wallet-screenshots/webex-wallet/add-exchange/2-click-get-cash.png b/design-documents/wallet-screenshots/webex-wallet/add-exchange/2-click-get-cash.png Binary files differnew file mode 100644 index 00000000..d7d247f0 --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/add-exchange/2-click-get-cash.png diff --git a/design-documents/wallet-screenshots/webex-wallet/add-exchange/3-click-add-exchange.png b/design-documents/wallet-screenshots/webex-wallet/add-exchange/3-click-add-exchange.png Binary files differnew file mode 100644 index 00000000..7a1a48e9 --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/add-exchange/3-click-add-exchange.png diff --git a/design-documents/wallet-screenshots/webex-wallet/add-exchange/4-input-URL.png b/design-documents/wallet-screenshots/webex-wallet/add-exchange/4-input-URL.png Binary files differnew file mode 100644 index 00000000..efdf852a --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/add-exchange/4-input-URL.png diff --git a/design-documents/wallet-screenshots/webex-wallet/add-exchange/5-click-next.png b/design-documents/wallet-screenshots/webex-wallet/add-exchange/5-click-next.png Binary files differnew file mode 100644 index 00000000..9a2782f2 --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/add-exchange/5-click-next.png diff --git a/design-documents/wallet-screenshots/webex-wallet/add-exchange/6-review-tos.png b/design-documents/wallet-screenshots/webex-wallet/add-exchange/6-review-tos.png Binary files differnew file mode 100644 index 00000000..44a85d6f --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/add-exchange/6-review-tos.png diff --git a/design-documents/wallet-screenshots/webex-wallet/add-exchange/7-accept-tos.png b/design-documents/wallet-screenshots/webex-wallet/add-exchange/7-accept-tos.png Binary files differnew file mode 100644 index 00000000..c73c5256 --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/add-exchange/7-accept-tos.png diff --git a/design-documents/wallet-screenshots/webex-wallet/add-exchange/8-confirm.png b/design-documents/wallet-screenshots/webex-wallet/add-exchange/8-confirm.png Binary files differnew file mode 100644 index 00000000..1041e2ee --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/add-exchange/8-confirm.png diff --git a/design-documents/wallet-screenshots/webex-wallet/add-exchange/9-click-get-cash.png b/design-documents/wallet-screenshots/webex-wallet/add-exchange/9-click-get-cash.png Binary files differnew file mode 100644 index 00000000..d7d247f0 --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/add-exchange/9-click-get-cash.png diff --git a/design-documents/wallet-screenshots/webex-wallet/deposit/1-balance.png b/design-documents/wallet-screenshots/webex-wallet/deposit/1-balance.png Binary files differnew file mode 100644 index 00000000..7c571c48 --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/deposit/1-balance.png diff --git a/design-documents/wallet-screenshots/webex-wallet/deposit/10-balance.png b/design-documents/wallet-screenshots/webex-wallet/deposit/10-balance.png Binary files differnew file mode 100644 index 00000000..4e3a787b --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/deposit/10-balance.png diff --git a/design-documents/wallet-screenshots/webex-wallet/deposit/2-click-send.png b/design-documents/wallet-screenshots/webex-wallet/deposit/2-click-send.png Binary files differnew file mode 100644 index 00000000..2cdb5fe0 --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/deposit/2-click-send.png diff --git a/design-documents/wallet-screenshots/webex-wallet/deposit/3-click-deposit.png b/design-documents/wallet-screenshots/webex-wallet/deposit/3-click-deposit.png Binary files differnew file mode 100644 index 00000000..afc4a431 --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/deposit/3-click-deposit.png diff --git a/design-documents/wallet-screenshots/webex-wallet/deposit/4-click-add-account.png b/design-documents/wallet-screenshots/webex-wallet/deposit/4-click-add-account.png Binary files differnew file mode 100644 index 00000000..c91bc8d9 --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/deposit/4-click-add-account.png diff --git a/design-documents/wallet-screenshots/webex-wallet/deposit/5-complete-form.png b/design-documents/wallet-screenshots/webex-wallet/deposit/5-complete-form.png Binary files differnew file mode 100644 index 00000000..77514161 --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/deposit/5-complete-form.png diff --git a/design-documents/wallet-screenshots/webex-wallet/deposit/6-click-add.png b/design-documents/wallet-screenshots/webex-wallet/deposit/6-click-add.png Binary files differnew file mode 100644 index 00000000..e78538c7 --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/deposit/6-click-add.png diff --git a/design-documents/wallet-screenshots/webex-wallet/deposit/7-confirm-deposit.png b/design-documents/wallet-screenshots/webex-wallet/deposit/7-confirm-deposit.png Binary files differnew file mode 100644 index 00000000..bf2c61bc --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/deposit/7-confirm-deposit.png diff --git a/design-documents/wallet-screenshots/webex-wallet/deposit/8-show-transaction.png b/design-documents/wallet-screenshots/webex-wallet/deposit/8-show-transaction.png Binary files differnew file mode 100644 index 00000000..381ae09e --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/deposit/8-show-transaction.png diff --git a/design-documents/wallet-screenshots/webex-wallet/deposit/9-after-deposit-confirmed.png b/design-documents/wallet-screenshots/webex-wallet/deposit/9-after-deposit-confirmed.png Binary files differnew file mode 100644 index 00000000..74c2026d --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/deposit/9-after-deposit-confirmed.png diff --git a/design-documents/wallet-screenshots/webex-wallet/dev-tools.png b/design-documents/wallet-screenshots/webex-wallet/dev-tools.png Binary files differnew file mode 100644 index 00000000..a817d055 --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/dev-tools.png diff --git a/design-documents/wallet-screenshots/webex-wallet/invoice/1-balance.png b/design-documents/wallet-screenshots/webex-wallet/invoice/1-balance.png Binary files differnew file mode 100644 index 00000000..a6692c4f --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/invoice/1-balance.png diff --git a/design-documents/wallet-screenshots/webex-wallet/invoice/10-confirm-transfer.png b/design-documents/wallet-screenshots/webex-wallet/invoice/10-confirm-transfer.png Binary files differnew file mode 100644 index 00000000..2611c9f3 --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/invoice/10-confirm-transfer.png diff --git a/design-documents/wallet-screenshots/webex-wallet/invoice/11-show-history.png b/design-documents/wallet-screenshots/webex-wallet/invoice/11-show-history.png Binary files differnew file mode 100644 index 00000000..52907939 --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/invoice/11-show-history.png diff --git a/design-documents/wallet-screenshots/webex-wallet/invoice/2-click-add.png b/design-documents/wallet-screenshots/webex-wallet/invoice/2-click-add.png Binary files differnew file mode 100644 index 00000000..7834436d --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/invoice/2-click-add.png diff --git a/design-documents/wallet-screenshots/webex-wallet/invoice/3-input-six.png b/design-documents/wallet-screenshots/webex-wallet/invoice/3-input-six.png Binary files differnew file mode 100644 index 00000000..0f910210 --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/invoice/3-input-six.png diff --git a/design-documents/wallet-screenshots/webex-wallet/invoice/4-click-invoice.png b/design-documents/wallet-screenshots/webex-wallet/invoice/4-click-invoice.png Binary files differnew file mode 100644 index 00000000..0d7c1b31 --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/invoice/4-click-invoice.png diff --git a/design-documents/wallet-screenshots/webex-wallet/invoice/5-complete-form.png b/design-documents/wallet-screenshots/webex-wallet/invoice/5-complete-form.png Binary files differnew file mode 100644 index 00000000..625afb3c --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/invoice/5-complete-form.png diff --git a/design-documents/wallet-screenshots/webex-wallet/invoice/6-create-invoice.png b/design-documents/wallet-screenshots/webex-wallet/invoice/6-create-invoice.png Binary files differnew file mode 100644 index 00000000..def698a8 --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/invoice/6-create-invoice.png diff --git a/design-documents/wallet-screenshots/webex-wallet/invoice/7-copy-qr-open-qr-page.png b/design-documents/wallet-screenshots/webex-wallet/invoice/7-copy-qr-open-qr-page.png Binary files differnew file mode 100644 index 00000000..fe221eac --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/invoice/7-copy-qr-open-qr-page.png diff --git a/design-documents/wallet-screenshots/webex-wallet/invoice/8-paste-URI.png b/design-documents/wallet-screenshots/webex-wallet/invoice/8-paste-URI.png Binary files differnew file mode 100644 index 00000000..26351cb9 --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/invoice/8-paste-URI.png diff --git a/design-documents/wallet-screenshots/webex-wallet/invoice/9-click-open.png b/design-documents/wallet-screenshots/webex-wallet/invoice/9-click-open.png Binary files differnew file mode 100644 index 00000000..90393d3b --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/invoice/9-click-open.png diff --git a/design-documents/wallet-screenshots/webex-wallet/payment/1-load-shop.png b/design-documents/wallet-screenshots/webex-wallet/payment/1-load-shop.png Binary files differnew file mode 100644 index 00000000..4aacc47b --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/payment/1-load-shop.png diff --git a/design-documents/wallet-screenshots/webex-wallet/payment/10-click-article-URL.png b/design-documents/wallet-screenshots/webex-wallet/payment/10-click-article-URL.png Binary files differnew file mode 100644 index 00000000..74488cb6 --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/payment/10-click-article-URL.png diff --git a/design-documents/wallet-screenshots/webex-wallet/payment/2-click-first-article.png b/design-documents/wallet-screenshots/webex-wallet/payment/2-click-first-article.png Binary files differnew file mode 100644 index 00000000..31635b8a --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/payment/2-click-first-article.png diff --git a/design-documents/wallet-screenshots/webex-wallet/payment/3-confirm-payment.png b/design-documents/wallet-screenshots/webex-wallet/payment/3-confirm-payment.png Binary files differnew file mode 100644 index 00000000..016f5514 --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/payment/3-confirm-payment.png diff --git a/design-documents/wallet-screenshots/webex-wallet/payment/4-click-refund.png b/design-documents/wallet-screenshots/webex-wallet/payment/4-click-refund.png Binary files differnew file mode 100644 index 00000000..4a3ddd39 --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/payment/4-click-refund.png diff --git a/design-documents/wallet-screenshots/webex-wallet/payment/5-click-request-refund.png b/design-documents/wallet-screenshots/webex-wallet/payment/5-click-request-refund.png Binary files differnew file mode 100644 index 00000000..9b27cd5b --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/payment/5-click-request-refund.png diff --git a/design-documents/wallet-screenshots/webex-wallet/payment/6-accept-refund.png b/design-documents/wallet-screenshots/webex-wallet/payment/6-accept-refund.png Binary files differnew file mode 100644 index 00000000..a4b1c137 --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/payment/6-accept-refund.png diff --git a/design-documents/wallet-screenshots/webex-wallet/payment/7-click-refund-detail.png b/design-documents/wallet-screenshots/webex-wallet/payment/7-click-refund-detail.png Binary files differnew file mode 100644 index 00000000..14291836 --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/payment/7-click-refund-detail.png diff --git a/design-documents/wallet-screenshots/webex-wallet/payment/8-show-history.png b/design-documents/wallet-screenshots/webex-wallet/payment/8-show-history.png Binary files differnew file mode 100644 index 00000000..2758f7f3 --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/payment/8-show-history.png diff --git a/design-documents/wallet-screenshots/webex-wallet/payment/9-click-receipt.png b/design-documents/wallet-screenshots/webex-wallet/payment/9-click-receipt.png Binary files differnew file mode 100644 index 00000000..a4b1c137 --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/payment/9-click-receipt.png diff --git a/design-documents/wallet-screenshots/webex-wallet/scan-qr-code.png b/design-documents/wallet-screenshots/webex-wallet/scan-qr-code.png Binary files differnew file mode 100644 index 00000000..ae28e3db --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/scan-qr-code.png diff --git a/design-documents/wallet-screenshots/webex-wallet/settings-developer-mode.png b/design-documents/wallet-screenshots/webex-wallet/settings-developer-mode.png Binary files differnew file mode 100644 index 00000000..c93883dc --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/settings-developer-mode.png diff --git a/design-documents/wallet-screenshots/webex-wallet/settings-normal-mode.png b/design-documents/wallet-screenshots/webex-wallet/settings-normal-mode.png Binary files differnew file mode 100644 index 00000000..50f70cab --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/settings-normal-mode.png diff --git a/design-documents/wallet-screenshots/webex-wallet/store-installed.png b/design-documents/wallet-screenshots/webex-wallet/store-installed.png Binary files differnew file mode 100644 index 00000000..67c481fc --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/store-installed.png diff --git a/design-documents/wallet-screenshots/webex-wallet/store-payment.png b/design-documents/wallet-screenshots/webex-wallet/store-payment.png Binary files differnew file mode 100644 index 00000000..3f776696 --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/store-payment.png diff --git a/design-documents/wallet-screenshots/webex-wallet/store-withdraw.png b/design-documents/wallet-screenshots/webex-wallet/store-withdraw.png Binary files differnew file mode 100644 index 00000000..8409a0b9 --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/store-withdraw.png diff --git a/design-documents/wallet-screenshots/webex-wallet/transfer/1-initial-balance.png b/design-documents/wallet-screenshots/webex-wallet/transfer/1-initial-balance.png Binary files differnew file mode 100644 index 00000000..20e74cf3 --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/transfer/1-initial-balance.png diff --git a/design-documents/wallet-screenshots/webex-wallet/transfer/10-open-URI.png b/design-documents/wallet-screenshots/webex-wallet/transfer/10-open-URI.png Binary files differnew file mode 100644 index 00000000..22f21f89 --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/transfer/10-open-URI.png diff --git a/design-documents/wallet-screenshots/webex-wallet/transfer/11-accept-transfer.png b/design-documents/wallet-screenshots/webex-wallet/transfer/11-accept-transfer.png Binary files differnew file mode 100644 index 00000000..9ee2083a --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/transfer/11-accept-transfer.png diff --git a/design-documents/wallet-screenshots/webex-wallet/transfer/12-show-history.png b/design-documents/wallet-screenshots/webex-wallet/transfer/12-show-history.png Binary files differnew file mode 100644 index 00000000..d2d12ca8 --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/transfer/12-show-history.png diff --git a/design-documents/wallet-screenshots/webex-wallet/transfer/2-click-send.png b/design-documents/wallet-screenshots/webex-wallet/transfer/2-click-send.png Binary files differnew file mode 100644 index 00000000..0e705860 --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/transfer/2-click-send.png diff --git a/design-documents/wallet-screenshots/webex-wallet/transfer/3-amount-five.png b/design-documents/wallet-screenshots/webex-wallet/transfer/3-amount-five.png Binary files differnew file mode 100644 index 00000000..ffe4bee7 --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/transfer/3-amount-five.png diff --git a/design-documents/wallet-screenshots/webex-wallet/transfer/4-send-wallet.png b/design-documents/wallet-screenshots/webex-wallet/transfer/4-send-wallet.png Binary files differnew file mode 100644 index 00000000..f566b0cb --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/transfer/4-send-wallet.png diff --git a/design-documents/wallet-screenshots/webex-wallet/transfer/5-complete-form.png b/design-documents/wallet-screenshots/webex-wallet/transfer/5-complete-form.png Binary files differnew file mode 100644 index 00000000..836755ca --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/transfer/5-complete-form.png diff --git a/design-documents/wallet-screenshots/webex-wallet/transfer/6-confirm-transfer.png b/design-documents/wallet-screenshots/webex-wallet/transfer/6-confirm-transfer.png Binary files differnew file mode 100644 index 00000000..55de4bb0 --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/transfer/6-confirm-transfer.png diff --git a/design-documents/wallet-screenshots/webex-wallet/transfer/7-show-history.png b/design-documents/wallet-screenshots/webex-wallet/transfer/7-show-history.png Binary files differnew file mode 100644 index 00000000..39de7b66 --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/transfer/7-show-history.png diff --git a/design-documents/wallet-screenshots/webex-wallet/transfer/8-scan-qr.png b/design-documents/wallet-screenshots/webex-wallet/transfer/8-scan-qr.png Binary files differnew file mode 100644 index 00000000..cacdce06 --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/transfer/8-scan-qr.png diff --git a/design-documents/wallet-screenshots/webex-wallet/transfer/9-paste-URI.png b/design-documents/wallet-screenshots/webex-wallet/transfer/9-paste-URI.png Binary files differnew file mode 100644 index 00000000..32ac0ff4 --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/transfer/9-paste-URI.png diff --git a/design-documents/wallet-screenshots/webex-wallet/withdrawal/10-transaction-completed.png b/design-documents/wallet-screenshots/webex-wallet/withdrawal/10-transaction-completed.png Binary files differnew file mode 100644 index 00000000..2a774334 --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/withdrawal/10-transaction-completed.png diff --git a/design-documents/wallet-screenshots/webex-wallet/withdrawal/11-history-after-withdraw.png b/design-documents/wallet-screenshots/webex-wallet/withdrawal/11-history-after-withdraw.png Binary files differnew file mode 100644 index 00000000..54b05212 --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/withdrawal/11-history-after-withdraw.png diff --git a/design-documents/wallet-screenshots/webex-wallet/withdrawal/2-empty-wallet.png b/design-documents/wallet-screenshots/webex-wallet/withdrawal/2-empty-wallet.png Binary files differnew file mode 100644 index 00000000..79fc787b --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/withdrawal/2-empty-wallet.png diff --git a/design-documents/wallet-screenshots/webex-wallet/withdrawal/3-get-digital-cash.png b/design-documents/wallet-screenshots/webex-wallet/withdrawal/3-get-digital-cash.png Binary files differnew file mode 100644 index 00000000..273d5f5f --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/withdrawal/3-get-digital-cash.png diff --git a/design-documents/wallet-screenshots/webex-wallet/withdrawal/4-select-kudos.png b/design-documents/wallet-screenshots/webex-wallet/withdrawal/4-select-kudos.png Binary files differnew file mode 100644 index 00000000..741ac32a --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/withdrawal/4-select-kudos.png diff --git a/design-documents/wallet-screenshots/webex-wallet/withdrawal/5-set-amount-five.png b/design-documents/wallet-screenshots/webex-wallet/withdrawal/5-set-amount-five.png Binary files differnew file mode 100644 index 00000000..8454928b --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/withdrawal/5-set-amount-five.png diff --git a/design-documents/wallet-screenshots/webex-wallet/withdrawal/6-withdraw-from-bank.png b/design-documents/wallet-screenshots/webex-wallet/withdrawal/6-withdraw-from-bank.png Binary files differnew file mode 100644 index 00000000..e0942a0c --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/withdrawal/6-withdraw-from-bank.png diff --git a/design-documents/wallet-screenshots/webex-wallet/withdrawal/7-review-tos.png b/design-documents/wallet-screenshots/webex-wallet/withdrawal/7-review-tos.png Binary files differnew file mode 100644 index 00000000..505e06d3 --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/withdrawal/7-review-tos.png diff --git a/design-documents/wallet-screenshots/webex-wallet/withdrawal/8-accept-tos.png b/design-documents/wallet-screenshots/webex-wallet/withdrawal/8-accept-tos.png Binary files differnew file mode 100644 index 00000000..61d3c0a4 --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/withdrawal/8-accept-tos.png diff --git a/design-documents/wallet-screenshots/webex-wallet/withdrawal/9-confirm-withdraw.png b/design-documents/wallet-screenshots/webex-wallet/withdrawal/9-confirm-withdraw.png Binary files differnew file mode 100644 index 00000000..579803cc --- /dev/null +++ b/design-documents/wallet-screenshots/webex-wallet/withdrawal/9-confirm-withdraw.png |
