プラットフォーム向けで決済を処理するには、プラットフォーム事業者が決済処理事業者である「販売者決済処理モデル」を採用する必要があります。

決済を作成する

(1) 決済資金フローのロジック

• プラットフォーム加盟店は、決済ごとにプラットフォーム事業者に請求するプラットフォーム手数料を指定します。
• プラットフォーム事業者は、決済処理事業者として、決済手数料を KOMOJU に支払う責任があります。

(2) API 経由で決済を作成する

クレジットカード決済の処理は、次の 3 つの手段に対応しています。

1. API 経由の直接支払い:
   • プラットフォームが PCI-DSS に準拠している場合は、Payment: Create APIを使用して、サーバ上でカードの詳細を処理し、顧客の決済情報を直接送信できます。詳細につきましては、こちらのガイド をご参照ください。
2. トークン化:
   PCI-DSS に準拠していない場合は、トークン化を使用して生のクレジットカード データを処理しないようにします。
   • まず、Token: Create API をリクエストして、カードの詳細をトークン化します。手順の詳細につきましては、こちらのガイド をご参照ください。
   • トークン ID を受け取ったら、Payment: Create API を使用して決済を作成するときに、それを payment_details として渡します。
3. 3D セキュア:
   3D セキュアが必要な決済の場合:
   • SecureToken: Create APIをリクエストしてセキュア トークンを生成し、verification_status に応じて顧客を authentication_url にリダイレクトします。詳細につきましては、こちらのガイド をご参照ください。
   • 次に、Payment: Create API でセキュア トークンを使用して決済を完了します。

クレジットカード以外の決済の場合は、適切な顧客の決済詳細を指定して Payment: Create API を使用するだけです。

決済を作成するときは、リクエストに以下の情報を提供する必要があります。

• processing_merchant_id: 決済を処理するプラットフォーム事業者の ID です。
• submerchant_id および platform_fee: プラットフォーム事業者が支払うプラットフォーム手数料の金額です。

 "platform_details": { 
    "processing_merchant_id": "submerchant_one",
    "submerchants": [
      {
        "submerchant_id": "submerchant_one",
        "platform_fee": "100",
        "amount": "700"
      }
    ]

上記の例では、processing_merchant は submerchant_one です。

• submerchant_one の認証情報が決算リクエストの処理に使用される
• submerchant_one の残高に決済金額が入金される
• platform_fee が submerchant_one の残高から加盟店の残高に移行される
• submerchant_one が KOMOJU 手数料を支払う

📘

取引の入金時の決済分割ロジックを指定する必要があります

決済を確定する際、platform_details 配列に決済分割情報（プラットフォーム事業者への金額とプラットフォーム手数料）を指定する必要があります。これにより、確定中に決済が適切に分割されます。

決済を作成するときに capture が true に設定されている場合、最初のリクエストに決済分割を含める必要があります。

capture が false の場合は、後で Payment: Capture API をリクエストするときに決済分割を指定できます。

(3) ホスト ページ経由で決済を作成

KOMOJU のHosted Page ソリューションは、デフォルトで PCI コンプライアンスと 3D Secure を提供します。PCI-DSS に準拠していないプラットフォームや開発の労力を削減したいプラットフォームに最適です。顧客は決済を完了するために KOMOJU のホスト ページにリダイレクトされます。詳細につきましては、こちらのガイド をご確認ください。

ホスト ページのセッションを開始するには、Session: Create API を使用し、次の詳細を指定します。

• processing_merchant_id: 決済を処理するプラットフォーム事業者です。
• submerchant_id および platform_fee: プラットフォーム事業者が支払うプラットフォーム手数料です。

   "platform_details": { 
      "processing_merchant": "submerchant_one",
      "submerchants": [
        {
          "submerchant_id": "submerchant_one",
          "platform_fee": "100",
          "amount": "700"
        }
      ]

capture モードが auto に設定されている場合、最初のセッション作成リクエストに決済分割を含める必要があります。

manual 確定の場合、確定に Payment: Capture API を使用するときに、分割を後で指定できます。

2 段階キャプチャ

(1) 承認

クレジットカード決済の場合、加盟店は capture パラメータを設定することで、決済を承認するか即時に確定するかを決定できます。capture: false を使用する場合、プラットフォーム分割情報は認証時には必要ありませんが、確定手順中に提供する必要があります。ただし、承認の際には処理事業者が必要となります。

2 段階確定の詳細については、こちら をご参照ください。

curl https://komoju.com/api/v1/payments \
-u degica-mart-test: \
-X POST \
-H "Content-Type: application/json" \
-d '{
   "amount":"1000",
   "currency":"JPY",
   "fraud_details": {
       "customer_ip": "192.0.2.1",
       "customer_email": "[email protected]"
   },
   "payment_details":{
       "email":"[email protected]",
       "month":"01",
       "name":"Taro Yamada",
       "number":"4111111111111111",
       "type":"credit_card",
       "verification_value":"123",
       "year":"2025"
    },
   "capture":"false",
   "platform_details":{
       "processing_merchant_id":"submerchant_one"
    }
}'

(2) 入金

決済の確定の際に、分割情報を指定する必要があります。合計金額（プラットフォーム事業者の負担額とプラットフォーム手数料）は、承認された決済金額を超えてはなりません。

curl https://komoju.com/api/v1/payments/{PAYMENT_UUID}/capture \
-u degica-mart-test: \
-X POST \
-H "Content-Type: application/json" \
-d '{
   "amount":"1000",
   "platform_details": {
   "processing_merchant_id":"submerchant_one",
   "submerchants": [
        {
          "submerchant_id":"submerchant_one",
          "amount":"900",
          "platform_fee":"100",
      }
    ]
  }
}'

