Shopify×Stripe連携の実装：Shopify ペイメントの仕組みとヘッドレス構成の決済設計

ShopifyでStripeを使いたいとき、日本のストアではまず「Shopify ペイメントの決済処理はStripe Japanが担っている」という事実から考えます。本記事では、ShopifyとStripeをつなぐ4つの経路を整理し、自前のStripeアカウントをShopifyのチェックアウトへ直接つなげない理由、ヘッドレスのStorefront APIカートからShopifyチェックアウトへの接続実装、決済後の注文をWebhookで受ける処理を、コードを添えて解説する内容です。あわせて、Stripeで決済してShopifyへ注文だけ記録する構成がShopify API規約に触れる根拠も、2026年10月時点の条文で示します。

まとめ：ShopifyでStripeを使うならShopify ペイメント経由が基本線

日本のShopify ペイメントの処理事業者はStripe Japanです。ShopifyのストアでStripeの決済基盤を使いたいなら、Shopify ペイメントを有効にするのが正規の経路になります。自前のStripeアカウントの残高やダッシュボードで売上を管理したい、という要望はこの経路では満たせません。

ヘッドレス構成でも、決済はShopifyのチェックアウトに任せます。Storefront APIのcartCreateで得たcheckoutUrlへ購入者を遷移させ、決済後の注文はorders/paidのWebhookで受け取る形が公式の手順に沿った実装です。

避けるべきなのは、自前の画面でStripeに決済させ、Admin APIのorderCreateでShopifyへ注文を書き込む構成です。APIとしては書けますが、Shopify API規約2.3.18が書面許可のない代替チェックアウトと、それに伴うAPI経由の取引登録を禁じています。Stripe側の柔軟さが必要な取引は、Shopifyの外で別に受けるか、Shopifyを外してStripe単独で組むかを先に決めてください。

ShopifyとStripeをつなぐ4つの経路と、日本のストアで選べる構成

「ShopifyとStripeの連携」と一口に言っても、実際の経路は4つあり、規約上の扱いも手数料もそれぞれ違います。最初に経路を見分けると、以降の実装判断が速くなります。

日本のShopify ペイメントとStripe Japanの関係を示す処理事業者一覧

Shopifyが公開しているShopify ペイメントの処理事業者一覧では、Japanの行に「Stripe Japan, Ltd.」と記載されています（2026年10月19日確認）。米国は「Stripe, Inc.」と「PayPal, Inc.」、カナダは「Stripe Payments Canada, Ltd.」です。つまり日本でShopify ペイメントを有効にした時点で、カード決済の裏側ではStripeの基盤が動いています。

ただし契約の相手はShopifyです。Shopify ペイメント利用規約は、利用者が「指定国に所在する事業者」であることを条件にしており、入金や返金もShopifyの管理画面で扱います。Stripeのダッシュボードで売上を見たり、Stripe側のAPIで返金したりする運用にはなりません。

自前のStripeアカウントを直接つなげない理由と決済アプリの承認制

Shopifyのチェックアウトに表示される決済手段は、Shopifyの決済プラットフォームに載った決済アプリが提供します。Shopifyの決済拡張の開発ドキュメントには「承認済みのパートナーだけが決済拡張を開発できる」と明記されており、収益分配を含むパートナー要件への同意も必要です。カスタムの決済拡張を作れるのは、対象となるShopify Plusの加盟店に限られます。

開発会社が「自社のStripeアカウントにつなぐ決済アプリ」を自作して入れる道は、通常のプランでは閉じています。管理画面の決済設定に第三者決済として何が並ぶかは国とストアの条件で変わるため、案件ごとに実際の一覧で確認してください。Plusの条件はShopify Plusと通常プランの機能差を整理した記事で扱っています。

ShopifyとStripeをつなぐ4経路の比較、決済画面・取引手数料・規約上の可否

経路ごとの違いを1枚にまとめます。表のShopify ペイメントは、Stripe Japanが処理を担う経路です。手数料の実額はShopifyの料金プランと手数料の総額を整理した記事に譲り、ここでは発生の有無だけを示します。

Shopifyヘルプの第三者決済サービスのページは、第三者・代替決済を通る取引すべてに取引手数料がかかり、Shopify ペイメントを主な決済にしている場合はPayPalの取引だけが免除されると説明しています。実務で検討に値するのは上の3行で、4行目は次の章以降で理由を示すとおり選びません。

ヘッドレスのStorefront APIカートからShopifyチェックアウトへの接続実装

