How to deal with situations when the buyer tries to gain the system? (online shop with price in fiat, BTC payments also possible)

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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