<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>

CC BY-SA 4.0
2020-07-31T09:23:17.553Z
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
CC BY-SA 4.0
2020-07-31T09:24:42.053Z
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
CC BY-SA 4.0
2020-07-31T10:54:09.977Z
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
Raghav Sood
CC BY-SA 4.0
2020-07-31T13:12:33.900Z
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
CC BY-SA 4.0
2020-07-31T13:22:54.200Z
The electrum API also has a fee estimation method: https://electrum.readthedocs.io/en/latest/protocol.html#blockchain-estimatefee. 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
Raghav Sood
CC BY-SA 4.0
2020-07-26T16:04:26.340Z
2020-07-26T16:04:26.340Z
Raghav Sood
<p>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.</p>
<p>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).</p>
<p>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.</p>

CC BY-SA 4.0
2020-07-26T05:41:13.003Z
You haven't grasped the core issue raised in my question.
 Leloucha
CC BY-SA 4.0
2020-07-26T06:13:05.017Z
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
CC BY-SA 4.0
2020-07-26T06:16:08.433Z
Sell me 10 bitcoins for  $10 -- the price I'd have paid for them 10 years ago.
 Leloucha
CC BY-SA 4.0
2020-07-26T06:19:55.930Z
No, the issue isn't `How do I deal with accounting for payments, when the BTC/USD exchange rate is fluctuating?"`
 Leloucha
CC BY-SA 4.0
2020-07-26T06:21:57.410Z
@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
CC BY-SA 4.0
2020-07-26T06:23:18.717Z
Exchange-rate-risk is something to be considered, for certain. I'd suggest considering a timeout for payment confirmation of maybe just an hour, or a few hours at most, so that you can be fairly sure that the price won't change much while you are awaiting payment.
chytrik
CC BY-SA 4.0
2020-07-26T06:25:01.680Z
Yes, time limit. But I said "how do I ensure that a customer sent coins within that time limit?" provided that there're delays in bitcoin network. And also that with low fees a payment, even the 1st confirmation, may take a day to appear
 Leloucha
CC BY-SA 4.0
2020-07-26T06:26:12.710Z
How would I know whether a customer tries to gain the system by lying or it's been a delay in the network due to a low fee / delay on its own (overload)?
 Leloucha
CC BY-SA 4.0
2020-07-26T06:29:43.943Z
Software can simply watch the address that was specified in the invoice, for an incoming payment of the specified amount. If a payment does not confirm before the invoice times out, then the invoice is considered unpaid an invalid, and any BTC received after that could simply be returned to the sender (how this is done might take some consideration, but that is the basic idea at least). There is no need to worry about being gamed: you set the rules of the transaction at the time the other party is invoiced. They either make the payment correctly, or not.
chytrik
CC BY-SA 4.0
2020-07-26T06:30:12.293Z
Software! Yes! Re-read my question, software-man
 Leloucha
CC BY-SA 4.0
2020-07-26T06:35:36.303Z
I will be very impressed if you manage to build a system to receive bitcoin payments, that involves no software... but in any case, yes, the software would watch for a payment to be confirmed. Under the hood, this means that a transaction which pays you (as specified in the invoice) has been included in a new valid block on the bitcoin network. If you see this block arrive before the invoice times out, then the transaction would be considered complete. If no block contains a transaction paying you before the timeout period ends, then the transaction is to be considered incomplete.
chytrik
CC BY-SA 4.0
2020-07-26T18:57:10.520Z
@chytrik I think you are wasting time, I gave an answer that got a -1 because started with "You can try some service" without even understanding I was suggesting to use a service as an user to see how it behave, going then deeper explaining how they works and why.
His attitude isn't worthing the effort to reply.
Not Important
CC BY-SA 4.0
2020-07-26T05:34:44.427Z
2020-07-26T05:34:44.427Z
chytrik
<p>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 &quot;confirming transaction&quot; phase, where the order isn't confirmed yet until the transaction is included in the blockchain.</p>
<p>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.</p>
<p>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</p>
<p>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).</p>
<p>There is more to talk about but already this is something that should make you think about pros and cons of DIY solutions</p>

