コンテンツ概要
この記事では、ライブ支払いを処理せずに、チェックアウトをテストし、顧客の視点からフローを確認する方法について説明します。
これにより、目標到達プロセスを通過して、顧客のフロントエンドビジュアルだけでなく、フルフィルメントとオートレスポンダーの動作ルール、Zapier、およびWebhook（使用されている場合）を使用して、物事がどのように機能するかを確認できます。
この記事はいくつかのセクションに分かれています。
製品をテストモードに設定する
製品設定で設定できるステータスはXNUMXつあります。
ライブテストモードを無効にしました
これは、最初のオプションタブの製品設定で構成できます。
カートを「テストモード」に設定すると、ライブ支払いは受け付けられなくなります。
カートは、製品アクセス、動作ルール、Webhookなどがすべてトリガーされるという点で、「ライブ」カートと同様に機能しますが、実際の支払いは行われません。
ライブ支払いは処理されないため、ベンダーとして販売通知メールを受信することはありません。
テストモードの製品と顧客からの実際の支払いを受け入れる準備ができている製品との間に混乱がないことを保証するために、いくつかの単純な識別子があります。 記事に飛び込む前に、あなたはチェックすることができます Thrivecartクーポン.
1.製品のステータスは、ダッシュボードの製品サムネイル全体に表示されます。
2.チェックアウトページの上部にあるバナー。
カートのURLにアクセスすると、ライブ支払いが処理されないことを警告する透明なオレンジ色のバナーが上部に表示されているため、テストモードになっていることがわかります。
3.支払いフィールドは黄色になるか、その上にテストモードの警告が表示されます。
Stripeを使用している場合は、テストカード番号（4242 4242 4242 4242）と、CVCの将来の有効期限と3桁をコピーできます。
見つけることができます Stripeで直接異なる結果を得るための他のテストカード番号はこちら チェックアウト時にさまざまなシナリオ（SCAシナリオや辞退など）をテストする場合。
実際の顧客がテストモードで目標到達プロセスを通過する場合、支払いは処理されず、実際のカード支払いを使用できなくなります。
目標到達プロセスのテスト
目標到達プロセスをテストして顧客と同じように処理するには、詳細を入力してから[注文を完了する]ボタンをクリックするだけです。 その後、目標到達プロセスの次のステップ（アップセルまたは成功ページ）に進みます。
覚えておいてください 動作ルール、メンバーシップの履行、Zaps、およびWebhook通知もトリガーされます。 これにより、すべての統合をチェックし、すべてが期待どおりに機能していることを確認できます。
「顧客」として入力した電子メールアドレスは、支払いの領収書を受け取るので、顧客への通知がどのように表示されるかを確認できます。
テスト時のアドバイス：
特にメンバーシッププラットフォームまたはオートレスポンダーをテストしている場合は、テストごとに異なる電子メールアドレスを使用してください。
Gmailなどのサービスを使用すると、既存のメールアドレスに基づいて一意のメールアドレスを簡単に生成できます。これはテストに最適です。
あなたのメールアドレスが [メール保護]、「johnsmith」と「@gmail.com」の間に「+xyz」を追加するだけです。
例えば、 [メール保護]
このメールは引き続き受信トレイで受信されますが、他のシステムでは一意のメールとして扱われます。 「新規顧客」としてテストする場合、これは理想的です。
テストオーダーの表示
デフォルトでは、ダッシュボードにはアカウント内の最新のトランザクションとデータのみが表示されます。 ただし、テストの払い戻しを処理したり、サブスクリプションを管理してZapier、Webhook、その他の統合に関連する追加機能をテストする必要がある場合に備えて、処理するテストモードの順序を表示することをお勧めします。
トランザクション領域でセレクターを有効にするには、[設定]>[アカウント全体の設定]>[財務]に移動し、[モード間の切り替え]オプションを変更します。
それが保存されたら, あなたがあなたに向かうなら 取引 このページの下部にある領域は、切り替えるためのセレクターになります。
システムはオレンジ色に変わり、テストモードデータのレビューを表します。
サブスクリプションのテストモードの注文を完了し、支払い処理業者としてStripeを使用した場合、このサブスクリプションは、テストデータの下のStripeダッシュボードにも設定されていることがわかります。
たとえば、Stripeは期限が到来したときに再請求をトリガーし、それらの「テスト」定期支払いはダッシュボードで追跡され、該当する場合は動作ルールや履行などをトリガーします。
最終テスト
したがって、すべてのテストを終了し、すべてが希望どおりに設定されていることを確認したら、製品を実際に使用して、顧客からの実際の支払いを受け入れ始めます。
テストモードでは検出されない問題が支払いプロセッサ側にないことを確認するために、各プロセッサでライブテストを実行することを常にお勧めします。 あなたはいつでもあなたの製品の価格をXNUMXドル（またはあなたの通貨で同等のもの）に下げ、ライブ支払いでテストし、そしてあなたの価格をあなたの製品の正しい価格に戻すことができます。
または、クーポンを使用して価格を下げ、テストが終了したらクーポンを無効にすることもできます。
ライブペイメントでテストするときは、実際に製品の代金を支払い、無料で提供しないようにしてください。 製品が無料の場合、実際の支払い処理は行われません。
また、製品の稼働中にすべてのテストを実行することはお勧めしません。データが稼働中の統計やトランザクションと混同され、実際の数値が歪むためです。
