Shopify POSの更新後に会計・返金を止めない｜店舗別の回帰テスト台帳とギフトカード返金・分割返金の確認手順
ON THIS PAGE▼
Shopify POSの更新後に確認すべきなのは、「商品を売れるか」だけではありません。レジでの会計操作、返品時の返金先、在庫の戻し先、レシート、スタッフ権限まで、日常業務で使う一連の操作が店舗方針と一致することを確認する必要があります。
とくに、現金返金を原則にしない店舗、ギフトカードでの返金を選択肢にする店舗、複数の支払い方法を受ける店舗では、通常販売を1件試すだけでは確認が不足します。Shopify POSには、返金方法ごとの上限、管理画面で返品を開始した注文に関する制約、ギフトカード返金の適用条件などがあります。
本記事では、Shopify POSのアプリ更新または決済・返品設定の変更後に使う、店舗別の回帰テスト台帳と確認手順を示します。仕様の確認時点は2026年10月5日です。実施前には、利用中の決済事業者、Shopify POSのプラン、接続端末、スタッフ権限に該当する最新のShopifyヘルプも確認してください。
回帰テストを「店舗別」に設計する理由
同じShopifyストアでも、店舗ごとに実運用は異なります。たとえば、販売する商品、在庫ロケーション、利用するカードリーダー、受け付ける支払い方法、返品を受ける担当者の権限は一致しないことがあります。
この差分を無視して本部や代表店舗だけでテストすると、現場で必要な返金先が表示されない、返品商品が意図しないロケーションに戻る、担当者が返金操作を完了できない、といった問題を見落とします。更新後の検証では、アプリの画面が表示されることではなく、各店舗で業務を完了できることを合格条件にします。
台帳を作る前に、店舗ごとに少なくとも次を棚卸しします。
- 店舗名、Shopify POSを使うロケーション、テスト実施端末
- Shopify POSアプリとOSのバージョン
- 使用する決済方法（現金、Shopify Payments、外部決済など）
- カードリーダーなど周辺機器の接続状況
- 返品時の店舗方針（元の支払い方法、ギフトカード、交換対応など）
- 返品商品を戻す在庫ロケーション
- 返金を実行するスタッフの権限とテスト担当者
- レシートの発行方法（紙、メール、SMSなど）
ここで重要なのは、店舗方針とShopify POSの仕様を混同しないことです。たとえば「原則として現金返金をしない」は店舗方針です。一方で、特定の注文をどの返金手段に戻せるかは、元の決済、注文の状態、返金方法、利用サービスなどに左右されます。方針だけを台帳に書くのではなく、その方針を実現できる注文条件もテスト対象に含めます。
最初に作る回帰テスト台帳の項目
テスト結果をチャットや口頭だけで残すと、更新後に何を確認し、どの例外を見送ったのかを追えません。スプレッドシートなどで、店舗ごとに同じ列を持つ台帳を作成します。
| 列 | 記載内容 |
|---|---|
| テストID | 店舗名と連番。例：TKY-REF-03 |
| 実施日・実施者 | 実施日時、担当者、確認者 |
| 前提条件 | ロケーション、端末、アプリ版、ログイン権限、決済方法 |
| 対象注文 | テスト注文番号、商品、数量、元の支払い方法 |
| 操作 | 販売、部分返品、返金、在庫戻し、レシート再発行など |
| 期待結果 | 店舗方針とShopify仕様を踏まえた判定条件 |
| 実結果 | 画面上の選択肢、返金額、在庫数、レシートの確認結果 |
| 証跡 | 注文管理画面、POS画面、レシートの記録場所。顧客情報はマスキング |
| 判定 | 合格、不合格、対象外、保留 |
| 対応 | 設定変更、手順修正、Shopifyサポートへの照会、再テスト日 |
期待結果は「正常にできた」と書かず、観察可能な状態に分けます。たとえば部分返金なら、「返品しない商品の数量と在庫が変わらない」「返品する商品の返金額が指定額である」「返金先の候補が方針・注文条件に合う」「返金後の注文履歴を確認できる」と記録します。
更新前と更新後の画面を単純比較する必要はありません。画面構成が変わっても、スタッフが定めた手順で会計・返金を完了でき、注文・在庫・レシートの結果が正しいなら、業務上は合格と判断できます。
無償の現金テストと実決済テストを分ける
Shopifyの案内では、Shopify POSのテスト取引は現金決済で行います。また、Shopify Paymentsのテストモード中は、Shopify POSのカードリーダーでクレジットカード取引を処理できません。したがって、テストモードでカードリーダーを使ったカード会計から返金までを検証する前提には置けません。
この制約を踏まえ、台帳ではテストを二系統に分けます。
現金テストで確認する範囲
現金テストでは、金銭授受を伴わずに確認できるPOSの基本動作を扱います。
- 商品検索、バーコード読取、カート追加、数量変更、削除
- 割引、税、顧客情報など、店舗で使うカート操作
- 現金での会計完了と注文作成
- 注文検索からの返品・部分返金の画面遷移
- 返品時に在庫を戻すかどうかの選択と結果
- 紙・メール・SMSなど、採用しているレシート発行経路
- スタッフアカウントごとの操作可否
ただし、現金テストで確認できたことを、カードリーダー、外部決済端末、決済事業者側の取消・返金まで確認済みと扱ってはいけません。決済連携固有のエラー、返金先の表示、入金・取消の扱いは別の検証対象です。
実決済テストで確認する範囲
実カード決済を使うテストは、返金を含む決済フローの確認が必要な場合に限定します。実施前に、社内の承認者、使用するカード、購入額、取消または返金の担当者、会計処理の扱いを決めます。カード会社や決済サービス側で発生しうる処理・手数料・反映時刻は、利用契約と各サービスの案内を確認してください。
実決済テストでは、次を別々に判定します。
- カードリーダーまたは利用中の決済手段で会計が完了する
- POSと注文管理画面で支払い状態を確認できる
- 取消ではなく返金が必要な状態になった場合に、許可された返金先を選べる
- 返金後の注文、在庫、レシートまたは顧客連絡が整合する
- レジ締め・売上照合の担当者がテスト取引を識別できる
テスト注文には、社内で識別できる商品やメモの運用を用意します。ただし、通常の顧客に見える説明や在庫・売上レポートへの影響も確認し、テスト終了後に削除・調整できるものと、履歴として残すべきものを事前に決めてください。
通常販売から返品までの最小テストケース
店舗の全商品・全決済を網羅する必要はありません。まずは各店舗の方針を満たす最小ケースを作り、変更があった部分を追加します。以下は台帳に登録する基本セットです。
| ID | ケース | 主な合格条件 |
|---|---|---|
| SALE-01 | 単品を現金会計 | 商品追加、会計、注文作成、レシート発行が完了する |
| SALE-02 | 複数商品・数量変更 | カート内の数量・金額が意図どおりになる |
| REF-01 | 全品返品・元の方法へ返金 | 返金先、返金額、注文履歴、在庫戻しが正しい |
| REF-02 | 一部商品の返品 | 返品対象以外の商品・在庫・支払額に意図しない変更がない |
| REF-03 | 数量の一部を返品 | 返金数量と在庫数量を区別して確認できる |
| REF-04 | 在庫を戻さない返品 | 在庫戻しの選択が反映される |
| RCT-01 | レシート確認 | 採用する発行手段で注文内容・返金内容を確認できる |
| AUTH-01 | 権限確認 | 返金担当者が必要な操作を実行でき、不要な権限を付与していない |
Shopify POSでは、注文の一部を返金できます。また、返金時に返品商品の在庫を戻すかを選択できます。一方で、支払い方法ごとに返金できる金額には上限があり、注文の構成によって操作できる範囲が変わります。そのため、部分返金は「返金ボタンがあるか」ではなく、注文単位で返金額と在庫結果を確認します。
管理画面で返品を開始した注文には、POSからの処理に制約が生じる場合があります。POSで受ける返品を想定するなら、同じ注文を管理画面でも途中まで処理したケースを、必要に応じて別テストとして追加します。オンラインと店舗の双方が返品を受け付ける運用では、このケースを省かないほうが安全です。
また、外部フルフィルメントが関わる商品は、通常の店舗在庫と同じように戻せない場合があります。該当商品を店舗で返品受付する方針なら、商品種別と戻し先を前提条件に記録し、実際の画面で選択できる内容を確認します。
分割決済・分割返金は「元の内訳」を基準にする
分割決済の注文は、合計金額が一致していても、返金先の配分を誤ると注文履歴や顧客説明が複雑になります。テストでは、支払い方法Aと支払い方法Bの金額を台帳に分け、返金前後の残額をそれぞれ記録します。
確認する順序は次のとおりです。
- 元注文で、各支払い方法の金額と支払い状態を確認する
- 返品する商品・数量・返金額を確定する
- POSに表示される返金方法と、方法別に返金できる上限を確認する
- 返金後、各支払い方法の返金額と注文全体の残額を記録する
- 在庫を戻す設定、レシート、顧客への説明内容を確認する
「分割返金」は、単に返金額を複数回に分ける操作とは限りません。複数の支払い方法で受けた注文をどう返すか、という意味でも使われます。台帳には曖昧な表現を残さず、元の決済内訳、今回の返金先、返金額、返金後残額を列として持たせます。
返金先を任意に選べると想定しないことも重要です。Shopifyの返金処理では、支払い方法別の返金上限などの条件があります。実際に表示された選択肢と、店舗の返品方針が一致しない場合は、その場の独自判断で処理を続けず、CS・経理・運用責任者が使う代替手順を決めてから再テストします。
ギフトカード返金は対象注文と例外を先に確認する
ギフトカード返金は、店舗の返品方針を実現する手段になり得ますが、すべての注文に同じように適用できるわけではありません。テスト前に、返金対象の注文がどの決済で処理されたか、返品がどこで開始されたか、サブスクリプション商品を含むかを確認します。
Shopify POSのギフトカード返金に関する公式案内では、既存のギフトカードへ再チャージできるのは、Shopify Paymentsで処理された注文に限られます。また、管理画面で返品を開始した注文には制約があります。Interacを含む分割返金や、サブスクリプション商品についても例外が案内されています。
このため、ギフトカード返金を使う店舗では、少なくとも次のケースを分けて台帳化します。
- Shopify Paymentsで処理した注文から、既存ギフトカードへの返金可否を確認するケース
- 新しいギフトカードを発行して返金する運用を採る場合のケース
- 管理画面で返品開始済みの注文をPOSで扱うケース
- 複数の支払い方法を含む注文のケース
- サブスクリプション商品を含む注文のケース
合格条件は「ギフトカードに返せた」では不十分です。対象の注文条件で返金先として選択できること、返金額が正しいこと、既存カードへの再チャージまたは新規カード発行が運用方針どおりであること、顧客に渡す残高・利用条件の案内が整うことまでを確認します。
例外に当たる注文は、不合格ではなく「対象外」と分類する場合があります。ただし、その場合も現場が迷わないよう、元の支払い方法へ返金するのか、別の返品窓口へ引き継ぐのか、交換として扱うのかを手順書に明記します。機能上できないことをスタッフ教育だけで補おうとすると、レジでの説明が属人的になります。
不合格時の復旧判断とリリース基準
テストで不一致が見つかったとき、直ちに全店舗で更新を止めるべきとは限りません。一方で、返金額、決済、在庫、権限に関わる不一致は、操作説明だけで暫定対応できるかを慎重に判断します。
台帳の不合格には、次の3分類を加えると優先順位を付けやすくなります。
- 会計停止：販売または返金を完了できず、通常営業を継続しにくい
- 金額・在庫影響：誤返金、返金先誤り、在庫差異につながる可能性がある
- 運用差異：操作数や画面位置が変わったが、正しい処理は完了できる
会計停止と金額・在庫影響では、該当店舗の更新・設定変更の展開を保留し、端末状態、アプリ版、注文番号、発生時刻、再現手順をそろえて確認します。Shopifyへの問い合わせが必要な場合にも、台帳の証跡があると、単なる「返金できない」ではなく、どの注文条件で何が表示されたかを共有できます。
運用差異の場合は、更新前の画面へ戻すことだけを目的にせず、操作手順、レジ前の案内、スタッフ研修を更新するコストと比較します。新しい操作が店舗方針と矛盾せず、会計・返金・在庫の結果が正しいなら、手順変更で吸収する選択肢もあります。
最後に、更新を完了とする基準を明文化します。最低限、各店舗で通常販売、採用する決済、代表的な返品、在庫戻し、レシート、必要権限が合格していることを確認します。ギフトカード返金や分割決済を扱う店舗は、該当する例外ケースの結果と代替手順が承認済みであることも条件に加えてください。台帳を次回の更新時に複製して差分だけを追加すれば、検証の漏れを減らしながら、店舗固有の運用を継続して管理できます。
参考情報
この課題、もっと詳しく相談したい方へ
記事では答えきれない個別の状況にもお応えします。