GNU Taler Demo Upgrade Checklist

GNU Taler Demo Upgrade Checklist#

Domains#

The checklist uses the demo.taler.net domains. However, the same sandcastle demo can also be hosted at other domains. The same instructions should apply.

Post-upgrade checks#

  • Run the headless wallet to check that services are actually working:

    taler-wallet-cli api 'runIntegrationTestV2' '{"exchangeBaseUrl":"https://exchange.demo.taler.net/", "corebankApiBaseUrl": "https://bank.demo.taler.net/", "merchantBaseUrl": "https://backend.demo.taler.net/", "merchantAuthToken":"secret-token:sandbox"}'

Basics#

LibEuFIn#

To run those test you need one wallet.

  • Visit https://bank.demo.taler.net/

  • register two user bank1 & bank2

  • bank language switcher

  • bank logout

  • bank login

  • account management

  • transaction history: delete pending withdraw

  • check transaction history

  • change credentials (password)

  • (conversion-only) test cash-in

  • (conversion-only) test cash-out

  • (conversion-only) test cash-out limit enforced

  • (if configured) 2FA for withdrawals

  • (if configured) 2FA for cash-out

  • (MB-only) manually import transactions from bank account

  • (MB-only) manually export transactions to bank account

Wallets#

We consider the following published wallets to be “production wallets”:

  • Browser: Firefox Add-On Store

  • Browser: Chrome Web Store

  • Android: Google Play / F-Droid / APK

  • iOS: Apple Store / Testflight

To run those tests you need one to three wallets (you should ideally use three different platforms) and one to two opened bank accounts into a bank with Taler Integration.

Withdraw & Deposit#

To run those tests you need one wallet and two bank accounts.

  • wallet withdrawal payto-URI

    • trigger withdraw from wallet & copy URI

    • paste URI in bank & pay more

    • wallet redirect to success and receive more

    • paste URI in bank & pay -> bounce

  • bank withdrawal success

    • bank trigger withdrawal & save QR code

    • wallet scan QR code

    • bank pay

    • wallet redirect to success

    • wallet scan QR code -> redirect to success

  • bank withdrawal failure

    • bank trigger withdrawal

    • wallet scan QR code

    • bank cancel

    • wallet redirect to failure

    • wallet scan QR code -> redirect to failure

  • deposit existing account

    • check bank1 account is already registered

    • trigger deposit using bank1

    • check deposit in bank1 account

  • deposit new account

    • add bank2 account

    • trigger deposit using bank2

    • check deposit in bank2 account

P2P payments#

TODO: some pay* interactions should become unnecessary in a future update: https://bugs.gnunet.org/view.php?id=9670 TODO: check different kind of failure (aborted, expired, already complete by another wallet) are correctly shown

To run those test you need three wallets.

Concurrent flow#

Test what happens when two wallets compete on the same payment.

  • initiate payment in wallet1 and save URI

  • scan QR code in wallet2 & wallet3

  • pay with wallet2 -> redirect to success

  • check wallet1 redirect to success

  • pay* with wallet3 -> redirect to failure

  • paste URI in wallet2 -> pay* -> redirect to success

  • paste URI in wallet3 -> pay* -> redirect to failure

Abort flow#

Test what happens when a payment is aborted.

  • initiate payment in wallet1 and save URI

  • scan QR code in wallet2

  • abort in wallet1 -> redirect to failure

  • pay* with wallet2 -> redirect to failure

  • paste URI in wallet3 -> pay* -> redirect to failure

Expire flow#

Test what happens when a payment is expired.

  • initiate payment in wallet1 with short expiration and save URI

  • scan QR code in wallet2

  • wait for expiration

  • check wallet1 redirect to failure

  • pay* with wallet2 -> redirect to failure

  • paste URI in wallet3 -> pay* -> redirect to failure

Network flow#

Test what happens when the wallet does not have internet access.

  • disable network in wallet1

  • initiate payment in wallet1

  • check that a loading state with warning is shown

  • enable network in wallet1

  • check that wallet1 recover and display QR code and URI

  • disable network in wallet2

  • scan QR code -> network failure screen

  • enable network in wallet2

  • pay with wallet2 -> redirect to success

Checklist#

  • pull payment (receive) concurrent flow

  • pull payment (receive) abort flow

  • pull payment (receive) expire flow

  • pull payment (receive) network flow

  • push payment (send) concurrent flow

  • push payment (send) abort flow

  • push payment (send) expire flow

  • push payment (send) network flow

  • check pull payment insufficient fund error on completion

  • check push payment insufficient fund error on initiation

  • sending money back from wallet to bank account

  • wallet transaction history rendering

  • delete history entry

