We often receive comments to the effect of “we want to purchase a @haveibeenpwned subscription but our company doesn’t allow us to use a credit card”. What is the financial reason behind this?
This is a very small portion compared to those that *do* pay by card, but why is this?
To add to this, having spent 14 years at Pfizer I’d see policies like this all the time. But it’s also not like there was a blanket ban: try going on a business trip and asking the person at the noodle shop you’re having lunch at to raise an invoice on 60 day terms 🤣
This also isn’t about traceability; spend the money, raise an expense claim with receipt, job done. I could understand if the answer was “because an invoice and wire transfer stops people randomly being stuff and puts procurement in control”, but they could still pay with a card.
Here's the complete kludgy mess this makes for us: as an Australian company, we can't accept wire transfers via @Stripe and the only ways to achieve this involves registering a US-entity which we *really* don't want to do. That scenario is just nuts - it shouldn't be this hard.
@stripe So, we end up referring people to resellers (and often they're required by the company anyway) which then costs them more money, more time and more mucking around on our end. The whole simple workflow of "enter card, get service" dies and becomes a complete mess.
@stripe But again, empirically we're talking a very small percentage of all purchases (definitely single-digit), whilst this creates the vast bulk of support overhead for us (definitely >80%). It's an incommensurate amount of effort for what appears to be just corporate bureaucracy.
@stripe And I wonder - of that small single-digit percentage, how many would suddenly find a way if it was the only way? Not all, but some...
Ok, I feel better now, thank you for reading 😊
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Let me add some more context to the Dymocks breach, starting with giving them a massive pat on the back for responding so quickly. It was less than 48 hours ago between me contacting someone there via LinkedIn and them having sent disclosure emails to customers. Massive kudos!
What's not as clear from the story is the extent to which the data was already circulating before I was able to get in touch with them. Multiple Telegram channels and a popular *clear web* (not dark web) forum were broadly circulating the data.
I also suspect we're about to see a repeat of the question so many people raised after Optus and Medibank: why do they still have my data? About a quarter of the rows are flagged "inactive" with dates as far back as 2005, yet still sit there with address, email, phone etc.
Had a weird thing happen with @AzureApiMgmt that caused the public @haveibeenpwned API to start getting laggy, especially around 1 week ago. It went from ~220ms response times 90 days ago to over 1 second up until yesterday. Scaled out an instance and now we're down to ~70ms.
This is despite very consistent performance of the underlying @AzureFunctions app. Something started gradually going south at the APIM level and I'm continuing to look at that with the team there.
What I'm a bit more interested in now is tackling this graph. This is "gateway errors", namely the reason APIM rejects requests. Exceeding the rate limit is number 1, but invalid subscription keys are massive too, plus there's an obvious hourly spikey pattern.
Ok folks, here’s the next edition of “Troy’s IoT Hell” 👿
Recently I had to make a call between buying the older Yale Assure locks sold locally here in Aus or the newer one only sold in the US. This was for 2 locks, one for the front door and one for the front (undercover) gate.
I went with the newer ones from the US as they were smaller, looked a lot neater, support Matter (with a coming add on module) and only took a few days for shipping. They look *great*!
However… I knew I wouldn’t be able to pair them with the Yale app in the Aussie App Store. I’m going to come back to this issue later in the thread, for now it was an easy fix with a spare iPhone and US Apple account reddit.com/r/homeautomati…
Got an unexplainable Azure Function problem which I suspect will have an obvious answer once I start explaining it to other people, so here goes:
I have a function with a queue trigger that makes an outbound HTTP call after the queue item is picked up. I can place messages in the queue and see them disappearing moments later, but the outbound call never gets sent.
Maybe something else is picking message up from the queue? Ok, so stop the function in the Azure dashboard and now the messages just sit there. 10 mins later, start the function and the messages disappear. So that rules out another process.
So @Charlotte_Hunt_ is selling a fridge on Gumtree and immediately starts getting messages like this. The first one gets a bit of “no, we can discuss here” and they disappear. This one… gets a burner address to see how weird shit gets. What’s the angle? There’s always an angle…