KOMOJU + Shopifyのアップデート

決済アプリ以前、ShopifyはHPSDKというシステムを使っていました。これはHosted Page Software Development Kitの略です。「Hosted Page (ホストページ)」は、お客様があなたのストアで商品の支払いをしようとすると、Shopify以外の誰かが「ホスト」している「ページ」に連れて行かれるという意味です。

新しい決済アプリシステムは、今までと同じくホストページを使用します。主な違いは、オリジナルのHPSDKの後にリリースされたShopifyの包括的なアプリシステムの上に構築されていることです。

新システムの利点

我々はShopify社ではありませんので、彼らがなぜシステムの切り替えすることにしたか明確に説明できませんが、この新システムでどのような改善が期待できるのかについては、概要をお伝えしてみます。

1. OAuthとのプラグ・アンド・プレイ

以前のHPSDKシステムでは、ShopifyストアとKOMOJUアカウントの接続は手作業で行わなければなりませんでした。このプロセスでは、マーチャントがKOMOJUでAPIキーを探してコピーして、それをShopifyストアにペーストする必要がありました。これはかなりエラーの多い作業で、間違ったキーを貼り付けたり、誤ってスペースを入れてしまったりするマーチャントが後を絶ちませんでした。

新しいPayments Appsシステムは、Shopify Appsエコシステムと同じOAuthセットアップを使用しています。これにより、マーチャントはサードパーティの決済プロバイダーを簡単に発見、追加、削除することができます。

これにより、マーチャントはテストモードの認証情報を誤って本番のストアに挿入しないように確認する必要がなくなりました。ShopifyとKOMOJUは、ストアが開発ストアであるかどうか、注文がテストオーダーであるかどうかに基づいて、この処理を自動的に行います。

2. 冪等性 + リトライセマンティクス

Shopifyの新しいPayments Appsシステムでは、サーバー側が不安定になった場合にリトライポリシーが適用されます。これは、KOMOJUがShopifyに接続しようとした際にShopify側で障害が発生した場合、KOMOJUは再試行しなければならないことを意味します。これは、インバウンドとアウトバウンドの両方のすべてのAPIリクエストに適用されます。

もうひとつの要件は、「冪等性」です（これも双方に共通）。ある動作を複数回実行しても、1回だけ実行した場合と同じ結果になる動作を、「冪等性」と呼びます。

上の図では、「注文を支払い済みにする」というリクエストがShopifyのサーバーに届いていますが、そのレスポンスはKOMOJUに戻ってきていません。Shopifyが知っている限りでは、この注文は支払われています。一方、KOMOJUは、この注文の状態を知りません。

ありがたいことに、「注文に支払済マークを付ける」操作は冪等であるため、KOMOJUは重複作業を気にすることなく単純に再試行することができます。Shopifyは実際に処理を行うことなく、成功のレスポンスを返してくれます。実際の処理は前のリクエストで行われています。これは、特に複数回の返金の試行が、「500円を返金してください、おっと何かが間違っていました、もう一度試してください」ではなく、「500円を2回返金してください」という意味になる可能性がある場合に有効です。

まとめると、ユーザーが直面するエラーが少なくなることが期待できます。

新システムの欠点

この記事を書いている時点では、まだいくつかの問題が残っています。遅かれ早かれ、その問題は解決されると思いますが、加盟店とお客様の両方に顕著な影響を与える可能性があるため、認識しておくべきです。

1.注文のステータスに「未確定」がない 

この機能はHPSDKの頃から、KOMOJUが非同期型の決済を実現するために必須だったものです。

お客様が支払いを予約してから、実際に支払いをするまでに時間がかかるものを非同期型と呼んでいます。コンビニ決済の場合、お客様はまずどの店舗で支払うかを選択し、その数時間後（あるいは数日後）に実際に店舗に出向いて支払います。

上図は、ユーザーがコンビニ決済を行う際に、KOMOJUとShopifyがどのように状態を把握するかを示しています。

