Square APIとは？決済統合の仕組み・実装フロー・Stripe/PAY.JPとの選び分けを開発視点で解説

Square API（スクエアAPI）は、クレジットカード決済や注文・顧客・在庫の管理を、実店舗とオンラインの両方で共通のプラットフォームに組み込める、Square社の開発者向けAPI群です。この記事では「Square APIとは何か」という定義から一歩踏み込み、Web Payments SDKとPayments APIによるトークン化の決済フロー、OAuth認証とSandbox環境、Orders・Customers・Subscriptions・Webhookといった実装パターン、そして対面とオンラインを統合するSquareならではの強みと、Stripe・PAY.JPとの選び分けまで、開発者・技術選定者が導入可否を判断できる粒度で整理します。読み終えると、自社の要件でSquareが合うのか、どこまで内製し、どこから受託開発に委ねるべきかが判断できます。

まとめ｜Square API導入判断の決済フローと採用可否の要点

Square APIは、実店舗のPOS決済とオンライン決済を同じ在庫・顧客・売上のデータで扱えるのが最大の性格で、対面と非対面をまたぐ事業に向いた決済プラットフォームです。実装は、フロントのWeb Payments SDKでカード情報を単回利用の支払いトークンに変換し、そのトークンをサーバーへ渡してPayments APIで決済を作成する二段構えが基本になります。認証はOAuth 2.0のアクセストークンで行い、SandboxとProductionの2環境で本番前の検証を分けられます。

APIはPaymentsを中心に、注文管理のOrders、顧客のCustomers、商品マスタのCatalog、返金のRefunds、定期課金のSubscriptions、実店舗端末のTerminalなどで構成され、決済結果はWebhookの署名付き通知で非同期に受け取ります。決済作成には冪等（べきとう）キーが必須で、再送時の二重課金を防ぐ設計です。判断の分岐点は「実店舗とオンラインを一元管理したいか」で、この統合が要件の中心ならSquareが強みを発揮します。逆に、グローバル・多通貨や高度な請求ロジックが主眼ならStripe、国内カード決済を最短で組むだけならPAY.JPとの比較が判断の助けになります。

Square APIとは何か｜決済プラットフォームとしての立ち位置

Square APIは、Block, Inc. 傘下のSquareが提供するDeveloper Platform上のAPI群で、決済・注文・顧客・在庫といった商取引の要素を、自社のWebサービスやモバイルアプリ、実店舗システムから操作するための入口です。単なる「オンライン決済の受け口」ではなく、Squareが持つPOS・在庫・顧客のデータ基盤にプログラムからアクセスできる点が、他の決済代行と性格を分けます。

Square APIの定義と決済プラットフォームとしてカバーする提供範囲

Square APIの中核は、カード決済を受け付けるPayments APIですが、その周辺に注文を束ねるOrders、顧客情報のCustomers、商品・価格のCatalog、返金のRefunds、定期課金のSubscriptions、実店舗端末を制御するTerminal、予約のBookingsといったAPIが揃っています。これらが同じアカウント・同じデータモデルの上で連動するため、オンラインで受けた注文と店頭の在庫、会員の購入履歴を分断せずに扱えます。開発者はSquare公式のSDKやREST APIを通じて、これらのリソースを組み合わせて自社のフローを構築する流れです。

実店舗POSとオンラインを統合するユニファイドコマースという性格

Squareが国内外で選ばれる背景には、POSレジ・カードリーダー・Terminalといった対面決済の資産と、オンライン決済・ECを、同一の在庫と顧客と売上で管理できる設計があります。実店舗とオンラインショップを別々の決済サービスで運用すると、在庫の二重管理や顧客データの分断が起きがちですが、Squareはこの対面と非対面の境目をAPIレベルで橋渡しする設計です。飲食・小売・サービス業など、店頭とネットの両方で売上を立てる事業では、この統合そのものが採用の理由になります。決済方式そのものの選び方は決済システムとは何かで全体像を整理できます。

Square APIの認証と環境構成｜OAuthとSandboxの使い分け

Square APIの実装は、まず認証と環境の理解から始めます。ここを押さえると、どの権限で何を呼び出し、どこで本番前の検証を挟むかの線引きが明確になります。

