Stripe
Overview
Eコマースが活発になった今日、オンラインでの決済を処理するプラットフォームを構築、または導入するビジネスも多くなっている。
この中でもとくに国際的に広く使われているオンライン決済プラットフォームがStripeになる。
stripeのAPIを使うと、自身のサービスの決済処理を担ってくれる。
ユーザーにお金を請求してその支払を受け取りたい!
「買切り」や「定額プラン」を設定して請求したい!
といったことが可能となる。
私がstripeの特に良いと思ったところは、ユーザーがstripeのアカウントがなくても支払ができるということです。
Stripeを導入するにあたり検討する
PCI DSSについて
ここに書いてある内容は正確性に欠けている可能性があるので、実際に対応を進める場合は必ず専門家に相談しながら進めてください。 決済機能を提供する上で避けて通れないのがPCI DSSへの対応です。PCI DSSとは、クレジットカード情報を事業者がどのように扱うべきかを定めた情報セキュリティ基準です。クレジットカード情報を自社で保持する場合は300 件を超えるPCI DSSの各セキュリティ制御要件を満たさなければなりませんが、カード情報の処理をStripeなどの外部SaaSに任せる事で事業者に求められるセキュリティ制御要件は22件にまで減ります。そのためにカード情報の「非保持・非通過」を目指します。
Stripe拒否コード
Stripe Billing(サブスクリプション)
Stripe のサブスクリプション(すばら しいblog)
Stripe Subscription 開始パターンごとの作成方法まとめ
今まで Stripe Subscriptions
として出してきた製品が Stripe Billing
としてパワーアップし、新しくなった。
リソース | 概要 |
---|---|
顧客(Customer) | Subscription の購入者。カード番号を保持するのに必須で、Subscription を作るのに必須。 |
製品(Products) | 販売するサブスクリプション。名称や料金など設定する。料金の保存場所的なリソース。 |
料金(Price) | サブスクリプションの販売価格。Products に対して複数設定可能で請求金額と請求間隔を設定する。Subscription を作るのに必須。 |
サブスクリプション(Subscription) | 販売するサブスクリプション。状態を持ち支払いに関連して状態遷移する。 |
請求書(Invoice) | サブスクリプションに対する請求。顧客にサブスクリプション料金を請求するタイミングで自動的に作られる。明細、税率、支払いの合計金額が記載される。 |
PaymentIntents | 顧客の支払い処理。請求に対する顧客側から見た記録を保持する。状態を持つ。 |
税率(TaxRate) | 請求に加算する税率。Subscription を作成するときに default_tax_rates で指定してやると適用される。 |
クーポン(Coupons) | 割引クーポン。Subscription を作成するとき coupon に指定すると適用され、割り引かれる。定額または割引率で設定する。割引期間も設定できる。税率を設定している場合、割引後の請求額で税金が計算される |
Charge と Transaction | Invoice に対して、支払いが発生すると、ワンショットの決済の様に Charge が作成される。Charge の balance_transaction を見ると、その決済手数料がわかる。 |
サブスクリプションの状態
状態 | 概要 |
---|---|
trialing | Subscription 試用期間。まだ請求してない。 |
active | Subscription が有効な状態。直近の請求に対する請求が成功している。 |
incomplete | Subscription 作成時の請求が失敗した状態。 |
incomplete_expired | 作成時の請求に失敗し、その後 23 時間以内に支払われなかった状態。 |
past_due | 直近の請求が失敗している状態。リトライを試みている。 |
canceled | Subscription がキャンセルされた状態。自動的な定期請求が止まる。 |
unpaid | 直近の請求が失敗し、リトライも成功しなかった状態。請求書は作成されるが、自動的には請求されない。 |
サブスクリプションの更新について
【Stripe】サブスクリプションの支払いタイミングが特定日時においてズレる問題について(月末版)
まず起点の時間を把握しておく必要がある。
Stripeでは毎月・四半期・毎年などのサイクルを指定でき、起点からそのサイクルに則って開始される。
- billing_cycle_anchor
billing_cycle_anchorとは支払い開始の起点となる日時のことです。たとえば、毎月1日に決済したい場合、サブスクリプション作成時にbilling_cycle_anchorに翌月の1日を指定することで、毎月1日払いを実現することが出来ます。特に指定をしなければ、サブスクリプション作成時刻 = billing_cycle_anchorとなります。
サブスクリプションの更新
ドキュメントの内容を基に deleted: true
が必要なケース。
サブスクリプションを更新する際に、現在の料金を新しい料金に置き換えるには以下の方法がある。
- 既存のサブスクリプションアイテムを指定し、そのpriceを新しいprice_idに置き換える
items: [
{
id: '{{SUB_ITEM_ID}}',
price: '{{NEW_PRICE_ID}}',
},
]
これにより、サブスクリプションアイテムの料金が上書きされます。 2. 既存のサブスクリプションアイテムを削除してから、新しい料金を持つアイテムを追加する
items: [
{
id: '{{SUB_ITEM_ID}}',
deleted: true,
},
{
price: '{{NEW_PRICE_ID}}',
},
]
この方法では、削除のフラグdeleted: trueを使って既存の料金を無効化します。
deleted: trueを指定しない場合の
- 対象のサブスクリプションアイテム(id)が正しく指定さ れている場合
- サブスクリプションアイテムが特定され、その価格が新しい価格(price)で上書きされる。
- 特に問題なく更新処理が行われます。
- サブスクリプションアイテム(id)が間違っている場合
- Stripeは指定されたサブスクリプションアイテムが存在しないと判断する。
- その結果、新しい料金(price)が「追加」され、サブスクリプションには複数の料金(既存のもの+新しいもの)が紐付けられる状態になる。
deleted: trueを指定する場合
既存のサブスクリプションアイテムを明示的に「削除」してから新しい料金を追加するため、以下が保証されます:
- ミスによる新規料金の追加が防げる 間違ったidを指定する可能性がなくなる(削除対象が見つからない場合はエラーになります)
- サブスクリプション内の料金が常に1つに保たれる: 古い料金が削除され、新しい料金へ完全に置き換わる。
よくあるケースと選択
- シンプルなサブスクリプション構成(料金が常に1つだけ):
- deleted: trueを使って確実に料金を置き換 えるべき。
- 複数の料金をサブスクリプションで併用したい:
- deleted: trueを省略して、新しい料金を追加する。
まとめ
- deleted: trueを省略すると:
- 指定したidが正しければ更新される。
- idがミスっている場合は新しい料金が追加され、既存の料金も残る(サブスクリプションに複数の料金が紐付けられる)。
- deleted: trueを使うと:
- 常に既存の料金が削除されるため、ミスや重複を防ぎ、サブスクリプション構造がシンプルに保たれる。
安全性を高めたい場合は、deleted: trueを指定するのがおすすめです!
サブスクリプションの次回以降の支払い日時を変更する方法
次回以降の支払い日時を変更する方法としてtrial_endを使用します。
trial_endは本来であればトライアル期間を設定するために使用するパラメーターですが、支払い日時を変更する用途でも使用できます。
サブスクリプション継続決済
基本的にイベントは update
が発行される。
しかし一度サブスクリプションをキャンセルした後に、再度入り直すとイベントはcreateになる。
Stripe Billing - 定期支払いにおける比例配分の考え方
Stripe document比例配分の仕組み
Stripe Billing - 定期支払いにおける比例配分の考え方
Stripe Billingで、サブスクリプションのプラン・料金変更後の請求金額を事前にプレビューする
Stripe Billingでサブスクリプションを提供している場合、契約期間中のプラン変更で「使った分だけ支払う」決済ができる。
stripeではこれを「比例配分」と呼んでいる