Exchange management#

  • Try to explicitly reload exchange keys (still needed?)

  • Have wallet show ToS of an exchange

  • Have wallet show PP of an exchange

  • Remove exchange with remaining balance

  • Check remaining balance is deposited into origin account

Android Cashier App#

To run those test you need one wallet and a bank account.

  • Configure cashier app with libeufin account

  • Lock and reconnect

  • Reconfigure

  • Check insufficient balance error

  • Check zero error

  • Withdraw cash from cashier

    • Initiate withdraw in cashier

    • Scan QR code in wallet & accept

    • Pay in cashier

  • Withdraw cash from cashier & bank

    • Initiate withdraw in cashier

    • Scan QR code in wallet & accept

    • Pay from bank account website (TODO do we want this to be proposed ?)

    • Check cashier redirect

Blog demo#

  • Visit https://shop.demo.taler.net/

  • blog page article list renders

  • blog purchase & repurchase

    • payment for blog article

    • Verify that the balance in the wallet was updated correctly.

    • Go back to https://shop.demo.taler.net/ and click on the same article link. Verify that the article is shown and no repeated payment is requested.

  • blog repurchase

    • Open the fulfillment page from the previous step in an anonymous browsing session (without the wallet installed) and verify that it requests a payment again.

    • Delete cookies on https://shop.demo.taler.net/ and click on the same article again. Verify that the wallet detects that the article has already purchased and successfully redirects to the article without spending more money.

    • Remove purchase payment

    • Clear cookies and check repurchase no longer works

  • blog refund

    • payment for other blog article

    • refund of 2nd blog article (button at the end)

    • wallet transaction history rendering

    • delete refund history entry; check original purchase entry was also deleted

    • payment for other blog article

    • refund of 3rd blog article (button at the end)

    • wallet transaction history rendering

    • delete 3rd block purchase history entry; check refund entry was also deleted

Donation demo#

  • Reset wallet

  • Withdraw age-restricted coins (< 14)

  • Try to make a donation on https://donations.demo.taler.net/, fail due to age-restriction

  • Withdraw age-restricted coins (>= 14)

  • Make a donation on https://donations.demo.taler.net/

  • Make another donation with the same parameters and verify that the payment is requested again, instead of showing the previous fulfillment page.

Merchant SPA#

  • test SPA loads

  • check SPA language switcher

  • try to login with wrong password

  • try to login with correct password

  • create instance, check default is set to cover (STEFAN) fees

  • modify instance

  • add bank account

  • (if KYC is on) check KYC AUTH request notification is requested

  • edit bank account

  • (if KYC is on) check KYC AUTH request notification is requested

  • (if KYC is on) perform KYC AUTH wire transfer

  • (if KYC is on) check KYC AUTH request notification is cleared

  • remove bank account

  • check order creation fails without bank account

  • add bank account again

  • (if KYC is on) check KYC AUTH request notification remains off

  • add inventory category

  • add 2nd inventory category

  • edit inventory category

  • add product with 1 in stock and preview image and two categories

  • edit inventory product

  • add 2nd inventory product

  • delete 2nd inventory product

  • add “advanced” order with inventory product and a 2 minute wire delay

  • claim order, check available stock goes down in inventory

  • create 2nd order, check this fails due to missing inventory

  • pay for 1st order with wallet

  • check transaction history for preview image

  • trigger partial refund

  • accept refund with wallet

  • create template with fixed summary, default editable price

  • scan template QR code, edit price and pay

  • add TOTP device (using some TOTP app to share secret with)

  • edit TOTP device (using some TOTP app to share secret with)

  • edit template to add TOTP device, set price to fixed, summary to be entered

  • scan template QR code, edit summary and pay

  • check displayed TOTP code matches TOTP app

  • delete TOTP device

  • delete template device

  • do manual wire transfer in bank to establish reserve funding

  • check that partially refunded order is marked as awaiting wire transfer

  • check bank wired funds to merchant (if needed, wait)

  • add bank wire transfer manually to backend

  • change settings for merchant to not pay for (STEFAN) fees

  • create and pay for another order with 1 minute wire transfer delay

  • edit bank account details, adding revenue facade with credentials

  • wait and check if wire transfer is automatically imported

  • check that orders are marked as completed

