Exchange notifies processor of payments

[natefriedman]

The current proposal has the processor independently determine when payment is made. This adds significant complexity to each processor and creates the possibility that the processor thinks a payment was made when the exchange does not (or vice versa).

Having the exchange notify the processor of payments via a webhook solves this. This is easier for the exchange to implement since they are already crypto experts, lowers the barrier for processor adoption (since they don't now need to be crypto experts), and ensures that invoices are marked as paid only when they really are.

[NicolasDorier]

@natefriedman it makes sense for the exchange to send a callback when the payment is considered done on the exchange side.

However, the payment processor always need to be able to track payments, so it does not make life easier for payment processors. Because when the user pays, he expects the UI of the invoice to update instantly, not after 6 confirmations.

I am also thinking: Does payment processor really need to know what happens on the exchange side? Does the fact that the rate could be guaranteed or not, should influence the lifetime of an invoice on the payment processor ?

[natefriedman]

@NicolasDorier good point. It makes for good UX for payment processor to know when payment is sent. I would propose the exchange also makes a callback to processor when the transaction hits the mempool.

I imagine the processor would likely want to communicate how long the invoice amount is valid for to minimize exchange rate risk. The duration can come from the exchange if the rate is guarenteed or from the processor's or merchant's policy if it is not.

Because of this invoices denominated in crypto really have 5 possible states -- unpaid, payment in process, paid, incorrect payment amount, and expired. Traditional ecommerce invoices only have 2-- unpaid and paid. This is because customers cannot pay the wrong amount and know almost instantly whether the payment has gone through.

So for crypto the invoice could be:

• Payment in process would be when a payment hits the mempool. Invoice would stay in this state until payment is confirmed.
• Paid is when the payment is confirmed by the exchange, is the for the right amount, AND was sent within the right timeframe (if a timeframe was required)
• Incorrect payment amount is when too little or too much payment was received. This can occur if the wrong amount was sent OR it took too long to confirm and the processor chooses to not accept unlimited exchange rate risk.
• Expired is when the duration of the invoice amount has expired.

It would be up to the processor to determine how to handle "Incorrect payment amount" and payments to expired invoices.

Strictly, the processor doesn't need to know the exchange rate in the confirmed callback since it can just determine invoice state based on BTC amount and timeframes. However, exchange rate is helpful in creating more advanced processor rules such as "accept invoice a paid if fiat amount = +/- 2% of invoice amount even when payment timeframe has elasped"

So maybe the flow should be:

1. Customer adds item to cart/checks out
2. PROCCO queries MYCOIN to get address and exchange rate and creates invoice. Invoice may be valid for a limited duration to limit exchange rate risk.
3. Customer sends payment. MYCOIN sees payment in mempool and notifies PROCCO.
4. PROCCO updates invoice to "payment in process"
5. Payment is confirmed and accounts credited at MYCOIN. MYCOIN notifies PROCCO of when and at what rate.
6. If payment is for right amount and sent/confirmed in right timeframes, invoice marked PAID. If payment is for wrong amount or confirmed too late and at unfavorable exchange rate then PROCCO marks invoice as "Incorrect payment amount" and communicates next steps to merchant/consumer.

[NicolasDorier]

I imagine the processor would likely want to communicate how long the invoice amount is valid for to minimize exchange rate risk.

Just some background about the different states of BTCPay/Bitpay:

• new: Invoice created, rate fixed. Stays here if underpaid.
• expired: Goes from new to expired after 15 min
• paid: Goes from new to paid if invoice paid or overpaid. (tx reached mempool)
• confirmed: Goes to from paid to confirmed either immediately, after 1 conf, or after 6 conf (merchant settings) This is what merchants use to consider the order "settled"
• complete: After 6 confirmation, the conversion from BTC to fiat has been done by Bitpay (this should be an exchange setting)
• invalid: Goes from paid to invalid if tx not confirmed after an hour.

So the way Bitpay works for example is to consider the invoice p expired if paid after 15 minutes and invalid if not confirmed in 1H. (Needless to say, they had problems recently)
So not only there is volatility risk between invoice issuance and payment, but volatility risk between payment and confirmation. (The later solved by Lightning)

Strictly, the processor doesn't need to know the exchange rate in the confirmed callback since it can just determine invoice state based on BTC amount and timeframes

The POST request to the address source that gives the rate to use, from the exchange, at invoice creation. With the rate being guaranteed under some conditions. So the callback does not really need the rate (Ok actually it makes sense, for making advanced processor rules as you talked about below).

more advanced processor rules such as "accept invoice a paid if fiat amount = +/- 2% of invoice amount even when payment timeframe has elasped"

Just to be sure we talk about the same thing: when you say even when payment timeframe has elasped you mean even if the guarantee rate condition are failing ?

You convinced me callbacks are a good idea after all. I am in holiday now, and taking the plane tomorrow. I will review more closely your PR in the plane. Concept ACK.

Maybe your callbacks make my 'guarantee rate conditions' useless.

[natefriedman]

Just to be sure we talk about the same thing: when you say even when payment timeframe has elasped you mean even if the guarantee rate condition are failing ?

Partially yes. My thinking was "rate conditions" could be put in place by either the exchange (as a guarantee) or the processor. If the exchange doesn't guarantee rates

You convinced me callbacks are a good idea after all. I am in holiday now, and taking the plane tomorrow. I will review more closely your PR in the plane. Concept ACK.

Maybe your callbacks make my 'guarantee rate conditions' useless.

It's important for the processor to know whether the Address Source provides a guaranteed rate and what the conditions are so the right information can be displayed to the customer. If the conditions are fixed, they can be entered when the processor is setup.

Is there value in giving the exchanges more flexibility in what they quote? Would an exchange change their guarantee conditions based on mempool backlog? If so then it would make sense to include the guarantee conditions in the API.

I'll update the PR to include the second callback. Let me know what you think and how else I can help.