-1

I'm a developer. I have a custom online store, with code I wrote myself, where I sell products in fiat money. I plan to introduce payments in bitcoin.

Issue: the customer may try to gain the system by taking advantage of the fact that bitcoin price always fluctuates.

For instance: on Monday BTC, or any abstract coin, costs $100, and on Tuesday it will $75.

A customer makes an order of $500 on Monday, with an intention to pay in BTC. The shop will generate price for thim: $500 => 5 BTC. But a customer waits a day ("may be tomorrow BTC will decline? Let's see") and sends those 5 BTC on Tuesday but claims that he really sent bitcoins on Monday.

That is, he should've sent me 6.66.... BTC (rate of Tuesday, $500 = 6.66 BTC) instead of 5 BTC (rate of Monday, $500 = 5 BTC). I end up loosing 6.66 - 5 BTC = 1.66 BTC as of Tuesday.

Question:

How to deal with such situations? How would I know that a customer sent me coins on Monday, when BTC was more expensive, and not on Tuesday?

Note:

  • At this point I don't want to run a full node, because I want to keep things simple. It's for now. I'm using Electrum and I think its API will do. Or at least semi-manual checking for bitcoin payment will work because I don't expect tons of orders, let alone in bitcoin.

  • I don't consider third-party payment processors or software to resolve this issue. I may use some public API of those, but I don't want to sign with them, go through KYC, pay them fees... Electrum the wallet is ok at this stage, something similar will do to.

  • The question is about an algorithm and isn't about software or payment service.

2
  • I think the BTCpayserver software will work for you. It is an open source project that allows you to self host a bitcoin payment gateway. It will take care of the issues you are worried about.
    – chytrik
    Jul 25 '20 at 18:53
  • @chytrik you don't understand. I'm telling you "I'm a car manufacturer, how do I deal with a problem X"? You're telling me "You just buy Ford and it'll work as is". I'm not asking what software to use.
    –  Leloucha
    Jul 26 '20 at 4:52
2

You seem to be somewhat confused about how currency markets, specifically for Bitcoin work, so I'm going to breakdown how a payment service using Bitcoin works for using your example.

You have a shop that sells an item, let's say a basket, for $500.

On Monday, 1 BTC = $100. The customer places an order on Monday, and you generate an invoice based on that price - the customer needs to send you 5 BTC. You note down the time you generate this invoice, let's say 13:00.

Scenario 1:

The customer sends you 5 BTC on Monday AND it is mined into a block within 60 minutes of your invoice being generated. That means the block must be mined prior to 14:01 on Monday.

In this case, all works well - you have your BTC, and can proceed to liquidate it for fiat at the price you intended

Scenario 2:

The transaction is broadcast on Monday, but is not mined into a block on Monday, either due to slow block times or low fees.

In this case, after 60 minutes from the generation of the invoice have elapsed, you simply cancel the order, and send back a transaction that refunds the BTC to the customer - remember, a refund transaction can be made even if the parent is unconfirmed, they will both be mined in sequence.

You should only make a refund using the incoming coins to avoid certain classes of attacks.

Now, the customer can attempt to place a new order if they still wish to proceed - the new order will be invoiced using the exchange rate at the time of the new order.

Scenario 3:

The transaction isn't broadcast until Tuesday, but the customer claims it was sent on Monday.

This is effectively the same as Scenario 2 - the order is cancelled 60 minutes after it was placed, and once the transaction is sighted on the network on Tuesday, you make a refund transaction.


This is the only sane way to achieve the kind of price fluctuation protection you're asking for - if this is not acceptable for your use case, you should consider working with less volatile coins, or coins with faster block times where this is less likely to be an issue.

