See here about serverless. It is a very common industry term that does not mean there is no server.

mdk wraps ldk to make it able to run on a serverless platform. Underneath, your node is spinning up and down as needed and expected by this model. When you create a checkout your node creates an invoice. The keys are to your node.

None of this is exposed to the user, as we're optimizing for people who could care less about the technical detail and want payments. But it is important to me that the bitcoin community understands there's no funny business under the hood. You can go look at the code for our libraries if you want.

Hm I get the feeling nothing will be completely satisfying here.

Your node creates the invoice, we do take a fee on the last hop, but we only get paid if you get paid.

We don't use a wrapped invoice, but even those are trustless as the provider is not able to collect any fees if the payment doesn't make it to you.

Hey thanks for giving it a try!

Local testing is on our list for near term priorities, for a v1 we're thinking we'll add a button to mock the webhook so you can be sure everything else is set up right before you deploy.

We're working through multiple websites / locations as well. Your example with local / deployed should be fine. The state for the node is stored encrypted in remotely in VSS linked to your seed, so where the node spins up does not matter so much.

I'm a mechanical engineer by trade and did consumer product design for the first 10 years of my life. That's what brought me to Block, I helped with the Square Terminal, and did early prototyping for what became the handheld.

But I'm a class of 2013 Bitcoiner and alongside my product design career I was always running nodes, miners, and on Bitcoin twitter.

At Block, I managed to get on the early Bitkey team, and at the time was also going deep on lightning. While we were designing and building Bitkey prototypes I was pitching for c= within Block, and the rest is history.

I would call my time at Block my first founding story, because we started c= from scratch, albeit with a bit more funding and support than most startups.

My father was an entrepreneur, so let's say the suggestion to start a company was always there :)

:)

The node and keys are in your (serverless, typically) infrastructure and control. No trustody, it's all you.

I think people who know to search for lightning bitcoin payments right now have better concepts of on-chain than lightning.

But I think most people don't even know what on-chain is :)

I agree that most people just want payments to just work for them.

The scale of real payments on the lightning network. It took us by surprise (in a good way).

There's some differences. Technically, with mdk the node and keys are on your infrastructure, not ours.

We spent a lot of time focusing on the developer experience for mdk. When a developer thinks "I want to add payments" the products they pick up are very full featured. They don't just get the credit card network send / receive API, they get a lot handled for them. To me this is the biggest difference, you don't need to know anything about Bitcoin to get a checkout page and get paid.

We spent a lot of time thinking through "Payouts" from mdk as having an easy way for us to let someone get money out of mdk using our dashboard while staying self-custodial was a bit of a puzzle :)

Exposing a send API for a more advanced users to use in their app actually shouldn't be too hard. It just wasn't our focus at first.

Exactly the sort of thing we've set up mdk for. If you're on something like vercel / netlify, you'd be able to do it today, just ask your agent to add payments using moneydevkit. If you used Replit, we have something coming for you soon :)

Feel free to jump into our discord and ask questions if you need help working through it!

Our main customers are not served well by traditional payments, and moreover are not super Bitcoiners into running their own nodes. Compared to the options these people realistically have access to, 2% is 50 - 70% off their next best option.

Our first use case is easy to add payments for AI assisted devs / vibe coders.

But the way we've packaged LDK, we can fit it into a lot of use cases. POS could be cool :)

Definitely something we want to look into 👀

It's a little different!

Instead of needing to run / self-host, you can just include the moneydevkit library into your project and deploy from there. Most of our examples just have us asking the AI that's helping to build the website "hey add payments with moneydevkit"

moneydevkit is self-custodial, and the node / keys live on the same infrastructure your website is deployed to, but you don't need to really think about the node really. You can just treat it like another dependency to add to your web app.

With moneydevkit, you can easily pay out to Blink or any other wallet / exchange that supports LNURL or Bolt12.

It's funny because we've had a few devs in the Bitcoin community scoff at the term "serverless" :)

Serverless does not mean there are no servers! Mainly, it means that the developer doesn't have to think about the servers. The service provider handles it all for them, and typically they're also actively spinning up and down the functions a developer deploys on an on demand basis, which is very cheap for them.

Vercel and Netlify are the platforms we're thinking about when we're talking about serverless. They let you link your code via github and deploy for free very quickly, no setup or monthly fees. In the background they're spinning up and down your functions on demand.

With mdk, we've shoehorned LDK into a package that can deploy natively on these platforms. This means you get all the benefits of running a self-custodial lightning node without the cost / complexity of hosting one yourself. It's free to start and scales easily with your application.