The Geldmaat website states that debit cards need to be Maestro or Mastercard and that credit cards can be Mastercard and Visa. I’m surprised the Visa debit card worked at all in a Geldmaat, because as far as I can tell it shouldn’t.

One of the (otherwise helpless) bankers I spoke to said Visa is probably not accepted by Geldmaat. I thought the banker had to be wrong but maybe they meant to say visa debit does not work. Yet I have a receipt from a functional Geldmaat machine which says “visa debit” in a field named “app. label”. Then at the bottom of the receipt it (incorrectly) says “credit card account … credit limit …” which actually reflects the card balance.

Some point of sale terminals are said to only work with visa credit or visa debit, but then I’ve had banks tell me their cards act like what the machine wants it to be. I’m fuzzy on the details. There are situations where you have to choose “credit” or “debit” on the terminal, and the bank says I can choose credit even if it’s debit, and vice versa. So it’s hard to pin down what’s going on. I don’t even get why the distinction between the two exists at the network API level. It’s not the business of the merchant or the ATM to know those details.

I can only imagine that perhaps it’s there for casino situations. A credit card holder once went to LasVegas with a credit card from a region where gambling is illegal. One of the laws was that it’s illegal to collect on a gambling debt. So he took a cash advance on his credit card inside a casino, lost it all, then returned home and told the bank it’s a gambling debt, get lost. My understanding of the story is that he got off the hook for the debt on that basis. But I wonder if that’s why this distinction exists on the card networks.

Another theory is that credit cards have more buyer’s protections and higher fees to the merchant and so some merchants don’t like that and want to insist on debit cards. But the ATM seems like the reverse of that.

Anyway, maybe not all Geldmaat machines are the same.

I appreciate your insight. Perhaps some of the refusals is related to visa debit incompatibility.

Withdrawing money from Dutch banks is effectively free (that’s what the banks charge you for) so a commercial party putting down ATMs in public can’t make money from the vast majority of potential customers.

Well free to the customer but the ATM likely still profits. My bank eats the atm fee but they have no deal to hide the fee from the customer. So I agree to the fee, see the fee on the receipt, and the fee appears on the bank statement followed by a credit back in the amount of the fee. EU accounts probably just hide the fee from the customer otherwise ATMs would not be sustainable.

Your comment is mostly sensible and I appreciate your insight on the obligation to post cashless signage, but this seems a bit off:

What about the case where someone enters with bank card(s) that are in a broken state, unknown to the card holder?

What if someone enters a place that takes cash, thinking they can pay with dollars (which happens at a non-zero rate in Amsterdam), or rubies and gold? The answer is the same in both cases: that’s the customers problem.

EU law has established the definition of legal tender in the eurozone to include euro banknotes and coins. Each eurozone member state keeps its own laws as far as defining the role and purpose of legal tender (and that creates a bit of a mess, but it is what it is). I think a member state can include more forms of money as legal tender, but euro banknotes and coins are mandated by the commission to be part of the legal tender definition. So there can be little confusion about other currencies having legal tender status. There is also an EU Recommendation that legal tender be accepted on payment toward debts, and I believe running a tab and paying later must be a debt (as opposed to a point of sale). In any case, gold and rubies would not have equal standing to euro banknotes in Amsterdam.

I cannot say I put much stock into any guesswork that a broken card would be treated as if the customer brought nothing to pay with. Banks can (and often do) spontaneously disable cards at any moment without communicating to the card holder. The card may even be functional while you eat, and the bank could disable it 5 seconds before you tap the payment terminal. It could be entirely outside the card holder’s control – by an shitty anti-fraud AI mechanism (which I have been at the receiving end of lately). It would be absurdly and embarrassingly harsh for a society to treat a victim of AI like a deadbeat freeloading non-payer. I can’t say you’re wrong because I don’t know Dutch law and procedure, but it sounds like conjecture.

Sometimes the card and card holder’s bank is not even at issue. Some machines rejected my perfectly valid card in Netherlands. The logo for the payment network matched and my account was funded. Machine rejected it saying “contact your bank”. The bank said there’s nothing wrong with the account… no blocks… card should work. The bank did a deeper check and said the transaction attempts were never even transmitted to the bank – that the card processor itself decided to reject the card. So the machine that rejected my card lied, and erroneously implied the problem was on my side.

So when a card fails to pay out, that failure can potentially be entirely on the merchant side of the transaction. E.g. some merchants refuse foreign cards, which violates the terms of the Visa merchant agreement but it’s not enforced so merchants are happy to break it. And the messaging cannot be trusted. So surely as someone is in a bar or restaurant with a failing payment, there is no way to know with certainty on the spot where the fault is, amid false error messages. It requires investigation which may take some time. On top of that, some banks charge high hourly fees for investigations. This is why I’m interested in what Dutch law and procedure is in this situation.

Theoretically that’s true but I’ve already seen it fail. Using a non-EU card to buy airfare from an EU airline website still results in all flight details (flight number, time, origin, destination, name of traveler) being needlessly¹ shared with the credit card network and with the bank. So non-EU people can only fantasize about getting GDPR protections on EU transactions.

And now that I’m thinking about this, the GDPR protection is limited. That is, the bank must know that a bar is on one side of the transaction (legal basis would be a “contract” if not “legitimate interest”). The GDPR limits the bank from sharing that info and also limits the bank from using it internally for purposes unrelated to the performance of the contract (e.g. the bank cannot send you beer ads as a result).

