SolutionsA media group
Your biggest churn reason is a card that failed
Payment failure can be the largest reason subscribers leave, and the wall usually learns of it after the reader does.
- Access during dunning
- Keep access
- Access continues through your provider's retry schedule.
- Access during pause
- Suspend
- No access now; the term end is unchanged.
When your provider saysAccess does
Renewal paidExtended to the new period end
Invoice past dueKept by default, or suspended
Subscription pausedSuspended by default, or runs to period end
Invoice paid againResumed
Ended earlyEnded · reason kept: refund, chargeback, non-payment
Ended on its dateRuns out on that date
The situation
What is going wrong
The person paying you most is the person you are most in the way of, and each fix is a ticket that changes no rule.
The lapse arrives as a wall
The card expires, the retry fails, and the first the reader hears of it is a paywall on an article they paid for. By then the renewal is a win-back.
Billing knows, the paywall does not
The billing system holds the failed payment and the paywall holds its own copy of the reader, reconciled on a schedule, so the warning that could have gone out on site goes nowhere.
Grace is a support ticket
Whether a reader in retry keeps reading is decided case by case, by whoever answers the ticket, rather than once, as a setting.
What changes
When the renewal and the wall read one record
EdgeKit Subscriptions
Access follows the renewal
A renewal moves the expiry forward on the same record the wall reads, with no reconciliation step. When a payment fails, whether the reader keeps reading through the retries or loses access now is a setting you choose once, for every title. Today this holds for subscriptions bought through EdgeKit checkout; the subscribers you already have keep reading through the sign-in you run now.
- A renewal only ever moves the end date forward
- Access during retries: keep or suspend, one setting for every title
- Every change to access is a dated row naming where it came from
- Provider
- Recurly
- Sold as
- Individual
- Access to
- 3 Mar 2027
- StartedEdgeKit checkoutBought Digital Annual on an article page
- ExtendedRecurlyRenewal paid · access to 3 Mar 2027
- SuspendedRecurlySubscription paused · reason: pause · term end unchanged
- ResumedRecurlyPause ended · access to 3 Mar 2027
Written from the provider's own events
EdgeKit Paywall
A message before the lapse
A rule can read how many days of access remain and show that reader a message on the page, in your words, before the lapse rather than a wall after it. Your revenue team writes it and publishes it; nothing waits for a release.
- Days of access remaining is a fact any rule can read
- The message is yours, and the rule is live 60 seconds after you publish
- The version before is one publish away
Access · computed by EdgeKit
- Access
- Paid
- Products
- Markets Pro
- Titles they can read
- 2 of 3
- Access ends in
- 41 days
- Lapsed
- Never
On this title
- Joined
- 19 Sep 2025
- Joined through
- Newsletter
- Newsletters
- Morning Brief · Markets Close
Answered at sign-up
- Industry
- Financial services
- Job level
- Director
- Interests
- Markets · Policy
Your fields
- account_type
- Individual
- seniority
- Senior
EdgeKit Analytics
Churn with the reading beside it
A reader’s reads land on the same record as their subscription, so the one who stopped reading weeks before the card failed shows up as one person, not as a billing export matched against an analytics export. Every read is also loaded into a warehouse table of your own, carrying the reader id the subscription is held under.
- Every read, wall and sign-up as a first-party event on your domain
- How recently and how often each signed-in reader reads, kept on the record
- Loaded into a warehouse table you query yourself; the decline itself stays with your processor
select * from edgekit.events limit 5
5 rows · 2 titles · one table
EdgeKit Profile
The win-back knows what they held
A lapsed reader keeps their record: what they held, when it ended, how they joined. The win-back is a rule on that record, so a lapsed subscriber meets a different offer on the page from a registrant who never paid. The lapse stays on the record, in a database you own; your marketing platform receives the reader’s events, not the lapse, so the win-back email is a list you draw from the record rather than a journey EdgeKit starts.
- Lapsed, never paid and active are different readers to a rule
- What they last held and when is on the record
- The record is yours to export; the lapse does not reach your marketing platform yet
- Access today
- Registered
- Last held · your field
- All Access
- Lapsed on
- 14 Aug 2026
- Joined through
- Newsletter
- Access today
- Registered
- Last held · your field
- Nothing yet
- Lapsed on
- Never
- Joined through
- Sign-up
Same access today. Different history.
How it goes live
Four steps to a first rule live beside your current paywall
White-glove onboarding: we set it up with you, start to finish.
- 01
Lay out who holds what today
Bring your processor’s retry schedule and whoever owns renewals. We go line by line through which system holds the card, the retry and the access today, and which of your vendor contracts comes up first.
- 02
Connect the processor you already run
Recurly and Stripe are read into EdgeKit today and kept current by webhook. Checkout, which is what puts a subscription on the record the wall reads, runs on Recurly today; Stripe checkout is not built yet. Any other processor is wired by EdgeKit, at no charge, inside the migration.
- 03
Set the retry policy and write the first rule
Keep or suspend access during retries, one setting across your titles. Then the first rule: who sees the message before the lapse, and what it says.
- 04
Move one title
The old wall is switched off rather than deleted, so switching back is a setting. The next title moves when its team is ready.