Android Merchant PoS#

  • Configure using instance with configured inventory

  • Check categories and products show (with images!)

  • Add product to order

  • Add product again to order (+)

  • Remove product from order (-)

  • Request payment

  • Abort payment, check order can still be edited

  • Request and make payment, check payment confirmed

  • Create another order, delete/abort it without paying

Auditor#

  • Check auditor SPA is access controlled

  • Check /config endpoint (and implied POST /deposit-confirmation are public)

  • Check exchange /keys reports auditor’s existence

  • Check auditor imports exchange transaction data (non-zero progress points)

  • Check auditor SPA reports no failures from previous transactions

  • Check auditor SPA bank balance matches exchange bank balance

Exchange KYC Triggers#

Each of these checks should be done with a fresh account, merchant instance or wallet (if they previously ran into a KYC check already). Specific amounts depend on the configured trigger thresholds.

  • withdraw: withdraw large amount, make sure it is forbidden or runs into KYC check (shown by wallet)

  • aggregation: pay large order, make sure it runs into aggregate KYC check (shown by merchant SPA)

  • deposit large amount into other account with wallet, make sure it runs into KYC AUTH + KYC check (shown by wallet)

  • balance: withdraw large amounts from multiple accounts, make sure it is forbidden or runs into KYC check (shown by wallet)

  • P2P receive large amount: make sure it runs into KYC check (shown by wallet)

  • P2P invoice large amount: make sure it runs into KYC check (shown by wallet)

  • Onboarding check (KYC AUTH, ToS-acceptance) triggered for new merchant accounts

Exchange KYC SPA#

Consult the specific deployment’s KYC configuration to see which KYC processes are used.

  • check SPA language switcher

  • check INFO page(s) where KYC status is shown

  • check LINK page(s) with link to external KYC process (e.g. challenger)

  • (if possible) check challenger SPA language switcher

  • (if possible) check KYC SPA main page with multiple choices (AND/OR combinators)

  • perform LINKed external process, check data imported correctly

  • check FORM pages for each possible KYC form of the deployment

  • submit FORM pages with valid but also obviously invalid data (if applicable)

  • check main page updated to next stage correctly after each possible FORM

  • check SMS generation (and restriction to CH-only) by SMS challenger (telesign!), production-only (not for demo)

  • check Postal mail generation (incl. address conversion to proper format) by Postal challenger (pingen!), production-only (not for demo)

Exchange AML SPA#

  • check SPA language switcher

  • load, enable account using taler-exchange-offline

  • log out

  • check log in fails from different browser with same password

  • check log in fails from original browser with incorrect password

  • check log in succeeds with correct password

  • enter data in each available AML form

  • check data of AML form shows properly in account history

  • submit AML form and trigger event (explicitly or by setting account property)

  • check event statistics are properly updated and shown on main page

  • submit AML form and change account thresholds for some operation with VERBOTEN

  • check new threshold is now enforced by the exchange (VERBOTEN)

  • submit AML form and change account threshold for some operation to trigger KYC check

  • check new threshold is now enforced by exchange and KYC check is triggered

  • submit AML form and change account threshold for some operation to trigger AML investigation (and clear investigation flag)

  • check new threshold marks account again for investigation after threshold is crossed

  • submit AML form with a short expiration (minutes) and a fallback of “investigate again”

  • check new rules are applied until expiration

  • check account is automatically listed again for investigation after expiration time is reached

  • view historic AML decisions in history, view submitted KYC data

Sanction lists#

  • ensure account with KYC data exists in the system

  • manually write santion list with user that clearly does not match

  • import sanction list, check nothing is done

  • edit sanction list to match the existing account a bit

  • import sanction list, check account is flagged for investigation by AML staff but remains operational

  • clear the investigation flag

  • edit sanction list to match the existing account perfectly

  • import sanction list, check account is flagged for investigation by AML staff and also frozen (all limits 0, not exposed)

  • manually clear user and unfreeze account in AML SPA (setting “SANCTION-OVERRIDE: $DATE” property)

  • re-import sanction list with yet another user and cleared user

  • check manually cleared user is not re-frozen (due to “SANCTION-OVERRIDE” property with date in the future)

  • add user matching new entry in sanction list

  • check new user is auto-frozen and flagged for investigation

Shutdown#

  • create two full wallets, fill one only via (a large) P2P transfer

  • revoke highest-value denomination

  • spend money in a wallet such that the balance falls below highest denomination value

  • revoke all remaining denominations

  • fail to spend any more money

  • if wallet was filled via p2p payments, wallet asks for target deposit account (exchange going out of business)

  • enter bank account (if possible)

  • wallet balance goes to zero

  • specified bank account receives remaining balance