This is the third article in our "Building Recurring Payments in Public" series.

Rules are easy to understand in theory, but real-life scenarios show how they actually work.

In Part 2, we explained the rules that shape recurring payments, like amount limits, retry schedules, and how cancellations work. Today, we’ll look at real examples to show how these rules come together. Each scenario is based on real situations and helped guide our design.

The Happy Path

Let's begin with a situation where everything works as expected.

Devin is a creator who's published a terms record offering $10/month support. Nick wants to subscribe. On October 10th, Nick creates a recurring payment that references Devin's terms.

Here's what happens:

  • The system validates that Devin's terms exist and Nick's reference matches the current CID

  • Nick's card is charged $10

  • Three records are created: a supporter record in Nick's repository, a supporter proof in Devin's repository, and a broker proof in ours

  • Nick's next billing date is set to November 10th

On November 10th, the daily billing job finds Nick's payment, charges another $10, and updates the next billing date to December 10th. This continues until someone cancels.

The important detail is that billing happens on the same date each month, based on when Nick first subscribed. This date is specific to his support for Devin. Nick always knows when he'll be charged, and Devin knows the support is up to date until the next billing date.

Multiple Creators, Independent Relationships

Nick decides to support Rob too, starting at $5 per month on October 15th. He uses a different card for this payment.

Now Nick has two recurring payments:

  • Devin: $10/month on Personal Visa, bills on the 10th

  • Rob: $5/month on Business Amex, bills on the 15th

These payments are completely separate. They have different amounts, use different cards, and have different billing dates. On October 10th, Nick's Visa is charged $10. On October 15th, his Amex is charged $5.

Why is this important? On November 10th, Nick's Visa is declined. He might have reached his spending limit or the card may have expired. The payment to Devin does not go through.

But on November 15th, Nick's Amex charge to Rob succeeds without issue. Rob's support continues uninterrupted. Each relationship stands on its own.

We chose this approach because it means more individual charges and more Stripe fees, but it also gives us better isolation and resilience.

Payment Failure and Recovery

Let's return to Nick's failed payment to Devin on November 10th. The card was declined, so the retry system starts working.

The system enters retry mode:

  • November 11th (Day 1): First retry. Still declined.

  • November 13th (Day 3): Second retry. Still declined.

  • November 17th (Day 7): Third retry. This time, Nick's card is accepted and the payment goes through.

What changed? Nick might have paid off his balance or a temporary hold was removed. Whatever the reason, the payment finally worked, so Nick's support for Devin continues. The next billing date is now December 10th.

We have a retry schedule because cards often fail for temporary reasons. By giving payments several chances to go through, we reduce interruptions and make sure fewer fans need to re-subscribe after a problem.

When All Retries Fail

Sometimes the card keeps failing.

Same scenario, but this time every retry fails. November 11th, 13th, and 17th all decline. Now what?

There’s a 24-hour grace period. On November 18th (Day 8), if the payment remains unpaid, the system takes action:

  • The recurring payment status changes to "canceled"

  • The broker proof record is updated to include "active": false

  • The record's CID changes, breaking the link to what we stored

That last point is important. The attestation is now broken on purpose. Anyone checking Nick's support for Devin will see that the relationship has ended. The proof was accurate when it was made, and now it clearly shows the support is over.

The verification chain stays truthful. When support ends, the proof says so.

Cancellation During Retry

Here's a more subtle situation. Nick's payment to Devin failed on November 10th and entered retry status. But on November 12th, before the second retry, Nick decides to cancel.

What happens?

The cancellation is immediate. Nick is removed from the retry queue. No more attempts, no more charges. The broker proof is marked inactive.

Why is the cancellation immediate? Because Nick clearly said he wants to stop paying. The retry system is only for fixing card issues. If someone wants to leave, they can leave right away. What the user wants is more important than retrying payments.

Payment Method Update During Retry

Different scenario: Nick’s payment failed, but instead of cancelling, he updates the payment method for that specific charge.

The system tries to charge the new card right away for the specific recurring payment. If it works, Nick's support continues and he gets instant confirmation. If it fails, Nick finds out immediately and can try another card or stop trying.

This quick feedback helps fans fix payment problems faster. It would be frustrating to wait days for the next retry after adding a new card that works.

Quarterly Billing and Retries

Nick supports another creator, Sam, at $10/month billed quarterly. That's a $30 charge every three months.

On January 10th, the quarterly charge fails. The retry schedule kicks in: January 11th, 13th, 17th.

Here's the key point: every retry tries to charge the full $30. The billing period runs from January 10th to April 9th. It's one period, one charge, all or nothing.

This keeps billing periods clean. The attestation says Nick supports Sam at $10/month billed quarterly. The retry amount matches the original charge, and the proof stays accurate.

Creator Account Terminated

One more scenario: what happens when a creator's account is terminated?

Nick has supported Devin for months. Then Devin chooses a different broker with better rates for his preferred currency. Devin closes his ATProtoFans account in the middle of a billing cycle.

At Nick's next billing date, the system sees Devin's account is gone. Instead of attempting a charge, it treats the situation like Nick cancelled:

  • No charge is attempted

  • The broker proof is marked inactive

  • Nick's recurring payment ends

We do not issue refunds for past payments. The support relationship was real, the records were made, and the money was paid out. Our part of the transaction is complete. Past support stays valid no matter what happens to the creator's account later.

Nick can resume support through the brokers that Devin is using, under the terms that Devin sets.

Why Scenarios Matter

These situations have shaped our design from the beginning. Every payment system faces the same questions: What happens if a card fails? What if a user cancels in the middle of a cycle? What if an account disappears? The answers show what the system truly values.

We focus on honesty (attestations match reality), user intent (cancellation really means cancellation), and resilience (each relationship is independent). It's up to you to decide if these are the right trade-offs, but now you can see how they work in practice.

In Part 4, we’ll take a step back and look at the overall system architecture. We'll explain what "locked open" means and why anyone can become a broker.