So consider the non-EU customer angle. The non-EU bank would also know that a cardholder spent X amount in bar Y. Do you believe that non-EU bank would recognize that bar Y is in Europe and thus not sell that info to data miners for whatever the data is worth? If yes, what would the enforcement recourse be? Could the non-EU person report their non-EU bank to a data protection authority under Art.77 in the member state where the bar was located? I’m a bit fuzzy on this cross-border aspect of the GDPR. IIRC there are DPAs in some non-EU countries that the EU considers acceptable (which ironically includes the US), but I’m quite skeptical of their powers or willingness to use their power to handle an Art.77 complaint. I suppose there must be some mechanism in place but I’d be quite far from trusting it.

¹ Sharing airfare data happens because some credit cards include travel insurance and the bank needs those details to trigger the insurance coverage. But not all cards have that insurance yet it seems the sharing is automatic regardless.

(They might also know it by its Dutch acronym, AVG.)

Good point. It was an English conversation but indeed I should have said AVG. In any case, you just lowered my degree of surprise that they didn’t know the GDPR.

The UK is this way on debts, where you consume a product or service before payment? Do you know the answer to any of my series of questions w.r.t the UK because that would be interesting as well.

Not Dutch, but next time you go to a new place, check reviews or information regarding if they accept cash.

That’s exactly what I’m doing here. This is the purpose of this thread. That was not my first visit to Netherlands and it won’t be my last.

If this situation was different and you were adamant about paying in cash, you could argue that you don’t have enough money in your debit, but did have enough in cash. They might pity you, but you are still attempting to pay your debt, and if they don’t take it, you can argue that they refused the payment.

My questions are not really of the “how do I weasel out of this” variety. I can hack my way out of lots of situations. But those hacks are best constructed with an understanding the law and the how the system works, which is what I hope to gain. It would be nice to know if Dutch shops have a transparency obligation to post signage conveying their cash hostility. The suggestion is a reasonable hack for finding one’s self broad-sided by this situation. Tough I imagine they would want proof: “show us your card does not work”. In which case I should ideally carry a card that I know is broken. But the best planning ahead is to train myself on avoiding such businesses to begin with.

Enshitification warning: #Arstechnica manages to push bandwidth-wasting autoplay video in a way that bypasses Firefox’s setting to disable autoplay.

One other Lemmy instance is on 0.19.4, and that also has the same problem:

Ungoogled Chromium: the create post form erases the fields after tabbing out of them. Tor Browser (firefox based): no issues with the create post form.

Now slrpnk is on 0.19.5, along with two other Lemmy nodes I tested this on. The create post form is working in this version with Ungoogled Chromium.

timeline selector broken

There is another problem that was introduced with version 0.19.4 and still persists in 0.19.5: There are four possible timeline views: subscribed, local, all, moderator view. That selector is broken in Ungoogled Chromium 112 but not in Firefox-based browsers. In UC, I click “moderator view” and the button highlights as I click it, the page refreshes, but the selector does not stick. It is trapped in the “local” view and only shows the local timeline.

This problem is replicated in other 0.19.4 and 0.19.5 instances.

update

Actually there is still a problem with 0.19.4 w.r.t. post creation. And this affects Firefox too: if I use the cross-post feature to copy the post elsewhere, the form is populated just fine but then I have to search for the target community at the bottom of the form. As soon as I select the target community, the whole rest of the form clears. I have not yet tested this specific scenario in 0.19.5.

I recently read a complaint about the opposite. Someone deleted their Proton account and their handle was made available 1 year later. They were rightfully angry because the next user would potentially start receiving mail from things like the original user’s bank. The new user could perform password resets on accounts where the original user had not yet changed the email address on file.

I started with the “Browser Default” theme.

Which browser did you try to replicate it in?

i just switched to hanubeki cold. Same problem.

Also another problem I forgot to mention: the main timeline is trapped on the local view. When I click on all, subscribed, or moderator view, there is no effect. The button highlights in parallel to the local button, but does not stick. It just refreshes the local timeline.

not sure what you mean by “doesn’t prevent using the function entirely.” Do you mean the function is available for those who install another browser? My current theory is that the create post function is 100% broken for Ungoogled Chromium users, but probably operational for people running 3rd party clients or Firefox. Considering Ungoogled Chromium is based on the single most popular browser (Chromium), vanilla Chromium users are probably also impacted, which seems serious.

The form should probably display a loud warning about this. Someone might opt to write the body of their post as a very first step, before the title. They could put a substantial effort into writing a long text and then see it all vanish the instant they click the title field. Nothing is worse than seeing one’s work thrown away like that.

I would roll back to the previous version if there is no fix for this.

(edit) Are there any stats kept on user agent strings? It might give a clue on the number of users affected.

For the past few days, the “create post” form is usually broken. After entering a title I hit tab to the next field and the title is instantly erased upon shifting the focus to another field. The form is unfillable.

I was able to post once after this behavior started for no apparent reason. No idea how to reproduce that.

It’s worth noting that submitting comments in existing posts is not a problem.

Browser: Ungoogled Chromium 112

(edit) after more thought, I think that one time I was able to post was probably done using Tor Browser, not UC.