Lore Forge is moving away from Gumroad for payments and subscriptions.

Gumroad helped make it possible to sell and support Lore Forge in its early stages, and I’m grateful to everyone who purchased the app or supported its development there. This decision is not about dismissing that support, nor about pretending that moving payment infrastructure is easy.

It is about reliability.

For a subscription-based application, a payment platform is not merely a checkout page. It is part of the system that determines whether someone should have access to the product. That system needs to be predictable, documented, and dependable.

In the summer of 2024, I learned that my Gumroad integration was not dependable enough.

What happened

Lore Forge used Gumroad’s membership-verification API to determine whether a subscriber’s access was still valid.

At some point during summer 2024, Gumroad changed the data returned by the verification response. There was no version change to the endpoint I was using, no advance notice, no deprecation period, and no migration guidance that I received.

The existing Lore Forge integration had been written against the response structure Gumroad returned at the time. Once that structure changed, the app could no longer safely infer that a membership had expired from the old status data alone.

The practical result was serious: memberships that should have failed verification—specifically memberships whose subscription period had elapsed—could still be treated as valid.

The problem was discovered because Lore Forge users noticed something was wrong and contacted me. I’m genuinely grateful to those users. They did not have to report it, but they did, and that gave me the information I needed to investigate, correct the integration, and release an update.

The eventual fix was to explicitly examine the membership timestamps that Gumroad returns under the purchase object:

const hasValidMembership = !res.purchase?.subscription_ended_at &&  !res.purchase?.subscription_failed_at

In other words, access could not be treated as valid if Gumroad reported that the subscription had ended or failed.

That is a sensible condition once you know the response model. The issue is that the existing integration was built around the previous behavior, and the critical change happened without a versioned endpoint, a compatibility period, or a notice to developers relying on it.

Why this matters

An API response is a contract.

When an application depends on an API to decide who receives subscription access, a change in the response structure or the fields required for that decision is not a minor implementation detail. It can affect whether expired members retain access, whether active members are incorrectly blocked, and whether the business can accurately enforce the subscription terms it offers.

Gumroad’s current documentation makes clear that membership enforcement is the creator’s responsibility. Its verification response contains a nested purchase object, and its documentation directs creators to inspect membership lifecycle fields including:

• subscription_ended_at
• subscription_cancelled_at
• subscription_failed_at

Gumroad also notes that it does not automatically enforce license-key access for creators; the creator must decide how to handle the result of the Gumroad verification response.

There is nothing wrong with giving creators responsibility for entitlement checks. But if the platform expects creators to make those checks, the underlying response contract needs to be stable, clearly documented, and carefully versioned when it changes.

I cannot build Lore Forge’s subscription access around an external integration where a backwards-incompatible change can silently alter who passes verification.

Why I’m moving

The immediate issue was fixed. I updated the code, released a new version, and restored correct verification behavior.

But fixing the immediate bug did not resolve the underlying business risk.

Lore Forge is an ongoing application. It has accounts, subscription access, user data, and customers who reasonably expect their billing and access status to be handled accurately. I need control over the systems that determine entitlement, the ability to test changes before they reach users, and a clear audit trail when billing state changes.

That means moving away from a model in which a public third-party verification response is a critical part of access control.

This decision is also about the tradeoff between convenience and long-term ownership. Gumroad remains convenient in important ways: it handles merchant-of-record responsibilities and associated sales-tax collection and remittance. But its current direct-sale fee is 10% plus $0.50 per transaction, with card-processing fees listed separately; marketplace sales through Discover carry a 30% fee. (Source)

Those tradeoffs can make sense for a creator selling downloads or running a small storefront. They make less sense for Lore Forge as a subscription software product that needs durable, tightly controlled account and entitlement management.

Customer experience matters too

The technical verification issue was the clearest reason to reconsider Gumroad, but it was not the only one.

Over time, I received a steady stream of questions from Lore Forge users about managing their subscriptions through Gumroad. People needed help finding where to cancel, update billing information, change a card, understand whether a subscription was still active, or locate the correct Gumroad account in the first place.

Those are normal things for subscribers to need. They should also be simple things to do.

In practice, Gumroad places subscription management behind its own account and purchase flow. A customer may need to find an old purchase receipt, use the “Subscription settings” link from that receipt, or sign into the Gumroad Library using the email address associated with the purchase. From there, they must locate the relevant purchase and open the membership-management controls.