Next.jsなどで独自のフロントを組むヘッドレス構成でも、決済はShopifyのチェックアウトが受け持ちます。フロント側が作るのは「カート」までで、支払い画面は作りません。構成と費用の考え方はmicroCMSとShopifyのヘッドレス構成を解説した記事にまとめています。

cartCreateでカート作成とcheckoutUrl取得を行うcurlの実装例

Storefront APIのリファレンスでは、2026年10月時点の最新版は2026-10で、公開アクセストークンはX-Shopify-Storefront-Access-Tokenヘッダーで送ります。次のリクエストで、商品バリアントを1点入れたカートを作り、決済画面のURLを受け取れます。

curl -X POST "https://{shop}.myshopify.com/api/2026-10/graphql.json" \
  -H "Content-Type: application/json" \
  -H "X-Shopify-Storefront-Access-Token: {storefront-access-token}" \
  -d '{"query":"mutation { cartCreate(input: { lines: [{ quantity: 1, merchandiseId: \"gid://shopify/ProductVariant/1\" }], buyerIdentity: { countryCode: JP } }) { cart { id checkoutUrl } userErrors { field message } } }"}'

応答のcheckoutUrlは、カート操作の公式ガイドが「ShopifyのWebチェックアウトへ購入者を案内するURL」と説明しているものです。{shop}とgidの数値は自店舗の値に置き換えます。userErrorsが空でないときは在庫切れや存在しないバリアントなので、フロント側で表示を分けてください。

Shopify-Storefront-Buyer-IPなどサーバー側のヘッダー設定

同じガイドは、サーバー側からStorefront APIを呼ぶ場合にShopify-Storefront-Buyer-IPヘッダーで購入者のIPアドレスを渡すよう求めています。Next.jsのRoute HandlerやサーバーコンポーネントからAPIを呼ぶ構成では、このヘッダーが抜けると全リクエストがサーバーのIPから来たように見えます。

サーバー側ではプライベートアクセストークンをShopify-Storefront-Private-Tokenヘッダーで送り、公開トークンはブラウザ側に限定します。ログイン済みの購入者にはbuyerIdentityにcustomerAccessTokenを設定すると、チェックアウトもログイン状態で始まります。

決済画面をiframeやJavaScript SDKで自社ページへ埋め込まない理由

見た目をそろえたいという理由で、Shopifyのチェックアウトを自社ページ内へ取り込みたくなる場面があります。Shopify API License and Terms of Use（2026年10月7日更新）は、Shopify Checkoutの使い方を「Pop-Up Implementation」に限る規約です。この定義は「決済画面が別のブラウザウィンドウで開く実装」で、iframe要素、JavaScript SDK、直接のAPI連携で表示する実装は当てはまらないと明記されています。

決済画面は自社ページに埋め込まず、checkoutUrlでShopify側の画面へ移す公式手順に沿ってください。チェックアウトの見た目を変えたい場合は、Shopifyのチェックアウト設定やPlusのチェックアウト拡張の範囲で対応します。規約の当てはめに迷う設計は、実装前にShopifyへ書面で確認するのが安全です。

決済完了後の注文データをWebhookで受けて基幹・会計へ渡す手順

Shopify ペイメントで決済した売上を、在庫や会計の自社システムへ流す処理はWebhookで組みます。Stripe側のWebhookではなく、Shopifyのorders/paidなどのトピックを購読する点が、Stripe単独の実装との違いです。

Node.jsによるWebhookのX-Shopify-Hmac-SHA256署名検証例

Webhook配信の検証ガイドによると、HTTPSの配信にはX-Shopify-Hmac-SHA256ヘッダーにBase64のHMAC署名が付きます。アプリのクライアントシークレットを鍵に、生のリクエストボディで計算したHMAC-SHA256との比較が検証方法です。ボディをJSONとして先に解析すると検証できないため、Expressではexpress.rawを使います。

import express from 'express';
import crypto from 'node:crypto';

const app = express();
const secret = process.env.SHOPIFY_API_SECRET; // アプリのクライアントシークレット

app.post('/webhooks/orders-paid', express.raw({ type: 'application/json' }), (req, res) => {
  const received = Buffer.from(req.get('X-Shopify-Hmac-SHA256') || '', 'base64');
  const expected = crypto.createHmac('sha256', secret).update(req.body).digest();
  // 長さが違うとtimingSafeEqualが例外を投げるため先に比べる
  if (received.length !== expected.length || !crypto.timingSafeEqual(received, expected)) {
    return res.status(401).end();
  }
  const webhookId = req.get('X-Shopify-Webhook-Id');
  // 重い処理はキューへ回し、ここではすぐ200を返す
  enqueue({ webhookId, order: JSON.parse(req.body.toString('utf8')) });
  res.status(200).end();
});

