AtmosphereConf was an incredible experience. The people, talks, and energy were everything I hoped they’d be. The days since have been harder. Some difficult conversations and difficult decisions have come out of the conference, and I’m still processing a lot of it. I don’t want to dwell on that here; it doesn’t feel good. Instead, I want to look back at the work we did at Graze Social and share the parts that feel good. This is one of a series of posts doing that.

I believe payments open up new ways for people to engage on ATProtocol. When individuals, organizations, or even automated systems can use and reference payment proofs, it lets them exchange goods and services on an open protocol that anyone can verify and observe. That was our idea, and we built something to show it works.

What We Built

On atprotofans.com, people can set up Stripe Connect to get payments. Anyone can log in and send a one-time payment to someone who has set this up. The features are basic, but the site got a lot of attention and showed that the ecosystem needs this kind of tool.

Behind the scenes, we built on features that Graze already had. Since we could already set up payout accounts for advertising, adding this new payment feature was pretty straightforward.

We always meant for the name “atprotofans” to be temporary and just for fun. Devin, Andrew, and I knew that from the start. We chose to support only one-time payments at first because this was just an early proof of concept. We had planned to build something more advanced later.

How It Works

The payments themselves aren’t the most interesting part; Stripe handles that. What matters is what happens next: a proof-of-payment record chain gets created. That initial record keeps you in control of this data. If a creator moves to a different service, they keep their followers and payers. If someone who pays switches apps, their purchase history goes with them. This is a big deal and sets us apart from just adding a payment form to a website.

Most of the technical challenges were about coordination. We had to write proof records for both recipients and observers and deal with the tricky situations that come up with asynchronous payment processing. That said, the main implementation was simple.

Teaching users how the process works is a challenge, but I’m not sure most people care about the details. What matters to them is the result: they control their own data, and switching services doesn’t cause any problems.

We made it clear from the start that everything would be public. Since ATProtocol doesn’t support private data yet, we decided to work with that limitation instead of trying to avoid it. Now that spaces and permissioned data are taking shape, the shape and scope of payments can change a little to adapt, but I don’t think by much.

Why It Matters

When you have a proof of payment recorded on the protocol, you can create new kinds of interactions that weren’t possible before. This isn’t about cryptocurrency. It’s just straightforward technology that lets you easily prove one person paid another, without needing to change or add to the protocol.

That proof creates many new possibilities. Payments can be linked to event RSVPs, like tickets, or to specific content, or even to recurring subscriptions. Each payment is a record on the protocol, so it’s portable and verifiable, not stuck on one platform.