Skip to content

DNET_Stripe

Jump to bottom
nishi_74322014 edited this page Sep 11, 2026 · 1 revision

Stripe

概要

Stripeについて調査してみた。

ポイント

機能

  • 日本企業が130以上の通貨でビジネスできる。
  • 『Connect機能』で、代理店販売事務作業などを一気に無人化可能。

評価

  • フィンテック企業ではもっとも企業価値が高いユニコーン企業
  • もっとも重要な世界インフラの1つであるオンライン決済を構築。
  • PayPalと異なり、個人間取引でなく、企業間オンライン決済インフラを目標としている。
  • 25カ国で事業展開、毎年数10億ドルの成長、約3億ドルの資金調達、企業価値は50億ドル。
  • Bitcoin決済に対応、Apple Payの決済プラットフォームパートナーに選定。

参考（概要）

基本

仕組み

大枠は、WebPayと同じと思われる。

項番 API 説明
1 Account アカウント管理
2 Customers 顧客情報/カード情報
3 Charges 課金情報
4 Subscriptions 定期課金
5 Events イベント
6... ..., etc. ..., etc.

http://qiita.com/akinrt/items/06e54683f6a6d07e8c1e#api%E6%AF%94%E8%BC%83%E8%A1%A8

が、しかし、WebPay、PAY.JPなどと比べて、
『Connect機能』など、Stripeの方が多機能。

サインアップ・ログイン

https://stripe.com/jp

WebAPIの認証

以下が、WebAPIの認証機構（基本的に基本認証を使用する）。

秘密鍵と公開鍵

で、以下の4つの鍵を取得可能。

  • テスト・モード

    • Test Secret Key（sk_test_xxx...）
    • Test Publishable Key（pk_test_xxx...）

  • ライブ・モード

    • Live Secret Key（sk_live_xxx...）
    • Live Publishable Key（pk_live_xxx...）

基本的に、

  • Secret Keyは、サーバー側で使用する。
  • Publishable Keyは、露見しうる、クライアント側で使用する。
    （Publishable Keyには、トークン化する権限しか無い）

認証方法

基本認証か、Bearer Tokenを使用した認証ヘッダを使用して認証を行う。

Card Payments（カード決済）

https://stripe.com/docs/quickstart

どのようなケースでも、始めに、以下のステップが必要。

  • カード情報をトークン化して安全に支払情報を収集する。
  • 課金要求に支払情報を含めるか、一時的に保存する。

カード情報をトークン化する。

以下の2通りの方法で、カード情報をトークン化できる。

checkout.js

  • https://stripe.com/docs/checkout/tutorial

  • ざっくり、

    • checkout.jsを使用し、カード情報をトークン化する。

    • checkout.jsの使用には公開鍵が必要になる。

    • トークンは、stripeTokenというHidden要素に格納される。

      tok_XXXXXXXXXXXXXXXXXXXXXXXX

    • これを、FormからサーバにPOST、サーバは請求処理を行なう。

    • 郵便番号収集することを強く推奨（・・・日本ではあまり見ないが）

Stripe.js or mobile SDKs

  • https://stripe.com/docs/custom-form

  • ざっくり、

    • 支払いFormの外観を完全に管理したい場合は、
      HTMLとStripe.jsを使用して、カスタム支払いFormを実装可能。

    • Stripe.jsの使用には公開鍵が必要になる。

    • 支払いFormの要素にはname属性を付与しない（サーバに送信されない）

    • data-stripeを付与して、Stripe.jsによって処理を行う。

    • Stripe.jsはStripeでカード情報をトークン化する。

      tok_XXXXXXXXXXXXXXXXXXXXXXXX

    • stripeResponseHandlerでトークンをstripeTokenというHidden要素に格納する。

    • これを、FormからサーバにPOST、サーバは請求処理を行なう。

    • 郵便番号収集することを強く推奨（・・・日本ではあまり見ないが）

次のステップ（トークン化）

請求する。

直ぐに請求する。

https://stripe.com/docs/charges

