背景
今まで Stripe Subscriptions として出してきた製品がこの 4 月に Stripe Billing としてパワーアップし、新しくなりました。今回は、従来の定期支払いの請求に加え、より複雑な請求方法を Billing で実装できるようになりましたので、紹介していきます。
これまで Stripe Subscriptions 101 Part 1 としていた記事の更新記事になります。
Stripe Billing
今回のアップデートでは、段階制料金体系を構築する Tiered Pricing や毎月の利用料に応じて請求できる Metered Billing といった、主に SaaS 界隈で採用されている手法に、さらに寄り添うことができる仕組みとなりました。
例えば、ライセンスの数量テーブルに応じて価格が異なるサービスやライセンスが増えるごとに単価が異なるようなサービス、決められたサイクルで定期的に請求するものの利用量に応じて料金が異なるような従量制のサービスにしっかり対応できるようになりました。
それに加え、都度決済をオンライン請求書を通してメールで決済リンクを送り、リンク先に Stripe がホストするカード決済機能がついたオンライン請求書機能等もできるようになっております。
この記事では、上記のオンライン請求書をメールで送る決済はあまり API 等とは関係なく、ダッシュボードから送る機能ですのでここではフォーカスせず、定期支払い（subscription）をメインに解説します。
この記事での表記に関する補足
できるだけオブジェクト名や API の名前は混乱しないよう、オブジェクトや API に関しては、英語表記をしております。例えば、plan、customer、subscription、invoice、invoice item などです。
また、ドキュメントの表現と日本語がをマッチさせるためにも、日本語と英語を両方表記している部分があります。例えば、段階制料金（tiered pricing）などです。
定期支払いの請求モデル作り
まず、定期支払いを始める上で、サービスの請求モデルを設計することがとても重要です。
- 請求をするタイミング: サービス開始時 or サービス利用料に応じて請求する（その月の利用分を次月の頭に請求するなど）
- 段階制料金（tiered pricing）を利用するか: ライセンスやユーザ数、利用ボリュームなどに応じて単価を変動させるか など
- 請求サイクル: 毎週、毎月、毎年、四半期に一回
- 請求日: 毎月1日、Subscription を開始した日付を起点にする etc
- 差額の調整: サービス開始時に請求する場合には、前払いになるのでプラン変更時には差額が発生します。その対処をどうするか etc
Subscription を開始するまでの大まかな3つのステップ
上記の請求モデル設計が終わると以下のステップで subscription を作っていきます。
- Product・Plan の作成
- Customer の作成
- Subscription の作成
Plan（プラン） + Customer（顧客情報） = Subscription （定期支払い）
という基本的な考え方を理解しておくと、ドキュメントを読み進めていく上で頭が整理されます。下記にて、まずは大きな流れを理解すべく、毎月 980 円のサービスという考えで、 subscription を作成し、開始してみたいと思います。
Step 1: Product・Plan の作成
Product と Plan の概念
大きなカテゴリとして product という概念があります。Product はサービスや製品として、その配下に料金や通貨などが異なる Plan を複数紐付けることができるようになっています。
例えば、一つの Product のなかに、毎月、毎年など異なる請求インターバルをつけることができたり、日本円、USドル、ユーロの料金プランなどがあるような、製品としては共通でもプランは分けたいということもあります。
- Product: その名の通り製品やサービスです。複数の料金プランを持つ製品の場合、または一つの料金プランで成り立つ場合など組み合わせ次第で、多くの Subscription ビジネスをサポートします。カード明細書に表記される文字列
statement_descriptorを共通に持ちます。Plan では指定されなくなりました - Plan: Product の下に入ります。月額や年額など請求サイクルが異なるプランを持ったり、請求通貨が異なるプランを持ったりすることができます。
Product と Plan を作成する
まず、Step 1 の Product と Plan を作成します。
product = stripe.Product.create(
name='YT ウェブサービス',
type='service',
statement_descriptor='YT Web Service',
)
これで product オブジェクト（prod_xxxx）が生成されます。これを受けて、Plan を作成します。
plan = stripe.Plan.create(
currency='jpy',
interval='month',
product='{{PRODUCT_ID}', #Product IDを指定
nickname='毎月基本プラン',
amount=980,
usage_type='licensed', #Subscription開始時に請求を開始するタイプ
)
毎月980円の料金 plan (plan_xxxx) ができました。
Step 2: Customer の作成
毎月請求するためには、顧客の決済情報が必要になります。Stripe では、customer として顧客の決済情報を保存します。
日本のアカウントでは、クレジットカード情報が主な決済情報になります。カードの生データを持つためには PCI DSS というカード業界のセキュリティ基準に準拠する必要がありますが、Checkout（テンプレート型） や Elements（埋込み型） という Stripe が提供する決済フォーム利用すると、カードの生データを自社のサーバにヒットさせることなく、トークンを利用した仕組みで安全に取り扱うことができます。今回の記事では、この部分は割愛しますが、Elements を用いて書いた記事とサンプルなどをこちらに貼っておきます。
- Elements: https://qiita.com/y_toku/items/7e51ef7e69d7cbbfb3ca
- Elements のサンプル集は こちら
- Checkout のドキュメントは こちら
Elements や Checkout で収集したトークンをもとに customer を作成します。
customer = stripe.Customer.create(
email='xxxx@sample.com',
source='tok_xxxx', #トークン
)
これで顧客の請求情報が customer として保存され、何回もクレジットカード情報を聞くことなく決済ができます。定期支払いを実装する上では、customer が必須になります。
Step 3: Subscription の作成
Plan と Customer を紐づけて、Subscription を開始します。
subscription = stripe.Subscription.create(
customer='{{CUSTOMER_ID}}',
items=[{'plan': '{{PLAN_ID}]'}],
)
こで毎月決まった日（作成した日付を起点）に980円、この customer に請求することができるようになります。
このように、plan と customer を紐付けるという作業で subscription を作成し自動の請求を開始できるということを理解しておきます。
それでは、主な請求モデルごとに、plan の作成を中心にまとめていきたいと思います。
請求モデル
まずは、請求モデルの中で、重要な概念の説明をしていきます。
Licensed か Metered（従量制）
プランの設計でまず大事になるのが、どのタイミングで請求するか。Plan 作成時に usage_typeとして指定します。
-
licensed: Subscription 開始時に請求が始まり、各期間の始めに plan に設定された単価（amount）と数量（quantity）をもとに定期的に請求していきます。quantityが一度セットされるとその値を続けて利用していきます。毎月980円を請求するモデルがまさにこれです。事前払いのモデルです。 -
metered: こちらは該当期間の利用量を毎回更新し請求する「従量制」の請求タイプです。インターバル中の利用量（usage） を API 経由で更新し、各インターバルでアップデートしていきます。つまり各期間の終わりにその期間分を請求することができます。水道・ガス・電気代のように先月（前の2ヶ月）の利用料に応じて、期間の最後に請求されるタイプなどはこれです。
Tiered Pricing（段階制請求モデル）の利用
顧客の利用状況（ライセンスや利用しているボリューム）に応じて単価のテーブル（tier）を用意し、段階制の料金モデルを採用する場合、billing_schemeをtieredとして plan を作成します。Tiered 以外はper_unitとなります。
Licensed でも metered でもどちらのパターンでも段階制の請求モデルを利用できます。利用量の範囲（テーブル/tier 等とも呼ばれます）に応じて料金が異なるタイプのビジネスをサポートことが可能になります。ビジネスによって請求するタイミングを前にしたいのか、後にしたいのかによって選択します。
段階制の請求モデル
- モバイルのデータプランなどで見ますが、ある程度の利用量の幅に応じて料金テーブルがあるモデル
- ライセンス数によって単価が安くなる料金体系モデル
さまざまな料金モデルを組み合わせることで、多様なビジネスの請求ロジックをサポートすることができるようになります。
上記を踏まえて、さまざまな請求モデルの plan を作成してみます。
シンプルな定期支払いモデル
上記の説明の繰り返しになりますが、シンプルに毎年、毎月、2ヶ月に一回など決まったサイクルで決まった金額を請求するモデルです。その場合の plan は下記のような形で作成します。
plan = stripe.Plan.create(
currency='jpy',
interval='month', #year, month, week, day
product='{{PRODUCT_ID}}', #Product IDを指定
nickname='毎月基本プラン',
amount=980,
usage_type='licensed',
)
必要に応じて、quantity で数量を指定し、amount × quantity を請求金額とすることもできます。
複数プランを一つの subscription として請求するモデル
携帯の料金プランのようなモデルです。ベースの基本料金プランとオプションのデータプラン、2つの異なる料金プランを一つの請求にまとめるパターンです。このような場合、基本料金とオプションという2つの plan を用意し、一つの subscription の中に作成します。
plan = stripe.Plan.create(
currency='jpy',
interval='month',
product='{{PRODUCT_ID}}', #Product IDを指定
nickname='毎月基本プラン',
amount=980,
usage_type='licensed', #Subscription開始時に請求を開始するタイプ
)
plan = stripe.Plan.create(
currency='jpy',
interval='month',
product='{{PRODUCT_ID}}',
nickname='毎月データオプションプラン',
amount=300,
usage_type='licensed',
)
そして、Customer に plan を紐づけます。
subs = stripe.Subscription.create(
customer="{{CUSTOMER_ID}}",
items=[
{
"plan": "{{毎月基本プラン_PLAN_ID}}",
"quantity": 1,
}, {
"plan": "{{データオプション_PLAN_ID}}",
"quantity": 2, #数量を2つに指定
},
]
)
こうすると一つの subscription に複数のプランを紐づけて請求できます。ダッシュボードで請求 invoice を確認するとこんな感じです。（消費税はここでは指定しておりませんが、subscription を作成する際に tax_percentとして指定できます）
段階制の請求モデル - Tiered Pricing
英語圏では Tiered Pricing （呼び方: ティアードプライシング）と呼ばれている手法で、利用量に応じて単価が異なるモデルです。日本では、段階制料金などと呼ばれていることが多いようです。
まず、段階制料金を利用するには、billing_scheme を tiered として、plan を作成します。このモデルには、2つのタイプがあります。これを指定するには、tiers_mode というパラメータを利用し区別します。
- 利用量に応じ単価が異なる段階制モデル（最終的に使われる単価は一つ）:
tiers_mode=volume - 利用量に応じ単価が累進的に利用される段階制モデル（最終的に使われる単価は複数又は一つ）:
tiers_mode=graduated
それぞれ例をもとに説明したいと思います。便宜上まったく同じ Tierの設計で tiers_mode を volume と graduated にし、動きの違いがわかるようにしてみたいと思います。
| 階層（tier） | 単価 |
|---|---|
| 1-5 (up_to=5) | ¥500 (amount=500) |
| 6-10 (up_to=10) | ¥400 (amount=400) |
| 10-15 (up_to=15) | ¥300 (amount=300) |
| 15-20 (up_to=20) | ¥200 (amount=200) |
| 20+ (up_to=inf) | ¥100 (amount=100) |
plan = stripe.Plan.create(
nickname="月額段階制 Volume モデル",
product="{{PRODUCT_ID}}",
currency="jpy",
interval="month",
usage_type="licensed", #開始時、期間の始めに利用するモデル, `metered`も指定可能
billing_scheme="tiered",
tiers_mode="volume",
tiers=[
{
"amount": 500,
"up_to": "5",
},{
"amount": 400,
"up_to": "10",
},{
"amount": 300,
"up_to": "15",
},{
"amount": 200,
"up_to": "20",
},{
"amount": 100,
"up_to": "inf", # 21から無限
},
]
)
これで plan が作成されます。ダッシュボード見るとこんな感じです。
そして、subscription を開始します。例えば、ライセンス数が 11 だとすると以下のような指定になります。
subscription = stripe.Subscription.create(
customer="{{CUSTOMER_ID}}", #customer id を指定
items=[
{
"plan": "{{VOLUME_PLAN_ID}}", #plan id を指定
"quantity": "11",
},
]
)
総量が 11 ですから単価 ¥300 （Tier 11-15の量の単価）が適応され、11 × ¥300 = ¥3,300 が請求金額になります。
プラン作成をダッシュボードで行う場合、総量の変化に応じて料金がいくらになるのかプレビューすることもできます。
利用量に応じ単価が累進的に利用される段階制モデル (tiers_mode=graduated)
まったく同じ設計で、tiers_modeをgraduatedとします。
plan = stripe.Plan.create(
nickname="月額段階制 累進(graduated) モデル",
product="{{PRODUCT_ID}}", #product id を指定
currency="jpy",
interval="month",
usage_type="licensed",
billing_scheme="tiered",
tiers_mode="graduated", #ここがポイント
tiers=[
{
"amount": 500,
"up_to": "5",
},{
"amount": 400,
"up_to": "10",
},{
"amount": 300,
"up_to": "15",
},{
"amount": 200,
"up_to": "20",
},{
"amount": 100,
"up_to": "inf",
},
]
)
これで tiers_mode が graduatedとして作成されました。ダッシュボード見るとこんな感じにテーブルができます。
このように “最初の” と “次の” というような表記になっているのがわかります。つまり、それぞれの tier の単価を利用して計算していくことになります。
Subscription を開始します。例えば、ライセンス数が 11だとすると以下のような指定になります。
subscription = stripe.Subscription.create(
customer="{{CUSTOMER_ID}}",
items=[
{
"plan": "{{GRADUATED_PLAN_ID}}",
"quantity": "11",
},
]
)
tiers_modeがgraduatedの場合、それぞれの単価を利用しますので 11 の場合は下記のようになります。
(5 × ¥500) + (5 × ¥400) + (1 × ¥300) = ¥4800
ダッシュボードで見るとこんな感じです。
なお、ダッシュボードから plan を作成した場合のプレビューはこちら。
段階制の請求モデルには上記のような違いを認識し、正しい方法で作成しましょう。
従量制の定期支払いモデル - Metered Billing
該当期間の利用量をもとに、請求金額を決め後から請求する手法で、従量課金制などともよく呼ばれるモデルです。ドキュメントでは metered billing (呼び方: ミータードビリング)として記載されております。たとえば、このモデルは該当月に利用したデータ量をもとに請求したいようなビジネスにフィットします。オフラインのビジネスで考えると、水道や電気、ガス料金などがこれにあたるかと思います。
つまり、metered billing では、subscription を開始した時点では請求は発生しません。利用量 (quantity) を更新する必要があるため、Usage を API 経由で更新していく必要があります。なお、期間の最後に請求されるので proration（差額の配分）も起きません。
プランの作成
まずは、早速プランを作っていきたいと思います。YT サービス Pro というプラン名で、単価 500円の毎月の従量制定期支払いとして考えてみます。
plan = stripe.Plan.create(
currency='jpy',
interval='month',
product='{{PRODUT_ID}}', #product id を指定
nickname='YTサービス Pro',
amount=500, #利用量あたりの単価
usage_type='metered', # ここがポイント
)
subscription を開始
Plan と customer を紐づけます。
subscription = stripe.Subscription.create(
customer="{{CUSTOMER_ID}}",
items=[
{
"plan": "{{METERED_BILLING_PLAN_ID}}",
},
]
)
この時点で、subscription は走り始めますが、請求は quantity が無いので起こりません。ダッシュボードではこのように確認ができます（0円です）。そして、メーターマークが付きます。
ここでポイントがあります。Usage をレポーティングする際、subscription item の id を利用します。そのため、metered billing を利用する時、subscription 作成時にレスポンスで返ってくる subscription item を保存しておきます。
{
"application_fee_percent": null,
...
"id": "sub_xxxx",
"items": {
"data": [
{
"created":1533535200,
"id": "si_xxxx",
"metadata": {},
"object": "subscription_item",
"plan": {
"active": true,
...
"usage_type": "metered"
},
"subscription": "sub_xxxx"
}
...
}
上記のように subscription item が si_xxxx として返ってきます。これを保存しておきます。
利用量の更新について
利用量の更新（Usage record の作成）は、API 経由で行います。背景としては、従量制のモデルを利用し顧客が増えた場合、ひとつひとつダッシュボードで利用量をマニュアルでは行うわけにはいかないという考えが根底にあります。
stripe.UsageRecord.create(
quantity=3,
timestamp={{timestamp}},
subscription_item='{{**subscription_item**_id}}', #subscription item id, si_xxxx
action='increment', #incrementは加算、set は上書き
)
usage_typeをmeteredの plan 作成時には、aggregate_usageというパラメータがオプションでつけられます。これらと、action というパラメータで、increment もしくは set という usage の更新を加算するか上書くか指定することができます。
-
aggregate_usageの デフォルト はsumで、action のデフォルトはincrementです。つまり、利用量が更新されると、quantity を加算していきます。Usage を一度リセットしたいときには、actionをsetにすれば上書きされます。 -
aggregate_usageがlast_during_periodのときは action を set として指定し、quantity を上書き、その期間中に最後に利用した usage records をもとにします。 -
aggregate_usageがlast_everのときも、action を set として上書きます。上記と何が違うかというと、期間関係なく最後に利用された usage records を参照します。つまり、現在の期間中に活動がゼロでも、過去最後に利用された usage を引き継いで来るタイプです。 -
aggregate_usageがmaxの時、該当期間中の usage records の中で最大の値を利用します。
また、usage record を作成する際、重複をさけるために idempotency_keyを指定することもおすすめです。
https://stripe.com/docs/api#idempotent_requests
従量制（usage_type = metered）かつ段階制（billing_scheme = tiered）の定期支払いの考え方
これは一見すると難しく聞こえるのですが、考え方は至ってシンプルです。usage_type が metered ですので、請求タイミングが各期間の最後になるだけです。レポートされた quantity に応じて、単価が決まり、各期間の最後に tier に応じて請求するということになります。
plan = stripe.Plan.create(
nickname="月額段階制・従量制モデル",
product="{{PRODUCT_ID}}",
currency="jpy",
interval="month",
usage_type="metered", #ここがポイント
billing_scheme="tiered", #ここがポイント
tiers_mode="volume",
tiers=[
{
"amount": 500,
"up_to": "5",
},{
"amount": 400,
"up_to": "10",
},{
"amount": 300,
"up_to": "15",
},{
"amount": 200,
"up_to": "20",
},{
"amount": 100,
"up_to": "inf",
},
]
)
Subscription の作成は割愛します。
stripe.UsageRecord.create(
quantity=11,
timestamp=1533663950,
subscription_item='si_xxxx', #subscription item id
)
この場合の請求金額は、11 × ¥300 = ¥3300 ということになりますが、ただ請求が各インターバルの最後になるということになります。tiers_mode が graduated になっても考え方はまったく一緒です。
このようにして、従量制の定期支払いモデルを実現します。
以上が、請求モデルに応じた plan の作成、及び subscription の始め方になります。
それぞれのモデルをうまく組み合わせて、柔軟に対応できるようになりました。
下記では、よくあるご質問をもとに、補足的に解説していきたいと思います。
定期支払い関連のよくあるご質問
Q. 月初など請求日を揃えたいがどうしたらよいか?
billing_cycle_anchor を利用することで初回請求の起点日を調整（anchor）することができます。例えば、毎月1日に請求をする定額サービスで月途中に顧客が使い始めた場合、請求サイクルは 1 日に揃え、月途中から定期支払いの初回請求日までの利用分を日割り計算で請求したいというときに利用するケースです。
subscription = stripe.Subscription.create(
customer='{{CUSTOMER_ID}}',
items=[{{'plan': 'PLANID'}}],
billing_cycle_anchor=1535760000, #初回開始日を 2018/09/01に揃える
)
これで、初月の日割りを自動で計算し、請求サイクルはbilling_cycle_anchorに合わせられます。例えば、毎月 980 円のプランに 2018/08/09 に登録し、billing_cycle_anchor は 2018/09/01（billing_cycle_anchor=1535760000）にした場合、以下のようになります。
こうすることで、初月の日割り分を即時決済し、次月の1日から毎月請求することが可能になります。
###[補足] 請求日を同じ日にすることが、そもそも本当に良いのか考えてみる
社内会計上の理由で、請求日を揃えたいという理由が多いとは思いますが、Subscription ビジネス（サブスク）を企画する際には、請求日を同じ日にする意味があるかどうか、考えることをオススメします。
サービスによっては、請求日を揃えない方が運用しやすいケースが多くあります。SaaS ビジネスはこのタイプが多いです。例えば、いつでもサービスに登録できる Spotify のようなサービスです。サービスに登録し、決済した時からすぐに利用が開始できます（もちろんトライアルの日もありますが）。多くのユーザが毎日サービスに登録する場合、サービス開始日を起点として、毎月、毎年などで更新する、という方が利用状況に即しています。
一方で、製品をバルクで決まったサイクルで送らなければいけない、イベントを月 1 回のペースで同じ日に開催するなどは、いつも同じ日に何か起こることがある場合には、請求日を揃えた方が楽かもしれません。
##Q. trial_endは引き続き使えるか
引き続き、trial_endを利用できます。trial を始めた時点から trial_end までは無料期間になります。無料期間や、subscription 途中の請求サイクルの調整に使えます。Subscription 途中でのtrial_end を利用するときは、prorate（差額の調整）をするかしないかを考慮することをおすすめします。多くの場合は false かもしれません。日割りの考えかたは、ぜひこちらの記事をご覧ください。
##Q. 初期費用を Subscription とは別に都度決済を追加したい。どうすれば良いか？
（ユースケース）Subscription を始める際、他にかかる費用がある場合、定期支払いとは別に請求したいというケースがあります。例えば、オンラインの教育サービスで毎月料金を支払うタイプの Subscription サービスがあるとします。Subscription にかかる定期支払いとは別に、一番最初に 5000 円で初期教材費として請求したい、というケースを考えてみます。
2 つアプローチがあります。
###1. すぐに決済したい場合
####Charge を作成する
もっとも簡単で、オーソドックスな都度決済をする、という方法です。この方法は、Charge を作成するので、 Invoice とは関係ありません。
charge = stripe.Charge.create(
amount=5000,
currency='jpy',
description='初期費用'',
source=token,
)
メリット
- 一番簡単
デメリット
- Subscription ID と紐付かない
####Invoice を作って、Close する方法
一方、特定の Subscription と紐づく形で Invoice を作成し、すぐに Invoice を支払うという方法です。
Stripe::InvoiceItem.create(
customer: "{{CUSTOMER_ID}}",
amount: 2500,
currency: "jpy",
description: "教材費",
subscription: "sub_XXXX"
)
new_invoice = Stripe::Invoice.create(
customer: "{{CUSTOMER_ID}}",
subscription: "sub_XXXX"
)
new_invoice.pay
メリット
- 教材費と Subscription の関連がわかりやすい
デメリット
- Charge を作ることに比べ API コールが多い
###2. 次の Invoice にまとめたい場合
もし、すぐには決済せず、次の Invoice でまとめて OK という場合、Invoice Item オブジェクトが便利です。最終的な請求金額は、Invoice item の総額となります。これを利用すれば、Invoice に請求をまとめることができます。
- 定期支払い料金（便宜上、Daily ¥100 の定額プランを使っています）
- 初期セットアップ費用 ¥5000
stripe.InvoiceItem.create(
amount=5000,
currency='jpy',
customer='{{CUSTOMER_ID}}',
description='初期セットアップ費用',
)
[Invoice と Customer との関係]
[Invoice の内容]
[Charge のログの一部]
つまり、100 円の Subscription に加えて、¥5,000 のセットアップ費用を Invoice に追加して、¥5,100 の Charge とすることができました。Charge のログの中には、どの Invoice による Charge か、ログが残りますので後で確認ができます
##Q.月額プランに加入している方で、決済が失敗してしまい、後日お支払いをしていただいた場合、次に Invoice を作成するのはいつになるか？
Subscribe した日を起点として、Invoice を決められたインターバルで作成し続けるので、"後日お支払いをする"という意味は、"過去日になった Invoice の精算をする" というイメージです。つまり、その後の Invoice の作成インターバルに影響は与えません。
##Q. Subscription と相性の悪いプリペイドカードを弾きたいが、何か策はないか？
Subscription とプリペイドカードは相性が悪いので、サービス側で拒否したいという問い合わせをいただきます。
その場合、使えるパラメータは Card オブジェクトの fundingです。
fundingで返される値は、以下の 4 つ。
-
credit: クレジットカード -
debit: デビットカード -
prepaid: プリペイドカード -
unknown: 不明
デフォルト値がなく、上記のいずれかが返りますのでprepaidの場合、サービス側でエラーを返すというのがオススメです。
また、unknownのときは、運営者の目を通すために、ダッシュボードに表示し、ひとつひとつレビューするという手段もあります。
この際、一つの対策として、もしfunding typeが unknown の場合は、不正対策ツール Radar でルールを作成し、必ずレビューする（place in review）という方法もあります。
Radarの概要- https://stripe.com/radar
Radarのドキュメント- https://stripe.com/docs/radar
Radarのルール設定- https://dashboard.stripe.com/fraud/rules
Review に設定するルールの例- :card_funding: ='unknown'
Radarでレビューに入ると、決済は完了となりますが、決済を受けたくないと御社で判断する場合は、返金対応をしていただく形になります。返金した上で今後の決済をブロックするという方法もあります。
Radar でのレビューについて: https://stripe.com/docs/radar/review
以上です。
最後になりますが、Billing は別途料金がかかることがありますので、ご一読ください。
https://stripe.com/jp/billing
もし、何かご質問などござましたら、support-jp@stripe.com までお問い合わせください！
日本語でサポートしております。