OAuth 2.0とアクセストークン・Application IDによる認証の考え方

Square APIの呼び出しは、Application IDとアクセストークンで認証します。自社アカウント内で完結する用途なら個人アクセストークンで足りますが、他のSquareアカウント（マーチャント）に代わってAPIを呼ぶSaaS・プラットフォーム型では、OAuth 2.0のフローでスコープ付きのアクセストークンを取得します。スコープは「決済のみ」「顧客の読み取りのみ」のように必要な権限だけへ絞れるため、預かる権限を最小に保つ設計が可能です。トークンは秘匿情報としてサーバー側で管理し、フロントに露出させないのが前提になります。

SandboxとProductionを分けた検証フローとテスト用リソースの扱い

Squareは、実際の請求が発生しないSandboxと、本番のProductionの2環境を提供します。Sandboxでは、テスト用のカード番号や擬似的な決済結果を使って、成功・失敗・返金・Webhook通知までを本番と同じAPI形状で検証できます。開発初期はSandboxのアクセストークンとアプリケーションで実装・テストを固め、本番切り替え時にProductionの資格情報へ差し替えるのが、事故を減らす進め方です。環境ごとに資格情報とWebhookの宛先を分けて管理し、テストデータが本番に混ざらないようにすることが運用の要点です。

Square APIの決済フロー｜Web Payments SDKとトークン化

Squareの決済実装を理解する鍵は、フロントでのトークン化と、サーバーでの決済作成の役割分担です。ここを押さえると、カード情報をどこにも保持せずに決済を通す型が見えてきます。

Web Payments SDKでカードをトークン化する仕組みと前提条件

オンラインのカード決済は、フロントに組み込むWeb Payments SDKが起点です。SDKが提供する入力フォームでカード情報を受け取り、その場でSquareへ送ってトークン化し、単回利用の支払いトークン（source_id）を生成します。カード番号そのものは自社サーバーを通らず、ブラウザから直接Squareへ渡るため、事業者が保持するのはトークンだけになります。なお2025年10月1日以降、Web Payments SDKの実装にはSecure Contexts（HTTPS）と適切なCSP（Content Security Policy）の設定が求められる点に注意が必要です。

Payments APIで決済を作成する流れと冪等キーによる二重課金防止

トークンを受け取ったあとの標準的な決済は、次の流れで組み立てます。カード番号をサーバーに通さないことが、PCI DSS準拠範囲を小さく保つ設計の前提です。

1. トークン生成：フロントのWeb Payments SDKで、入力されたカード情報を単回利用の支払いトークン（source_id）に変換します。
2. トークン送信：生成されたトークンだけを自社サーバーへ送ります。生のカード番号は自社を経由しません。
3. 決済作成：サーバーでPayments APIのCreatePaymentを呼び、source_id・amount_money・idempotency_keyを指定して決済を作成します。
4. 結果確認：返ってきたPaymentオブジェクトのstatus（COMPLETEDなど）で成否を確認し、注文確定などの後続処理へ進みます。

決済作成のような変更系リクエストにはidempotency_key（冪等キー）が必須で、通信のタイムアウトなどで同じリクエストが再送されても、二重に課金されないよう一意なキーで保護します。決済作成時に売上確定を保留し、与信枠の確保だけを先に行う運用も可能で、この与信と確定を分ける考え方はオーソリ（決済オーソリゼーション）そのものです。予約商材や在庫確保が絡む決済では、確保と確定のタイミングを分けて設計します。

Square APIの主要リソースと実装パターン｜注文・顧客・定期課金・Webhook

Payments単体でも決済は通りますが、実サービスではOrdersやCustomers、Subscriptions、Webhookを組み合わせて運用します。どのリソースに何を任せるかを決めると、自前で状態管理を抱え込まずに済みます。

Orders・Customers・Catalogで注文と顧客・商品を束ねる設計

Ordersは、複数の明細・税・割引・配送などを1つの注文として束ねるリソースで、Paymentsと紐付けることで「何を・いくらで・誰に」売ったかを一貫して記録できます。顧客情報はCustomersに保存し、カードはCards on Fileとして安全に保管でき、再決済にも回せる設計です。商品マスタや価格・在庫はCatalogとInventoryで管理でき、これらを組み合わせると、単発の決済ではなくEC・POSとしての取引全体をSquare上で表現できます。自前で注文テーブルや在庫ロジックを組む前に、これらの標準リソースで賄える範囲を見極めると、設計が軽くなります。