app.listen(3000);

enqueueは自社のジョブキューへ積む関数の置き場所です。署名が合わないリクエストは401で返し、注文の処理には進めません。

5秒以内の応答と8回再試行を前提にした冪等な受信処理の組み方

同じガイドでは、Shopifyの待ち時間は接続1秒、リクエスト全体で5秒です。応答できないと4時間のあいだに8回再試行し、Admin APIで登録した購読は8回続けて失敗すると自動で削除されます。会計システムへの書き込みを受信処理の中で同期的に行うと、この5秒を超えやすくなります。

再試行があるので、同じ注文が2回届く前提で作ります。X-Shopify-Webhook-Idを保存し、処理済みのIDなら何もせず200を返すのがガイドの推奨です。同じ操作から複数の購読へ届いた配信はX-Shopify-Event-Idが共通なので、関連付けにはこちらを使います。署名検証と冪等化の考え方はStripeのWebhookと共通で、決済Webhookの署名検証と冪等な注文確定を解説した記事で詳しく扱っています。

自前のStripe決済をorderCreateで記録する構成がAPI規約に触れる根拠

「決済はStripe、在庫と配送はShopify」という分担を考える開発者は少なくありません。APIだけを見ると実装できてしまうため、規約を読まずに作り始めると後で作り直しになります。

orderCreateのtransactionsとgatewayによる取引記録の仕様

Admin GraphQL APIのorderCreateミューテーションはwrite_ordersスコープで呼べます。取引を表すtransactionsにはgateway（決済ゲートウェイ名）、kind、status、amountSet、receiptJsonなどを指定でき、外部で決済済みの注文を「支払い済み」として作ること自体は仕様上できます。

開発ストアやトライアルストアでは1分あたり5件までという作成上限があり、明細ごとの割引を複数かける指定にも対応していません。自動割引は自前で同じ計算を再現しない限り効かないため、技術面でもShopifyのチェックアウトが持つ機能を作り直す量は多くなります。

API規約2.3.18が禁じる代替チェックアウトと取引登録の範囲

決定的なのは規約です。Shopify API License and Terms of Useの2.3.18は、Shopifyの明示的な書面許可がない限り「Shopifyの加盟店のために、Shopify Checkoutの代わりとなるチェックアウトや決済処理を使うこと、またはそれに関連してShopify API経由で取引を登録すること」を禁じています。自前画面でStripeに決済させ、orderCreateで注文と取引を書き込む構成は、この文言にそのまま当たります。

規約冒頭の拘束力のない要約にも「決済にはShopify Checkoutを使い、他のWebチェックアウトや決済処理へ流さない」とあります。書面許可を得る見込みがないなら、この構成は設計段階で外してください。卸売の受注や電話注文を管理画面から手入力する運用とは別の話で、問題になるのは購入者向けの決済をShopifyの外へ流す点です。

ShopifyとStripeを併用してよい場面と、Stripe単独へ寄せる判断基準

ここまでの制約を踏まえても、ShopifyとStripeの両方を契約して使い分ける構成は成り立ちます。線を引く基準は「その取引がShopifyのストアでの購入かどうか」です。

店舗外の請求やBtoBの後払い、予約金をStripe側で分けて受ける構成

Shopifyのストアで売る商品とは別に、工事費の請求、法人向けの月額保守、イベントの予約金のように、カタログとカートを通らない取引があります。こうした取引をStripeの請求書やStripe Checkoutで受けるのは、Shopify Checkoutの代わりではないため2.3.18の対象外です。

この場合、売上はShopifyとStripeの2つの管理画面に分かれます。会計への連携は、Shopifyは前章のorders/paid、Stripeはcheckout.session.completedなどのイベントを受けて、自社側でまとめる設計です。Stripe側の実装はStripe Checkoutのセッション作成とWebhookでの注文確定を解説した記事、APIの基本はPaymentIntentの作成と冪等キーをコードで示した記事が参考になります。

Shopifyを外してStripe Checkoutで組むほうが合う商材と規模の条件

次のどれかに当てはまるなら、Shopifyを使わずStripeと自前のカタログで組むほうが無理がありません。

• 売るものが数種類の料金プランや利用権で、在庫・配送・テーマの機能をほとんど使わない
• Stripe Connectで出店者へ売上を分配するなど、決済の資金の流れ自体が事業の中核にある
• Stripeのダッシュボードと既存の会計連携を、売上管理の正本として使い続けたい

