Stripe外からアプリの支払いを受け取った時の対処手順

Stripe外からアプリの支払いを受け取った時の対処手順

Stripe外からアプリの支払いを受け取った時の対処手順

カード決済の失敗理由は基本的に分からない/信用コストは自分で払う必要がある/根本解決は事業者としての信用を高める事

どうも、個人アプリ作家のTAKUYAです。サブスク制のサービスを、カード決済プラットフォーム「Stripe」を使って組んでいます。基本的に支払いはクレジットカードとデビットカードのみ受け付けています。しかしながら、そのカード決済がどうしてもうまく行かないケースがごく稀にあります。その時、例外的にPayPal経由で支払ってもらうようにしています。本稿ではその際の管理手順について、自分用の備忘録も兼ねて解説したいと思います。

カード決済の失敗理由は基本的に分からない

クレジットカード決済は様々な理由でdecline(拒否)されます。体感的には全体の10%ぐらいが失敗しているように見えます。declineされるポイントは2つです:

  • カード登録時
  • 決済実行時

失敗理由は実に様々で、StripeのドキュメントにDecline Code一覧が記されています。

Bank Decline Codes | Stripe
Understand what decline codes mean and how you can resolve them when a charge is declined. If a card issuer declines a…

この中でも最も多いのがdo_not_honorgeneric_declineです。その説明は両方とも:

Description: The card has been declined for an unknown reason.
Next streps: The customer needs to contact their card issuer for more information.

となっており、全く参考になりません。3年間のサービス運営を通じてユーザさんと一緒に調べた結果、以下のケースがありました:

  • デビットカードが継続支払いに対応していなかった
  • 日本からの請求を不審と判断された
  • .info ドメインが不審と判断された
  • Let’s EncryptのSSL証明書が不審と判断された

最初の理由以外はすべてセキュリティ上のfalse positiveです。この場合、カード発行会社に直接連絡してdeclineしないようにお願いするしかありません。それでも必ず許可が下りるとは限りません。別のカードを試したらすんなり通る事も多々あるので、基準はカード会社ごとにバラバラのようです。あと、今まで何ヶ月間も普通に決済できていたのに突然謎の理由で拒否されるケースも多くあります。カード所持者を守るための仕組みですから、一概にカード会社を責められる問題ではないのが難しいところです。

信用コストは自分で払う必要がある

上記の経験から、僕のサービスではもともと inkdrop.info というドメインを使っていたのですが inkdrop.app に変更しました。また、彼らはwhoisも見ているようですので、虚偽の情報を設定しないように注意が必要です。Let’s Encryptは無料で手軽に入手できるSSL証明書である一方、フィッシングサイトなどにも濫用されるらしく全く信用されていないようです。そりゃそうですね、個人や法人の実在確認無しで発行できるんですから。なので自分のサービスが法人化した折に、社会的信用の高い証明書を買うつもりです。

つまり、Stripeは個人でも審査無しでカード決済が導入できる一方で、上記のような信用上のコストがのしかかる事が分かりました。それもなかなか無視できない大きさです。

有料アプリを売る手段の代表例として、AppleのApp Storeがあります。彼らの課金手数料は30%と高いですが、この信用上のコストだと思うと納得できます。アプリのサイズが大きいとCDNの配信コストも馬鹿になりませんが、App Storeでは一切かかりません。うまく行けばApp Storeがアプリをピックアップして宣伝してくれる事もあります。決済トラブルはAppleが対応してくれます。やみくもに課金手数料を忌み嫌うのではなく、こういったコスト面・マーケティング面でのメリットが30%に含まれている事を念頭に置くと良いでしょう。

外部から支払いを受け取った場合の調整方法は2つ

このように、カード決済失敗の問題に対してこちらで対処を尽くしても解決できないケースが稀にあります。その場合は諦めてPayPal経由で支払いを受け付けるようにしています。自分のサービスでは、1年間のライセンス料($49.9)をPayPalから請求しています。その際、Stripe上では以下の2つの場合に分けて支払いステータスを調整します:

  1. 試用期間がまだ残っていて請求がまだ実行されていない
  2. 試用期間がすでに終了して請求が実行された後

それぞれの手順について説明します。

Customer Balanceにクレジットを追加する

試用期間がまだ終了しておらず、Stripe側でまだ請求が実行されていない場合。予定している請求が試用期間終了時に実行されます。この請求が失敗してしまわないように、Customer Balanceを調整します。以下の通りStripeには台帳機能が備わっていて、「借り方(credit)」「貸し方(debit)」の管理ができます。

Customer balance | Stripe Billing
How to use the customer balance ledger Every customer in Stripe Billing has a ledger against which you can issue credit…

まず顧客のアカウントを開いて、Customer Balanceのセクションを確認します。

Customer Balanceのセクション

“Add balance adjustment”をクリックします。

上記のようにCreditを追加します。要するに、あなたはこの顧客に対して「借りがある」と設定する訳です。すると、次回の請求からこのCreditの額面が差し引かれます。以下のようにAdjustmentの項目が追加されます:

これで調整出来ました。

請求ステータスを手動で支払い済みに変更する

試用期間が終了してStripe側から既に請求が実行された場合。Customer Balance Creditを既に実行された請求に対して後から適用する事は出来ません。実行された請求(Invoice)を手動で調整します。該当するInvoiceを開きます:

「…」ボタンをクリックします。

「Change invoice status」を選択します。

「Paid」を選択します。説明にある通り、この操作によって該当の請求がStripeの外で回収された事にします。よく出来てますね。注意欄で表示されているように、この操作は取り消しできないので慎重に操作して下さい。

これで支払いステータスを調整できました。

事業者としての信用を高めていきたい

Stripeはカード決済の「導入」と「運用」の開発コストを大幅に下げてくれますが、信用面は一切サポートしてくれません。トレードオフですね。今回ご紹介した通り、機能面では申し分なく柔軟な対応が出来てとても便利です。しかし、いち事業者としての信用は自分で高めていかなければならない事を常に痛感します。これは僕にとって今後の課題です。今のところは、適宜手動運用で対応していこうと思います。

Read more

Inkdrop v6 Canary版リリースしました — 新Markdownエディタやその他新機能盛り沢山

Inkdrop v6 Canary版リリースしました — 新Markdownエディタやその他新機能盛り沢山

Inkdrop v6.0.0 Canary版リリースしました — 新Markdownエディタやその他新機能盛り沢山 こんにちはTAKUYAです。 v6.0.0 の最初の Canary バージョンをリリースしました 😆✨ v6では、アプリのコア機能の改善がたくさん盛り込まれています! * リリースノート(英語): https://forum.inkdrop.app/t/inkdrop-desktop-v6-0-0-canary-1/5339 CodeMirror 6 ベースの新しいエディタ フローティングツールバー v5ではツールバーがエディタの上部に固定されており、使っていないときもスペースを占有していました。 v6では、テキストを選択したときだけ表示されるフローティングツールバーに変わりました。 GitHub Alerts 構文のサポート Alerts の構文が正しい色と左ボーダーでハイライトされるようになりました。 ネストされたアラートや引用にも対応しています。 また、アラートタイプの入力を支援する補完機能も追加されました。 スラッシュコマンド 空行で /

By Takuya Matsuyama
AIのお陰で最近辛かった個人開発がまた楽しくなった

AIのお陰で最近辛かった個人開発がまた楽しくなった

AIのお陰で最近辛かった個人開発がまた楽しくなった こんにちは、TAKUYAです。日本語ではお久しぶりです。僕はInkdropというプレーンテキストのMarkdownノートアプリを、デスクトップとモバイル向けにマルチプラットフォームで提供するSaaSとして、かれこれ9年にわたり開発運営しています。 最近、その開発にClaude Codeを導入しました。エージェンティックコーディングを可能にするCLIのAIツールです。 最初の試行は失敗に終わったものの、徐々に自分のワークフローに馴染ませることができました。そして先日、アプリ開発がまた「楽しい」と感じられるようになったのです。これは予想外でした。 本稿では、自分がエージェンティック・コーディングをワークフローに取り入れた方法と、それが個人開発への視点をどう変えたかを共有します。 * 翻訳元記事(英語): Agentic coding made programming fun again 自分のアプリに技術的負債が山ほどあった ご想像のとおり、9年も続くサービスをメンテするのは本当に大変です。 初期の頃は新機能の追加も簡単で

By Takuya Matsuyama
個人開発を7年以上続けて分かった技術選択のコツ

個人開発を7年以上続けて分かった技術選択のコツ

個人開発を7年以上続けて分かった技術選択のコツ InkdropというMarkdownノートアプリを作り続けて7年になる。 お陰さまでその売上でずっと生活できている。 これまで個人開発でどう継続していくかについて「ユーザの退会理由をあれこれ考えない」とか「アプリの売上目標を立てるのをやめました」とか、ビジネス面あるいはメンタル面からいろいろ書いてきた。 今回は、技術面にフォーカスして、どう継続して開発していくかについてシェアしたい。 TL;DR * 最初はとにかく最速でリリースする事を最優先する * 迷ったら「ときめく方」を選べ * 程よいところで切り上げて開発を進める * 使っているモジュールがdeprecatedされるなんてザラだと覚悟する * 古いから悪いとは限らない * シンプルにしていく * 老舗から継続の秘訣を学ぶ * 運ゲー要素は排除しきれない 最初はとにかく最速でリリースする事を目標に技術選定する 開発計画とビジネス計画は切っても切り離せない。 コーディングに傾倒するあまり完璧主義に陥って結局リリース出来ないまま頓挫してしまう個人開発者は多い

By Takuya Matsuyama
子育て中の個人開発者の一日

子育て中の個人開発者の一日

子育て中の個人開発者の一日 どうもTAKUYAです。 久しぶりに生活まわりの事を書きたい。自分はInkdropというMarkdownノートアプリを売って生きている。 子供も無事順調に成長しており、あと数ヶ月で3歳になるというところで、イヤイヤ期もやっと終わりが見えてきた。 生活パターンもなんとなく定着しつつあるので、ここで一旦どんなルーティンなのか書き出してみる。ちなみに当方今年で40歳。 平日の1日の流れ * 06:30 妻と子供起床、朝食 * 07:10–30 俺起床、朝食 * 07:40 布団を畳んで子供を着替えさせる。妻はその間に化粧や通勤の準備 * 08:00 ストレッチと軽い筋トレ(腕立て50回、スクワット100回) * 08:10 妻と子供を見送る。15分前後瞑想 * 08:30 散歩 * 09:00 作業開始(カフェまたは家) * 11:00 昼飯 * 12:00 ダラダラする * 12:30 作業再開(だいたい家)

By Takuya Matsuyama