(3) 部分入金

部分入金は、VISA/Mastercard、JCB/AMEX/Diners Club、PayPay、メルペイに対応しています。プラットフォーム分割の合計額は、部分入金の金額と一致する必要があります。KOMOJU はトランザクションごとに 1 つの部分入金のみに対応し、複数の部分入金には対応していません。

API 経由で決済を直接作成する場合（Payment: Create）、部分入金は VISA/Mastercard および JCB/AMEX/Diners Club にのみ対応しています。

一方、ホスト ページ ( Session: Create) 経由で決済を作成する場合、4 つの決済手段すべてが部分入金に対応しています。

たとえば、元の支払いが 1,000 円だった場合、500 円を部分入金できます。

curl https://komoju.com/api/v1/payments/{PAYMENT_UUID}/capture \
-u degica-mart-test: \
-X POST \
-H "Content-Type: application/json" \
-d '{
   "amount":"500",
   "platform_details":{
      "processing_merchant_id":"submerchant_one",
      "submerchants": [
          {
            "submerchant_id":"submerchant_one",
            "amount":"400",
            "platform_fee":"100"
        }
      ]
   }
}'

決済をキャンセルする

(1) API 経由で決済をキャンセルする

Payment: Cancel API を使用すると、pending または authorized 状態の決済をキャンセルできます。

(2) ダッシュボード経由で決済をキャンセルする

pending または authorized 状態の決済は、ダッシュボードからプラットフォーム事業者に代わってキャンセルできます。

取り消し返金を作成する

(1) 設定

• 取り消し返金では、決済入金の際の決済分割ロジックに基づいて、支払いが顧客に全額返金されます。
• 該当する決済手段: VISA/Mastercard、JCB/AMEX/Diners Club、PayPay、メルペイ
• 加盟店の残高とプラットフォーム事業者の残高が、それぞれが担当する返金額よりも大きくなければなりません。そうでない場合、返金は処理されません。

(2) 決済資金フローのロジック

次に、システムはプラットフォーム事業者の口座から資金を引き落とし、顧客の銀行口座に返金します。その後、加盟店の口座から当該金額を引き落とし、プラットフォーム事業者の口座に振り込みます。

