Sending refunds by hand from the wallet is getting stupid — what handles it

Situation is this. I sell software licence, price between 40 and 200 dollar. Customer pay crypto, all good. Then customer want money back.

Right now i do it by hand. Open the invoice, find what he send, open wallet, send back minus network fee, then argue with him because network fee is not his problem apparently. Anyway is maybe six or seven of these a month and each one take me twenty minutes and one email fight.

What i need is gateway where refund is a button on the invoice. Customer address is already there, amount is already there, i press it and is done. No bank anywhere, i do not have merchant account and i do not want one.

Which one actually has this working. Not on the feature page, working.

seven a month out of how many sales. that number decides whether you need a feature or a policy

Around 300 sale a month. So is two percent, not disaster. Is the twenty minutes that kill me not the money.

Plisio has a refund action on the invoice and it does work — it pays back to the address the payment came from, and you choose whether the network fee comes off the refund or off your balance. That second toggle is the bit that ends your email argument, because you can just eat it and stop discussing it.

NowPayments has something similar but it is a payout, not a refund, in the sense that it is a fresh outbound transaction that doesn't link back to the original invoice in the reporting. Functionally identical for the customer, more annoying for you at the end of the month when you're reconciling.

Both need a balance sitting there to refund from, which is the part people forget when they've set everything to auto-forward.

that last line is the whole thread. you cannot auto-forward everything and also refund on demand. pick one or keep a float.

If you're already sending them by hand you're most of the way to BTCPayServer, which has the best refund handling of anything in the category — you issue a refund and it generates a claim link the customer redeems to an address of their choosing, so you are not guessing which of his three wallets he wants it in.

That also solves the case you didn't mention: the customer who paid from an exchange withdrawal address and cannot receive at it. On a hand-sent refund that becomes a support ticket. On a claim link it becomes his problem.

Cost of that is you're running a node. Seven refunds a month against a node you have to keep alive is not obviously the right trade at 300 sales.

Or sell something people don't want refunded. Radical.

Ok i test Plisio on maybe fifteen invoice this week. Refund button is there and it work, fee toggle also work.

One thing nobody say: refund only available for 30 day after invoice. After that button is grey. My licence is annual so people ask at month four sometimes. Anyway is still better than before.

The thirty day window is not an arbitrary product decision; it is roughly how long the operator is willing to treat the original inbound as reversible against your balance rather than as a fresh disbursement. Past that you are making a payment, and a payment has a different character in every framework I have ever worked in.

Practically: put the window in your own terms at twenty-eight days and the mismatch disappears.