That creates unnecessary friction for a Lore Forge customer.

When someone subscribes to Lore Forge, they naturally expect to manage their subscription through their Lore Forge account. They do not expect to remember whether they created a separate Gumroad account, locate an old receipt, find the correct Gumroad Library login, or learn a second account-management interface just to update a payment method or stop a renewal.

Gumroad does provide ways for a member to cancel, switch tiers, change billing frequency, or update payment details. But those options are accessed through Gumroad’s “Manage membership” experience rather than through the product the person actually subscribes to. To change a card, for example, Gumroad directs customers to open the membership-management page, choose “Use a different card,” and then select “Update membership” to save the change.

That may be acceptable for a one-time digital purchase. For a continuing software subscription, it has created confusion, support requests, and avoidable work for both users and me.

Lore Forge needs subscription management to feel like part of Lore Forge—not like a scavenger hunt through a separate storefront, an old email receipt, and another account system.

Why the migration cannot be fully automatic

There is another practical limitation that makes this migration more difficult than it should be.

Gumroad’s public API provides ways to inspect products, sales, subscribers, and membership status. But it does not provide a documented creator-side API endpoint that lets Lore Forge cancel a customer’s active Gumroad membership on their behalf. The cancellation process remains customer-driven through Gumroad’s membership-management page, receipt link, or Gumroad Library.

That means I cannot responsibly migrate someone’s recurring billing from Gumroad to the new Lore Forge account system with a single automated button.

Instead, the transition will work in three (3) separate steps:

1. An existing customer will create or sign into their new Lore Forge account.
2. They will enter their Gumroad license key to verify their existing purchase and exchange it for an active subscription in the new Lore Forge account system. Prorated, of course.
3. After their new Lore Forge subscription is active, they will need to cancel the old recurring membership directly through Gumroad.

That final step is not ideal, and I want to be completely transparent about it. It places some of the migration work on customers because Gumroad does not give creators a documented way to cancel an individual member’s recurring subscription through the API.

I will make the process as clear and low-friction as I can:

• Lore Forge will verify the Gumroad key before activating the new account subscription.
• The migration flow will clearly tell users when their Lore Forge subscription is active.
• It will provide direct, step-by-step instructions for cancelling the old Gumroad membership.
• It will explain that cancellation stops future Gumroad renewals while preserving access through the remainder of the already-paid Gumroad billing period, where applicable. Gumroad states that cancellation ends future charges while keeping membership access through the end of the current billing cycle.
• It will include support for anyone who cannot locate their receipt, Gumroad Library, account email, or cancellation controls.

I would prefer a migration where the platform could safely end the old recurring agreement after confirming a customer’s successful move to Lore Forge. That is not an option available through Gumroad’s documented API, so the migration has to prioritize consent, clarity, and customer control instead.

What changes next

Lore Forge will transition away from Gumroad for new purchases and subscription management.

Existing Gumroad subscribers will be able to use their Gumroad license key to verify their purchase and activate a subscription in the new Lore Forge account system. Once that new subscription is active, they will need to cancel their old Gumroad membership separately to prevent future Gumroad renewals.

I know that is an extra step, and I do not take that inconvenience lightly. It is necessary because Gumroad does not provide a documented creator-side endpoint for cancelling a customer’s membership through the API; Gumroad instead directs customers to cancel through their receipt, their Gumroad Library, and the “Manage membership” page.

The new system is being designed to remove this kind of confusion going forward. Customers will be able to manage their Lore Forge subscription from their Lore Forge account, including:

• Viewing subscription status and renewal information.
• Updating payment information.
• Cancelling, restarting, or up/downgrading a subscription.
• Managing account access without needing to locate a separate Gumroad account or an old receipt.
• Receiving clearer guidance when billing or subscription status changes.

Before this transition affects anyone, I will publish a complete migration guide with screenshots, exact steps, frequently asked questions, and a support path for customers who need help. No one should be left guessing whether their new subscription is active, whether their old subscription is still renewing, or where they need to go to manage it.

A customer should not have to become an expert in a payment platform’s account system just to manage a subscription to Lore Forge.

A note on Gumroad

This is not an argument that Gumroad is unusable for everyone. It just sucks for most.

For simple digital-product sales, especially where merchant-of-record services and low setup overhead are the priorities, Gumroad may still be a reasonable choice. Its pricing and tax-handling model will be worthwhile for some creators.

