I have no idea what's going on in CashApp's case, but it definitely reminds me of Bottlepay's behaviour. The app used to require users to "validate the node is theirs by signing a message" when trying to withdraw to one's own node. It would let you pay invoices to services without any problem.
I don't know exactly how it worked, but an easy way to trick this system was to use a BTCPay Server linked to one's node. Bottlepay would pay the invoice without batting an eye, even if it was paying the exact same node.
Re CashApp, could it just be that liquidity is exhausted between them and you?
Interesting,...And yes the inbound capacity seems fine, especially for these small 10-50 sat payments. I can pay other wallets with cashapp, and I can pay my node with other wallets.
I was going to ask about workarounds, and sounds like BTCPay Server is a good one. I was also wondering about lightning addresses, and whether you could create arbitrarily many of them to always generate a new recipient for each invoice or something like that?
reply
I was also wondering about lightning addresses, and whether you could create arbitrarily many of them to always generate a new recipient for each invoice or something like that?
I'm considering making a service that does exactly this. You could make unlimited lightning addresses that all pointed to a single address. The invoices generated by any of the aliases, or the main address, would be identical.
Not sure if this would help in your case though, if they are blacklisting something in the invoice like your nodes public key (since you aren't using a custodial service where all the public keys are the same), it wouldn't help.
More here #223185
reply
Love this, I'm going to look into it more, and feel this is definitely needed.
reply