Since it was announced, I have been wondering how tip protection work behind the scenes. The official post, doesn't mention it: https://together.bunq.com/d/57145-what-is-tip-protection
How does bunq know, how much the original price of a restaurant visit was and what part of a transaction is the fee?

Thank you, @thijsoost, for the reply. I'll keep that in mind and will use the support more for bug reports. In my experience, when I notified them of bugs, they didn't really get resolved, and I was asked to post on here.
As it's not possible to have multiple open support ticket, maybe this makes it a bit easier to structure them.

@Jakob-Y#271564 thank you for the answer.
I agree, users set the source sub-account for a transfer themselves. But it would also be nice to just set the type of transfer and later select and change the account from which these kinds of payment types should be paid.
As of right now, it is not possible to change the source sub-account of a scheduled payment at all. It would be nice to get access to this to a feature like this: https://together.bunq.com/d/58746-change-schedule-payment-source-account

bunq being a bank driven by technological advancements to improve the user & banking experience, I was interested if there has been some research into adopting an integration with https://interledger.org/
It defines an internet standard for exchanging money, very similarly to what TCP does for exchanging information, and thus has been supported by Mozilla with a grant for the web.

As an interoperable standard, it doesn't care about the currency exchanged, and can be adopted by any party or payment solution.
As of now, I only know of projects using crypto in the background that are actively using it. In my opinion, this has been due to the fact, that the adoption of new technologies is much faster in the crypto space and smaller projects.
I was hoping bunq might be the exception to the rule, that banks take forever to even consider such a step.

Oh, actually, since the last update that issue is resolved.

Currently, if you add a balance widget to the home of your app (https://together.bunq.com/d/53932-widgets/), the vertical scale is based on the sum of the balance of all accounts to show the graph.
As these widgets can be configured to plot the graph based on a selected group of subaccounts, the graph scale should only be based on the sum of the balance of those subaccounts.

Unfortunately, this isn't the case yet. So the graphs for a small amount of subaccounts, with a low balance, are very difficult to read.
For example, if the sum of the balance of all subaccounts is 50k and the selected subaccounts for the balance widget is only accumulate 1k, changes in balance are hardly noticeable, as the scale stays at 50k.

As the feature appears to be only adjustable in cards, I suspect it only works with card payments.
It would be interesting to know if there are plans to support it with direct debit as well as singular & planned outgoing credit transfers.

That way you could schedule payments like rent, which is to be taken from the right accounts.
A lot of my subscriptions (& insurance) are paid via credit transfer. The default for Germany, and it makes switching bank accounts easier instead of always adjusting direct debit settings, which typically involves talking to some kind of support on the receiver's side and delays.

https://together.bunq.com/d/53929-easy-budgeting/2

@thijsoost#257636 hey Thijs, thanks for your reply.
Generally, I understand what you mean. But why is there a bug section, that the users can post to, if it is not being used and read by the developers.
Like you said, I would like to improve things and had a lot of issues to share today. If I would do that through the support, it would take a long time, since I cannot create multiple support conversation, they get closed very fast, and I never receive any update on them when they are closed. That's why I decided to use the community, so more people know about them and they can get some traction. It's also great, so bugs don't get reported multiple times :)

I work in the tech space as a very technical project manager and are writing a lot of bug reports internally, processing them from clients as well as providing a lot of them to software we are using in our business. A good flow for that is important. With bunq, it has always been a hassle to do it properly, in the right place and understandable by other people and further along the line.
I even considered applying for a position at bunq, to change that and improve the process :)

Just a little write-up to let you know where I am coming from.
If you show me a better way, I will adhere to it.

@dosz-Grey-Goat why did you remove the "Bug reported" label? Isn't this discussion, a bug being reported?
And if I should not apply that label, why do I have permission to do so? ;)

Correction: This seems to only be an issue, when the issue is first reported. Later, when a support staff member wrote something and you responded, the preview seems to update as expected.

Trying to get a refund on an unknown card transaction, the wizard always lead me to a screen with only one option: To block the card entirely and irreversibly.
That is not what I wanted. Yes, I was considering that option, but first and foremost I wanted to initiate the refund.
Currently, it is enough to change the CVC and I wanted to have control over which actions I take.

Luckily, I found a workaround. If I freeze the card and initiate the refund then, it doesn't ask me to block the card and lets me proceed with the refund request.

Even though I get a strong suggestion to block the card, it should not be the only option, especially if the refund request hasn't even been created yet. And other options like temporarily freezing the card, changing the CVC, etc. should be made available.
Blocking the refund request entirely, until you block the card first, is really annoying and hinders the process. It can even be confusing.

@thijsoost#257595 exactly. Especially, if I still need support on that open issue.
And I cannot see the current state of availability of the sos support. I might not exactly remember, when I last used it and when it will be available again. So I might do close the open issue for no benefit at all.