Draft — Not yet published. This specification is in active development and is not ready for review or critique. Stay tuned for formal announcements.

Home / Recipients

Receiving Payments

Set up your identity to accept attested payments from supporters.

How It Works

When someone supports you through an attested payment, three things happen simultaneously—creating a verifiable record that no single party controls.

A payment record is written to your supporter’s repository, declaring that they made a payment. A proof record is written to your repository (by the broker acting on your behalf), confirming you received it. And the broker writes their own proof to their repository, witnessing the exchange.

This three-way structure is what makes attested payments powerful. Any application on ATProtocol can look at these three independent records and verify the support relationship—without asking permission from any platform or payment processor.

graph LR
  S["Supporter pays"] --> PAY["Payment Record
Supporter's repo"]
  PAY --> CP["Proof
Your repo"]
  PAY --> BP["Proof
Broker's repo"]

Why three records? If only your supporter had a record, they could fabricate payments. If only you had a record, you could fabricate supporters. The broker’s independent proof ties it all together—and because all three are on ATProtocol, any app can verify the relationship without trusting any single party.

Choosing Payment Servicers

You signal which payment servicers (brokers) you use by publishing an ordered list in your DID document.

Brokers handle the actual payment processing—credit cards, bank transfers, and other payment methods—so you don’t have to. You publish an ordered list of broker DIDs, each referencing their #AttestedNetwork service endpoint. The order matters: it represents your preference ranking, so apps know which servicer to try first.

You can use multiple brokers simultaneously. This gives your supporters options and protects you from relying on a single provider. If one broker goes down or raises fees, your other servicers continue working immediately.

The ecosystem is designed for competition and choice. Brokers can be regional (focused on local payment methods), non-profit (community-run cooperatives), crypto-native (accepting digital currencies), or traditional payment processors. You pick the ones that work for you and your audience.

Your choice of brokers also affects discoverability. Apps can query for payments that have been validated by specific brokers—so using well-known, trusted servicers means your payment proofs are more likely to be recognized and accepted across the ecosystem.

No lock-in. Switching brokers is as simple as updating the list in your DID document. Your existing payment history and proofs remain valid regardless of which servicers you use going forward.

Setting Up

Getting started takes three steps. Your chosen servicer handles everything else.

  1. Choose one or more payment servicers (brokers). Browse available brokers and pick the ones that support the payment methods your audience uses. You can start with one and add more later.
  2. Add their DIDs to your DID document. Publish an ordered list of broker DIDs, each referencing their #AttestedNetwork service endpoint. The order signals your preference—apps will try brokers in the order you list them.
  3. Configure your products or tiers with each servicer. This happens on the servicer’s platform. Set up your pricing, subscription tiers, or tip amounts. The servicer will guide you through their onboarding process.

That’s it. Once your DID document lists your servicers and you’ve configured your offerings, supporters can start paying you through any ATProtocol app that supports attested payments.

What Happens When Someone Pays

Here’s what the flow looks like from your perspective when a supporter decides to pay you.

sequenceDiagram
  participant App as Supporter's App
  participant DID as Your DID Document
  participant Svc as Payment Servicer
  participant SR as Supporter's Repo
  participant YR as Your Repo
  participant BR as Broker's Repo

  App->>DID: Resolve your DID document
  DID-->>App: Return servicer list
  App->>Svc: Initiate payment with preferred servicer
  Svc->>Svc: Process payment
  Svc->>SR: Write payment record
  Svc->>YR: Write proof to your repo
  Svc->>BR: Write proof to broker's repo
  Note over SR,BR: All three records are now verifiable by any app

The key thing to notice is that you don’t have to do anything once you’re set up. The servicer handles the payment, writes the records, and everything is automatically verifiable. You don’t need to be online, run a server, or respond to webhooks.

Payment Types

Attested payments support three types, each suited to different creator needs.

One-time

Single tips, donations, or one-off purchases. A supporter pays once and receives a permanent, verifiable proof of that payment. Great for tipping on individual posts or making a one-time contribution.

Recurring

Ongoing subscriptions that renew automatically—monthly, quarterly, or at any interval you choose. The servicer handles renewals and writes fresh proofs each period. Ideal for ongoing creator support or membership access.

Scheduled

A fixed series of payments with a defined end. For example, six monthly payments to sponsor a project, or four quarterly payments for a course. The total commitment is clear upfront for both you and your supporter.

Portability

Your supporter relationships belong to you and your supporters—not to any platform.

Every payment record and proof lives on ATProtocol, not in a proprietary database. This means your entire payment history—who supports you, when they started, what they’ve contributed—travels with you across the network.

If you switch apps, your new app can read the same records and display your supporters immediately. If you change servicers, your existing payment history remains intact and verifiable. Active subscriptions continue to be honored because the proof records are independent of which servicer processed them.

This is a fundamental departure from traditional platforms where your subscriber list, payment history, and supporter relationships are locked inside a single service. On ATProtocol, those relationships are yours.

Built on open infrastructure. Attested payments use badge.blue attestations and ATProtocol repositories. Every record is content-addressed and cryptographically bound to its repository—portable, verifiable, and owned by the people who created them.