(3) API を経由して取り消し返金を作成する

取り消し返金を開始するには、Payment: Refund API をリクエストします。また、プラットフォームの詳細を省略すると、決済分割は自動的に取り消されます。

curl https://komoju.com/api/v1/payments/{PAYMENT_UUID}/refund \
-u degica-mart-test: \
-X POST \
-H "Content-Type: application/json" \
-d '{

}'

(4) ダッシュボードを経由して取り消し返金を作成する

取り消し返金は、ダッシュボードを使用してプラットフォーム事業者に代わって開始できます。

取り消し返金リクエストを作成する

(1) 設定

• 取り消し返金のリクエストは、自動返金をサポートしていない決済手段に使用されます。また、返金の取り消しでは、決済入金の際の決済分割ロジックに基づいて、支払いが顧客に全額返金されます。
• 該当する決済手段: コンビニ、銀行振込、ペイジー
• 加盟店の残高とプラットフォーム事業者の残高が、それぞれが担当する返金額よりも大きくなければなりません。そうでない場合、返金は処理されません。
• 顧客が後で KOMOJU から返金を受け取れるよう、顧客の銀行口座情報を集めて KOMOJU に渡す必要があります。
• KOMOJU は、プラットフォーム事業者からの取り消し返金リクエストの返金が 1 件成立するごとに 300 円の返金手数料を請求します。(参照)。
• 最初の決済時にプラットフォーム事業者が顧客手数料を請求していた場合、include_payment_method_fee パラメータを使用して返金するかどうかを指定できます。

(2) 決済資金フローのロジック

次に、システムはプラットフォーム事業者の口座から資金を引き落とし、顧客の銀行口座に返金します。その後、加盟店の口座から当該金額を引き落とし、プラットフォーム事業者の口座に振り込みます。

(3) API を経由して取り消し返金のリクエストを作成する

Payment: Refund Request API をリクエストして、顧客の銀行口座情報と共に取り消し返金リクエストを開始できます。プラットフォームの詳細は省略でき、システムは自動的に分割を逆にします。

curl https://komoju.com/api/v1/payments/{PAYMENT_UUID}/refund_request \
-u degica-mart-test: \
-X POST \
-H "Content-Type: application/json" \
-d '{
   "include_payment_method_fee":"true",
   "customer_name":"ｶﾀｶﾅ",
   "bank_name":"青森銀行",
   "bank_code":"0117",
   "branch_name":"東京支店",
   "branch_number":"921",
   "account_type":"ordinary",
   "account_number":"1234567",
}'

(4) ダッシュボードを経由して取り消し返金リクエストを作成する

取り消し返金リクエストは、ダッシュボードを使用してプラットフォーム事業者に代わって実行できます。

取り消し以外の返金を作成する

(1) 設定

以下の場合には、取り消し以外の返金を使用します。

1. 全額払い戻しが、元の支払分割ロジックに従わない
2. 一部返金が必要

注意:

• 返金額が元の支払い金額を超えることはできません。
• サポートされている決済手段: VISA / Mastercard、JCB / AMEX / Diners Club、PayPay、メルペイ
• 加盟店の残高とプラットフォーム事業者の残高が、それぞれが担当する返金額よりも大きくなければなりません。そうでない場合、返金は処理されません。

(2) 決済資金フローのロジック

貴社とプラットフォーム事業者の両方に対して返金額を指定します。システムがプラットフォーム事業者の口座から引き落としを行い、顧客に返金します。その後、加盟店の口座から当該金額を引き落とし、プラットフォーム事業者の口座に振り込みます。

この例では

• 1,000 円の決済が、決済の入金の際に 2 つに分割され、プラットフォーム事業者に 900 円、加盟店に 100 円が最初に支払われました。
• その後、加盟店は取り消し以外の返金をリクエストし、プラットフォーム事業者から 850 円とプラットフォーム加盟店から 50 円の合計 900 円を顧客に対して返金すると指定します。

(3) API を経由して取り消し以外の返金を作成する

