この記事でわかること
この記事の目次Contents閉じる開く
サブスクリプションアプリの設定画面は、どれも同じ3項目に行き着きます。リトライ回数、リトライ間隔、そして全部失敗したときの挙動です。多くのストアはこの3つの数字を調整し、回復率が1〜2ポイント動くのを見て、残りは仕方がないと結論づけます。
この捉え方には、具体的でコストの大きい誤りがあります。Shopifyの課金APIはサブスクリプション決済の失敗に対して50種類以上のエラーコードを返しますが、リトライという手段が正しい対処になるのは、そのうちの一部だけです。数日で勝手に解決するものもあれば、顧客側で何も変わっていない以上10回目も同じように失敗するものもあります。そして非常によくあるケース——在庫が足りずに更新注文を作れない——は、そもそもdunningのサイクルに入らないことがあります。
本記事では、決済失敗に対してShopify標準が何をしているのか、リトライで回復できる失敗とできない失敗の切り分け、そしてAppstle、Seal、Loop、Rechargeがその差にどんな課金単位で値段を付けているのかを整理します。
Shopify標準でできること
一般的な比較記事が認めているより、かなり広い範囲です。サードパーティを検討する前に、無料の純正アプリShopify Subscriptionsがすでに設定可能なdunningを備えていることを押さえておく必要があります。
Shopifyヘルプセンターによれば、アプリの設定 → Billing attemptsで、Number of retry attempts（リトライ回数）、Days between payment retry attempts（リトライ間隔の日数）、Action when all retry attempts have failed（全失敗時の動作：skip / pause / cancel）を調整できます。いずれの場合も顧客へ通知が送られます。
注目すべきは、これらの設定がPayment method failureとNot enough inventoryで別々に用意されている点です。Shopifyは「カードが通らない」と「在庫がなくて注文が作れない」を、別々のリトライ設計が必要な別問題として扱っています。後述のAppstleとSealは、いずれも課金失敗全体に対して1系統のリトライ設定を公開しています。
標準側で効いてくる要素はほかに4つあります。
- カードの自動更新（Card auto updater）。Shopifyのサブスクリプション要件ページには、Shopify Paymentsが主要カードネットワークと連携し、顧客が新しいカードを受け取った際に保存済みカード情報を自動更新する仕組みが記載されています。対応範囲は「米国では主要カードネットワークで広くサポートされ、国際的な対応状況は異なる」とされています。追加費用はかからず、アプリではなく決済ゲートウェイ側で決まる要素です。他のゲートウェイの場合、カードネットワークから更新情報を受け取れるかは各社に確認するようShopifyは案内しています。
- カード更新リンクの送付。顧客プロフィールのPayment methods → Send link to update cardからメールを送れます。ただしShopifyは、このリンクが送信から48時間で失効すると明記しています。dunningメールを3日間隔で送っている場合、次の試行が来る前にリンクは死んでいます。
- Failed paymentセグメント。顧客リストをProduct subscription status → Failed paymentで絞り込めるため、対象者の抽出と一斉連絡はアプリなしでも可能です。
- Shopify Flowのトリガー。Flowにはsubscription billing attempt failureトリガーとsubscription billing attempt challengedトリガーがあり、いずれもbilling attemptオブジェクトとsubscription contractオブジェクトをワークフローへ渡します。エラーコードで分岐してKlaviyoやSlack通知、タグ付けへ回す処理は、リカバリ専用製品を買わなくても組めます。
課金タイミングは固定です。顧客への請求は、サブスクリプションの予定日の翌日、ストアのローカルタイムで午前10時に行われます。
判定：Shopify Paymentsを使い、サブスクリプションが数百件規模なら、標準のdunningとFlowで仕組みとしては足ります。アプリに払うのはリトライ機能そのものではなく、スケジュールの精緻さ、通知の設計、そしてレポーティングです。
リトライが効くかどうかはエラーコードが決める
ShopifyのSubscriptionBillingAttemptErrorCode enumは、公式ドキュメント上「error_messageを補完して一貫した結果を提供し、dunning managementを助けるため」に存在すると説明されています。これらのコードは、デバッグ用の副産物ではなく、リトライロジックの入力として設計されています。
コードは大きく3つに分かれ、リトライが有効なのは最初のグループだけです。
| グループ | コード例 | リトライの効果 |
|---|---|---|
| 一時的で状況が変わりうる | INSUFFICIENT_FUNDS、TRANSIENT_ERROR、CALL_ISSUER、TRANSACTION_LIMIT_EXCEEDED | 有効。給料日、与信サイクル、銀行側フラグの解除で結果が変わりうる |
| 顧客の操作が必要 | EXPIRED_CARD、EXPIRED_PAYMENT_METHOD、INVALID_PAYMENT_METHOD、PAYMENT_METHOD_NOT_FOUND、BUYER_CANCELED_PAYMENT_METHOD、INVALID_CUSTOMER_BILLING_AGREEMENT | なし。顧客が更新するまで同じ決済手段は毎回失敗する。リトライはメール送信のスケジュールとしてしか機能しない |
| ストア側・設定側の問題 | PAYMENT_PROVIDER_IS_NOT_ENABLED、TEST_MODE、MERCHANT_RULE、INVALID_CURRENCY、PAYMENT_METHOD_INCOMPATIBLE_WITH_GATEWAY_CONFIG | なし。しかも設定不備に気づかないまま、リトライ回数だけを消費する |
enumの一覧を見るだけでは分からない挙動が2つあります。各コードと対処法を対応づけたSkioの公開ドキュメントPayment and billing errorsには、AUTHENTICATION_REQUIRED、AUTHENTICATION_FAILED、EXPIRED_BUYER_ACTIONが「generic declineとして扱われ、3DSのチャレンジフローには回されない（treated as a generic decline, not routed through the 3DS challenge flow）」と記載されています。Skioにおいては、銀行が3D Secureの確認を求めているだけの顧客が、dunningキュー上ではハードな拒否と見分けがつかなくなります。
さらに、名前に反してMERCHANT_ACCOUNT_ERROR、PAYMENT_PROVIDER_ERROR、PROCESSING_ERRORの3つは、いずれも一時的なプラットフォーム側の問題ではなく本物のdeclineとして扱われる、と同ドキュメントに明記されています。この3つは積極的にリトライして良い、という前提は成り立ちません。
Shop Pay固有の落とし穴もあります。PAYMENT_METHOD_NOT_FOUNDは「顧客がShop Payからカードを削除し、billing agreementが切れた場合によく発生する」とされています。Shopify公式も逆側から同じことを書いており、顧客がShop Payアカウントからカードを削除しても、紐づいたサブスクリプションは個別に解約されるまで継続します。契約は生きていて決済手段だけが消えている状態で、これは何回リトライしても埋まりません。
dunningキューに現れない失敗
ここからが、公開情報としてほとんど整理されていない部分です。
Skioのドキュメントは、Skioにおいて在庫切れエラーはdunningサイクルに入らないと明記したうえで、2つの結果を説明しています。
- サブスクリプション内の商品がすべて在庫切れの場合、課金自体がスキップされる。請求は発生せず、失敗メールも送られず、Failedタブにも表示されない。
- 一部だけ在庫切れの場合、その明細行が課金前に除外され、残りの商品だけが課金される。注文は正常に完了するが、想定より低い金額になる。
2つ目をもう一度読んでください。更新は成功し、リカバリのダッシュボードはきれいなまま、売上だけが静かに目減りします。これが表に出るのは、subscription audit logに残る「Billing out of stock」イベントだけです。
Shopify SubscriptionsがNot enough inventoryに独立したリトライ回数と間隔を持たせているのは、まさにこの領域に対応するためです。どのアプリを使う場合でも、実務上のルールは同じです。更新売上が予測を下回っているのに回復率は良好に見えるなら、リトライ設定をいじる前に在庫を確認してください。
アプリで実際に変わるところ
5つのアプリを同じ軸で見ます。決済失敗に対して何ができるようになるのか、そしてそれにいくら払うのか。数値はすべて各アプリのShopify App Storeリスティングから、2026年9月5日時点で確認したものです。
Shopify Subscriptions
出典: Shopify App Store（Shopify Subscriptions、2026-09-05時点）
Shopify提供、無料、評価3.7（801件）。リトライ回数、間隔、全失敗時の動作を、決済失敗と在庫不足で別々に設定できます。顧客通知は設定 → 通知でストアの他のメールと同じ場所から切り替えます。段階的なリトライ設計や、標準のサブスクリプションレポートを超える回復分析はありません。
Appstle℠ Subscriptions App
出典: Shopify App Store（Appstle℠ Subscriptions App、2026-09-05時点）
Appstle℠ Subscriptions AppはBuilt for Shopifyバッジを持ち、評価5.0（8,566件）。Failed Payment Recoveryのドキュメントには、リトライ回数1〜10回、間隔1〜10日、全失敗時にcancel / pause / skipを選べることが記載されています。
差がつくのはphased retry（2026年6月7日付ドキュメント）で、本記事で確認した5アプリのうち、段階的なリトライ設計を公開しているのはこれだけです。単一のリトライ間隔ではなく、回数と間隔を持つフェーズを順番に定義します。Appstleが挙げる例——フェーズ1が1日間隔で2回、フェーズ2が5日間隔で3回——では、1日目、2日目、7日目、12日目、17日目にリトライされます。これは前述のエラー分類にそのまま対応します。一時的なdeclineに備えて前半を詰め、後半はカード更新の時間を顧客に与えるためのものです。Resultsタブでは回復率、回復売上、dunning中の件数、多かった拒否理由を確認できます。なお、phased retryは自分で有効化する機能ではなく、Appstleのサポートに連絡して設定してもらう位置づけとされています。
料金は月間サブスクリプション売上ベースで、取引手数料は0%。Freeが月$500まで、Starterが$10/月で$5,000まで、Businessが$30/月で$15,000まで、Business Premiumが$100/月で$100,000までです。Payment Retryは無料プランの機能一覧に含まれています。
Seal Subscriptions App
出典: Shopify App Store（Seal Subscriptions App、2026-09-05時点）
Seal Subscriptions AppもBuilt for Shopifyで、評価4.9（3,076件）。公式FAQによれば、リトライ設定はSettings → General Settings → Billing settingsにあり、失敗ごとにカード更新手順を案内するメールをSettings → Notificationsで有効化することが推奨されています。このメールはデフォルトでオンではありません。
重要な制約は全失敗時の挙動です。同FAQは、すべてのリトライが失敗した場合「サブスクリプションは自動的にキャンセルされる（the subscription will be cancelled automatically）」と記載しています。Shopify SubscriptionsとAppstleがskip / pause / cancelを選べるのに対し、Sealが公開しているのはキャンセルという結果のみです。長いリトライ設計を組む場合、この差は「使い切った顧客をあとから救えるか」を決めます。
料金はアクティブなサブスクリプション件数ベースで、全プラン取引手数料0%。Freeが50件、$5.95/月が100件、$9.95/月が250件、$24.95/月が500件、さらに上位プランもあります。年払いで20%割引です。
Loop Subscriptions App
出典: Shopify App Store（Loop Subscriptions App、2026-09-05時点）
Loop Subscriptions Appは評価5.0（747件）。リスティングには「Smart dunning management with 15 retries」と書かれており、Appstleが公開している1〜10回より高い上限です。
ただし、それがどのプランに載っているかを確認してください。LoopのFree Foreverプランはアクティブ50件までで、機能一覧はカスタマーポータル、サブスクリプション更新の通知、成長・売上分析です。dunningはこの一覧に含まれておらず、$99/月＋取引額1.0%のStarterプランに記載されています。Proは$399/月＋0.75%です。つまり、Loopが打ち出しているリトライ上限は、小規模ストアが最初に選ぶ無料プランには含まれていません。
Recharge Subscriptions App
出典: Shopify App Store（Recharge Subscriptions App、2026-09-05時点）
Recharge Subscriptions Appは評価4.8（3,116件）、60日間の無料トライアル付き。Failed Payment RecoveryはStarter（$99/月＋取引ごとに1.49%＋19¢）の機能一覧に含まれます。さらに、サブスクライバー25〜50件向けの$25/月プランがあり、その機能欄は「Entire Starter feature set」と記載され、最初の50サブスクライバーには取引手数料がかかりません。つまり回復機能は$99プランの専用機能ではありません。Plusは$499/月＋1.34%＋19¢です。
リスティングには、Rechargeによる外部課金がShopifyの請求とは別に発生しうる旨の注記があり、経理上の突合では留意が必要です。業界動向として、Rechargeは2026年4月30日にSkioが同社に加わることを発表しています。Skioのエラーコードに関するドキュメントは引き続き公開されており、どのアプリを使っていても読む価値があります。
同じ規模でも請求額はここまで違う
月間サブスクリプション売上$12,000、アクティブなサブスクリプション約300件、更新注文約300件、平均注文単価$40のストアを想定し、各アプリの公開料金を当てはめます。
| アプリ | プラン | この規模での月額 | 課金単位 |
|---|---|---|---|
| Shopify Subscriptions | — | $0 | 無料 |
| Seal Subscriptions App | LEGEND | $24.95 | アクティブ件数 |
| Appstle℠ Subscriptions App | Business | $30 | 月間サブスク売上 |
| Loop Subscriptions App | Starter | $99＋$120＝$219 | 定額＋取引額1.0% |
| Recharge Subscriptions App | Starter | $99＋$178.80＋$57＝$334.80 | 定額＋1.49%＋19¢／取引 |
どのアプリもdunningと呼んでいる機能に対して、13倍の開きがあります。差はリトライの品質ではなく課金単位です。SealとAppstleは取引手数料0%、LoopとRechargeは取引額に比率をかけるため、守ろうとしている売上そのものに比例してコストが増えます。レベニューシェア型では、$40の注文を回収するたびにその$40から取り分が引かれます。
規模が大きくなれば、比率課金のプラットフォームが提供する導入支援、ベンチマーク、サポートが定額アプリでは代替できない領域になり、この計算は逆転します。ただし、高額プランのほうが回復額も大きいと決めつける前に、自社の数字で計算してください。
選び方
- Shopify Payments利用、サブスクリプション数百件規模 → 純正Shopify Subscriptions＋billing attempt failureトリガーのFlowワークフロー。Shopify Paymentsを使い続けることでカード自動更新の恩恵を受けられる。ここで止めてよい。
- コストを抑えつつ設定画面はきちんと欲しい → 件数課金のSeal（$5.95〜$24.95/月）か、売上課金のAppstle（$10〜$100/月）。どちらも取引手数料0%。全失敗時の自動キャンセルが許容できないならAppstle。Sealは全リトライ失敗時の結果としてキャンセルのみを公開している。
- エラー種別に合わせてリトライ間隔を変えたい → 本記事で確認した範囲で、段階的なリトライ設計を公開しているのはAppstleのphased retryのみ。有効化にはサポートとのやり取りが必要。
- Shopify Paymentsを使っていない → 回復の上限はアプリではなくゲートウェイのカード自動更新対応で決まる。まずそこを確認する。どんなリトライ設定よりも結論を左右する。
- 更新売上は足りないのに回復率は良好に見える → dunningではなく在庫の問題。在庫切れの更新が静かにスキップされていないか、一部明細だけ課金されていないかを確認する。
どのアプリでも解決しないこと
ここまでのすべての選択肢に共通する制約が3つあります。顧客が削除した決済手段や、更新されないまま期限切れになったカードは、リトライでは回復できません。必要なのは機能する更新導線であり、Shopifyの更新リンクは48時間で失効します。銀行の確認を求めるメール（「Confirm payment for your subscription」）にはロゴとアクセントカラーが反映されますが、Shopifyによればそれ以上のカスタマイズはできません。そしてチェックアウトのサブスクリプション同意文言の編集にはShopify Plusプランが必要です。
自社のサブスクリプション事業が何に比例して伸びるのか——サブスクライバー数か、売上か、注文件数か——に課金単位が合っているアプリを選び、リトライ設計はエラーコードで実際に変えられる範囲に合わせて組んでください。10回目の試行を足す前に、ゲートウェイがカードを自動更新しているか、更新リンクが48時間以内に顧客へ届いているかを確認する価値があります。この2つは、リトライでは扱えない失敗カテゴリに効く経路です。
参考情報
- Managing Shopify Subscriptions app settings — Shopify Help Center
- Considerations and payment gateways for subscription products — Shopify Help Center
- Viewing and managing customers' subscriptions in your Shopify admin — Shopify Help Center
- Subscription billing attempt failure trigger — Shopify Help Center
- SubscriptionBillingAttemptErrorCode — Shopify GraphQL Admin API
- Payment and billing errors — Skio Help Center
- Failed Payment Recovery in Appstle Subscriptions — Appstle Help Center
- Phased payment retry campaigns in Appstle Subscriptions — Appstle Help Center
- What happens an auto-charging payment fails? — Seal Subscriptions
- Recharge Welcomes Skio to Build the Future of Subscription Commerce — PR Newswire
- Shopify Subscriptions — Shopify App Store
- Appstle℠ Subscriptions App — Shopify App Store
- Seal Subscriptions App — Shopify App Store
- Loop Subscriptions App — Shopify App Store
- Recharge Subscriptions App — Shopify App Store
Hextom: Free Shipping BarがShopify App Storeから姿を消しています。Shopify標準のアナウンスバーでできること・できないことを整理したうえで、2026年9月時点で実際に確認した後継5アプリの料金・機能・制約を比較しました。