A decentralized payment processor with FIAT conversion

Yesterday we had some conversation on discord regarding payment processors, the need to convert to FIAT etc. I have always had some thoughts regarding a payment processor that would convert Nano into FIAT instantly for merchants since most merchants don't want Nano (or any crypto for that matter). I think from a merchant perspective we should treat Nano as a payment system, not a currency. For them receiving via Nano or paypal is the same, both are simply ways to receive his desired FIAT (with nano being cheaper obviously). The biggest hurdle to that service is that since a payment processor would require to move money around, several bureaucratic hurdles appear. The goal here is to create an open source, decentralized payment processor that converts into FIAT that every merchant could (in theory) run on its own, with no centralized service or server. For the sake of example I'll call it the Nano Payment System (NPS)

Why
There's no reason for merchants to hold onto Nano if they are not crypto (and Nano) enthusiasts. Conversions towards FIAT with minimum risk is a requirement for merchant adoption at this point in time.

How
The merchant will need his own exchange account, API keys etc.
Since the back-end is gonna be the back-bone of the system, let's talk about it first:

*Note: This is the most basic version I can think of, improvements will be listed later.

Back-end desired functionalities:

  1. Exchange the Received Nano for the FIAT of choice
  2. Request FIAT withdraw to merchant bank account.

Parameters for back-end:

  1. Exchange
  2. Exchange API Keys
  3. Desired FIAT currency
  4. Withdraw method and account
  5. Withdraw frequency (minimum being for every sale).
  6. Expected trading fees (just in case you can't check via API, default would be check current tier via API for tiered fee system, which is most exchanges)
  7. Default deposit address (in case the exchange API does not allow management of those)
  8. Expected withdraw fees (if unable to check via API)
  9. Slippage spread. A spread used to counter the effects of slippage when executing an order.

The back-end will receive 2 types of requests from the front end, one for exchange data and another for acknowledgement of payment.
The first request is for Amount of Nanos and exchange deposit address and in that request the front-end will include the payment size. The back-end must then check the exchange market data in order to answer the following question: "If I were to market sell Nano now, how many would I need in order to end with payment size?". That must include expected trading fees, withdraw fees and slippage spread. It then answers to the front-end with that data (amount of Nanos, exchange deposit address).
The second request is independent from the first, it's a sale confirmation request that inlcude the amount of Nanos being sent to which exchange deposit address. The back end will simply answer with an acknowledgment message so that the front end does not repeat the request.

Actions of the back-end:

Upon receiving the first request with parameter payment_size, the back end computes the required amount of Nanos to market sell and get the desired amount of FIAT (including fees and spreads) and answers it along with an exchange deposit address.
Upon receiving the second request the back-end adds the pending deposit to a DB and triggers a deposit confirmation scheme. It depends on the exchange and what its API can do, but the most basic system would be a 30 seconds (any interval really) funds check to see if the expected deposit has arrived.
On confirmation of the deposit, it trades the received Nano for FIAT and depending on the withdraw parameters either requests a withdraw now or schedule it by adding it to a DB.

Front-end desired functionalities:

  1. Offer addresses to receive payments
  2. Deal with incomplete/incorrect payments
  3. Communicate/notify the store and back-end when a correct payment is made and deposit the payment to the appropriate exchange deposit address.

Parameters for front-end:

  1. Safety spread (a spread added on top of the required amount of Nanos, a kind of insurance)

This parameter is added to the total amount of Nanos charged to the costumer as insurance versus the Nano volatility between the time of the price consultation and execution at the exchange. It includes the delay for the costumer to make the payment and the delay for the exchange to credit the eventual deposit.

The most basic version of the front end is a mobile wallet capable of making the requests to the back-end. A small physical store, where the merchant uses his mobile wallet to first receive the payment then forward it to his exchange address (if the payment was correct) and finally trigger the second request so that the back end converts to him automatically. The simplest possible version don't even need to make the first request, the merchant does it himself and just makes the second so that the system automatically converts for him.
A full version is the equivalent of the original Brain Blocks payment processor (with expiration time for payment addresses, automatic refunds for incorrect payments etc) with capabilities of making those requests to the back-end and sending the payed Nano to the appropriate address.

In any case the front end will require access to a Nano Node in order to:

  1. Check for payments
  2. Broadcast blocks.

I think the default decentralized option would be for the merchant to run its own Nano node and the NPS on its server.
I think it would be nice for the front-end designs to be sort of plug-ins for the back-end (that's why the limited and pre-determined communication protocol), so that existing payment processors (that only deal with Nano, like the original Brain Blocks) could be adapted to be used with the back-end rather easily.

For the back-end the goal here is to add support for exchanges as they add Nano (or we as a community implement them), so each exchange API must work as a plug-in for the back-end as well, with the NPS itself being exchange agnostic. So the NPS would have functions to market sell, withdraw, create/check deposit addresses and balances, trading fees etc, with each independent exchange API implementing those functions according to it's capabilities. The back end does not need a connection to the Nano network, all it's actions can be based on data from the exchange and the front-end, so it can be installed in any system, including pre existing ones the merchant owns (it also uses little resources).

This is an overview of the simplest version of the system I can think of. It's a starting point and not an end goal. Underneath I describe several improvements to make it really useful.

Features that should be added:

  1. Accounting features:
    Since every Nano transaction is technically a taxable event, keeping track of all of those is a must for merchant adoption of the system. The back-end already have access to all the trades, but it could also include and keep track of the sale value (it would become an optional parameter on the second request from the front-end).
    For taxes purposes, every time the merchant sells a product, it "buys" Nano from the costumer at sale value and sells at X at the exchange. A well designed system and parameters should offer a consistent small profit (insurance spreads ) result, but implementing a DB to keep track and compute all profit/loss from those trades would make the nightmare of taxes regarding accepting crypto easy.

  2. Automatic refund of "unused" safety spread/slippage spread. The merchants wants to receive A defined amount of FIAT. Because of the spreads (insurance) he will on average receive more and be left with a profit. He could refund such profit as soon as the trade occurs. For example: Costumer buys $10 worth of products. Merchants charges him 9.2 Nano for it, and costumer pays. At the exchange, the NPS system sells $10 + withdraw fees worth of the Nanos he received, and since the effective sell price was $1.16 (including fees), he sold only 8.6 Nanos leaving him with 0.6 Nano "profit". Those Nano could be refunded to the buyer immediately. In terms of accounting and tax events, I don't know if they can be considered "change" (the costumer payed more so now you are returning money) or if they become taxable as well. In any case, with item 1 implemented it makes no difference other than making sure the amount of profit/loss at the end is as close to 0 as possible (the refund would be a sell back to costumer at a $0 price to make the net result $0. Just for clarity imagine the price of Nano is $1 and the costumer buys $10 and pay 11 Nano for it so that you refund 1 Nano later. For tax purposes you first bought 11 Nano for $10 from the costumer, then sold 10 Nano for $10 at the exchange and finally sold 1 Nano for $0 back to the costumer, making your overall profit exactly 0). With this feature, the insurance spreads work as a kind of "maximum" charge for the costumer, with him receiving "change" most of the time.

  3. Ability to deal with more than one exchange at once, choosing which to use based on liquidity (price)

  4. Some merchants might want to vary exchange deposit addresses for private reasons. That's why I'm including parameters regarding deposit addresses, but the initial version can ignore this and simply use a single fixed deposit address

The overall costs:
As with any costs, they can be all passed to the costumer. There are 2 costs associated to this system, one is the infrastructure required to run the system. I'll deal with this later. The other is exposure risk, since the merchant does not want exposure on Nano. For every minute that the merchant owns Nano and it changes in price he realizes a profit/loss he never intended or desired. The parameter "safety spread" is there to move most of the risk to the consumer, but it's always gonna be there (If Nano loses more value than those insurance spreads can cover the merchants still loses money).
In terms of passing the regular costs to the costumer, the trading/withdraw fees would be there anyway even if the costumer bought with FIAT (imagine if the costumer had to liquidate his crypto himself in order to pay the merchant), so they are irrelevant. They are a cost that exists simply because the world wants FIAT and you own crypto and the only way to avoid it is to not own crypto in the first place so I don't consider it a problem to have this cost passed on to the costumer. Also, a costumer that owns crypto has chosen to incur in exposure risk by exposing his net worth into crypto in the first place, so I can't see the costumer feeling uncomfortable on having that risk throw onto him. With the implementation of improvement 2, I think the costumer would feel very comfortable, since the costs being passed onto him are equivalent to the ones he would incur himself or smaller (economics of scale regarding trading fees). In practice the costumer would pay the exact amount of Nanos he would if he sold his Nanos himself, withdrew and paid in cash. And from the merchant he would receive the exact amount of FIAT he would nominally charge.

The goal is to make all of this open source. Anyone could download all required files and if you have access to a Nano Node (for front-end communication) and fill the required parameters for the back-end (have an exchange account with API enabled etc), you should be able to accept Nano on your store and receive in FIAT with minimum risk.

But there is a business to run on top of it. Like with most open source software, installing and managing it is hard. So a consultancy business can be built on top on this that offers the following services:

  1. Consultancy regarding a local independent installation.
  2. Installation and support services for merchants.

The first is simple, you just help the client set everything up. Help him open an exchange account, set up the appropriate APIs, the Nano node etc, but after the initial set up the merchant is on his own.
In the second, you do everything for him and offer support in case he runs into any trouble. To avoid the money transmitter licenses and other bureaucratic hurdles, you have to open everything on his behalf and on an independent manner. The entire system belongs to the costumer, you just set up for him and manages it for him, but all belongs to him still. It's akin to consultancies specialized on helping companies move onto open source solutions. All the liabilities still lie with the costumer and the company offer help only to keep everything running smoothly.

So the costs of running the system depends on how the merchant acts. If he wants to run everything himself, the costs are the ones of running a Nano Node (since the NPS can run on the same server). If the merchant wants to hire someone to manage things, it can be a little more expensive, but could still be a fixed price which would do wonders for the merchants with scale (but would be terrible in the beginning when few people are using, so something to think about).

2 Likes

I haven’t read everything in details but:

If Appia/NF acquires BrainBlocks(BB) coupled with the library ccxt it is totally possible to set this up.

I was writing a little app using BB for micropayments.

BB handles the payment part and my app would simply monitor the exchange deposit address with the node callback, depending on certain rules, the app would market sell or not.

Unfortunately no more BB...

As for the accounting part, there are some software already so no need the invent the wheel once again

1 Like

That's basically it Jav, but a little more general. You could write it all inside a wallet app where exchange API keys are parameters you config. It's a physical PoS with automatic conversion. It can be very simple, I was just describing a more complex and general version.

2 Likes