VISIT https://scantopay.cash FOR A PROPER DESCRIPTION/DEMO.

THIS ARTICLE IS INTENDED TO COLLECT FEEDBACK FOR THE CONCEPT.

Why?

Bitcoin Cash merchant adoption is going great. However, there can be a few hiccups in places that are listed as accepting Bitcoin Cash, but have low customer throughput:

1. Infrequent BCH payments can lead to the Android Device that is being used as a Payment Terminal being neglected (not charged, not connected to WiFi, not turned on, etc).

2. High employee turnover can mean that many of the staff are unsure as to how to use the Payment Terminal (or don't know where it is).

As an experimental alternative, as opposed to a merchant using a dedicated Payment Terminal Device, we might fare better allowing staff to (simply and easily) use their own phone for accepting BCH Payments.

One way in which we can do this is by having two QR Codes that we simply print on Sticky Paper:

1. A QR Code that is staff-facing that can be scanned to open a WebApp that allows the staff to set the amount that is due.

2. A QR Code that is customer-facing that can then be scanned by their Wallet App to pay that amount.

For Example

Such a setup would have a few benefits for merchants and those spreading adoption:

1. For merchants, there is no dedicated Payment Terminal device that the merchant needs to maintain: Staff can simply use their own phone and open the Terminal in their phone browser (no need to install an app).

2. For those spreading adoption, on-boarding BCH Merchants becomes cheap. There is no need to supply a dedicated terminal device - just a sheet of sticky-paper with two QR Codes.

In this PoC, the interface for merchants has been kept simple so that no training should be required and the process is (hopefully) friction-less.

Constraints

This dual QR Code approach does require the customer's wallet to support either the BIP70 or JPP Payment Protocols. This means that some wallets, unfortunately, will not be supported.

This has been tested to work with:

1. Bitcoin.Com Wallet

2. Electron Cash

... but any wallet that properly supports BIP70/JPP should work and the intent is to support any future Payment Protocols.

Adoption Potential

There may be a few additional benefits to this setup from an adoption point of view:

1. On the flip-side of using a Payment Protocol (like BIP70 or JPP), there may in future be opportunity to provide some incentive to spread adoption as it would be possible to cut a small fee on-top of each BCH purchase for each merchant on-boarded. Thus, we could incentivize those spreading adoption.
   (For anyone wishing to attempt this, the code is open-source and I would be more than happy to assist.)

2. As an adoption strategy, due to this system being operable with paper-only, bulk-mailing adoption campaigns where these terminals are mailed to potential businesses (with setup instructions) becomes feasible.

Additional Considerations

The feasibility of the following would have to be evaluated.

1. In some cases, a merchant may also require purchases to be tracked internally (for inventory purposes). It may be possible to allow a guide to be written and displayed to the staff upon first scanning the Terminal QR Code to ease this process (alternately, this could just be printed on the Terminal QR Code sticker itself).

2. Streamlining the above, there might be the possibility of a Merchant's existing PoS system integrating directly with ScanToPay such that the Staff no longer needs to scan a QR Code - they can just input the amount in their existing PoS (which could interact with the ScanToPay API) and instruct the customer to scan the Payment QR Code.

Security

Although, not ideal, it is not currently possible to change the Destination/Receiving Address after a terminal has been initially configured. This is to prevent a malicious employee from changing the Receiving Address to their own. However, there are still some things to keep in mind:

1. A malicious employee (or third-party) can perform a "griefing attack" if they discover the Merchant URL and can set the amount due remotely. In this event, a customer could be presented an invoice that is incorrect, but the malicious party still cannot steal the funds to themselves (as the address will always remain the address that was initially configured). Thus, there should be little incentive in doing this, except to be a nuisance.

2. An malicious employee could try to replace the Payment QR code with their own. This would be like an employee "stealing money from the til" so we do not try to explicitly guard against this. However, to minimize risk and at least make this noticeable, these QR Codes could have a space for the owner to sign their signature (with pen) which should make it obvious if this has taken place. Another option is to physically secure the QR Code such that this cannot happen easily.

It would be ideal to have a mechanism for the Terminal configurations to be updated, but I do not believe a password is ideal. There are many naive store owners that may set the password to the same as all other passwords used by staff (or to something that is easily guessable), thus if anyone has suggestions that will NOT significantly hinder UX flow, please let me know. Another reason that this is useful is to prevent the griefing attack mentioned in point 1 above. If this happens to a merchant the simplest remedy would be to add a password hashbang (i.e. "#pwd=1234abcd") and then allow the Merchant to reprint the Merchant QR Code only (with this new password included in the URL).

One such approach might be to collect Email Address upon Terminal setup and then require Email Confirmation upon any changes. However, the trade-off here is that it's an additional piece of (private) information that the Merchant would have to provide.

Links

https://scantopay.cash

Git Repository: https://gitlab.com/scantopay.cash... but it needs a lot of janitorial work, so I don't recommend trying to build off it yet.