But Lore Forge has grown beyond the point where I’m comfortable treating an externally controlled verification endpoint as a core part of subscription access, and with the advent of Stripe's new Managed Payments system, the merchant-of-record and tax concerns are alleviated at a greatly reduced cost than Gumroad's offering.

Still, when the system determining whether a membership is active changes its behavior without a versioned migration path, the responsibility ultimately lands on the product owner—not on the platform and not on the customers. That responsibility is mine, and my response is to ditch the insane service.

Moving away from Gumroad is the right decision for Lore Forge and for the people who trust Lore Forge with their work.

Thank you

Thank you to every person who has supported Lore Forge through Gumroad, and especially to the users who reported the verification issue when they encountered it.

Your messages made it possible to identify and correct the problem quickly. This transition is part of making sure Lore Forge has a more reliable foundation going forward—one that treats subscription access with the same care users put into the worlds, stories, campaigns, and ideas they create here.

Every world begins somewhere.

Maybe it is a name scribbled in a notebook. A city on the far edge of a map. A character whose past refuses to stay in the past. A legend, a conflict, a strange rule of magic, or a question that keeps growing more interesting every time you try to answer it.

Then, almost without permission, the world gets bigger.

There are more people to remember. More places to connect. More histories, timelines, factions, stories, and consequences. The notes multiply. The threads become harder to follow. And the exciting part—making something alive—starts competing with the work of keeping track of it.

Lore Forge was built for that moment.

It is a tool for writers, game masters, and worldbuilders who want to develop worlds that can grow without becoming impossible to navigate. A place to keep the people, places, histories, systems, and stories behind your work connected enough that you can spend more time creating and less time searching through scattered notes.

And this is Lore Forge Dispatches.

What this is

Dispatches is the new home for notes from inside the work: building Lore Forge, building worlds, and learning how creative ideas become useful, connected, durable things.

Here, you can expect writing about:

• Worldbuilding systems, including cultures, history, geography, magic, factions, timelines, and the small details that make a setting feel lived in.
• Writing and tabletop campaign craft: turning background lore into scenes, stories, choices, sessions, and consequences.
• Lore Forge product updates, feature guides, design decisions, experiments, and the occasional honest account of the messy work behind shipping software.
• Creative prompts, examples, reflections, and interesting questions for anyone who enjoys making imaginary places feel real.

This is not intended to be a stream of empty announcements or polished marketing copy. I want it to be useful.

Some dispatches will be practical. Some will be technical. Some will be about creative process. Some will be progress reports from Lore Forge itself. If a post does not help you build something, understand something, or see your own work from a more useful angle, it probably does not belong here.

Why “Dispatches”?

A dispatch is a message sent from the field.

That feels right for Lore Forge.

Worldbuilding is not a neat, linear process. It is an expedition through half-finished maps, unanswered questions, character histories, contradictory notes, and sudden ideas that arrive at the worst possible time. Building a tool for that work is not neat either.

Dispatches will be where I send back what I find: lessons from making Lore Forge, practical ideas worth sharing, and notes from the ongoing effort to make the creative process a little less fragmented.

The goal is not to tell you the one correct way to write a novel, run a campaign, or build a setting. There is no such way.

The goal is to offer useful tools, clearer systems, and better questions—then leave room for you to make the world only you can make.

What’s coming first

The first few Dispatches will focus on two important changes for Lore Forge.

First, I’ll share a transparent look at why Lore Forge is moving away from Gumroad for subscriptions and payments. That change comes from a mix of technical reliability concerns and years of customer friction around billing and subscription management. It is a meaningful transition, and I want to explain it plainly rather than hide it behind a vague announcement.

Second, I’ll be writing about Lore Forge 2.0: what has changed, what is new, and how the next version of Lore Forge is being built to better support expansive worlds and the people creating them.

There will be more to come after that: feature deep dives, worldbuilding notes, writing tools, campaign-preparation ideas, and the occasional glimpse at what is being built next.

Come along

If you are writing a novel, preparing a campaign, developing a setting, or simply carrying a world around in your head, you are welcome here.

Subscribe if you would like these notes delivered when there is something worth sending. Follow along if you want to see Lore Forge evolve. And if there is a worldbuilding problem, writing challenge, or Lore Forge topic you want covered, tell me.

The forge is lit.

Let’s make something that lasts.