Is there anyone solving the problem of inability to collect recurring payments using Bitcoin?

[tkembo]

I've never really seen this as a problem until today. I wanted to buy a subscription for a service being offered by a Bitcoin start and then I realised that the only way payment option they have is Credit/Debit Card. After I asked if I can pay using Bitcoin, they said that they only collect payments via Credit/Debit Card . They went on to say that they don't collect Bitcoin payments because they couldn't collect recurring payments with Bitcoin. Has anyone solved this problem? Is anyone solving this problem?

[coinableS]

Bitcoin is a push only system. Only you can send a payment, and this is not a problem of bitcoin but rather a feature. Subscription services are some of the top scams in the credit/debit card space. If you give your card details to a merchant they can pull money whenever they like. It's a one sided trust system where you give all your trust to the merchant. When a consumer wants to cancel the merchant makes it as difficult as possible and also includes cancellation fees. With bitcoin this cannot happen, and personally I think this is a better way to offer subscription services for consumers. The services are now forced to provide better quality content in order to keep the user to choose to keep paying the subscription.

[taras]

https://developers.coinbase.com/docs/me ... g-payments

Also I think its even possible to implement 12 bitcoin transactions, which will be valid in different time. You could define a new OP that would allow one to redeem coins only after a certain amount of time, but then you'd be paying the full amount up front anyway.

[arnoudk]

A "solution" for this would be to build a layer on top of bitcoin, where the merchant can request a payment at a specified date. A wallet provider could "find" all these payment requests from all merchants that you have recurring payments with (you could e.g. send them through the bitmessage protocol that the wallet listens to, which maintains the p2p non centralized criteria). The wallet would display them, and you could get a notification. You would then be able to select the payments you wanted to make, and sign. The provider could send the payment request a long time in advance, ie it could send all the requests for a year subscription immediately, and you decide when to sign. The wallet could structure the payment in such a way that it would not be possible to collect the payment before time X or block Y (locktime). This means you can cancel the payment by double spending the input transactions, but at time X or block Y the payment would be included in the block. The signed, time locked, transaction could be sent to the merchant using the bitmessage protocol - as you cannot send transactions where the locktime has not yet passed onto the bitcoin network. (Or directly, but I prefer solutions without direct contact between seller and customer as a design criteria - you could always make something less secure, but it is hard to make something more secure).

I don't know if anyone is working on this. The main wallet providers could get together to look into this. It would work best if this approach was open and standard, and that it did not matter what wallet software was used.

This would be my idea, so it would be possible - just not an exact copy of the debit/creditcard system (thankfully!)

[harrymmmm]

When you sign up, you prolly give an email address (even if it's a onetime, throwaway thing), so the email is not usually a privacy concern. Then payment requests can be used as you described (multiple requests) over email more easily than bitmessage.

Click on the payment request for this month in the email, wallet opens with payment info autofilled, send...

'Course bitmessage is better if you're worried about law enforcement, hackers, etc, since they can subpoena/steal your email and/or login IP addresses if they target you.

[CryptAxe]

I already have recurring payments on hosterbox with bitcoin!

[kingscrown]

doesnt seem doable at this moment - which is also a plus for BTC

[SamouraiDev]

A 1-1 payment channel via BIP47 could be imagined between a customer and a merchant. Such a layer could be developed by wallet providers. The customer (spender) must remain in control however and always have the possibility of confirming or canceling a payment. One nice feature of this is that the merchant would have an easy way to provide refunds if such were ever necessary.