user107735: 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.



user7272: 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.

107735: <p>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.</p>
<p><strong>Issue:</strong> the customer may try to gain the system by taking advantage of the fact that bitcoin price always fluctuates.</p>
<p><strong>For instance:</strong> on Monday BTC, or any abstract coin, costs $100, and on Tuesday it will  $75.</p>
<p>A customer makes an order of $500 on Monday, with an intention to  pay in BTC. The shop will generate price for thim: $500 =&gt; 5 BTC. But a customer waits a day (&quot;may be tomorrow BTC will  decline? Let's see&quot;) and sends those 5 BTC on Tuesday but claims that he really sent bitcoins on Monday.</p>
<p>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 <strong>as of Tuesday.</strong></p>
<p><strong>Question:</strong></p>
<p>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?</p>
<p><strong>Note:</strong></p>
<ul>
<li><p>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.</p>
</li>
<li><p>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.</p>
</li>
<li><p>The question is about an algorithm and isn't about software or payment service.</p>
</li>
</ul>
 7272: <p>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.</p>
<p>You have a shop that sells an item, let's say a basket, for $500.</p>
<p>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.</p>
<p><strong>Scenario 1:</strong></p>
<p>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.</p>
<p>In this case, all works well - you have your BTC, and can proceed to liquidate it for fiat at the price you intended</p>
<p><strong>Scenario 2:</strong></p>
<p>The transaction is broadcast on Monday, but is not mined into a block on Monday, either due to slow block times or low fees.</p>
<p>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.</p>
<p>You should only make a refund using the incoming coins to avoid certain classes of attacks.</p>
<p>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.</p>
<p><strong>Scenario 3:</strong></p>
<p>The transaction isn't broadcast until Tuesday, but the customer claims it was sent on Monday.</p>
<p>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.</p>
<hr />
<p>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.</p>