5
  • Ok. Yes, but the customer may not be aware of the difference the low and normal fees make in terms of pace of propogation or mining of a transcaction. Should I advice the customer about that or what? How would I calculate the amount of fees that'll make a transcaction to be delivered within 60 minutes, in order to suggest that amount to a customer?
    –  Leloucha
    Jul 31 '20 at 9:23
  • Moreover, even if the customer sest a good fee, it doesn't guarantee that a transaction, or at least the 1st confirmation, will arrive withing 60 minutes, does it?
    –  Leloucha
    Jul 31 '20 at 9:24
  • Bitcoin Core offers a fee estimate API which gives you a suggested fee for confirmation within a number of blocks specified by you, and no, it is not guaranteed to confirm in 60 minutes, or at all, even with high fees Jul 31 '20 at 10:54
  • I won't run a full node. Can using Electrum wallet and its timestamps be relyable for this case, what do you think? I may use Electrum wallet manually, because I don't expect many BTC payments. Or perhaps API of Electrum servers or wallet directly too. Or perhaps, some other public free APIs of other companies. The bottom line, I won't run a full node on my own for now and will be using either Electrum desktop app or some free public APIs.
    –  Leloucha
    Jul 31 '20 at 13:12
  • The electrum API also has a fee estimation method: electrum.readthedocs.io/en/latest/…. The choice of API is not really important, as long as you are aware and able to deal with the currency fluctuations, or have a way to refund BTC when it is uneconomical for you Jul 31 '20 at 13:22
0

All you need to do is generate an invoice in your backend system at the time of checkout, which includes a specific amount of BTC to be paid, to a specific address. Then you just need to watch for payments to that address, and can consider the order 'paid' if an incoming payment for the correct amount of BTC is confirmed in a block.

In the event an incorrect amount of BTC is paid, you could simply create a customer service policy that stipulates a refund will be paid back to the customer (less transaction fees, perhaps).

As a suggestion, the open-source BTCPayServer project might work well to solve your problem. During checkout BTCPayServer generates an invoice requesting a specific amount of BTC, payable to a specific address, with a customizable time-out period for the payment to be considered 'completed'. If the software itself isn't quite what you want, you could at least consider copying it's workflow.

12
  • You haven't grasped the core issue raised in my question.
    –  Leloucha
    Jul 26 '20 at 5:41
  • I understand your issue to be "How do I deal with accounting for payments, when the BTC/USD exchange rate is fluctuating?" My answer is: at the specific point in time when the sale occurs (during 'checkout'), you declare an amount of BTC to be paid (according to the $ value of the item and the exchange rate), and then expect the customer to send that amount. Can you elaborate on how this doesn't answer the question, or what the actual question is?
    – chytrik
    Jul 26 '20 at 6:13
  • Sell me 10 bitcoins for $10 -- the price I'd have paid for them 10 years ago.
    –  Leloucha
    Jul 26 '20 at 6:16
  • No, the issue isn't How do I deal with accounting for payments, when the BTC/USD exchange rate is fluctuating?"
    –  Leloucha
    Jul 26 '20 at 6:19
  • @Leloucha that issue is why the invoice you generate should have a time limit on it, that the payment must be confirmed within. As per your example, obviously any offer to buy/sell bitcoin would be time-limited. As a savvy trader, I would offer my BTC at the going rate, but put a time limit on that offer, so that years later someone couldn't take advantage of me by claiming a long-past exchange rate.
    – chytrik
    Jul 26 '20 at 6:21
-1

You can try some service doing what you want and see how they behave. For example many of them (if not all of them) give you a time window to send the required amount. Most of the time it's not important that the transaction is confirmed but it has to be sent in that time frame window so it can be seen in nodes memory pool. When the transaction is found in memory pool, these services entry in a "confirming transaction" phase, where the order isn't confirmed yet until the transaction is included in the blockchain.

Some services accept the order once it has one confirmation, other that play more on the safe side wait 6 confirmations, it's up to you and to your risk profile. Waiting full confirmation time (6 confirmations) of course mean the end user has to wait more time to have it's order accepted so it's a worse user experience.

Note that if you aim to automatically move sent BTC somewhere else you could technically do that even before the transaction is fully confirmed, in case you want to convert btc to fiat as you get the payment, sending btc to an exhange or what

You still have to consider refunds problem, not sure the effort is worth not using a 3d party service. Consider for example an user that sends you money after the time window, it's up to you to handle it (if accept anyway the order or don't consider the payment as valid) If it's not valid, you may want to request some more fund to the user, so you need a support effort, in some case the user want a cashback so you have to send funds back to him (and probably not at the same address the money came from).

There is more to talk about but already this is something that should make you think about pros and cons of DIY solutions

2
  • I don't consider third-party payment processors.
    –  Leloucha
    Jul 25 '20 at 15:17
  • if you gave the -1 then tell why, because I explained how a solution you try to build usually works and what are the difficulty you have to deal with, that's not worthing the -1. When I said "you can try" of course mean as an user, so pay using other services. I gave you something to think about and you aren't polite at all. Other answers says same thing about using a time window. Jul 26 '20 at 18:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.