旅行ソフトウェアの決済
Paddle API連携：Merchant of Recordが旅行ビジネスに向くとき
Paddleは、Merchant of Record（販売者）としてソフトウェア、SaaS、デジタル商品をお客様に代わって販売します。そのため、自社のサブスクリプションを請求する旅行テック企業には最適ですが、航空券、ホテル、ツアーの代金を受け取る用途にはたいてい向きません。このページでは、その違いとPaddle連携の仕組み、そして用途が合う場合にPHPTRAVELSへ接続する方法を解説します。
- ゲートウェイではなくMerchant of Record
- ソフトウェアとサブスクリプション向け
- 署名付きWebhook
- カスタム連携として接続
2つの異なるモデル
Merchant of Recordと決済ゲートウェイ
決済ゲートウェイは資金の移動を代行する仕組みです。販売者はあくまで自社で、決済事業者はカード処理を行い、税金、請求書、返金、紛争対応は自社の責任のままです。Merchant of Recordはさらに一歩進み、顧客と税務当局から見て販売者そのものになります。Paddle経由で購入されると、Paddleがお客様に販売し、売上税やVATを徴収して納付し、請求書を発行し、チャージバックに対応したうえで、お客様の取り分を支払います。
このモデルならソフトウェア企業は税務とコンプライアンスの手間を大幅に減らせますが、何を再販するかはPaddleが決めることになります。Paddleのプラットフォームはソフトウェア、SaaS、デジタル商品向けで、航空会社、ホテル、ツアー会社が提供する旅行サービス向けではありません。カード決済の一般的な仕組みは決済ゲートウェイAPIのページで説明しています。
| 項目 | Paddle（Merchant of Record） | 決済ゲートウェイ |
|---|---|---|
| 販売者は誰か | Paddleが販売者（Merchant of Record）です。顧客の領収書やカード明細はPaddle側の販売として届きます。 | 販売者は自社です。ゲートウェイは自社の加盟店アカウントで決済を処理するだけです。 |
| 売上税とVATは誰が扱うか | Paddleが販売先の地域で売上税とVATを計算、徴収、納付します。 | 自社の税務登録、会計担当者、請求書発行で対応します。 |
| 請求書は誰が発行するか | Paddleが購入者に請求書または領収書を発行します。 | 自社のシステム、たとえば管理画面の予約請求書で発行します。 |
| チャージバックは誰が対応するか | Paddleが販売者として紛争とチャージバックに対応します。 | ゲートウェイのダッシュボードやAPIから、自社で証拠を添えて異議申し立てを行います。 |
| 何を販売できるか | Paddleの利用規定の範囲で、ソフトウェア、SaaS、サブスクリプション、デジタル商品。 | ゲートウェイが承認する物販とサービス販売。多くの旅行事業者の旅行予約も含まれます。 |
| どう支払いを受け取るか | Paddleが手数料を差し引いた収益を、所定の支払スケジュールで振り込みます。 | 売上確定した決済が、ゲートウェイの手数料を差し引いて加盟店口座または銀行口座に入金されます。 |
手数料、対応国、販売可能な商品の詳細はPaddleが定めており、随時変わります。導入を決める前に、Paddle自身の利用規約をご確認ください。
判断ガイド
販売する商品にPaddleは合うか
お客様が何に対して支払うのかから考えます。自社のビジネスに最も近いシナリオを選んでください。
01
旅行者が航空券、ホテル、ツアーを支払う
顧客が購入するのは、航空会社、ホテル、ツアー会社が提供する旅行です。決済では、オーソリを先に行って後で売上確定する運用、キャンセル料を差し引く一部返金、複数通貨でのチェックアウトが必要になることがよくあります。
当社の見解
決済ゲートウェイを使う
旅行予約にPaddleを使う前に、Paddleの利用規定を確認してください。旅行事業者の多くは、Stripe、PayPal、Adyen、地域のゲートウェイなどの決済ゲートウェイで予約代金を受け取っています。
02
自社の旅行ソフトウェアやSaaSを販売する
旅行テクノロジーのベンダーとして、予約ツール、APIアクセス、プラグイン、ホワイトラベルポータルの月額または年額サブスクリプションを旅行会社から受け取っています。
当社の見解
Paddleが合う
まさにMerchant of Recordが想定する販売です。Paddleがサブスクリプションを請求し、各国の税金を処理して支払いを行うため、顧客のいる国ごとにVATの登録をする必要がありません。
03
予約とソフトウェアの両方を販売する
旅行者向けの予約サイトを運営しつつ、自社のプラットフォームやツールを他の旅行会社にもライセンス提供しています。
当社の見解
分けて両方を使う
予約フローでは対応済みのゲートウェイで予約代金を受け取り、ソフトウェアのサブスクリプションはPaddleで請求します。フローも記録も2つに分け、それぞれに適切な税務処理を行います。
仕組み
Paddle連携の流れを最初から最後まで
Paddle Billingは、Paddleで作成する商品と価格、Paddle.jsが開くチェックアウト、そして処理結果をサーバーに知らせるWebhookで成り立っています。
01
商品と価格
月額と年額など、各プランをPaddleで一度だけ作成し、価格IDを自社のシステムに保存します。
pri_…02
Paddle.jsのチェックアウト
ページにPaddle.jsを読み込み、価格IDと自社の顧客参照を渡して、オーバーレイまたはインラインフレームでチェックアウトを開きます。
Paddle.Checkout.open()03
トランザクション完了
購入者が支払うと、Paddleがカードまたはウォレットに請求し、税金を適用してトランザクションを作成します。価格が定期課金なら、サブスクリプションも作成します。
txn_…04
署名付きWebhook
Paddleがtransaction.completedなどのイベントを自社のエンドポイントに送信し、Paddle-Signatureヘッダーで署名します。
transaction.completed05
自社システムが処理
サーバーが署名を検証し、アカウントの有効化、プランの更新、支払いの記録を行います。
200 OK
APIキーはサーバー側だけで保管してください。ブラウザでは別のクライアント側トークンを使い、サンドボックスと本番環境にはそれぞれ専用のキー、価格、Webhookシークレットがあります。
Webhookのセキュリティ
Paddle-Signatureヘッダーを検証する
エンドポイントのURLを知っていれば、誰でもWebhookを偽装できます。イベントごとに署名を検証して初めて、Webhookを根拠にアカウントを有効化しても安全になります。
1$raw = file_get_contents("php://input"); 2$header = $_SERVER["HTTP_PADDLE_SIGNATURE"] ?? ""; // ts=…;h1=… 3parse_str(str_replace(";", "&", $header), $sig); 4 5$expected = hash_hmac("sha256", $sig["ts"] . ":" . $raw, $endpointSecret); 6if (!hash_equals($expected, $sig["h1"] ?? "")) { 7 http_response_code(400); exit; // not from Paddle 8} 9if (time() - (int) $sig["ts"] > $tolerance) exit; // too old1011$event = json_decode($raw, true);12if (alreadyHandled($event["event_id"])) exit; // repeat delivery13if ($event["event_type"] === "transaction.completed") {14 activatePlan($event["data"]["custom_data"]["account_id"]);15}16http_response_code(200);
素のPHPによる説明用の例です。正確な形式は、Paddleの最新ドキュメントまたは公式SDKに従ってください。
- 01
生のボディを使う
署名は受信したままのリクエストボディから計算されます。JSON解析で内容が変わる前に読み取ってください。
- 02
タイムスタンプとハッシュ
ヘッダーには、タイムスタンプと、エンドポイントのシークレットキーで作ったHMAC-SHA256ハッシュが入っています。自分で再計算し、定数時間で比較します。
- 03
古いイベントと重複を拒否する
タイムスタンプが古すぎるイベントは拒否し、イベントIDを保存して、再送されたイベントを二重に処理しないようにします。
- 04
まずサンドボックスで
Paddleのサンドボックスでテストカードを使って構築とテストを行い、その後でキー、価格、シークレットを本番用に切り替えます。
PHPTRAVELSとPaddle
PaddleをPHPTRAVELSに接続する
まず正直にお答えし、そのうえで選択肢をご紹介します。
Paddleは標準コネクタではありません
PaddleはPHPTRAVELSの決済ゲートウェイ一覧になく、公開されたセットアップガイドもありません。予約代金の受け取り用に作られた標準対応のゲートウェイは、下に表示しています。
予約代金には、標準対応のゲートウェイ
自社の加盟店アカウントで、Stripe決済やPayPal 決済などの標準対応ゲートウェイを管理画面で有効にします。決済ゲートウェイ連携のページで説明しているとおり、チェックアウト、返金、予約番号は予約フローにすでに組み込まれています。
ソフトウェア販売には、カスタム連携としてのPaddle
用途がPaddleの規定に合う場合、当社の開発者がカスタムAPI連携として接続できます。ページへのPaddle.jsチェックアウト、検証付きのWebhookエンドポイント、顧客ごとの支払い記録までを含みます。作業の開始前にお見積りします。
またはソースコードで自社開発
PHPTRAVELSはセルフホスト型で、ソースコードがすべて付属するため、自社の開発者が予約エンジンと並べてサブスクリプション用のPaddleを追加できます。各ライセンスの内容は料金のページに掲載しています。
予約決済にすぐ使える
PHPTRAVELSに接続済みの決済ゲートウェイ
旅行者とエージェントの支払いには、これらのゲートウェイをすぐにご利用いただけます。決済事業者でアカウントを開設し、管理画面にキーを入力してテストし、本番へ移行するだけです。一覧は連携ディレクトリの最新のものです。
Stripe連携ガイド
PayPal連携ガイド
xMoney
Fawaterk
Cashfree
Paystack
Flutterwave
Adyen
MyFatoorah
SSLcommerz
Razorpay- すべての連携
サブエージェントはB2B エージェントウォレットを通じて、前払い残高や与信枠から支払うこともでき、その場合はゲートウェイが一切不要です。
標準コネクタとしては対応していません。PaddleはPHPTRAVELSの決済ゲートウェイ一覧にありません。自社ソフトウェアのサブスクリプション販売など、用途がPaddleの規定に合う場合は、カスタム連携として追加するか、付属のソースコードをもとに自社の開発者が構築できます。
Paddleはソフトウェア、SaaS、デジタル商品向けのMerchant of Recordのため、航空券、ホテル、ツアーの決済には一般に向きません。旅行予約に使う前にPaddleの利用規定を確認してください。旅行事業者の多くは、Stripe、PayPal、Adyen、地域のゲートウェイなどの決済ゲートウェイで予約代金を受け取っています。
顧客に対して法的に販売を行う会社です。売上税やVATの徴収と納付、請求書の発行、返金とチャージバックへの対応を担い、顧客のカード明細にも表示されます。Paddleの場合は、Paddleがその役割を引き受け、お客様に支払いを行います。
ゲートウェイは決済を代行するだけで、販売者は自社のままなので、税務と紛争対応も自社の仕事です。Paddleは自らが販売者になるため、ソフトウェア販売ではその手間がなくなりますが、販売できるものは限られます。
旅行商品ではなく自社のソフトウェアを販売するときです。予約ツール、API、プラグイン、ホワイトラベルポータルなど、旅行会社がサブスクリプションで支払うものが該当します。Paddleが請求を行い、各国の税金も処理します。
Paddleは、トランザクションの完了やサブスクリプションの更新といったイベントを、登録したURLに送信します。各リクエストにはタイムスタンプとハッシュを含むPaddle-Signatureヘッダーが付き、サーバーはエンドポイントのシークレットキーでそれを検証してから処理します。
はい。Paddleには、専用のアカウント、APIキー、価格、テストカードを持つ別のサンドボックス環境があります。そこで構築とテストを行ってから、設定を本番環境に移してください。
はい。2つの別々のフローとして運用します。予約エンジンは標準対応のゲートウェイで旅行者の支払いを受け取り、Paddleは自社ソフトウェアのサブスクリプションを請求します。販売ごとに適切な税務処理ができるよう、記録は分けて管理してください。