Subscriptionsによる定期課金とCardsによるカードオンファイルのCV設計

定期課金は、価格や請求間隔を定義するCatalogのサブスクリプションプランと、それを顧客へ割り当てるSubscriptions APIで実装します。更新日の計算や請求の繰り返し、停止・再開といった状態管理をAPIに委ねられるため、課金スケジューラを自前で持つ負担を減らせます。継続課金や再決済に使うカードは、CustomersにCards on Fileとして保存し、次回以降はトークンの再取得なしで決済を作成する形です。定期課金は決済の中でも状態遷移が複雑になりやすいため、プラン変更・日割り・失敗時の再試行といった要件を最初に洗い出しておくことが、後戻りを防ぎます。

Webhookの署名検証と決済結果を非同期に受け取る実装の要点

決済の成否や返金、サブスクリプションの更新といったイベントは、Webhookで非同期に受け取ります。SquareはイベントごとにHTTP POSTを送り、リクエストヘッダのx-square-hmacsha256-signatureにHMAC-SHA256の署名を付与する仕組みです。受信側は、署名キーとリクエストURL・本文から署名を再計算して一致を検証し、なりすましのリクエストを弾く必要があります。Webhookは再送される前提で、同じイベントを複数回受け取っても副作用が起きないよう冪等に処理を組む設計です。決済完了の確定判定をフロントの戻り値だけに頼らず、Webhookでのサーバー側確認と二重化しておくと、通信断や離脱があっても売上の取りこぼしを防げます。

Square APIとStripe・PAY.JPの選び分け｜採用判断の軸

ここからは判断を言い切ります。Squareは万能ではなく、その統合設計から「合う要件」と「過剰・不利になる要件」がはっきり分かれます。

Squareの採用が合うプロダクト要件と事業フェーズの具体条件

次の条件が2つ以上重なるなら、Squareの採用が合います。第一に、実店舗とオンラインの両方で売上を立て、在庫・顧客・売上を一元管理したいこと。第二に、POSレジやカードリーダー、Terminalなど対面決済の仕組みも同じ基盤で揃えたいこと。第三に、注文・在庫・顧客まで含めた商取引全体をひとつのプラットフォームで扱いたいこと。第四に、飲食・小売・サービス業のように店頭とネットの導線がつながる業態であること。これらはSquareのユニファイドコマース設計が直接支える領域で、オンライン決済だけの用途にはむしろ機能が広すぎる場合があります。

Stripe・PAY.JPと比較して見送る・切り替える場面の判断

逆に、次の場面ではSquareだけで完結させず、比較や切り替えを検討します。多通貨・越境ECで海外発行カードや現地決済手段を幅広く扱い、従量課金の細かな按分など高度な請求ロジックが主眼なら、機能の厚いStripeのほうが自前実装を減らせる場面です。逆に、実店舗を持たず国内のカード決済をシンプルに組むだけなら、国産で日本語ドキュメントが整うPAY.JPのほうが学習コストを抑えられます。3者は「対面＋オンライン統合（Square）⇔ グローバル多機能（Stripe）⇔ 国産シンプルAPI（PAY.JP）」という軸で性格が異なるため、対象市場・販売チャネル・請求ロジックの複雑さを並べて選ぶのが妥当です。なお日本での決済手数料は取扱高や対面・オンラインの別で変わるため、公式の料金ページで実料率を確認してから総コストを見積もります。

内製での実装と受託開発を分ける判断軸と外注が向く具体的な局面

内製と受託開発の分岐点は「決済フローと基幹連携にどれだけ独自要件があるか」です。Web Payments SDKとPayments APIで完結する標準的なカード決済なら、SandboxとSDKが整うSquareは内製で十分に回せます。一方、実店舗POSと在庫・会計システムの連携、Subscriptionsでの複雑な課金設計、OAuthを使うプラットフォーム型でのマルチテナント設計、Webhookの署名検証・冪等処理・再送対策まで絡むと、初期の設計品質がその後の事故率を大きく決める局面です。ここは決済とシステム連携の設計経験がある体制で固めたほうが、後戻りコストを抑えられます。要件が重い決済・サブスクリプションの構築は決済・サブスクリプションシステムの受託開発で設計から相談でき、POSや基幹システムとのつなぎ込みはAPI開発・システム連携の領域として切り出せます。内製で走り出しつつ、難所だけ外部の設計を挟む進め方も有効です。

