保存するようにしよう。これは後述する決済失敗の判断材料になる。入れているのは、プラン以外の毎月変動する合計としての金額をここに保存するためだ。ライセンス数に応じて料金が変わったり、アドオンを追加して料金が加わったり、従量課金を追加して料金が加わったり。プランが複数の場合、ユーザーが途中でアップグレードした時にその決済をどうするか有料プランから有料プランのアップグレードは地味に計算が大変だ。プランの料金も支払ってもらうことにしてしまうと、ユーザーは余計に料金を支払わなければならない。日割り額を差分として頂くか、来月初からプランアップグレードが適用になるかのどちらかの設計になるだろう。作られていたら、そのプランでの料金を請求する実装にすれば良い。プラン以外での課金が発生するか。その課金はどのタイミングで決済されるかこれは例えば毎月末に全ユーザーの決済をすると決めた場合、その他の決済が行われるタイミングも考慮する必要があるということだ。トライアルから有料へアップグレードした瞬間、その日から月末までの日割り料金を請求する場合はその時点で課金が発生する。プランアップグレードで当日からプランのアップグレードを適用する場合にも日割り料金が発生するだろう。従量課金制の場合、退会時にも既に使っていた料金分を請求する必要がある。これらあらゆるパターンで決済が発生する可能性があるので、自社サービスに最適な決済フローを設計しよう。決済に失敗した時にどのように対応するかそして定期課金で最も厄介なのが決済に失敗した企業へのアプローチだ。決済に失敗することは実は非常によく起こる。社は毎月失敗すると考えてよい。その場合、即退会だとか使えなくするだとかはあまりに厳しすぎるので、一時的に支払ったことにして使える状態にしなければならない。