シンプルに、秘密鍵を使用して、以下のCharges APIで請求を行なう。

後で請求する。

https://stripe.com/docs/charges#saving-credit-card-details-for-later

クレジットカード情報を顧客IDに変換・保存し、後で請求する。

秘密鍵を使用して、以下の順序で、各 REST API を呼出し、請求を行なう。

  1. 顧客を作成する:
    https://api.stripe.com/v1/customers

    cus_XXXXXXXXXXXXXXXXXXXXXXXX

  2. カードの代わりに顧客に請求する:
    https://api.stripe.com/v1/charges

  3. 顧客IDとその他の情報をデータベースに保存。

  4. 顧客に再度請求するときは、顧客IDを取得し請求を行なう。
    https://api.stripe.com/v1/charges

請求にメタデータを追加する

https://stripe.com/docs/charges#storing-information-inmetadata

  • 請求の際、
    https://api.stripe.com/v1/charges

  • 以下のパラメタにメタデータを追加可能。
    metadata[order_id]=XXXX

  • メタデータは、

    • カスタマーに対しては表示されない。
    • ダッシュボードに表示・エクスポート可能（審査プロセスを迅速化可能）

次のステップ（請求）

支払いの失敗

  • 支払いはさまざまな理由で失敗する可能性がある。

  • 特定の失敗は予防手段で、紛争の原因となる詐欺行為を予防する。

  • 支払いの失敗の理由は以下で通知される。

    • Charges APIが返すChargeオブジェクトの一部
    • ダッシュボード内の支払いの詳細内

支払いのブロック

自動詐欺防止ツールセット・レーダによる。

銀行決済の失敗

  • 失敗する理由
    消費習慣、残高、有効期限やCVCなどのカード情報など
    様々な理由により銀行やカード発行会社が支払いを拒否した場合

    • カード番号、有効期限が間違っている。残高が不足している。
    • 銀行は、具体的な理由の1つを、
      拒否コードで明らかにできる。

  • 失敗を減らす方法

    • CVCと郵便番号により、不承認数を大幅に減らすことができる。
    • また、以下の何れかを顧客に提案する。
      • 不正なカード情報（不正なカード番号や有効期限など）を修正する。
      • 別のカードや、別の支払い方法を使用する。

  • 失敗への自動対応

    • 拒否コードに対応する処理を作成する。
    • 拒否コードにアクセスする方法は以下の2通り。
      • Charges APIが返すChargeオブジェクトを処理する。
      • WebhookによりChargeオブジェクトを含むcharge.failedイベントが通知される。

無効なAPI呼び出し

  • 良くテストされていれば、問題は摘出されているため、本番環境での問題発生は稀。
  • 通常、無効なAPI呼び出しでは、ダッシュボードに支払いが表示されない。
  • ただし、いくつかのケースでは、支払いが表示されることがある。

紛争の発生

紛争の内容

  • 顧客の1人が銀行やクレジットカード会社に請求したときに発生する。

  • 銀行は通常、顧客に紛争の理由を尋ねる。

    • 顧客の苦情に続いて、ほとんどの銀行は追加の調査をせずに紛争を起こす傾向がある。
    • 多くの場合、紛争解決プロセスで、その請求が有効であることを証明できる。

  • 紛争に応答して証拠を提出するつもりがない場合、紛争に同意する。

  • Stripeは紛争の詳細を提供し、紛争の解決のために協力する。

解消プロセス

紛争への対応

  • 適切な証拠を提供することが重要
    https://support.stripe.com/questions/my-customer-withdrew-the-dispute-do-i-still-need-to-provide-evidence

    • 勝つことを望む紛争においては適切な証拠を提供することが重要。

      • 顧客からの撤回メールはなりすましの疑念を抱かせる。
      • しかし、顧客から銀行に撤回を通知するのは期待できない。
      • 従って、署名付きの手紙をPDF添付ファイルとして証拠として提供する。
        （手数料額、手数料の日付、銀行の名前、カード番号の最後の4桁）

    • 顧客が撤回したとしても、銀行間通信のため証拠を提供する。

  • 紛争解決に要する日数。

  • 紛争発生の防止。
    https://stripe.com/docs/disputes/faq#how-can-i-prevent-disputes

    • 事業ごとに別のStripeアカウントを使用する。
    • 明確な返品と払い戻しポリシーを用意する。
    • 顧客サービスの連絡先情報を目立つように掲示。
    • 顧客に最新のプロセス状態と配送時間を提供する。
    • オンライン追跡と配信確認を使用する。

