taler
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Taler] Cashdesk with GNU Taler?


From: Christian Grothoff
Subject: Re: [Taler] Cashdesk with GNU Taler?
Date: Mon, 5 Dec 2022 09:30:38 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0

On 12/5/22 02:44, Florian Jung via Taler wrote:
Hm, after setting `global-fees`, it seems to kinda work...

I am still getting an error when creating the wallet to wallet transfer (and somehow, the exchange still complains about the missing kke7, but if I go back in the wallet menu and then tap the pending transfer, a QR code is displayed. If I scan this code, though, I get a 404 on /contracts/blah :/

Do i need to set a different fee, or is

    taler-exchange-offline global-fee 2024 MANA:0 MANA:0 MANA:0 365d 365d 100 | taler-exchange-offline upload

the wrong command?

This is about right, do note that the current wallet doesn't yet support non-zero fees, so good choice here ;-). But you of course should (also) do 2023 and 2022 as years for it to work 'now'.

If you only set the fees for 2024, I guess I see why the exchange would still complain anymore about the fees not having been configured at all, and maybe the wallet hits a different path and again displays the error badly.

Sebastian: can you please investigate and/or open a bug on wallet error handling for "interesting" configurations of global fees in an exchange? This totally feels like something we likely did not thoroughly test...

On 12/5/22 02:00, Florian Jung via Taler wrote:

A-ha!

I don't know what changed (except I withdrew 5 more coins, totalling to 15), but now I get "got error response from exchange"; and the exchange logs this:

2022-12-05T00:54:59.198329+0000 taler-exchange-httpd-38(DXP21S0H55400M503R8D3E4QXG) INFO Handling new request 2022-12-05T00:54:59.198548+0000 taler-exchange-httpd-38(5A3SYKNA84T2N3YKYTJBSR53VM) INFO Handling request (POST) for URL '/purses/FJHTHEZ1AQGDEVSBKAX2Y08TQCQJ50TVFN93FC36Q1SAQAPBK7T0/create' 2022-12-05T00:54:59.198605+0000 taler-exchange-httpd-38(5A3SYKNA84T2N3YKYTJBSR53VM) INFO Handling request (POST) for URL '/purses/FJHTHEZ1AQGDEVSBKAX2Y08TQCQJ50TVFN93FC36Q1SAQAPBK7T0/create' 2022-12-05T00:54:59.198649+0000 taler-exchange-httpd-38(5A3SYKNA84T2N3YKYTJBSR53VM) INFO Handling request (POST) for URL '/purses/FJHTHEZ1AQGDEVSBKAX2Y08TQCQJ50TVFN93FC36Q1SAQAPBK7T0/create' 2022-12-05T00:54:59.199065+0000 taler-exchange-httpd-38(5A3SYKNA84T2N3YKYTJBSR53VM) WARNING Cannot create purse: global fees not configured! 2022-12-05T00:54:59.199344+0000 taler-exchange-httpd-38(5A3SYKNA84T2N3YKYTJBSR53VM) INFO Request for `/purses/FJHTHEZ1AQGDEVSBKAX2Y08TQCQJ50TVFN93FC36Q1SAQAPBK7T0/create' completed (0)

"global fees not configured" sounds like a valid reason, but which config options are needed to fix this?


Also, can you help me understand how transferring money from wallet to wallet works on a technical level? My naive expectation is that it works the same as withdrawing via SEPA from a bank account, just that Taler coins are redeemed at the exchange in order to create a reserve, rather than using a SEPA transfer to create one. Is that about right?

Yes, modulo that we have the 'purse' as an extra construct to enable an intermediate stage where we can hold the money while the KYC happens, which we can use for pull payments (aka invoicing) and from which we can roll back the transfer in case the recipient doesn't accept (or receive) the payment request.

How is this different from paying a merchant? I'm a bit puzzled since wallet-to-merchant existed for a long time, but wallet-to-wallet was announced as something new. It would feel natural to me to break a merchant down to "wallet-to-wallet, and then wallet-to-sepa at the end of the business day", but apparently it's handled differently.

It is, the original merchant is always wallet-to-bank account. That's good for the security of the merchant: if you have significant revenue, keeping that in a wallet (with whatever security OSes and HW can offer today) might be inadequate, so depositing it into your bank account is likely better. Plus, depending on the legal system, that may or may not allow the exchange to not explicitly do the KYC, while with wallet-to-wallet the exchange is legally almost always required to do the KYC.


Thanks for your patient help! :)

Florian

On 12/5/22 00:49, Christian Grothoff wrote:
On 12/4/22 22:34, Florian Jung via Taler wrote:
Hi everyone!

I finally got my taler setup running so i can connect my android wallet to it, generate a withdrawal wire transfer subject, and use libeufin-cli to fake an incoming transaction on the exchange's bank account, so i actually can retrieve my talers in the wallet.


Now the next question is how do I give a customer some talers in exchange for real cash money. I see two options:

- The cash-desk-guy has a wallet and wallet-to-wallet-transfers the talers.

- I use the Taler Cashier app.


However, whenever I select "Send funds" in my wallet and try to send to a different wallet, i get:

"Let the payee scan this QR code to receive: 7001 (unexpected exception (message: insufficient balance)) [no QR code is displayed]"

>

What is the issue here? I definitely have enough balance in my "MANA" currency.


Enough inside your wallet (does the MANA balance show in your app?) Clearly at least the error message is bad here, but maybe something else is going on. If you put the wallet into developer mode and export the database (there is an option to do that), wallet devs (wallet@taler.net) could import the DB and try to see what's going on (assuming your exchange endpoint is reachable over the Internet).


And when trying to use the cashier app, it wants to be connected to a bank api (e.g. https://bank.demo.taler.net/demobanks). What would I specify here? Can I point this to my libeufin sandbox or the nexus somehow (which URL specifically, and what credentials do I use for login?)


You need to create another (non-exchange) bank account with credentials in the libeufin-sandbox, and then give the respective username/password to the cashier app, using "$ENDPOINT/demobanks/default" for the URL (yes, a bit awkward, on my list to get fixed). Additionally, you either need to have configured the sandbox to allow negative balances OR make a 'fake' wire transfer to that user's bank account to get money into the system to withdraw.

Last but not least, if you enable self-registration in libeufin-sandbox, you could also use the $ENDPOINT/webui/ to create accounts and initiate withdrawals.



I use the debian bullseye packages and wallet v0.9.0 (20) if that helps


That should be fine.

-Christian





reply via email to

[Prev in Thread] Current Thread [Next in Thread]