分割払いPOCの作成：App Builderの完全デモ

最終更新日： 2026年4月28日

トピック：
App Builder
Paas
Payments

作成対象：

Intermediate
Developer
Leader
User

これは、Adobe CommerceとAdobe App Builder上に構築された分割払い概念実証のエンドツーエンドのチュートリアルです。このデモでは、既にAI ツールとプロンプトを使用して、処理中のCommerce拡張機能とApp Builder アプリを生成していることを前提としています。このビデオでは、そのコードが結合され、ネイティブのLuma テーマを使用してAdobe Commerce Cloud web サイトにデプロイされ、App Builder プロジェクトが公開された後に何が起こるかを示しています。

買い物客は一部現金と一部 Store Credit で支払います。 Commerceは、同期チェックアウトとストアフロントに必要なAPIを所有し、App Builderはオーケストレーション、オペレーターワークフロー、I/O イベントコンシューマーを処理します。参照実装では、多くのマーチャントにとって共通のパスであるEdge Delivery Services ストアフロントではなく、Commerce（PaaS）プロジェクトとLuma ネイティブチェックアウトを使用します。別のトポロジで Adobe Commerce as a Cloud Service を使用する場合、App Builder コードは引き続き似ていますが、ストアフロントと処理中の作業は異なります。オンプレミス、セルフホスト、Luma上のクラウド内のCommerceの場合、このビデオでは、新しい機能に対するインプロセスコードとApp Builderの実用的な分割を示します。

ビデオ

https://video.tv.adobe.com/v/3484100?captions=jpn&learn=on

https://video.tv.adobe.com/vc/3484100/jpn.json

この動画は誰のためのものでしょうか？

Commerceの拡張性を計画するテクニカルアーキテクト
チェックアウトと統合を実装する開発者
PHPとApp Builderの現実的な分離が必要な実装チーム

ストアフロントでシナリオを設定する

デモアカウントには Store Credit があり、チェックアウト時にその残高が表示されます。注文総額が約80 ドルになるまで商品を追加します。このサイズでは、計算で争うことなく、カード辞退と同様に、成功した受け入れパスと辞退パスの両方を表示する余地が得られます。

セッションはストアクレジットを公開する必要があるため、Split paymentはサインインした顧客にのみ提供されます。ゲストチェックアウトでは、分割オプションは表示されません。

Payment ステップで、現金方法を選択します（デモでは、Cash on deliveryの名前が現金に変更されます）。
支払い方法の下に分割された支払い領域が表示されます。キャッシュフィールドは注文合計に事前入力され、コンポーネントはセッションから Store Credit を読み取ります。
～$80 カートの場合、$50の現金と $30 のストアクレジットを設定して、コンポーネントに$50 + $30 = $80が表示されるようにします。
金額が有効な場合は、注文します。

UIは、分割の新しいCommerce REST APIの呼び出しをトリガーします。チェックアウトの同期を維持：Commerceは、ストアクレジットを適用し、注文時に分割明細を保存し、App Builderが後で使用するI/O イベントを発生させます。成功ページは顧客にすぐに提供されます。

Commerce管理者での注文の確認

Sales > Ordersで、新しい注文を開きます。 Payment information領域に分割が表示されます。例えば、$50の現金と $30 の店舗クレジットなどです。現金がまだ収集されていない場合、ステータスは 保留中 です。注文の作成時には、既にストアクレジットが取得されています。

Commentsには、App Builderが追加したテキストを含めることができます。 App Builderの Payment orchestrator action はI/O イベントを受信し、分割金額を確認し、認証されたRESTを使用してコメントを追加しました。 Commerceは他のREST呼び出しと同様に処理され、ライターを知る必要はありません。

App Builderのオペレーターダッシュボード（ERPまたはバックオフィス）の利用

シンプルなHTML エクスペリエンスは、App Builder個のweb アクションとして実行されます（このビューでは Admin 個ありません）。ダッシュボードは Commerce Order のREST APIを呼び出し、保留中にフィルターを実行して、$50の現金足を見つけることができます。

通常、このパターンをERPや不正行為ツールと統合します。 2つのアクションが示されます。

受け入れる – 現金が受け取られたことを確認します（生産中、多くの場合、現金引き出しまたは店舗システムから自動投稿）。
辞退 – 不正行為または失敗した収集ステップをシミュレートします（本番環境で、通常はリスクサービスから自動化されます）。

注文を承諾して完了

App Builder アプリで、Acceptを使用して現金を確認します。
アプリは、キャッシュラインを最終処理する新しいCommerce エンドポイントを呼び出します。コア注文フロー（請求書、およびこのビルドの自動出荷）は、ネイティブの Commerce 動作で実行されます。このパスには Admin に人間が必要ありません。オーケストレーションとエンドポイントはApp Builderにあります。

Adminで同じ注文を更新します。現金が受け入れられ、請求書が添付され、製品が発送可能な場合は、デモで完全なライフサイクルを短縮するための出荷が完了すると、ステータスが完了に移動します。

辞退とキャンセル

まだ辞退シナリオにある事前構築済みの注文を開きます。
App Builder アプリで、辞退を使用して、不正行為またはコレクションの失敗をシミュレートします。
Adminでは、注文は キャンセル済み です。履歴には現金ステータスが表示され、コメントには結果が説明され、買い物客は最終的な販売であるかのようにストアクレジットラインに請求されず、ストアクレジットの請求書はキャンセルで無効になります。また、生産システムは顧客に通知し、在庫やサービスの保留を解除します。

注文合計しきい値（注文が作成される前の検証）

App Builderまたは Commerce 設定は、検証ルールをサポートできます。このビルドでは、$100を超える注文を買い物かごの値でブロックします（変更可能なデモの上限）。値チェックは、最も一般的なビジネスルールではありません。在庫チェックや可用性チェックはより一般的ですが、注文が作成される前に Commerce の Payment で検証を実行できることを示していますが、App Builderは引き続きフォローアップの自動処理を行います。

合計が $100 を超えるまで商品を追加します。
分割 UI は引き続き表示されます。超過制限結果は注文にのみ表示されます。
買い物客に、「支払いを処理できませんでした」などの一般的なエラーが表示されます。もう一度試すか、サポートにお問い合わせください。
cartは変更されていないため、お客様は合計を減らしたり、別の方法を選択したり、サポートに問い合わせたりできます。

リスクスコア、地域ルール、または類似の項目は、ここでプラグインできます。Commerceは注文をブロックし、App Builderは通知を所有し、事後処理を実行できます。

オンプレミスのCommerce、クラウドのCommerce、およびAdobe Commerce as a Cloud Service

このチュートリアルは、管理するインフラストラクチャの Adobe Commerce または従来のストアフロントを使用したCommerce in the cloud （PaaS）と一致します。フロントエンドが異なり、この形状のインプロセスモジュールがないAdobe Commerce as a Cloud service （SaaS）の場合、App Builderの部分はほぼ同じですが、ストアフロントと拡張機能の作業は異なります。いずれの場合も、同じ原則が適用されます。Commerce様にCommerce リクエスト内で必要な処理を実行させ、残りのエクスペリエンスに App Builder を使用させます。