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.
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?
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.
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.
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.
TekMol|3 years ago
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.
xiphias2|3 years ago
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).
moffkalast|3 years ago
nib99|3 years ago
woodruffw|3 years ago
imtringued|3 years ago
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.
rvz|3 years ago
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.
m00dy|3 years ago
a stable coin gets its audit in US.
shp0ngle|3 years ago
They just want to speculate on it; first buy, then sell. Nobody actually pays with cryptocurrency.
edit: ahh it’s in the actual article. Never mind.
TekMol|3 years ago
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.
0x64|3 years ago
herbst|3 years ago
z9znz|3 years ago
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).
ben165|3 years ago
Two questions
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?
yunohn|3 years ago
FabHK|3 years ago
ben165|3 years ago
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.
NavinF|3 years ago
sentrms|3 years ago
ben165|3 years ago
sshine|3 years ago
Practically impossible.
TimJRobinson|3 years ago
ben165|3 years ago
71a54xd|3 years ago
zeroclip|3 years ago
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.
Grimburger|3 years ago
> Please let me know what you think of it.
Literally not a single point of contact anywhere to be found anywhere on the site. I guess you mean here instead?
Also your login error message is just a db response :)
ben165|3 years ago
I'm going to look into the error need probably to catch it.
dnpp123|3 years ago