attested.network
this repo has no description
attested.network/
1<!DOCTYPE html>
2<html lang="en">
3<head>
4 <meta charset="UTF-8">
5 <meta name="viewport" content="width=device-width, initial-scale=1.0">
6 <title>Recipients — attested.network</title>
7 <meta name="description" content="Guide for setting up your identity to accept attested payments on ATProtocol.">
8 <link rel="preconnect" href="https://fonts.googleapis.com">
9 <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
10 <link href="https://fonts.googleapis.com/css2?family=Inter:wght@400;500;600;700&family=JetBrains+Mono:wght@400;500&display=swap" rel="stylesheet">
11 <link rel="icon" type="image/svg+xml" href="logo.svg">
12 <link rel="stylesheet" href="styles.css">
13 <script type="module">
14 import mermaid from 'https://cdn.jsdelivr.net/npm/mermaid@11/dist/mermaid.esm.min.mjs';
15 mermaid.initialize({
16 startOnLoad: true,
17 theme: 'base',
18 themeVariables: {
19 primaryColor: '#f5f3ff',
20 primaryTextColor: '#111827',
21 primaryBorderColor: '#ddd6fe',
22 secondaryColor: '#f8f9fb',
23 tertiaryColor: '#ffffff',
24 lineColor: '#8b5cf6',
25 textColor: '#111827',
26 mainBkg: '#f5f3ff',
27 nodeBorder: '#ddd6fe',
28 clusterBkg: '#faf9fc',
29 clusterBorder: '#e5e7eb',
30 fontFamily: 'Inter, -apple-system, system-ui, sans-serif',
31 fontSize: '13px'
32 }
33 });
34 </script>
35</head>
36<body>
37
38<div class="draft-banner">
39 <p><strong>Draft — Not yet published.</strong> This specification is in active development and is not ready for review or critique. Stay tuned for formal announcements.</p>
40</div>
41
42<div class="topnav">
43 <div class="topnav-inner">
44 <a class="topnav-logo" href="/"><img src="logo.svg" alt="" class="topnav-logo-img"><span><span>attested</span>.network</span></a>
45 <nav>
46 <ul class="topnav-links">
47 <li><a href="index.html">Spec</a></li>
48 <li><a href="brokers.html">Brokers</a></li>
49 <li><a href="app-developers.html">App Developers</a></li>
50 <li><a href="recipients.html" class="active">Recipients</a></li>
51 <li><a href="payers.html">Payers</a></li>
52 <li><a href="scenarios.html">Scenarios</a></li>
53 </ul>
54 </nav>
55 </div>
56</div>
57
58<div class="hero-sm">
59 <div class="hero-inner">
60 <div class="breadcrumb"><a href="index.html">Home</a> / Recipients</div>
61 <h1>Receiving <span>Payments</span></h1>
62 <p class="subtitle">Set up your identity to accept attested payments from supporters.</p>
63 </div>
64</div>
65
66<main class="container">
67
68 <!-- How It Works -->
69 <section id="how-it-works">
70 <h2>How It Works</h2>
71 <p class="section-desc">When someone supports you through an attested payment, three things happen simultaneously—creating a verifiable record that no single party controls.</p>
72
73 <p>A <strong>payment record</strong> is written to your supporter’s repository, declaring that they made a payment. A <strong>proof record</strong> is written to your repository (by the broker acting on your behalf), confirming you received it. And the <strong>broker writes their own proof</strong> to their repository, witnessing the exchange.</p>
74
75 <p>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.</p>
76
77 <div class="mermaid-wrapper">
78 <pre class="mermaid">
79graph LR
80 S["Supporter pays"] --> PAY["Payment Record<br/><i>Supporter's repo</i>"]
81 PAY --> CP["Proof<br/><i>Your repo</i>"]
82 PAY --> BP["Proof<br/><i>Broker's repo</i>"]
83 </pre>
84 </div>
85
86 <div class="callout">
87 <p><strong>Why three records?</strong> 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.</p>
88 </div>
89 </section>
90
91 <!-- Choosing Payment Servicers -->
92 <section id="choosing-servicers">
93 <h2>Choosing Payment Servicers</h2>
94 <p class="section-desc">You signal which payment servicers (brokers) you use by publishing an ordered list in your DID document.</p>
95
96 <p>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 <code>#AttestedNetwork</code> service endpoint. The order matters: it represents your preference ranking, so apps know which servicer to try first.</p>
97
98 <p>You can use <strong>multiple brokers simultaneously</strong>. 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.</p>
99
100 <p>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.</p>
101
102 <p>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.</p>
103
104 <div class="callout">
105 <p><strong>No lock-in.</strong> 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.</p>
106 </div>
107 </section>
108
109 <!-- Setting Up -->
110 <section id="setting-up">
111 <h2>Setting Up</h2>
112 <p class="section-desc">Getting started takes three steps. Your chosen servicer handles everything else.</p>
113
114 <ol class="steps">
115 <li><strong>Choose one or more payment servicers (brokers).</strong> Browse available brokers and pick the ones that support the payment methods your audience uses. You can start with one and add more later.</li>
116 <li><strong>Add their DIDs to your DID document.</strong> Publish an ordered list of broker DIDs, each referencing their <code>#AttestedNetwork</code> service endpoint. The order signals your preference—apps will try brokers in the order you list them.</li>
117 <li><strong>Configure your products or tiers with each servicer.</strong> 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.</li>
118 </ol>
119
120 <p>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.</p>
121 </section>
122
123 <!-- What Happens When Someone Pays -->
124 <section id="payment-flow">
125 <h2>What Happens When Someone Pays</h2>
126 <p class="section-desc">Here’s what the flow looks like from your perspective when a supporter decides to pay you.</p>
127
128 <div class="mermaid-wrapper">
129 <pre class="mermaid">
130sequenceDiagram
131 participant App as Supporter's App
132 participant DID as Your DID Document
133 participant Svc as Payment Servicer
134 participant SR as Supporter's Repo
135 participant YR as Your Repo
136 participant BR as Broker's Repo
137
138 App->>DID: Resolve your DID document
139 DID-->>App: Return servicer list
140 App->>Svc: Initiate payment with preferred servicer
141 Svc->>Svc: Process payment
142 Svc->>SR: Write payment record
143 Svc->>YR: Write proof to your repo
144 Svc->>BR: Write proof to broker's repo
145 Note over SR,BR: All three records are now verifiable by any app
146 </pre>
147 </div>
148
149 <p>The key thing to notice is that <strong>you don’t have to do anything</strong> 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.</p>
150 </section>
151
152 <!-- Payment Types -->
153 <section id="payment-types">
154 <h2>Payment Types</h2>
155 <p class="section-desc">Attested payments support three types, each suited to different creator needs.</p>
156
157 <div class="card-grid">
158 <div class="card">
159 <h4>One-time</h4>
160 <p>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.</p>
161 </div>
162 <div class="card">
163 <h4>Recurring</h4>
164 <p>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.</p>
165 </div>
166 <div class="card">
167 <h4>Scheduled</h4>
168 <p>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.</p>
169 </div>
170 </div>
171 </section>
172
173 <!-- Portability -->
174 <section id="portability">
175 <h2>Portability</h2>
176 <p class="section-desc">Your supporter relationships belong to you and your supporters—not to any platform.</p>
177
178 <p>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.</p>
179
180 <p>If you <strong>switch apps</strong>, your new app can read the same records and display your supporters immediately. If you <strong>change servicers</strong>, 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.</p>
181
182 <p>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.</p>
183
184 <div class="callout">
185 <p><strong>Built on open infrastructure.</strong> Attested payments use <a href="https://badge.blue">badge.blue</a> attestations and <a href="https://atproto.com">ATProtocol</a> repositories. Every record is content-addressed and cryptographically bound to its repository—portable, verifiable, and owned by the people who created them.</p>
186 </div>
187 </section>
188
189</main>
190
191<footer>
192 <div class="container">
193 <p>attested.network · Built on <a href="https://badge.blue">badge.blue</a> attestations · <a href="https://atproto.com">ATProtocol</a></p>
194 </div>
195</footer>
196</body>
197</html>