逆に、物販で商品点数が多く、配送・在庫・ストア運営をShopifyに任せたい場合は、決済をShopify ペイメントに寄せるほうが総額は下がります。Stripeを使いたい理由が「すでにアカウントがある」だけなら、Shopify側へ寄せる判断で問題ありません。Stripeそのものの仕組みと料金はStripeの仕組み・手数料・実装パターンをまとめた記事で確認できます。

構成選定と規約確認を開発会社へ依頼するときに渡す3項目の情報

見積もりや相談の前に、①Shopifyのストアで売る取引と、それ以外の取引の一覧、②売上の正本をどの管理画面に置くか、③ヘッドレスにする理由（表示速度、既存CMSとの統合など）、の3項目を整理しておくと、経路の選定が1回の打ち合わせで終わります。ここが曖昧なまま「ShopifyとStripeをつなぎたい」と依頼すると、規約に触れる構成で見積もりが出てくることがあります。

一創では、Shopify ペイメントを前提にしたストア構築から、ヘッドレス構成のカート実装、注文Webhookから基幹・会計への連携までを受託しています。どの経路を選ぶかの段階から相談したい場合は、ECサイト制作・Shopify構築のサービスをご覧ください。工程と外注範囲の考え方はShopify構築の進め方を解説した記事にあります。

よくある質問

ShopifyとStripeの連携を検討する際によく寄せられる質問をまとめました。

日本のShopifyストアでStripeを決済手段として追加できますか？

日本ではShopify ペイメントの処理事業者がStripe Japanなので、Shopify ペイメントを有効にすればStripeの基盤でカード決済を受けられます。一方、自前のStripeアカウントをそのまま決済手段としてつなぐことは、Shopifyの決済アプリが承認制であるため通常はできません。管理画面の決済設定に並ぶ選択肢は国やストアの条件で変わるので、実際の一覧で確かめてください。

Shopify ペイメントの売上はStripeのダッシュボードで確認できますか？

確認できません。Shopify ペイメントの契約相手はShopifyで、売上・入金・返金はShopifyの管理画面で扱います。処理の裏側でStripe Japanが動いていても、加盟店に自分のStripeアカウントが用意されるわけではありません。Stripe側で売上を管理したい取引は、Shopifyの外でStripeの請求書やCheckoutを使って受ける構成に分けます。

ヘッドレスコマースならStripeで決済できますか？

ヘッドレスにしても、Shopifyで売る商品の決済はShopifyのチェックアウトで行います。Storefront APIのcartCreateで作ったカートのcheckoutUrlへ購入者を遷移させるのが公式の手順です。自前の画面でStripeに決済させ、orderCreateで注文を記録する構成は、API規約2.3.18で書面許可が必要とされています。

Shopify ペイメントを使わずに外部決済だけで運用するとどうなりますか？

第三者・代替決済を通る取引には、Shopifyの取引手数料が決済会社の手数料とは別にかかります。Shopify ペイメントを主な決済にしている場合でも、免除されるのはPayPalの取引だけです。料率はプランごとに違い、月商によっては上位プランへの切り替えで総額が下がることもあるため、料金と手数料の記事で分岐点を確認してください。

ShopifyとStripeの顧客データや注文を自動で同期してよいですか？

決済を伴わない参照や集計のための同期は、決済の代替にあたりません。たとえばShopifyのorders/paidを受けて会計システムへ送る処理や、Stripeで受けた別取引と同じ顧客を名寄せする処理は組めます。ただし個人情報を外部サービスへ渡す場合は、Shopifyの規約と自社のプライバシーポリシーの両方で、移転先と目的が説明できるかを先に確認してください。

関連記事

• Stripeとは？決済プラットフォームの仕組み・手数料・実装パターンを開発視点で解説：Stripe単独で組む場合の全体像。
• Shopifyの料金プランと手数料｜総額と乗り換えラインの判断：第三者決済の取引手数料の実額と分岐点。
• microCMSとShopifyを連携したECサイト構築｜ヘッドレス構成・費用・API制限の実務：ヘッドレス構成の費用と体制。
• Shopify Liquidとは？テーマ開発の構造・構文とShopify CLIでの始め方：ヘッドレスにしない場合のテーマ側の実装。
• ECサイト構築とは？5つの構築方法の費用相場と、自社に合う進め方の判断軸を解説：Shopify以外も含めた構築方法の比較。