Horizon also gives you https://admin.<domain>/horizon for some UI, it's what we're using in production.

Used on line 90.

The effect is already as desired -- we're not sending the email. We're basically just validating $wallet is something and not nothing, so as to avoid running in to error conditions later.

Yes, you could, but that's not how spammers behave.

At this stage though, we don't have any information that uniquely identifies one such message from another such message.

If a user_id-hash-updated is older than one hour, the record will not have been found by the time we need to insert the new one.

A unique constraint would prevent this from completing successfully.

Must be App\Console\Command. Tests would catch it if they were created.

The constructor can be removed.

Maybe add orderBy().

What when $whitelisteable is null? E.g. deleted domain/user.

You can do $user->wallet().

First check if $wallet is not null, then try to get the owner. I'd also check if the $owner is not empty.

What about "or are at 100% discount"? Also, you coould do the balance check earlier for better performance. If balance>0 there's no need to check for payments.

Not that big of a deal, but this is execute on deleting and on forceDeleting. It would make sense to do this once.

why wl not whitelist?

Isn't this redundant if you define a unique key below?

Then the observer should have deleted these, I don't know what the reason would be to display them here.

I don't see a function wallet().

I was contemplating doing that but since there's public 100% discount codes it wouldn't suffice to combat spammers.

Updating commentary.

The need to get to count() is because I want >= 2 payments, so just checking ->balance > 0 is not enough.

table name length limitations.

It isn't.

unique constraints' primary purpose is an upon-write restriction, incidentally using some sort of index for duplicate detection purposes, but the type of index can be very bespoke to its use-case (i.e. a list of hash('sha256, '$a.$b') would do it).

indexes primary purpose is an upon-read helper with selecting particular records, including range queries and sub-string matches (i.e. a unique constraint duplicate detection table like the one does not help looking up any records). it uses far more complicated routines that are in turn sub-optimal for unique constraints.

I guess the line reference here could be also removed.

We should add protected $keyType = 'bigint'; here.

We should add protected $keyType = 'bigint'; here.

It could be unsignedTinyInteger

It would be useful to truncate ratelimit tables here.