ここで注意したいのは、クレジットカード決済の「承認（オーソリ）→売上確定（キャプチャ）」の流れとは違うということです。クレジットカード決済の「承認（オーソリ）」とは、基本的に資金がすでにマーチャントに帰属していることを意味します。いつキャプチャーするかは、マーチャントの選択次第です。コンビニ決済や銀行振込の場合は、お客様からの何かの行動を待っている状態です。顧客がいつ支払いをするか、または支払いをしないかを選択します。

Shopifyの新しいPayments Apps APIでは、現在、支払いを保留にすることができません。そのため、以下のようなフローにならざるを得ません：

この通り、Shopifyはキャプチャされるまで「未支払い」状態のままです。これは、以下のような欠点があります。

• Shopifyの注文が「未支払い」状態である間は、お客様はShopifyストアのウェブページに戻ることができません。顧客がShopifyに戻ると、再度支払いを促されます。
• キャプチャされるまで、在庫予約が遅れ、過剰販売の確率が極端に上がります。これは次のポイントにつながります。

2. 過剰販売の可能性

これは、品物が少ない加盟店によく見られる問題です。商品の在庫が定期的に0になる場合は、過剰販売が発生している可能性が高いです。「過剰販売」とは、在庫が0以下になることで、出品した商品よりも多く売れたことという意味です。

チェックアウトは複数のステップのプロセスであり、Eコマースプラットフォームは次の質問に答えなければなりません。*いつ在庫を引き当てるのか？もしそれが早すぎる場合は、顧客の購入離脱に対処しなければなりません。遅すぎる場合は、貧弱なUXと過剰販売との間の選択に直面することになります。

上の図は、カートからコンビニまでのチェックアウトの流れをやや簡略化して示したものです。各遷移にはTNと書いています。Eコマースプラットフォームは、任意の遷移で在庫を確保することを選択することができます。重要なことは、在庫の確保は、失敗する可能性があるということです。もし、顧客が2つの商品をリクエストし、在庫が0か1であった場合、以下のようなページが表示されるかもしれません。

あるいは、Eコマース・プラットフォームは、単に製品を過剰に販売することを選択することもできます。

図6の各Tのトレードオフを見てみましょう。

• (T1) ここで在庫を確保するということは、顧客が商品を必ず手に入れられることに安心できます。しかし、顧客がチェックアウトを放棄し、意図せず在庫を確保する可能性があります。この場合、加盟店には、顧客の在庫を無効にするまでの時間を決定する負担がかかります。
• (T2-T3）ここで在庫を確保することで、おそらく在庫を確保したまま放棄されるチェックアウトの数は減りますが、この時点の在庫切れのエラーはフラストレーションがたまるかもしれません。顧客はおそらく、フォームに記入するのが遅すぎたと感じてしまい、そしてそれは正しいでしょう。
• (T4) この時点で在庫を確保する場合、エラーページを表示するには遅すぎます。時すでに遅し、コンビニでは現金待ちの状態です。コンビニで「品切れ」のエラーは見せられません。このステップで在庫を確保すると、過剰販売を許容せざるを得なくなるのです。Shopifyのホストページ決済は、このステップで在庫を確保します。

対応方法

Shopifyのホストページ決済のための在庫予約ポリシーは、顧客にとって最も不満のないUXをもたらしますが、加盟店に管理上の負担を強いています。

品薄の商品に対してホストページ決済を利用する加盟店は、常に在庫バッファーを確保する必要があります。

例えば、本当は100個の在庫がある場合、Shopifyの在庫を90個など低めに設定し、過剰販売を可能にすることです。

どの程度のバッファーを確保するかの完璧な計算式は、マーチャントのトラフィックパターンによります。

そのためにはShopifyの外部で在庫管理をする必要がありますが、UXの面では報われます。

なお、ShopifyのPayments Apps APIは、決済プロバイダーに在庫情報を一切提供しません。したがって、KOMOJUのようなサードパーティの決済プロバイダーは、過剰販売を避ける手助けをすることができません。