Issuing のリアルタイムのオーソリ

同期型の Webhook を使用すると、オーソリリクエストをリアルタイムで承認または拒否できます。

Webhook エンドポイントは、設定で設定できます。カードを使用した購入が行われると、Stripe は issuing_authorization.request を作成し、お客様の承認を受けるために設定済みのエンドポイントに送信します。

リアルタイムのオーソリの対話型ガイドを参照して開始してください。

オーソリリクエストへの応答

Webhook イベントに直接応答することで、オーソリリクエストに応答できます。

直接応答する

オーソリリクエストを受信後に、issuing_authorization.request Webhook イベントに直接応答して承認または拒否します。

Webhook の応答

Webhook は、以下のパラメーターが指定された JSON レスポンスを受け入れます。

ステータスコード: 成功を示す場合は 200 を返します。

ヘッダー:

本文:

# Using Sinatra.
require 'sinatra'
require 'stripe'

set :port, 4242

# Set your secret key. Remember to switch to your live secret key in production.
# See your keys here: https://dashboard.stripe.com/apikeys
Stripe.api_key = 
'sk_test_BQokikJOvBiI2HlWgH4olfQ2'

# Replace with a real secret. You can find your endpoint's secret in your webhook settings.
webhook_secret = 'whsec_...'

post '/webhook' do
  payload = request.body.read
  sig_header = request.env['HTTP_STRIPE_SIGNATURE']

  event = nil

  # Verify webhook signature and extract the event.
  begin
    event = Stripe::Webhook.construct_event(
      payload, sig_header, webhook_secret
    )
  rescue JSON::ParserError => e
    # Invalid payload.
    status 400
    return
  rescue Stripe::SignatureVerificationError => e
    # Invalid signature.
    status 400
    return
  end

  if event['type'] == 'issuing_authorization.request'
    auth = event['data']['object']
    # ... custom business logic

    status 200
    header 'Stripe-Version' => '2025-03-31.basil', 'Content-Type' => 'application/json'
    data = { 'approved' => true }
    body data.to_json
  end
  # ...handle other cases
end

API コールを実行する Deprecated

このドキュメントは既存ユーザーを対象として作成・更新されています。新規ユーザーの方は、Webhook に直接応答してください。既存ユーザーの方は、Webhook の直接応答への移行をご検討ください。Webhook の直接応答への移行ガイドを参照して進めることができます。

API コールを作成して、リクエストを承認または拒否し、オーソリ ID を含めます。この方法を使用する場合、着信 Webhook リクエストに応答する前に Webhook が各オーソリを承認または拒否する必要があります。

# Using Sinatra.
require 'sinatra'
require 'stripe'

set :port, 4242

# Set your secret key. Remember to switch to your live secret key in production.
# See your keys here: https://dashboard.stripe.com/apikeys
Stripe.api_key = 
'sk_test_BQokikJOvBiI2HlWgH4olfQ2'

# Uncomment and replace with a real secret. You can find your endpoint's
# secret in your webhook settings.
# webhook_secret = 'whsec_...'

post '/webhook' do
  payload = request.body.read
  sig_header = request.env['HTTP_STRIPE_SIGNATURE']

  event = nil

  # Verify webhook signature and extract the event.
  begin
    event = Stripe::Webhook.construct_event(
      payload, sig_header, webhook_secret
    )
  rescue JSON::ParserError => e
    # Invalid payload.
    status 400
    return
  rescue Stripe::SignatureVerificationError => e
    # Invalid signature.
    status 400
    return
  end

  if event['type'] == 'issuing_authorization.request'
    auth = event['data']['object']
    handle_authorization(auth)
  end

  status 200
end

def handle_authorization(auth)
  # Authorize the transaction
  authorization = Stripe::Issuing::Authorization.approve(auth["id"])
end

オーソリリクエストへの応答には、上記の 2 つの方法のいずれか一方のみを使用することをお勧めします。ユーザーが 1 つの方法からもう一方の方法に移行する場合、移行中は両方の方法がサポートされます。同じオーソリで両方の方法が使用された場合には、API コールの方が直接応答より優先されます。移行する場合は、一度に 1 つのリクエストで 1 つの方法のみを使用することをお勧めします。

