Let me know if I am wrong about using crypto for payments:
My understanding is that a big, maybe the biggest, obstacle is taxes.
In countries like the USA and Germany, the way I understand tax law is: When you buy something with crypto, that counts as a sale of an asset. So you have to document what the fair value of the coffee you bought is at that point in time, subtract what you paid for the crypto you used and then pay taxes on the difference.
This makes it more or less impossible to use crypto for payments, right? Every coffee you buy would have to be documented and evaluated and be part of your tax declaration.
What you write is a very important part of the equotion. Another part is that implementing improvements to open source payment systems is not as organized as in a top-down company with a great visionary enterpreneur.
Blockchains are not practical for payments because they payments are not instantly finalized, so they can't be used for synchronous payments, which makes integrating them to a web site super hard.
It seems that the best solution for instant final debit payments is to have a network of payment channels (lightning network inside Bitcoin, but Ethereum has some similar projects as well).
Most of the talent is creating new cryptocurrencies/tokens which doesn't really help payments. The remaining talent working on payments is not that big (just a bunch of people really) split to 4 different implementations (in the lightning network case, but Ethereum's implementations also have competing projects) that are compatible but still take a lot of work just to rewrite the same thing in 4 languages.
Some of the improvements for scaling lightning network are clear, some are under research (I'm working on implementing min cost flow optimizer into one of the implementations to be able to send large payments on the lightning network, which is not possible right now, but I had to choose an implementation to work on first, as working on 4 implementations is too much).
>Right now nobody is really interested in using Crypto for payment. I like to find real use cases and looking forward to buy real stuff with it, but most people just hodl, especially when markets are down.
I saw Solana and thought, okay so it is possible to build a scalable cryptocurrency, but then again, the culture of speculation and excessive amounts of volatility make cryptocurrency useless for payments.
The only promising cryptocurrency I have seen so far is the non pegged stablecoin RAI which is basically trying to emulate central banks via a smart contract that uses control theory to adjust a redemption rate which is effectively an interest rate that changes the unit of account rather than the quantity of money.
Anyway, what this means is that cryptocurrency currency is still trapped in its degenerate gambling culture and we are at least a decade away from seeing real innovation in the cryptocurrency space beyond the usual tulip mania.
> I saw Solana and thought, okay so it is possible to build a scalable cryptocurrency, but then again, the culture of speculation and excessive amounts of volatility make cryptocurrency useless for payments.
Solana, Stellar and Algorand makes it usable and possible for scalable crypto payments with USDC. I just tried it, swapped it and it works well.
Every time I type my credit card number into some web form I think "Damn, I hope the number will not end up in some shady hands causing me trouble".
I had my credit card disabled once because someone started using it to buy stuff with it around the world. What a freaking hassle. Telephone calls, letters, several days without a CC, had to change the number everywhere .. annoying.
Paying a lightning invoice does not bear such risks.
You know that lots of card providers can generate virtual cards for free on demand these days right? Another set of details that works the same as your original card but can be used for, say, just one site and cancelled at any time if it gets misused.
If that's your only gripe than that's probably the easier way than switching to an entirely separate financial system.
It is not realistic to generate a virtual card for each purchase. It creates a documentation headache as well, such as handling returns and payment proofs.
I expect credit cards to become more like private keys in time, managed by the company, and transactions will have unique tokens so that your real number is never passed to the vendor. Blockchain like ideas will be implemented in "TradFi" without the overhead of blockchain.
You do not need to have your card "stolen" to get into this trouble. I did not get my card stolen. You hand out the data that can cause you trouble every time you pay something. That is not the case with crypto.
what kind of misleading analogy is this? you're not sharing your private key (if you have half a brain cell anyway) when paying with crypto so why even bring this up?
Porn: I'm not up to speed on the cryptocurrency use in porn. Shouldn't this run into consumer protection issues? That is: while it and debit cards don't guarantee as simple a chargeback as a credit card, there are still laws here.
So let's say pornhub takes bitcoin (can't check, as I'm in a public place). It still needs a refunds and frauds department for those payments, no?
And pornhub does take credit cards. Yes, the fees are higher. But largely because the chargebacks are more common (spouse finds out, buyer feigns ignorance).
Smm = Social media marketing, buying likes and that stuff. It's a huge market actually. Porn sites also heavily set on crypto to pay their creators, paying out is even more an issue than charging in such markets.
I don't understand where the issue with refunding crypto should be. It's also way cheaper than what stripe, PayPal or co charges if users issue refunds. Personally I only save money by using crypto, I save thousands of dollars in transaction and chargeback fees every year. For me as merchants it's a non brainer.
I also use crypto as a customer but I usually trust these companies before I send money. The swiss Amazon is accepting crypto for example, as customer I trust them and all customer protections laws apply as well.
The real difficulties in providing crypto payment options is that users are generally not educated enough to use it properly.
I built Bitcoin and Stellar payment systems for a client. In both cases, I generated an address for each customer and associated that address with the customer ID. By not reusing addresses, I never had the problem of not knowing who had paid and who had not. You cannot trust most people to provide a memo correctly.
Of course, I generated a QR code for each payment request, so mobile users had no trouble. However, desktop users had to copy paste, and some people have trouble with even basic computer tasks...
The biggest challenge was having people under-pay. Depending on the wallet a person used, the wallet might show them a fiat currency amount instead of a crypto amount. If I said to pay 100 XLM, they might put that into their wallet and see an incorrect (or inaccurate) conversion and adjust the number down (or up, but that rarely happened).
I gave a locked in quote price when the order was placed, and I would let that price stay fixed until the order was paid. That was better than updating the to-pay amount after the order was placed, since the user might have been busy going off to buy or transfer the exact amount. We noted that if the conversion rate fluctuated greatly, the user could simply cancel the order and re-place it to get the current rate.
Another problem was that people would pay directly from an exchange "wallet", and the exchange might take a fee out for the transfer. So that 100 we requested might arrive as 90. I did allow up to 3% under-pay, but in cases where the difference was greater I had to leave the order open as partially paid (and request the buyer pay the missing difference). Then we found that if that difference was small, some people couldn't transfer that small amount from their exchanges (there were often minimum transfer limits).
Then on the company side, we've got crypto that we had to decide whether to sit on or convert to fiat. Obviously if the crypto market is on a bull run, it's beneficial to keep the money in crypto. But it's really a gamble (obviously a losing gamble in the last 10 months). So normally we would convert the crypto back to fiat every couple of days.
The technical aspects of all this were not really difficult, and it was nice being in charge of refund decisions (unlike when taking credit cards or paypal where a bad actor can cause immediate and long term problems for the merchant).
1) Bitcoin needs time to transfer. How did you approve the transaction? Instantly in hoping it will go through or had the costumer to wait?
2) The problem with new Stellar addresses is, that they need to be "funded". Your sending wallet has to recognize if this address is empty to run the right function (it's not a normal transaction). Most of the wallets can't do that. They wouldn't be able to transfer any funds. Have you had problems with that?
1 - I ran a bitcoin node, and I had a script which would poll the node every few seconds to get the status of the addresses which I knew had open orders. Any that had received a payment would get marked accordingly so I could show on the order status page. But I didn't mark the order as paid until there were 2 confs.
2 - I pre-funded each Stellar address before providing it to the buyer. Periodically later if orders never got completed I would sweep the old addresses. But it wasn't much as Stellar was only about $0.2 USD at the time.
Regarding this, to clear up a common misconception, regular debit/checking takes at least one day to clear (US ACH), usually 2-3 business days, while Bitcoin transactions are validated within 1-2 hours, regardless of standard regional business hours.
Maybe I misunderstand the author’s goal, but using the “random number” from the payment amount and regularly checking wallet balance, just seem incredibly rudimentary compared to an actual payments system…
Yes. And using a "unique" number between 0 and 99 gives you an indication of how many transactions this system is designed to support. (Not many, it seems to me.)
The random number is just a temporarily solution. The ideal one would be to use the memo field with an unique random string which contains all kind of characters. With this option you would have infinite payments.
The number solution can be improved if you search in the database for "free" numbers. I set the maximum payment time to 12 minutes. In this case, you can offer 100 payments per 12 minutes. I should update the article with this information.
Yeah normally you’d create a new address to receive payments from each user. Addresses are essentially free so this is how everyone else figures out which user deposited money into their cryptocurrency wallet.
I did this in my first project. As I said, UTXO blockchains are intended to work like that. But with every address you create your daemon has to look for changes there. Your wallet file can grow like crazy if you don't built some spam protection in your system.
For blockchains with the balance model you actually use only one address. There are solutions for Stellar to provide an unique address but this is not implemented yet.
The memo tag/field is the way to go. But as I said, it isn't widely implemented.
Ehh how does Coinbase deal with this? They gave me a unique deposit address for Etherium which is account based (not UTXO) and IIRC they’ve never asked me to fill out a memo field for any currency.
If you do use the memo field, how do you deal with user error when they copy-paste the wrong number? Banks have humans guessing and correcting wire transfer instructions. Both you and the user will burn a transaction fee each way if you automatically refund unknown transactions.
It’s been a long time since I’ve messed with wallet APIs, but I’m pretty sure you’re using the wrong API. There should be some way to consume a stream of (row_id, transaction) tuples. That way you’re never polling every address. Instead you deal with relevant events that affect any of your addresses as they happen (which is not very often. A whole blockchain might do 15 transactions/second and you see ~0% of that)
It depends on the exchange provider. I use Kraken and they provide an unique address for every costumer. But I read some Exchanges require the memo field especially for Stellar addresses.
If you use a memo field and there is an error the order won't be found in the system. In this case, you can write a script which sends the funds back to the address - fees. In this case you don't lose money and you don't need humans to interact. A more difficult problem would be if sb. sends a wrong amount. Then you have to interact with the costumer.
Yes, you're right. Polling is bad but the easiest solution. The best one would be to listen to incoming transactions and take action if a new one comes in. I'm going to use this solution if I continue the project.
As I understood it you have an initial address when you create a wallet for example on a Litecoin core node.
All addresses you create after this initial address are deterministic depending on their position. It's like you add just a number to the first address. But they are all unique otherwise sb. would see these addresses belong to one wallet.
And because they are unique your daemon has to watch or compare incoming transactions with every address you created to monitor payments. I might be wrong, but otherwise how does it work?
> But with every address you create your daemon has to look for changes there.
On a Mimblewimble blockchain both sender and receiver need to sign for a transaction. So you could interact with the payer to construct a transaction which you as receiver sign last and then you can publish it yourself.
That also seems like an inefficient way to handle transactions. This is honestly surprisingly, I always assumed crypto had better payment solutions! After all, that’s what they all proclaim to be - not speculative gambling or scamming.
Ehh I guess you could ask users what addresses they are sending from or use the memo/credit-to field in the transaction as the article mentioned. The latter is how bank wire transfers work, but it’s inefficient for humans so nobody does that.
I’m not sure what you think is inefficient about spending microseconds generating a public/private key pair. This is done once per user. You then verify signatures to “accept” payments.
> memo/credit-to field in the transaction as the article mentioned.
I assume there should be an API to prefill this, making it easier for humans. Could literally just be the unique order ID or a hash thereof.
> I guess you could ask users what addresses they are sending
Why would you need to ask? Isn’t there a captive payment portal API, like with popular wallets eg Metamask?
> I’m not sure what you think is inefficient about spending microseconds generating a public/private key pair.
The problem is not in generation. Firstly, it pollutes the blockchain with single use addresses, though I guess maybe people don’t care. But AFAIK, the website would need to pay fees on a per-wallet-transaction basis when cashing out right? Payments need to pay fees anyway, but cashing out from a single wallet would be cheaper than this mess.
probably? Normally you’d just say “send $5 to xyz” and the user copy-pastes the number and address to their wallet. It’s like sending a wire transfer.
> Firstly, it pollutes the blockchain with single use addresses
UTXO blockchains like Bitcoin were designed with the assumption that each address will only be used for 1 transaction for privacy reasons. There are no per-address fees to cash out. The fees sorta scale with how many UTXOs (incoming transactions) you’re combining to form an outgoing transaction.
As a crypto enthusiast I looked into what it would take to accept ADA payments on my membership site without relying on a payment provider. I was surprised by the quality of the documentation and realized it was quite feasible to implement. I decided against it as the sentiment around crypto (even a proof of stake chain like Cardano) would probably have a negative net result on customer acquisition and retention. It would have been a fun endeavour with a potential poor outcome.
The best "comparison" I can make is this:
- I buy random shit online every now and then, also from Amazon. That one souvenir I got for me and a friend was about 40 dollars worth, and I paid with crypto that time.
- I buy steam games maybe one every 3 months? So buying that one game with crypto is a small percentage, yes, but also probably the next game I'll get will also be with crypto payment, so it will increase the percentage slowly?
- For the service, I have paid maybe 15 dollars for similar services in my life. That one that accepts crypto is also the best one I have found yet, and to that I have paid about 80 dollars so far. So for that, the percentage is up there, and I'll continue paying them that way!
There was a HN post a year or so ago from a guy running an e-commerce site who said they get orders of magnitude more requests for paying in cryptocurrency than they actually got as sales with it.
His experience was that basically nobody who asks for it are asking because they are potential customers, but because more sites showing the bitcoin logo means their Bitcoin portfolio goes up because people start believing it's real.
Asking for cryptocurrency options is basically market manipulation, not an actual request.
Yes. I am proud to be one of the few that have used crypto to buy something "regular". To use that thing in the way it is promised to be, and not as gambling or scams. So yes, I'm proud to have done that.
That’s what everyone was doing in the early days. Hell, I paid a small fortune for a pizza in 2012. It still would never cross my mind to be proud to use any form of payment that’s just preposterous.
So Stripe is harming their reputation for offering crypto payment services? Same with Moneygram? I don't think so.
They waited long enough for regulatory clarity on crypto (and still are waiting for other rules to go through) and they have already deployed their offerings today.
So there is no 'big problem' and those companies are choosing the cryptocurrencies that will survive regulations.
If I was building a crypto payment system now I'd go with metamask / wallet connect. These work with all EVM compatible chains and most people want to pay with USD stablecoins than with a cryptocurrencies anyway.
This would be a web3 solution. Most of the people are far away of using a wallet extension. I looked into it, the programming is much more challenging.
In my experience, NowPayments.io is at least a year ahead of everyone in the space of crypto payments integrations. They've effectively cloned stripe products to accept crypto and their support is also top tier.
This is a weird and brittle way to support crypto payments.
What should instead be done is:
1. Accept stablecoin tokens like USDC. People do not want to buy a pizza and one year later be told they could have bought a house with that same set of tokens.
2. Use smart contracts, cryptographic proofs and digital signature algorithms instead of trying to match up balances and spends in the ledger.
Example: Merchant has a product on their site with ID 1234. User purchases it for 5 USDC.
If this has infinite stock, like a Bandcamp MP3, VPN subscription, production-on-demand, the user can bypass the paywall and request access to the product by writing a signed message with their wallet proving their purchase.
If this has finite stock like a vintage clothing item or unique artwork, a smart contract can tally stock of ID 1234: decrement its quantity on each successful purchase, and increment the user’s balance of that item. Proof of payment is the same: user can just sign a message at any point proving they own X amount of the product.
Imprint wasn't a html link when I accessed the site, it was actually just a confusing bit of text down the bottom of the page. I did click through to index previously.
My understanding is that a big, maybe the biggest, obstacle is taxes.
In countries like the USA and Germany, the way I understand tax law is: When you buy something with crypto, that counts as a sale of an asset. So you have to document what the fair value of the coffee you bought is at that point in time, subtract what you paid for the crypto you used and then pay taxes on the difference.
This makes it more or less impossible to use crypto for payments, right? Every coffee you buy would have to be documented and evaluated and be part of your tax declaration.