Integrations

Failed renewal visibility for the subscription app you already run

Your subscription app records why each renewal failed, and the good ones keep a dunning report you can open, or email you a periodic performance summary. What none of them bring you is the individual failure and its reason. Moorly isn't a subscription app — it's the layer that watches every renewal in the one you already have, records each failure with its decline reason, and emails you a weekly summary of what failed, what came back, and what it cost. No migration, no theme changes, no touching your checkout.

Appstle Subscriptions

Our first and deepest integration. If you run subscriptions on Appstle, Moorly is built for your store.

Every failed renewal, with its reason

Moorly takes Appstle's failure events and keeps each one as a case with the decline reason attached, then emails you a weekly recovery summary — instead of a status you have to remember to go and read.

Acts through Appstle's own API

Every billing action — retries, reschedules, skips, recovery discounts — is a call to Appstle's official API, so Appstle stays the source of truth. On Appstle, Moorly does not email your subscribers. Reaching a customer needs the subscription app to hand over their contact details, and the Appstle connector has no path for that, so Moorly stops before a message is built. The customer-facing email on an Appstle store is whichever Appstle email you have switched on.

Aware of Appstle's dunning

When a failure says Appstle is going to retry, or carries the time of the next attempt, Moorly stands down and leaves that case to your app — so it does not stack an attempt on one Appstle already has scheduled.

Also works with

Seal Subscriptions

Connect with your Seal API token and Moorly adds merchant-side failure visibility on top of Seal's built-in dunning — a record for you, not just emails for your customer. Moorly reads whatever failure reason Seal records against each billing attempt and routes the failure by that reason. Moorly reads Seal through both its webhooks and a scheduled poll, so a failure is picked up even if a delivery is missed. Seal dunning guide →

Recharge

In active development and still being tested. The connector reads Recharge's API and webhooks, so failure visibility works. Retry-on-demand is not enabled yet — Recharge's charge-process route was refused on the store we tested, and we won't ship it until we know which stores allow it. Join the early-access list and we'll tell you when that changes.

Your subscription app?

Moorly's core is app-agnostic by design — each integration is a thin connector. Running Loop, Recurpay, Bold, Skio, or something else? Tell us what you're on and we'll prioritize by demand.

Every integration follows the same rules

Connect in minutes

Connect the credential your app uses — on Appstle, either the partner connection you approve in your Appstle admin or your own Appstle API key. No code, no theme edits, no checkout changes. If API access isn't available on your Appstle plan, the partner connection is the route.
Start read-only

Moorly's first job is to measure. It records each failed renewal with the kind of failure it was, and adds up what the ones it has already seen cost you — the cases still open, plus the ones that closed this month — before it changes anything.
Act only through your app

When you switch actions on, Moorly works each failure by its reason — always through your subscription app's own API, with every action written to the case it belongs to. Moorly cannot cancel a subscription at all.

Moorly issues no charge outside your subscription app: every write is a call to your app's own API, the same operation you could perform in its admin. The worst case is a missed opportunity, not a broken store.

The same failure, a different answer per decline reason

Whichever subscription app you run, a failed renewal arrives carrying a reason code — and the right response is completely different for each one. A retry recovers a card that simply had no balance on Tuesday. It will never recover a card that expired. Moorly reads the code your app passes through and applies the treatment for the codes its table recognises; a code the table does not carry gets a single conservative retry and no customer email, and the raw code is kept on the case.

Worth retrying

Balance and timing problems clear on their own schedule: insufficient funds, transaction limit exceeded, transient errors. Space the attempts and a real share of them come back.

Never worth retrying

Dead cards don't age back into working: expired card, incorrect number, invalid payment method. A retry cannot help here; only a card-update link can. Which app sends that link depends on the subscription app you run — see the notes above.

Not the customer at all

Some failures are yours to fix, and a dunning email makes them worse: amount too small, configuration errors, data mismatches. The card was often never even asked.

Full reference: every Shopify subscription decline code, what it means, and whether a retry helps.

Questions merchants ask before connecting

Does my subscription app tell me when a payment fails?

Most subscription apps handle the customer side well — they retry on their own schedule and email the subscriber. The merchant side is the gap: the failure sits on a screen you have to remember to open, so a declined renewal can go unnoticed for weeks. Moorly closes that gap — it lists each failed renewal on your dashboard with the kind of failure it was, and emails you a weekly recovery summary.

Do I have to switch subscription apps to use Moorly?

No. Moorly is not a subscription app and does not replace one. It connects to the subscription app you already run through that app's own API, so your contracts, prices, and checkout stay exactly where they are. There is no migration, no theme edit, and no change to how customers subscribe.

Will Moorly conflict with my app's own retries, or double-charge customers?

Moorly issues no charge outside your subscription app: every billing write it makes — a retry, a reschedule, a skip, a discount — is a call to your app's own API, the same operation you could perform in its admin. When a failure says your app is going to retry, or carries the time of its next attempt, Moorly stands down and leaves that case to your app. It cannot cancel a subscription at all, and it starts read-only.

Which subscription apps does Moorly work with?

Appstle Subscriptions is the first and deepest integration, and Seal Subscriptions is supported. A Recharge connector is in active development. Moorly's core is app-agnostic by design, so other platforms are added as thin connectors — tell us what you run and it gets prioritized by demand.

How do I find out why a subscription payment was declined?

Shopify publishes the list of error codes a failed subscription billing attempt can carry — insufficient_funds, expired_card, do_not_honor, and the rest of it. Which of them your subscription app shows you varies widely. Moorly reads the code behind each failure and picks the treatment for the codes its table recognises, because a retry that recovers an insufficient-funds decline is wasted on an expired card. See the full code reference →

Building a subscription app?

Moorly exists to keep your merchants' subscribers alive — every subscription a merchant loses to a failed payment is recurring volume your app loses too. If you'd like Moorly to integrate with your platform, or want to talk co-marketing, we'd love to hear from you: hello@getmoorly.com.

Find out what failed renewals are costing you

Early access is opening to a small group of Appstle and Seal stores.

Get early access →