手動によるエラーを避けるため、Payment: Refund APIを介してのみ、取り消し以外の返金を開始できます。

curl https://komoju.com/api/v1/payments/{PAYMENT_UUID}/refund \
-u degica-mart-test: \
-X POST \
-H "Content-Type: application/json" \
-d '{
   "amount":"900",
   "platform_details":{
      "processing_merchant_id":"submerchant_one",
      "submerchants": [
        {
          "submerchant_id":"submerchant_one",
          "amount':"850",
          "platform_fee":"50",
        }
      ]
    }
}'

取り消し以外の返金リクエストを作成する

(1) 設定

取り消し以外の返金リクエストは、次の場合に開始する必要があります。

1. 全額払い戻しが、元の支払分割ロジックに従わない。
2. 一部返金を行う。

注意:

• 返金額は元の決済金額を上回ることはできません。
• 該当する決済手段: コンビニ、銀行振込、ペイジー
• 加盟店の残高とプラットフォーム事業者の残高が、それぞれが担当する返金額よりも大きくなければなりません。そうでない場合、返金は処理されません。
• 顧客が後で KOMOJU から返金を受け取れるよう、顧客の銀行口座情報を集めて KOMOJU に渡す必要があります。
• KOMOJU は、プラットフォーム事業者からの取り消し以外の返金リクエストの返金が 1 件成立するごとに 300 円の返金手数料を請求します。(参照)。
• 最初の決済時にプラットフォーム事業者が顧客手数料を請求していた場合、include_payment_method_fee パラメータを使用して返金するかどうかを指定できます。

(2) 決済資金フローのロジック

API 経由で取消以外の返金リクエストを行う場合、プラットフォーム事業者と貴社の両方が返金額を指定する必要があります。次に、システムはプラットフォーム事業者の口座から返金額を引き落とし、顧客の銀行口座に返金します。その後、システムが加盟店の口座から当該金額を引き落とし、プラットフォーム事業者の口座に振り込みます。

例えば、

• 1,000 円の支払いが、プラットフォーム事業者に 900 円、加盟店に 100 円の 2 つに分割されたとします。
• 加盟店は、プラットフォーム事業者から 850 円、加盟店から 50 円の合計 900 円の取り消し以外の返金リクエストを開始します。
• KOMOJU はプラットフォーム事業者から返金手数料 300 円を引き落とします。

(3) API を経由して取り消し以外の返金リクエストを作成する

Payment: Refund Request API を使用して、取り消し以外の返金リクエストを開始します。顧客の銀行口座情報も提供する必要があります。この種類の返金は、手動によるエラーを避けるため、ダッシュボード経由で処理できなくなっています。

curl https://komoju.com/api/v1/payments/{PAYMENT_UUID}/refund_request \
-u degica-mart-test: \
-X POST \
-H "Content-Type: application/json" \
-d '{
   "amount":"900",
   "include_payment_method_fee":"true",
   "customer_name":"ｶﾀｶﾅ",
   "bank_name":"青森銀行",
   "bank_code":"0117",
   "branch_name":"東京支店",
   "branch_number":"921",
   "account_type":"ordinary",
   "account_number":"1234567",
   "platform_details":{
      "processing_merchant_id":"submerchant_one",
      "submerchants": [
        {
          "submerchant_id":"submerchant_one",
          "amount':"850",
          "platform_fee":"50",
      }
    ]
  }
}'

チャージバック

(1) 設定

プラットフォーム事業者が、カード発行会社の定める紛争に敗れた場合、チャージバックが実行されます。支払いの全額が顧客に返金され、対応する金額が加盟店の残高から引き落とされます。チャージバックは、プラットフォーム事業者の残高が十分にあるかどうかに関係なく実行されます。

(2) 決済資金フローのロジック

加盟店は決済処理業者であるため、チャージバック金額の全額に対して責任を負います。

トランザクション レコード タイプの概要

以下の表は、さまざまなアクションに基づいて生成される記録の種類をまとめたものです。