Difficulties of providing a crypto payment system on your website
cryptogif.info
cryptogif.info
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.
Ethereum and it’s many stablecoin tokens, Solana, Polkadot, Tezos, all do not have fixed supply and may be inflationary at times.
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).
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.
a stable coin gets its audit in US.
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.
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.
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).
What's SSM in this context?
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.
Honest question: Have you run that past a lawyer? Chargebacks are partially based in law, so while you could be saving money now, it could be by building up more and more legal liability and risk.
But maybe you'll be fine, because you refund any and all refund requests.
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.
If that's your only gripe than that's probably the easier way than switching to an entirely separate financial system.
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).
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?
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.
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.
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.
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.
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.
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)
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.
How exactly do you think this differs from a single address getting updated? On a lite client this is nothing, on a full client nothing has changed.
There's a reason nearly every single solution involves an individual address tied to a single public key.
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?
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.
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.
I am proud to say I have used crypto to buy a physical souvenir, a steam game, and a yearly subscription to a service.
I would gladly do that more if they allow me.
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!
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.
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.
Practically impossible.
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.
> 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 :)
I'm going to look into the error need probably to catch it.
Did you update it?