Topic: hypothetical POS situation (Read 1587 times)

"Trusting in a random one-off situation" -> "Fool me once, shame on you... fool me twice... you don't get fooled again."

If your connection goes down and you don't suspect your customer could cause or expect that to happen then you can just take the tx and broadcast it later. People used to take checks as a matter of course. Trusting in a random one-off situation where the person would have to be ready for just this sort of opportunity is orders of magnitude less risky. Also if you are in the habit of taking the tx and broadcasting it yourself the buyer doesn't even need to know that this is their rare opportunity to scam.

I've been to stores many times that wouldn't take plastic because their network was down. I don't think there is an electronic solution for trust here. A Casascius style physical bitcoin could be used and instead of getting change from the vendor, an IOU store receipt can be given that will transmit the change to a customer's address when the system is back online. It's not a perfect solution, but a brick and mortar store is usually trustworthy enough.

the POS terminals are connected to the internet.  That's how they process credit cards now.  The old way of dialing in on a phone modem is obsolete now.

When you swipe your card, the POS software uses an API from a credit card processor to post the payment and wait for a callback.

What happens if the internet connection goes down in the middle of your credit card swipe?

The same problem would exist with credit cards and bitcoin.  Both require an active internet connection to work.  So with the way we designed our API there's nothing different here.

Credit Card processing API - merchant posts payment data and waits for callback

Bit-Pay payment API - merchant posts payment data, displays response with QR to customer, and waits for callback

When we detect the payment was received (within 1-2 seconds) we can send the server response back to the merchant.  This can be sent to their back-end server or to the POS itself, their preference.  

We've tested this hundreds of times using our Mobile Checkout (which simulates POS software) and it works great.  Any delays are usually from the person's bitcoin wallet waiting before sending funds.  Some wallets are very fast to send, like BitcoinSpinner.

https://bit-pay.com/aboutMobile.html

Also, if the store does detect that you are trying to scam them, you can probably expect to be:
1.  taken out the back door and beaten
2.  kindly asked to pay another way
3.  told not to come back again

The problem is that if the customer actually did send the coins the store needs to either send them back or provide the goods.

One way to resolve it would be for the buyer to display a QR code of the signed transaction. The seller scans it and can verify it against their copy of the blockchain and transmit it to the network themselves.

I would imagine that the sender will have to show the adress from which he claims to have sent coins. The store can check that adress and see no coins sent.
They can than make a note. If we get X coins from adress X this customer have the right to item Y, valid as long as this note is not deleted. Delete note when item Y has been redeemed.

But until they do not se any coins they can simply not give away the item. Just like when sometimes VISA terminals do not work, you have to go and get cash.

Bitcoin transactions propagate globally within a few seconds so if the transaction truly reached the network the store would know about it.  I suppose if the mobile device is having connectivity issues, the transaction would be committed but not received by the store.  Without any method to cancel the transaction -- yes that could be a problem.  I suppose the store would be able to refund the customer when the transaction eventually makes it through.


Any web access can verify the transaction in the blockchain.   I suppose a Twillo-based voice app could be built to serve status even when there is no web access.


That would be bad if it really happens.   Though the code would have to be close and the customer wouldn't know the target address in advance.

'Imagine' a point of sale system that accepts bitcoin, operating in a popular grocery store. Payment is done by the customer reading a QR code of the address to pay to using something like BitcoinSpinner on their phone.

What happens when someone makes a fake app which looks just like one of the popular wallet clients which can read the amount from the QR code, then displays a fake 'i have sent x BTC to the store' in their client? Obviously nothing will come through on the POS side of things to confirm the transaction since there is no transaction, however the customer will say for certain that they sent the money cause their wallet app says they did, and it definitely looks like it has been sent according to the person standing at the POS terminal.

What policy should be set by the store and why? On the face of it, it seems like a good idea to simply say 'no sale' to the customer. I am interested to know if any other options can be reasonably considered that leaves both the store and the customer happy.

Are there any situations where the payment is legit but the terminal may not have received it? Some situations I could imagine which look like the above situation but are not, and thus confuse how to deal with the situation are:
The pos terminal temporarily loses internet connection and thus cannot confirm the transaction.
The customer has a bad read on the QR code and has accidentally sent it to the wrong address (unlikely, but possible).

Do you think this is going to be an issue? How would you suggest dealing with it from the perspective of the POS operator? Is there any good way to be able to accept offline transactions without pre-established trust?

If you think that the specific POS implementation matters, please say why and how it may be implemented in a specific way to avoid this potential problem. I think that this issue is independent of the pos implementation, but am happy to be shown to be wrong.