チャージバックへの対応

チャージバックについては、コチラを参照。

商品の注文

商品注文の概要

https://stripe.com/docs/orders

ダッシュボードやOrders APIで商品の注文を実装すると下記を実現できる。

商品の注文は、3つの主要なオブジェクト・APIに基づいている。

注文を使用すると、請求に加え以下の機能を追加できる。

  • 自動計算
    • 税金の自動計算
    • 送料の自動計算
  • 達成された注文を把握し、リターンをシームレスに処理
  • GoogleまたはLinkShare製品フィードから商品をインポート

使い分け（Orders APIと他のStripe機能）

  • 以下のケースでOrders APIが推奨される。

    • 税金や送料を計算する必要がある。
    • 顧客が出荷および返品できる物品を販売
    • Relay経由で製品を売りたい。

  • 一方、他のStripe機能が使い易い場合もある。

    • 定期的に顧客に請求したい場合、定期購読を使用する。
    • 変動料金サービス（Uber, Lyftのライドシェアサービス）を販売している場合
    • 在庫、税金、配送システムを既にお持ちの場合。

商品とSKUの定義

配送コストと税金の定義

https://stripe.com/docs/orders/tax-integration

  • 実際の注文には、商品の費用だけでなく、配送コストと税金が含まれる。
  • Stripeはこれらを自動的かつ動的に注文に追加できる。

配送コストと税金の設定

商品を注文する

  1. 顧客は１つ以上の商品（SKU）を選択。
  2. 税金と送料を計算し、注文を作成。
  3. 顧客に請求書を提供する。

上記の2・3のステップを、Orders APIで処理する。

  • Orders APIに、商品（SKU）と配送先住所を指定。

    • https://api.stripe.com/v1/orders
    • Stripeは以下のアクションを実行する。
      • SKUの在庫を確認し、現在の価格を取得。
      • 税額を取得し、税金明細を追加
      • 送料を取得し、配送方法を追加。
      • 集計し、Orderオブジェクトにパック

  • Orderオブジェクトが表示される。

    • オーダーIDをデータベースに格納
    • 顧客に注文総額を提示する。
    • 顧客に問題がなければ請求に進む。
    • TokenをStripeに渡して注文を支払う。

Subscriptions（定期購読）

https://stripe.com/docs/subscriptions/quickstart

3ステップで定期購読が可能。

秘密鍵を使用して、以下の順序で、各 REST API を呼出し、定期購読を行なう。

  1. プランを定義する
    • 請求額の設定
    • 請求間隔の設定
  2. 顧客を作成する。
  3. 顧客を定期購読のプランに登録する

一度プランを作成したら後は、2・3のステップを繰り返せばイイ。

定期購読を行なう。

プランを定義する。

以下のPlans APIを使用して、プラン（原価、通貨、請求サイクル）を定義する。

https://api.stripe.com/v1/plans

顧客を作成する。

  • ココで説明したように、顧客を作成する。
  • ただし、費用の掛からない基本プラン等、
    支払い方法無し（メアドのみ等）で顧客を作成できる。

顧客を定期購読のプランに登録する。

以下のSubscriptions APIを使用して、顧客を定期購読のプランに登録する。

https://api.stripe.com/v1/subscriptions

  • Stripeは、Billing Cycle毎に請求書を作成。

  • 請求書には以下の情報が記録される。

    • 顧客の支払い義務の概要
    • 料金の請求時期、支払い状況を追跡します。
    • 請求書に項目を追加し、一括請求を考慮できる。

  • Subscription activity は自動的に行われるため、
    Event通知のWebフックを確立する必要がある。

