Shop Cash に向けてシステムを準備する

外部サービスで Shop Cash のワークフローをローンチする前に、以下の要件を確認してください。

• ERP、OMS、フルフィルメント、会計、返品の各システムが、1 件の注文に対して複数の決済方法を受け入れることができる。
• ゲートウェイ値が利用可能な場合、shop_cash が決済方法としてマッピングされている。
• Shop Cash がディスカウント、ギフトカード、またはストアクレジットとして扱われていない。
• オーソリゼーション値が、少なくとも 1024 文字の不透明な可変長文字列として保存されている。可能であれば、制限のないテキストフィールドを使用している。
• 売上処理、無効化、および返金が、オーソリゼーション値ではなく取引 ID によって識別されている。Admin API の売上処理および無効化の操作には parentTransactionId を使用し、返金操作には parentId を使用している。
• システムが Shop Cash のオーソリゼーション値を構文解析、デコード、正規化、ハッシュ化、または切り捨てていない。
• システムがグループ化された支払いを処理でき、1 つの shop_cash_credit の行で複数の注文を表すことができる。
• 照合ワークフローで、1 件の注文と 1 つの支払いの行が等しいことを前提としていない。
• 照合ワークフローで、Shop Cash の部分と、カードまたは Shop Payの分割払い の部分が、異なる支払いで決済される処理に対応できる。
• 返金ワークフローで、カードまたは Shop Payの分割払い と Shop Cash にまたがる一部返金を処理できる。
• 返金アプリが、オーソリゼーション取引ではなく、Shop Cash の売上処理の取引を返金できる。
• 2026 年 1 月以前に Shop Campaigns を実行していた場合、財務ワークフローにおいて、過去の shop_cash_campaign_billing_debit や関連するキャンペーン請求の行を、注文の収益とは別に処理している。2026 年 1 月以降のキャンペーン費用は、代わりに Shopify の請求に課金されます。

Shop Cash は Shop の購入者アカウント、Shop Cash の残高、Shopify ペイメント、および Shop Cash の決済インフラストラクチャに依存しているため、Shop Cash のテストには制限事項があります。

エンタープライズの連携をエンドツーエンドで検証する最も信頼性の高い方法は、Shop を通じて少額の本番環境の注文を行い、その後で返金することです。これにより、本番環境と同様の注文取引、売上データ、支払いアクティビティ、返金取引、返金引き落としアクティビティが作成され、管理画面、Admin API データ、支払いエクスポート、および支払い API データを通じて処理されます。

開発ストアは、一部の API フィールドの形状やマッピングロジックを検証するのに役立ちますが、Shop 発の完全なチェックアウト、購入者の残高、および決済フローを確実に行えるわけではありません。テストモードや Bogus ゲートウェイは、実際の Shopify ペイメント の決済フローを使用しないため、本番環境と同様の Shop Cash の支払いの行を作成しません。

通常、Shop から開始された少額の本番環境の注文を使用して、以下のワークフローをテストできます。

• Shop Cash と Shop Pay または Shop Payの分割払いを含む、複数決済方法による注文の取り込み。
• shop_cash のための ERP または OMS のマッピング。
• Shop Cash の完全なオーソリゼーション値の保存。
• 注文に対する全額返金および一部返金。
• shop_cash_refund_debit の支払いアクティビティの取り込み。
• Shop Cash クレジットの支払い照合。
• ストアで遅延決済を使用している場合の、予約注文またはフルフィルメント時の売上処理の動作。
• 複数の決済方法を含む注文に対する返品アプリの処理。

本番環境でテストを行う場合は、少額の注文を使用し、ストア内部のテスト注文および返金の手順に従ってください。

以下のいずれかの状況でサポートが必要な場合は、Shopify サポートにお問い合わせください。

• ロールアウト中のマーケットに対する Shop Cash の利用可否の確認。
• 失敗した Shop Cash の売上処理または返金の調査。
• 通常の支払いサイクルにさらに 1 回の支払いサイクルを加えた後でも、Shop Cash の支払い取引が不足している場合の調査。
• 無効になった、または期限切れになった Shop Cash のオーソリゼーションを再オーソリできるかどうかの確認。
• 複雑な ERP、OMS、予約注文、またはフルフィルメントのワークフローのローンチ計画。

Shop Cash の注文量を拡大する前に、以下の確認を完了してください。

• shop_cash に対して、ERP と OMS の決済方法のマッピングがデプロイされ、検証されている。
• サンプルの Shop Cash の注文が、オーソリゼーションと売上処理の取引を含めてエンドツーエンドで取り込まれている。
• サンプルの Shop Cash 支払いクレジットが、元の 1 件または複数の注文と照合されている。
• サンプルの Shop Cash の返金が処理され、返金引き落としと照合されている。
• グループ化された Shop Cash の支払いの行がサポートされているか、手動による照合プロセスが用意されている。
• サポートチームと財務チームが、一部返金の割り当てについて理解している。
• 該当する場合、予約注文、手動の売上処理、およびフルフィルメント時の売上処理の動作が検証されている。
• 返品アプリが、正しい Shop Cash 売上処理の取引を識別して返金できる。
• サポートチームと財務チームが、お客様の Shop Cash 残高、Shop のオファー、および Shop Campaign の請求アクティビティの違いを把握している。

API と注文データの要件については、「Shop Cash の注文データと外部サービスの連携」を参照してください。支払いの要件については、「Shop Cash の支払いの照合」を参照してください。