-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Exchange notifies processor of payments #1
base: master
Are you sure you want to change the base?
Conversation
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.
Exchange notifies processor of payments
@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 ? |
@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:
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:
|
Just some background about the different states of BTCPay/Bitpay:
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)
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.
Just to be sure we talk about the same thing: when you say 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. |
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
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. |
Mention BIP 44 as the Multi-Account standard
[DRAFT] Modern Hierarchy for Deterministic Multisignature Wallets
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.