Stripe が 2 秒以内に承認または拒否の応答またはリクエストを受信しない場合、Authorization はタイムアウト設定に基づいて自動的に承認または拒否されます。

オーソリリクエスト

オーソリリクエストが Webhook に送信されると、リクエストされた amount は pending_request に保存されます。

{
  "id": "iauth_1CmMk2IyNTgGDVfzFKlCm0gU",
  "object": "issuing_authorization",
  "approved": false,
  "amount": 0,
  "currency": "usd",
  "status": "pending",
  ...
  "pending_request": {
    "amount": 400,
    "currency": "usd",
    "merchant_amount": 360,
    "merchant_currency": "gbp"
  }
}

リクエストの最上位の amount は 0 に設定され、approved は false です。リクエストに応答すると、最上位の amount が承認または拒否された合計金額を反映し、approved フィールドが更新され、pending_request が null に設定されます。

Ｗebhook をローカルでテストする

Webhook をローカルでテストするには、Stripe CLI を使用できます。Stripe CLI をインストールすると、イベントをサーバーに転送できます。

stripe listen --forward-to localhost:4242/webhook
Ready! Your webhook signing secret is '{{WEBHOOK_SIGNING_SECRET}}' (^C to quit)

別の端末で CLI から手動で issuing_authorization.request イベントをトリガーして、より効率的なテストを行うことができます。

stripe trigger issuing_authorization.request

Webhook の設定についてもっと知る。

AutopilotPublic preview

Autopilot provides fallback options that allow you to continue making real-time authorization decisions when your systems are down, don’t respond to an authorization request, or provide an invalid response.

Autopilot makes an authorization decision on your behalf based on a predefined set of rules. We create Authorization objects for transmission to reconcile Autopilot transactions. When Autopilot approves or declines an authorization, the request_history.reason property of the issuing_authorization.created webhook is either webhook_error or webhook_timeout:

• webhook_error if you respond to the real-time authorization webhook with an invalid Stripe API version in the request headers, or if we can’t process your response.
• webhook_timeout for all other failure modes.

To configure Autopilot, contact Stripe support.

Stripe Autopilot パブリックベータ版

For users with their own dedicated Bank Identification Numbers (BIN), Stripe Autopilot can help make authorization decisions when the card network can’t reach Stripe.

When an authorization is approved or declined through Stripe Autopilot while Stripe is down, the request_history.reason property of the issuing_authorization.created webhook is network_fallback.

To configure Stripe Autopilot, contact Stripe support.

不正利用のチャレンジPublic preview

不正利用に関するチャレンジを使用すると、カード保有者は、通常はブロックされていた可能性がある、不正利用ではない取引を再試行できます。

不正利用に関するチャレンジが送信されるタイミングを決定するルールを管理するには、issuing_authorization.request Webhook へのレスポンスを調整します。疑わしい支出を検出し、追加の確認が必要なシナリオ (カード保有者が海外でカードを使用している場合など) で、不正利用に関するチャレンジをトリガーできます。

これを行うには、issuing_authorization.request Webhook を拒否し、send_fraud_challenges フィールドに ["sms"] 値を含めます。

不正利用に関するチャレンジは現在、ベータユーザーに限定されています。ベータにご参加いただくには、Issuing の顧客である必要があります。ベータへのアクセスをリクエストするには、Stripe アカウントにログインしてページを更新してください。詳細は Stripe にお問い合わせください。

加盟店データベースPrivate preview

Issuing オーソリ Webhook の enriched_merchant_data ハッシュは、次のようなイベントでより包括的な加盟店データを渡します。

• 加盟店カテゴリ
• 所在地データ
• 第三者

これらの詳細情報を利用して、よりロバストな承認ロジックとダウンストリーム UI を構築できます。

一般的なユースケースとして、以下の例が挙げられます。

• 支出管理のリアルタイム作成
• 取引分類の自動化
• 不正使用の検出と防止の改善