Square API導入でよくある質問｜認証・実装・安全性の疑問

Square APIの導入検討でよく挙がる質問に、開発・費用・セキュリティの観点から簡潔に答えます。

Square APIは無料で使えますか？決済手数料はいくらですか？

Square APIの利用そのものに月額のAPI利用料はかからず、費用は決済ごとの手数料が中心です。日本での決済手数料は、対面か非対面（オンライン）か、年間の取扱高などの条件によって変わり、対面ではSMB向けの優遇料率と標準料率が用意されています。実際の適用料率は条件で確定するため、公式の料金ページで自社の販売チャネルと想定売上を前提に確認し、総コストを見積もってから採用可否を判断します。

Square APIとStripe・PAY.JPはどれを選ぶべきですか？

実店舗とオンラインの両方で売上を立て、POS・在庫・顧客まで一元管理したいならSquareが向きます。多通貨・越境や高度な請求ロジックが主眼ならStripe、実店舗を持たず国内カード決済をシンプルに組むだけならPAY.JPが向きます。販売チャネル（対面の有無）・対象市場・請求ロジックの複雑さを並べ、要件で選ぶのが妥当です。

Square APIの実装にはどの程度の開発工数がかかりますか？

オンラインの標準的なカード決済は、フロントのWeb Payments SDKでのトークン化と、サーバーのPayments APIでの決済作成という二段構えで組め、Sandboxで検証できるため小〜中規模で実装できます。Orders・Subscriptions・Webhookの処理や、実店舗POSとの連携を含めるほど設計・テストの比重が上がるため、まず単発決済で公開し、段階的に機能を足す進め方が現実的です。

Square APIはOAuthやSandboxに対応していますか？

対応しています。他のSquareアカウントに代わってAPIを呼ぶプラットフォーム型ではOAuth 2.0でスコープ付きのアクセストークンを取得し、自社完結の用途では個人アクセストークンを使う形です。検証には実請求の発生しないSandbox環境が用意され、テスト用カードで成功・失敗・返金・Webhookまでを本番と同じAPI形状で確認してから、Productionの資格情報へ切り替えます。

Square APIはPCI DSSやセキュリティの面で安全ですか？

Web Payments SDKのトークン化を使えば、カード番号はブラウザから直接Squareへ送られ、自社サーバーを経由しないため、事業者側のPCI DSS準拠範囲を最小構成へ寄せられます。加えて、決済作成には冪等キーで二重課金を防ぎ、Webhookはx-square-hmacsha256-signatureの署名検証でなりすましを弾く二重の防御です。自前フォームでカード番号を受ける実装は準拠範囲が広がるため避け、アクセストークンをサーバー側で秘匿する運用と組み合わせます。

関連記事

• Stripeとは？決済プラットフォームの仕組み・手数料・実装パターンを開発視点で解説：グローバル志向のStripeと比較し、多通貨・多機能が必要な場面での選び分けを確認できます。
• PAY.JPとは？国産決済APIの手数料・実装フロー・Stripeとの選び分けを開発視点で解説：実店舗を持たず国内カード決済をシンプルに組むケースで、Squareとの違いを比較できます。
• オーソリ（決済オーソリゼーション）とは？仕組み・売上確定との違いと実装パターンを開発視点で解説：Squareで与信確保と売上確定を分ける決済の考え方を掘り下げられます。
• 決済システムとは？仕組み・種類と、決済代行との接続方式・自社構築の判断軸を解説：Squareを含む決済方式全体の選び方と、自社構築の判断軸を整理できます。
• 決済・サブスクリプションシステム開発：定期課金やPOS連携など、要件が重い決済実装を設計から相談できます。
• API開発・システム連携：Squareと基幹システム・外部サービスをつなぐAPI連携の設計・実装を切り出せます。