- はじめに：決済失敗は「バグ」ではなく「機会損失」
SaaSやECを運営していて、決済失敗（Transaction Decline）を単なる「エラー」としてログに流していませんか？
実は、決済失敗の数%〜十数%は、適切なタイミングでのリトライや、カード情報の更新促しによって救える売上です。
グローバルでは Payment Orchestration という概念でこれらを最適化するのが一般的ですが、日本ではPSP（決済代行会社）の仕様が独自であるため、自前での実装が放置されがちです。本記事では、その実装の勘所を解説します。
- なぜ決済は失敗するのか？（エラーの分類）
すべての失敗を一律に扱うのは非効率です。エラーコードを分類し、戦略を分ける必要があります。
即時リトライが有効なケース:
ネットワーク一時エラー、システムメンテナンス等。
タイミングをずらすべきケース:
insufficient_funds（残高不足）。給料日（25日や月末）を狙ってリトライすると承認率が劇的に上がります。
リトライが無意味なケース:
expired_card（期限切れ）や card_not_supported。これらはリトライせず、即座にユーザーへカード変更を促すメールを飛ばすべきです。
- 実装のコード例（Node.js / Express）
PAY.JPのWebhookを受け取り、失敗理由に応じてリトライをスケジュールする簡易的なロジック例です。
app.post('/webhook/payjp', async (req, res) => {
const event = req.body;
if (event.type === 'charge.failed') {
const charge = event.data.object;
const failureCode = charge.failure_code;
// 1. 失敗理由の判定
if (failureCode === 'insufficient_funds') {
// 残高不足の場合：3日後にリトライをスケジュール（例：Queueシステムへ）
await scheduleRetry(charge.id, 3 * 24 * 60 * 60);
} else if (failureCode === 'card_error') {
// その他のカードエラー：ユーザーに通知メールを送信
await sendUpdateCardEmail(charge.customer);
}
}
res.sendStatus(200);
});
-
マルチPSP（GMOPG, DGFT, SBPS）への拡張
StripeやPAY.JPだけでなく、エンタープライズ領域で使われる GMOPG（GMOペイメントゲートウェイ） や DGFT（デジタルガレージ） 等を併用している場合、管理はさらに複雑になります。
各社のAPI仕様やエラーレスポンスの違いを吸収し、共通のロジックで「決済の健康状態」を管理する Orchestration層 を持つことが、中長期的なスケーラビリティに繋がります。 -
まとめ：決済を「守り」から「攻め」へ
決済手数料を払うだけでなく、決済成功率（承認率）を1%でも高めることは、マーケティング予算を増やすのと同じ、あるいはそれ以上のインパクトを利益にもたらします。
【お知らせ：決済の健康診断をしませんか？】
現在、自社の決済成功率や失敗理由を可視化する診断レポート 「PPR (Payment Performance Report)」 を無料で提供しています。
また、本記事で紹介したリトライ最適化や、複数の不正検知（IPQualityScore/Fingerprint等）をAIで統合する AI Orchestra では、現在 GMOPG / DGFT / SBPS / PAY.JP 等をご利用の事業者様向けに、3ヶ月無料のベータモニター（先着5社）を募集中です。
自前実装の工数をかけずに売上を最大化したい方は、ぜひ一度お問い合わせください。
詳細・診断はこちら：
Payment Performance Report (PPR)
https://recover.ai-orchestra.work/ppr
AI Orchestra 公式サイト（RecoverAI)
https://recover.ai-orchestra.work/