次のステップ（定期購読）

Recipes

Managing your Stripe account（Stripeアカウントの管理）

https://stripe.com/docs/dashboard

テスト・モードとライブ・モード

  • テスト・モードとライブ・モードは≒。

  • テスト・モードとライブ・モードのデータは分離されている。

  • ダッシュボードで、テスト・モードとライブ・モードの表示切換が可能。

  • テスト・モードの特徴

    • 実際のカード・ネットワークを使用しない（テスト用カードを使用）。
    • Test mode allows you to fake having a Stripe balance in order to test (fake) transfers.
      （having a Stripe balanceって何よ？）
    • DisputeやBitcoinの微妙なフローがテスト・モードには存在しない。
    • テスト・モードで使用する値はコチラを参照。

API keys

アカウントの有効化

https://dashboard.stripe.com/account/details

上記URLの画面で、以下の様な情報を入力する。

  • あなたの所在地は？
  • サービスについて
  • 運用者情報
  • 個人情報
  • 明細書表記情報
  • 銀行口座情報

アカウントを安全に保つ

  • パスワードは秘密にする。また、再利用しない。
  • コンピュータとブラウザを定期的にOS X、Windowsアップデート
  • フィッシング詐欺によるパスワード漏洩に注意（特に電子メールのリンクに注意）
  • 携帯電話番号を使用した、2要素認証を活用する。

Connect

https://stripe.com/docs/connect

Connect用のアカウントを支払先単位に作成し、支払元と支払先を接続できる。

Connect用アカウント

Connect用のアカウントに以下の2つの支払先アカウント種類が存在する。

Standalone Account

  • ＝Stripeアカウント
    Stripeにサインアップ & ログインし、オンボードで処理できる支払先ユーザ。
  • オンボーディングフローでは、
    OAuth 2.0により、WebAPIで支払先ユーザの一部のオンボード処理代行が可能。
  • 支払いの受け取りなどは、支払先ユーザがオンボード処理で行なう。

Managed Account

  • Stripeにログインしない、APIで作成・処理される支払先ユーザ。

テスト

カード番号

テスト用のカード番号

テストモードで使用するテストカード情報

国際テストのカード番号

  • 発行国毎のテストカード番号
  • 国際価格設定が異なる場合、国際レートで計算される。

応答のテスト用のカード番号

特定の応答、エラー応答のテストのためのカード番号

紛争のテスト用のカード番号

  • 紛争のテスト用のカード番号

Bitcoin

・・・

JavaScriptのデバッグ

以下を使用してデバッグ。

管理アカウント

  • 特定のイベントをトリガする管理アカウントを作成・更新する。

  • テストモードの管理アカウント作成・更新APIでのみ使用できる。

  • スタンドアロンのStripeアカウントの場合

    • テストモードでは、有効な銀行詳細を使用する。
    • テストモードは、ライブ転送を模倣（銀行では処理されない）。

Routing numbers

米国における銀行コード

Account numbers

送金の失敗。

Debit card numbers

  • デビットカードへの転送テスト
  • テスト秘密鍵でのみ使用可能

Tax IDs

  • 納税者番号（SSNまたはEINの両方として有効）
  • 希望の検証動作に対応するIDを渡す。

レート制限

Bug、Bulk dataのFetch、極端な負荷テストで、429 HTTPを受け取ることがある。

Webhook

  • Webhook（IFTTTの該当節を参照）

  • アカウント設定内で、Webhookをエンドポイントに送信できる。

  • テストモードでAPI実行し、Webhook が送信されるようにする。

  • 結果のイベントデータは、APIを使用して確認する。

自動詐欺防止ツールセット・レーダ

https://stripe.com/docs/radar

  • Stripeの自動詐欺防止ツールセット・レーダは、
    高リスクであると判断したすべての支払いをブロックする。

    • CVCまたは郵便番号が一致しない場合に支払いをブロックする。
    • その他、高度な機械学習と詳細なコントロールを使用し、不正行為、紛争を予防する。