CC BY-SA 4.0
2020-07-25T15:17:45.747Z
**I don't consider third-party payment processors.**
 Leloucha
CC BY-SA 4.0
2020-07-26T18:51:28.917Z
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.
Not Important
CC BY-SA 4.0
2020-07-25T12:49:27.653Z
2020-07-25T12:49:27.653Z
Not Important
<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>

CC BY-SA 4.0
2020-07-25T18:53:23.730Z
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
CC BY-SA 4.0
2020-07-26T04:52:51.860Z
@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
<transactions><api><exchange-rate><fraud><fiat>
How to deal with situations when the buyer tries to gain the system? (online shop with price in fiat, BTC payments also possible)
 Leloucha
# How to deal with situations when the buyer tries to gain the system? (online shop with price in fiat, BTC payments also possible)

(Asked by: username_0 on 2020-07-25)

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.

**Tags:** transactions, api, exchange-rate, fraud, fiat

> **Comments:**
> **username_1**: 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.  
> **username_0**: @username_1 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.  

---

## 3 answers

### Answer by username_2 on 2020-07-26. Score: 2 | Accepted answer

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.

> **Comments:**
> **username_0**: 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?  
> **username_0**: 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?  
> **username_2**: 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  
> **username_0**: 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.  
> **username_2**: The electrum API also has a fee estimation method: https://electrum.readthedocs.io/en/latest/protocol.html#blockchain-estimatefee. The choice of API is not really username_3, 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  

---

### Answer by username_1 on 2020-07-26. Score: 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.

> **Comments:**
> **username_0**: You haven't grasped the core issue raised in my question.  
> **username_1**: 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?  
> **username_0**: Sell me 10 bitcoins for  $10 -- the price I'd have paid for them 10 years ago.  
> **username_0**: No, the issue isn't `How do I deal with accounting for payments, when the BTC/USD exchange rate is fluctuating?"`  
> **username_1**: @username_0 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.  
> **username_1**: Exchange-rate-risk is something to be considered, for certain. I'd suggest considering a timeout for payment confirmation of maybe just an hour, or a few hours at most, so that you can be fairly sure that the price won't change much while you are awaiting payment.  
> **username_0**: Yes, time limit. But I said "how do I ensure that a customer sent coins within that time limit?" provided that there're delays in bitcoin network. And also that with low fees a payment, even the 1st confirmation, may take a day to appear  
> **username_0**: How would I know whether a customer tries to gain the system by lying or it's been a delay in the network due to a low fee / delay on its own (overload)?  
> **username_1**: Software can simply watch the address that was specified in the invoice, for an incoming payment of the specified amount. If a payment does not confirm before the invoice times out, then the invoice is considered unpaid an invalid, and any BTC received after that could simply be returned to the sender (how this is done might take some consideration, but that is the basic idea at least). There is no need to worry about being gamed: you set the rules of the transaction at the time the other party is invoiced. They either make the payment correctly, or not.  
> **username_0**: Software! Yes! Re-read my question, software-man  
> **username_1**: I will be very impressed if you manage to build a system to receive bitcoin payments, that involves no software... but in any case, yes, the software would watch for a payment to be confirmed. Under the hood, this means that a transaction which pays you (as specified in the invoice) has been included in a new valid block on the bitcoin network. If you see this block arrive before the invoice times out, then the transaction would be considered complete. If no block contains a transaction paying you before the timeout period ends, then the transaction is to be considered incomplete.  
> **username_3**: @username_1 I think you are wasting time, I gave an answer that got a -1 because started with "You can try some service" without even understanding I was suggesting to use a service as an user to see how it behave, going then deeper explaining how they works and why. His attitude isn't worthing the effort to reply.  

---

### Answer by username_3 on 2020-07-25. Score: -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 username_3 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

> **Comments:**
> **username_0**: **I don't consider third-party payment processors.**  
> **username_3**: 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.  

---

