Difficulties of providing a crypto payment system on your website(cryptogif.info)
cryptogif.info
Difficulties of providing a crypto payment system on your website
https://cryptogif.info/project2/docs.php
72 comments
Sorry, just use the top "index" link to the main blog website. At the bottom you find the imprint and my contact details.
I'm going to look into the error need probably to catch it.
I'm going to look into the error need probably to catch it.
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.
Did you update it?
Did you update it?
Yes, I inserted the imprint in both projects after you told me it's somehow hard to find.
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.
Yes, that's a big problem. You might harm your reputation including a Crypto payment option.
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.
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.
There are people, myself included, that appreciate a crypto payment inclusion.
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.
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.
Just out of curiosity. What is the fraction of these transactions in crypto compared to those with other payment methods?
Compared to my other transactions? Very small.
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!
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.
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.
You are proud because you used a specific form of payment?
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.
Agree to disagree, I guess. I'm glad you did use it for pizza back then, and I hope more of us use it for pizza in the near future. You are one of the few that don't just gamble and buy nfts.
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.
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.
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)
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.
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.
> But with every address you create your daemon has to look for changes there
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.
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.
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?
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.
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.
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.
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.
> Isn’t there a captive payment portal API
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.
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.
Yep, I understood that. My point is cashing out 500 payments from single use wallets leads to 500x the transaction fees versus 1 main wallet, right. The customers would anyway pay the incoming fees, but outgoing gets expensive esp for smaller txes. Why is this optimal for a store?
>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.
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.
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.
I'm not sure why people are not talking about BUSD. It is arguably safest and fastest stable coin.
a stable coin gets its audit in US.
a stable coin gets its audit in US.
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.
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).
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).
Your understanding is correct, at least for the US.
People ended up using crypto as a stock investment instead of as a currency and then they're surprised it gets taxed as a stock investment.
I mean, it's currency. Trading currency is pretty old, so I doubt anyone was surprised here.
Your typical currency is inflationary though, which unlike crypto generally makes it a bad long term investment.
Plenty of crypto tokens are inflationary. Some are deflationary. Some are both, based on supply and demand.
Let's be frank here, just about most of them are deflationary.
Bitcoin, sure.
Ethereum and it’s many stablecoin tokens, Solana, Polkadot, Tezos, all do not have fixed supply and may be inflationary at times.
Ethereum and it’s many stablecoin tokens, Solana, Polkadot, Tezos, all do not have fixed supply and may be inflationary at times.
at least in Germany after holding 1a you have no tax to pay.
The biggest error is to assume people want to pay with cryptocurrency.
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.
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.
I would love to pay with crypto.
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.
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.
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.
[deleted]
[deleted]
You are saying that you rather would have your crypto wallet stolen instead of your credit card?
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?
How come? There's no speculation in stablecoins, USD-following or not. Especially if you transact on a layer-2 solution, it's quite convenient.
That couldn't be further than the truth. It's just a more convenient way of trading forex.
To be fair that assumption is wrong if you look at more weird specific niches. Crypto payments definitely have a place, also outside of drug markets.
Like what?
Porn, SMM, basically any international digital services on the PayPal blacklist.
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).
What's SSM in this context?
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?
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.
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.
> I save thousands of dollars in transaction and chargeback fees every year
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.
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.
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.
Surprised nobody mentioned https://btcpayserver.org/ yet.
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).
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).
Thanks for the insights.
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?
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?
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.
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.
> Bitcoin needs time to transfer
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.
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.
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.
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.
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.
> 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 :)