I've seen lots mentioning the lightning network, but I can't see the debit part of it. Lightning transactions aren't debit; they're cash like.
OP, is an electronic peer-to-peer debit system what you're asking? Where debt is expressed in bitcoin, but you're the one who acts as bank? I think this can assist you: https://liquid.net/. Otherwise, you have to setup a bank-like business.
Topic: Direct debit for Bitcoin network (doable?) (Read 144 times)
All I am asking a perfect replica of direct debit system for Bitcoin.
No. You want to apply something that works for frogs also work for pigeons (just pigeons, while they fly very good, they don't swim).
Direct debit is based on third party that may be legally answering for your money (banks, VISA, ..). So if something goes wrong, you can file a complaint and may get reimbursed.
Doing this for Bitcoin will probably have no correct basis because the third party handling the direct debit may as well just steal all the money from your address (or wallet, depending on settings) and it will be your fault for giving your private key (or wallet seed) to unknown that ahs no legal binding to take care of your money.
After you understand this, there may be a better basis for a proper discussion.
All I am asking a perfect replica of direct debit system for Bitcoin. Set up direct debits for
Home rent
Salary payment
Subscription
Donation
There are so many use of direct debit and we all know how it save time and hassle to remind payer all the time.
Home rent
Salary payment
Subscription
Donation
There are so many use of direct debit and we all know how it save time and hassle to remind payer all the time.
I did not understand many details, but in a simple concept, where will you put your trust? If the customer will trust his money to a third party, anything can be built centrally so that the customer deposits a site, and then anything applicable to traditional payment systems can be done, but if you want something decentralized Or based on the network, so Lightning Network or Ethereum is more appropriate for what you want to do.
Perhaps if the idea is well explained, the frequency of payments, and whether the existing systems mentioned here[1] fail in that, then why can we reach this is possible programmatically and you only need a developer, or is it better to move to the Lightning Network and Ethereum.
[1] https://github.com/alexk111/awesome-bitcoin-payment-processors
Perhaps if the idea is well explained, the frequency of payments, and whether the existing systems mentioned here[1] fail in that, then why can we reach this is possible programmatically and you only need a developer, or is it better to move to the Lightning Network and Ethereum.
[1] https://github.com/alexk111/awesome-bitcoin-payment-processors
IMO it would be easier to setup regular bitcoin payments compared to building a debit system like this. Because no matter how good a system is built, there will be loopholes that can be used by hackers to break into the system and make payments that are not approved by the client. Between the owner and the customer can make a payment agreement according to the bitcoin rate at the time the bill is made, but it is possible that the payment in BTC will be slightly higher than the usual payment, because the rate is changing, and that is to avoid losses from the owner's side.
Is this very hard?
No, it's not. I think that, by far, it's not a difficulty issue. Just read about the huge number of people getting their coins stolen in the second they receive them. This means that scammers do have pretty much similar tools (actually what you need may be even simpler).
But I see it as a security issue. A software running on a whatever system will need access to the private key of that address of mine. I don't like that; I would not allow that with a wallet I have money on.
I know that many companies authorize agencies to make payments on their behalf, talking about fiat accounts. And trust and access to money are somehow not questioned here, the problem here is the high degree of anonymity of bitcoin transactions and in the case of "happening" it is difficult to determine whether it is embezzlement or just a hack.
The best prevention is certainly not to give private keys to anyone.
I guess the question is why they would want to. I could be looking at this a different way but more and more I see people / businesses want to initiate payments to people so if I do have a recurring payment to you I either have to go into my banks website and send a payment to you or go to your site and have you pull it from my account.
There are ways to do what you want as others have said, but I can see it leading to headaches as people change wallet addresses or want to pay in fiat since BTC is up or down or some other reason. It's probably easier / better IMO to just setup a regular payment gateway like BTC pay and have people pay you.
-Dave
There are ways to do what you want as others have said, but I can see it leading to headaches as people change wallet addresses or want to pay in fiat since BTC is up or down or some other reason. It's probably easier / better IMO to just setup a regular payment gateway like BTC pay and have people pay you.
-Dave
Without using any timelocks (and thus unnecessarily locking up money), I believe a solution for this can be made on a per-wallet basis.
It would work something like this:
The wallet records an address to send recurring payments to (it must be the same address).
Then, after you send the first transaction to the wallet, the wallet creates a second transaction automatically, assuming the requisite funds are available beforehand. It does not sign the transaction by itself.
At any time you go to the recurring payments screen, you will see a list of addresses together with a description. The description would come from a QR code or the bitcoin: payment URI. You will be prompted to sign any transaction which you want paid in the next billing cycle, which requires a manual password prompt.
These are stored unencrypted (as they can't be modified by hackers), and can be broadcasted at the appropriate time assuming that the wallet is always online. If not, then it could be broadcasted earlier, but then the payment gateway will have to record these advance payments accordingly.
It would work something like this:
The wallet records an address to send recurring payments to (it must be the same address).
Then, after you send the first transaction to the wallet, the wallet creates a second transaction automatically, assuming the requisite funds are available beforehand. It does not sign the transaction by itself.
At any time you go to the recurring payments screen, you will see a list of addresses together with a description. The description would come from a QR code or the bitcoin: payment URI. You will be prompted to sign any transaction which you want paid in the next billing cycle, which requires a manual password prompt.
These are stored unencrypted (as they can't be modified by hackers), and can be broadcasted at the appropriate time assuming that the wallet is always online. If not, then it could be broadcasted earlier, but then the payment gateway will have to record these advance payments accordingly.
Is this very hard?
No, it's not. I think that, by far, it's not a difficulty issue. Just read about the huge number of people getting their coins stolen in the second they receive them. This means that scammers do have pretty much similar tools (actually what you need may be even simpler).
But I see it as a security issue. A software running on a whatever system will need access to the private key of that address of mine. I don't like that; I would not allow that with a wallet I have money on.
I believe there might be some implementations using lightning network
They probably use some type of time lock transactions
https://support.coincorner.com/hc/en-us/articles/5785088860956-Recurring-Lightning-payments
A friend told me he also saw something similar in trust nodes, but I don't know how it works.
Is this very hard?
No, it's not. I think that, by far, it's not a difficulty issue. Just read about the huge number of people getting their coins stolen in the second they receive them. This means that scammers do have pretty much similar tools (actually what you need may be even simpler).
But I see it as a security issue. A software running on a whatever system will need access to the private key of that address of mine. I don't like that; I would not allow that with a wallet I have money on.
Agencies need recurring payments, not just agencies but in any business recurring payments is a system that removes a huge headache for accounting department.
I don't think there are much to talk about direct debits.
In Bitcoin I don't find anything yet to fulfill the demand. Is it not doable?
I run an agency and have clients around the world. One of the many reasons I can not use crypto in our payment systems is not having a good system for recurring payments from the clients.
It should be simple.
Client and we agreed in a signed contract
Client will have a wallet where he will have balance always
We will have a dedicated address to receive the amount we are in contact with the client.
An exchange rate will be determined based on the current market rate and we can use any api for it.
If the client wallet does not have enough coins they will be notified. X times failed to pay means at some point the contract will terminate.
To terminate the contract when client and we agree then both party again sign a contract that will unlink the client wallet.
Is this very hard?
Thank you.
I don't think there are much to talk about direct debits.
In Bitcoin I don't find anything yet to fulfill the demand. Is it not doable?
I run an agency and have clients around the world. One of the many reasons I can not use crypto in our payment systems is not having a good system for recurring payments from the clients.
It should be simple.
Client and we agreed in a signed contract
Client will have a wallet where he will have balance always
We will have a dedicated address to receive the amount we are in contact with the client.
An exchange rate will be determined based on the current market rate and we can use any api for it.
If the client wallet does not have enough coins they will be notified. X times failed to pay means at some point the contract will terminate.
To terminate the contract when client and we agree then both party again sign a contract that will unlink the client wallet.
Is this very hard?
Thank you.
Jump to: