1. 雨宿りとWEBの小噺.fm
  2. Season 5-5. Stripe の決済は..
Season 5-5. Stripe の決済は裏で最大3回再実行している
2026-07-22 08:31

Season 5-5. Stripe の決済は裏で最大3回再実行している

spotify apple_podcasts youtube

第5回は,現代では多くの方が何かしらのサブスクを使われていると思います,というか使っていない人はほぼいないのではないでしょうか.さらにその中で決済に Stripe を利用しているサービスを使っている方も多いと思います.本日はその Stripe の決済が裏で最大3回再実行(つまり合計4回実行)しているということを知り,そのカラクリについてお話しています.是非お聴きください💁


📒 Quick tip: Stripe attempts to pay invoices up to 4 times, not 3.

https://blog.stunning.co/quick-tip-stripe-attempts-to-pay-invoices-up-to-4-times-not-3/

📒 How we built it: Smart Retries

https://stripe.com/blog/how-we-built-it-smart-retries

📒  Implementing Smart Retries with Stripe

https://www.tomaszezula.com/implementing-smart-retries-with-stripe/



ではでは(=゚ω゚)ノ


ーーーーー

📧 お便りはこちらから

https://forms.gle/utkE7JBKSReSdArPA

See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.

感想

まだ感想はありません。最初の1件を書きましょう!

サマリー

本エピソードでは、多くの人が利用するサブスクリプションサービスで使われているStripeの決済システムについて掘り下げています。特に、決済が失敗した場合にStripeが裏で最大3回(合計4回)再試行する仕組みに焦点を当てています。この再試行は単なる間隔ではなく、時間帯、曜日、地域、過去の成功率などを考慮した機械学習モデルに基づいて最適化されており、エクスポネーシャルバックオフという戦略も活用されています。失敗を前提としたシステム設計と、そこから顧客を回復させることの重要性が語られています。

はじめに:サブスクリプションと決済の課題
雨宿りとWEBの小噺fm
はい、どうもこんにちは。 雨宿りとWEBの小噺、始まりました。
Keithこと、Kuwaharaです。
この番組では、WEBテクノロジーの歴史や 裏側にあるちょっとした小噺をご紹介しております。
さて、今回の話ですけど、皆さんサブスクリプション たぶんいっぱい使ってると思います。
僕もいくつか使ってて、昨年、一昨年と年末にサブスクリプション 一気に整理して解約をしたんですよね。
すると、年間なんか1万ないし、2、3万ぐらい 解約していくみたいなことがあって、
でもさ、こんなもん使ってたなー っていうのあったんですけど、
やっぱ使わなくなってるものたくさんあるんでね、 定期的にサブスクは見直ししたほうがいいと思います。
1年じゃなくて、たぶん半年、なんなら 3ヶ月に1回でもいいと思いますけど。
その余談はさておき、サブスクって更新日に 残打が足りなかったりするけど、
気づいたら継続してたみたいなの なかったりしますか?
もしくは、いつまでか支払い完了してた みたいなのないですか?
いや、あれね、サブスクリプションで 例えばストライプを使ってる方、
ストライプが実は裏でこっそり リトライ処理とかをやってたりするんですよ。
残打がちゃんと入れといたら 後で勝手に支払いすると。
自分で残打が足りなくて 振り込みをするとかじゃなくて、
交差に入れとけば勝手に継続している。
あれはストライプが裏で リトライ処理してるってことでした。
今日はね、なんでそんなことやってんのかなとか、
裏でやっているリトライ処理 どんな風にやってんのっていうのが
エンジニアとして気になったので、 それを見に行ってみようかなと思いました。
Stripeの決済リトライの仕組み
じゃあ本編行きたいと思いますけど、
皆さんも多分エンジニアなら特にそうですけど、
ストライプ使ってる方多いと思いますが、
確かデフォルトで3回ぐらい 最大リトライをしている。
要は1回目失敗してリトライ3回なので、 合計4回ですね、試されているんですけど。
3回リトライって結構ね、 初回失敗含めと4回って、
僕知らなかったんですけど、 皆さんご存知でした?
僕本当に知らなくて。
失敗するとWebhookで通知が飛ぶんですね。
どっかの会で配信する予定ですけど、
自分のPodcastのプレミアム配信の機構を 自分で作ったんですね。
今回ストライプを使ったので、 ストライプのWebhookを使ってるんですけど、
確かに通知飛ぶんですよね。
これを使っているんですけど、
リトライ処理ですけど、一定間隔で 再試行しているのかなと思ったんですよ。
バッチ的に裏で何か仕込まれていて、 それをやっているのかなと思ったら、
そうじゃないっぽくて、
ストライプさんなので過去のデータ、
何十億件のトランザクションというのを データとして持っていて、
何十億のトランザクションで学習した マシンラーニングのモデルがあって、
タイミングというのを判断されているらしいですね。
ストライプさんのブログに、
そういうブログがあるんです。
英語だったので長かったので省略して AIに読ませたんですけど。
深夜2時の失敗をしたら、
次翌朝10時に再試行するのが 成功率が高いという風に彼らは言ってます。
残高が回復しているタイミングが、
その深夜から翌朝10時に 回復されていることが多いと。
そのタイミングでリトライ処理を もう一回やってますよと。
考慮している要素としては、
時間帯と曜日と、
しかもどの週で、
お客さんとビジネスの地域とか、
カードの過去の成功率とかを考慮して、
このタイミングらしいですね。
デフォルトは2週間以内に最大8回 みたいな条件をつけていて、
これもブログ出てましたね。
Stripeさんのブログ1つは、
How We Built It Smart Retries と、
スマートリトライズというページがあって、
単純にStripeさんの公式Docですね。
docs.stripe.comのビリングの下の、
レベニューリカバーの スマートリトライズというページがあるんですけど、
この辺にも書いてあります。
リトライ戦略:エクスポネーシャルバックオフ
開発者目線でリトライ設計の 小話的な話ですけど、
リトライの基本思想というのは、
エクスポネーシャルバックオフというものの 思想に乗っかっているらしいです。
知っている人は知っているんでしょうけど、
僕はこの名前を初めて聞いたんですね。
通信やAPIリクエストが失敗した際に、
再試行するまでの待機時間を、
指数関数的に増加させる リトライ戦略というのがあって、
これをエクスポネーシャルバックオフ というふうに名前がついています。
これによってサーバーに過負荷がかかることを防いで、
システムの安定性というのを保っている。
例えば初回失敗時は1秒待機しました。
次は2秒、次は4秒みたいな感じで 倍々に増やしていく。
そういうリトライの方法ですね。
いろんなクラウドサービス、AWSもそうですし、
Googleクラウド、GCPとかでも推奨されていて、
いわゆる乱数を使っている感じですね。
ジッターと言われたりする乱数、 ランダムな揺らぎというのを加えて、
リクエストの集中というのを防いでいる。
なので同時リトライというところの衝突を 避けようというのをやっている感じですね。
よく考えられているなと思いましたね。
感覚的には、確かStripeさんは100ミリ秒、 そして200ミリ秒、そして400ミリ秒という風に
感覚を伸ばしているんじゃなかった?
ここら辺間違ったらごめんなさい。
いわゆる待機時間をベースディレイタイムに 2の試行回数乗ですね。
2の累乗を掛け算して、プラスそのジッターを 足し算するという感じで。
最大の待機時間は大体32秒でキャップを持つ ということが多いんじゃないかと。
Stripeはこれを決済というシビアな文脈で、
マシンラーニングと組み合わせてやっています。
これもブログに書かれてますね。
見ていただければと思います。
Implementing Smart Literals with Stripeというのがあって、
Stripe社じゃない別のドットコムのサイトではありますけど、
こういうのがありますということでした。
失敗を織り込むエンジニアリング思想
短期間の過剰リトライを抑えて回復を持つ効率的な手法って、
どんなものにもいろんな過去の偉人たちの手法とか、
仕組みっていうのが考えられてて面白かったですね。
Exponential Backoffというものがあります。
実際に調べると出てきますよ。
実装例のポートとかも出てくるんで、
エンジニアの人は見てみていただいたらと思います。
でもこのリトライって、僕らエンジニアなら裏で
ネットワーキングとか見れば一応見れなくはない気はしますけど、
ユーザーからすると、ブラウザーで開発者ツールとか開かないじゃないですか。
そもそもそんなページあったの?みたいな人も絶対いると思うんであれですけど。
失敗してる、でも諦めなくて、
裏で実は静かに試み続けているっていう感じです。
メールとかで一応決済失敗しましたみたいなことは通知に出されてますけど、
ユーザーのほうでお金、降参のところですね。
復活させておけば、後は勝手にまたシステムをやってくれるっていうことですね。
失敗しないように作るんじゃなくて、
失敗することはエンジニアとして織り込むんですね。
大前提、何かしら僕らが想像しない失敗なんかあるはずですよ。
失敗した時に早く回復できるように作るという設計思想ですね。
これがエンジニアとして学ぶべきところであるし、
ここは常に意識していかなきゃいけないなと、改めて思いました。
あとはストライプの調査っていうのもあって、
リトライで回収した顧客っていうのはその後、
平均7ヶ月計測をすると、
新規顧客獲得と同じくらいの価値が実はありますよってことをおっしゃってます。
これ結構大事なデータですよね。
これもストライプさんのブログにあります。
payments-literalize-101
ここに回収した結果のデータっていうのが載ってますので、
この辺も興味があれば、
後ほど概要欄に載せておきますので、
見ていただければなと思います。
まとめとクロージング
今回ちょっと短いですけど、
ストライプの決済、ここ見えないところで、
実は裏で何度も試みていて、
それは定期的にやってるように見えて、
秒数ちょっと変化量をつけていてやってます。
さらにちゃんと時間帯とかタイミングとか、
曜日とかなんちゃらかんちゃらとか考慮して、
深夜2時の失敗した時から、
次翌朝10時の再試行をするっていうのが
成功確率が高いっていうので、
深夜2時に決済を走らせるみたいなことをやってる子ですね。
はい、いかがだったでしょうか。
こんないろんなことを考えて、
彼らはその決済の自動化の仕組みを考えてましたよってことでございました。
どっかで使える何かのタイミングで、
使える話題かどうかはわからないですけど、
エンジニアだったら酒の魚ぐらいに一瞬使える気もしますけど、
Stripeさん、いかにこうやって保っているかっていうところの裏側の一端が知れたんじゃないかなと思います。
はい、じゃあこんな感じで今回のお話は終わっていきたいと思います。
でもStripeさんいつも本当にありがとうございます。
これからもお世話になります。
何卒何卒という感じで終わりたいと思います。
じゃあクロージングです。
この番組面白かったよという方はぜひチャンネル登録もお願いします。
もし聞いていて気になることや話してほしいトピック、感想などございましたら、
Xでハッシュタグウェブ小話でつぶやいてください。
ウェブはアルファベット、小話は漢字でもきらがなでも大丈夫です。
それではまた雨宿りしに来てください。
今回もお聞きくださりありがとうございました。
雨宿りとウェブの小話、お相手はキーズでした。
バイバイ。
08:31

コメント

スクロール