他のアプリでの販売

Relayを使ってアプリを売る

https://stripe.com/relay

その他のトピック

チャージバック

概要（チャージバック）

  • クレジットカード会員がクレジットカードの不正使用による損害を受けないためのルールの1つ。

  • 顧客がクレジットカード不正使用による利用代金の支払に同意しない場合、
    クレジットカード会社がその代金の売上を取消す。

  • 販売元はクレジットカード会社に利用代金を返金しなければならず、
    さらに商品も戻ることはないため、損害が発生する。

  • ビジネス運用費用の中にチャージバックによる損失分も想定して計上するのが一般的。

  • 銀行による調査
    カード保有者の銀行がチャージバックの前に苦情の調査を開始する場合がある。

    • 用語
      • American Express : inquiry という用語を使う。
      • MasterCard, Visa, Discover : retrieval という用語を使う。

クレジットカード不正使用の手口

  • クレジットカード情報の漏洩・流出による不正使用

    • スキミング
    • フィッシング詐欺
    • ウイルスやスパイウェア

  • クレジットカード本体の盗難・紛失による不正使用
    ECサイトではPIN入力やサインによるカード会員の本人確認が不要のためハードルが低い。

  • クレジットマスターによる不正使用
    プログラムを利用して利用可能なクレジットカード番号を割り出し、不正使用する手法

狙われやすい商材

高額商品や現金への還元をしやすい商材

クレジットカード不正使用の予防

  • セキュリティコード

    • CVCなどカード会社により異なる名称
    • 文字列なので、スキミングなどで情報が盗まれにくい。

  • 3Dセキュア（認証サービスの該当節を参照）の利用

  • 不正使用検知の利用
    会社によって仕組みが違う。

参考

公式

Stripe API Reference

https://stripe.com/docs/api

Guides

This is the Stripe dashboard, where you view and manage
all your payments, customers, transfers and more.

We've put together some guides to help get you started:

その他（参考）

移行メモ

  • PukiWiki のページ内アンカ（#xxxxxxxx）は GitHub Wiki では再現できないため、

    • 同一ページ内のアンカは、見出しから生成されるアンカに張り替え、
    • 他ページのアンカを指すリンクは「〜（ページ名 の該当節を参照）」の形に置き換えた。

  • 同名の見出しが複数あり GitHub Wiki ではアンカが衝突するため、 括弧で文脈を補って一意にした （「次のステップ（トークン化）」「次のステップ（請求）」「次のステップ（定期購読）」、 「参考（概要）」「概要（チャージバック）」「その他（参考）」）。

  • 元 Wiki で見出しそのものがリンクになっていた箇所 （「チャージバックへの対応」「紛争のテスト用のカード番号」「API keys」「Webhook」）は、 GitHub Wiki では見出しからアンカが生成されるため、 見出しをプレーン・テキストとし、リンクは直下の箇条書きに置いた。

  • 元 Wiki の行頭空白によるプレフォーマット・ブロックは、 フェンス付きコードブロックまたはインライン・コードにした。

  • 元ページの誤記を修正した。 「紛争の原因となるの詐欺行為」→「紛争の原因となる詐欺行為」、 「PDF添付ファイルを証拠として」→「PDF添付ファイルとして証拠として」、 「顧客が撤退したとしても」→「顧客が撤回したとしても」、 「表示エクスポート可能」→「表示・エクスポート可能」、 「現在の価格を取得。。」→「現在の価格を取得。」、 「Subscriptionactivity自動的に」→「Subscription activity は自動的に」、 「希望の検証動作に対応するDIを渡す」→「…対応するIDを渡す」。

  • 本ページは 2016〜2017 年頃の調査記録であり、 Stripe の API（Checkout / Orders / Relay など）や料金・企業情報は 現在では大きく変更されている点に注意。

Tags: 移行, Stripe, オンライン決済, 決済, カード決済, 定期購読, Connect, チャージバック, FinTech

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally