AMA — six years running payments for offers nobody else will touch. Ask.

This is the clearest statement of it I have read on this board, and I have tried to make the same point twice and been ignored both times.

My friend, do you have experience with LATAM? Everything here is EU and US and for us the problem is different, the customer don't have card sometimes.

Not really, no. I've had two Brazilian merchants pass through and both times I was learning from them rather than the other way round. Better asked to someone who actually operates there.

whats the fastest an account has died on you

Nine minutes. Signed up, integrated the test key, ran one 1 dollar transaction, account suspended before I'd finished the second. Never got an explanation. I assume the IP or the domain was already on something.

Six years of this and the answer at the end is still "run your own node and sweep". Does it ever bother you that the entire industry you've described is a workaround for a problem that self-custody solved before you started?

It bothers me less than it used to, and the reason is conversion.

You are correct that BTCPayServer solves the merchant's problem completely. It does not solve the customer's problem at all, and the customer is the one with the money. Every time I've measured it, moving a mainstream audience to a self-hosted crypto checkout costs somewhere between half and three quarters of the completions. That's not a rounding error you can absorb on principle.

So the honest framing isn't "workaround for a solved problem". It's that self-custody solved the half of the problem that faces the operator, and the other half is a distribution problem that no amount of protocol design touches. I run both. The self-hosted rail is the one I trust and the hosted rail is the one that pays for it.

If your buyers already hold crypto, ignore everything I've said in this thread and go self-hosted today. Genuinely. Most people's buyers don't.

What does your monitoring look like? Specifically: how do you find out an account is in trouble before the email arrives?

Three signals, in order of how much warning they give.

Settlement time drift. Log the delta between invoice-confirmed and funds-arrived for every single payout, and alert on the rolling median moving, not on any individual one. When an account is being looked at, settlements get slower for a week or two before anything is said. This has given me four to ten days of notice on maybe half the accounts I've lost.

Support latency. Send a trivial question once a fortnight from a normal-looking address and record the reply time. When it goes from six hours to three days, something is going on internally, and it may not be about you — but it's about their capacity to deal with you when it is.

Dashboard field changes. Screenshot the withdrawal page monthly. New verification steps appear silently and the first person to notice is usually someone who needed money that day.

# the only one of these that's automatable cheaply
# emit on every payout, alert on 7d median vs 28d median
payout_settle_seconds{gateway="x"} 

None of these are reliable. All three together have bought me time more often than not, and time is the whole game — an account you know is dying is a migration, an account that dies is an outage.

If a client needed to move a certain monthly volume from one rail to another without a gap in acceptance, how long would you tell them it takes?

Six weeks if nothing goes wrong, and something goes wrong.

The integration is a week. The rest is the part people don't budget: opening the new relationship and letting it age, running maybe 5% of volume through it for a fortnight so it has a history before it has a spike, and only then moving the bulk. A brand new account that receives your full volume on day one looks exactly like the thing every fraud system is built to catch.

If you don't have six weeks you don't have a migration, you have a scramble, and the scramble is where people leave a balance behind.

Six weeks feels like forever but that "let it age" bit makes total sense

You said forty relationships and two acquirers you won't name. How many of the forty were the same operator under a different brand, and did you know at the time?

Question if you're still answering: what would you do differently if you were starting today rather than in 2020?

Been away, catching up on the last few.

Three things, and only one of them is about payments.

One: I'd build the self-hosted rail first, not last. I treated it as a fallback for years and it should have been the foundation with the hosted rails bolted on for reach. The reason is not ideological, it's that building it first forces your product to work without a middleman, and everything after that is upside. Building it last means retrofitting a checkout that assumes someone else holds the money.

Two: I'd pick on exit terms, not entry friction. In 2020 I optimised entirely for how little a provider asked me. Every single one of the relationships that cost me money was one I chose because signup was easy. The question I ask now is "what happens on the day you close me" and the answer is on page four of the terms, and most operators in this space have never read page four of anything.

Three, and this is the one that isn't about payments: I'd have kept better records from day one. Not for tax, though quietaccountant is right about that too and gets ignored every time. For the freeze. Every time an account has been held, the thing that got it released was being able to produce an invoice trail within an hour of being asked. The people who lose the money are almost never the people who did something wrong — they're the people who couldn't demonstrate quickly that they hadn't.

Short version: build the rail nobody can close, choose the others on how they end, and keep the paperwork you think you'll never need.