決済代行の切り替えで、工数が集中したのは接続ではなく業務側だった

決済代行を替えることになったとき、見積もりに出てくるのはたいてい「接続の工数」です。ところが実際に走ってみると、時間を取られるのはそこではありませんでした。

ここでは、3週間で切り替えた案件をもとに、どこに手が要ったのか、発注する側が先に確かめられることは何かを書きます。

前提

通販サイトを運営している会社です。売れてから入金されるまでの期間が資金繰りを圧迫していて、翌日入金を基本とする決済サービスへ切り替えることになりました。

期限は決まっていました。審査が通ってから3週間です。

カード決済の接続そのものは、仕様書のとおりに作れば終わります。テスト環境も用意されているので、詰まる場所は多くありません。

問題は、その決済を前提にして動いていた業務のほうです。

返金の締め日が変わると、経理の月次が変わります。キャンセル可能な期間が変わると、カスタマーサポートの案内が変わります。領収書の発行元が変わると、法人のお客様への説明が変わります。

どれもシステムの話に見えて、実際は業務の取り決めの話です。ここを先に洗い出さないと、接続が終わってから止まります。

これらは、開発側だけでは決められません。

返金の締め日をいつにするかは、経理の判断です。キャンセルを何日前まで受けるかは、サポートの判断です。決める人が別にいるので、確認に時間がかかります。

だから先に洗い出します。接続の作業と並行して確認を進めれば、待ちが重なりません。

期限が決まっていたので、優先順位をつけました。

止まると事業が止まるものだけを先に通し、それ以外は手作業を一時的に許容しました。

「全部自動でやる」を最初から狙わなかったことが、結果的に間に合った理由です。

たとえば返金の処理は、当面は担当者が管理画面で1件ずつ操作する形にしました。件数が多くないので、運用で回せます。自動化は、切り替えが落ち着いてから足しました。

作業と並行して、手数料の条件も交渉しています。

切り替えのタイミングは、条件を見直す機会でもあります。作る話だけに集中していると、この機会を逃します。

決済は、止まると売上が止まります。切り替えの当日は、何かあってもすぐ戻せる状態を作りました。

具体的には、本番のカードで実際に注文を通し、データが正しく流れるかを見ながら進めます。おかしければ、その場で出荷を止められる時間の中で判断します。張り付いていれば戻せる、という状態を保つことが前提でした。

全件をいきなり新しい決済へ移すのではなく、まず数件を通して確認しています。

この数件で、注文の登録、入金の記録、メールの送信までを一通り見ます。ここで問題が出なければ、残りを移します。

切り替えの前後には、古い決済で受けた注文と、新しい決済で受けた注文が混ざります。

返金やキャンセルの依頼が来たとき、どちらの決済で受けた注文かによって操作が変わります。この期間の手順を、サポートの担当と先に決めておきました。

決済を替えると決めた時点で、次の3つは先に確かめられます。システム会社に聞く前に社内で出せます。

これが出ていると、見積もりの精度がまったく変わります。

決済の切り替えで工数が集中するのは、接続ではなく、その決済を前提に動いていた業務のほうです。

返金の締め日、キャンセルの期限、領収書の名義。この3つは開発側では決められないので、先に社内で確かめておくと待ちが減ります。

期限が厳しいときは、全部自動を狙わずに、止まると事業が止まる部分だけを先に通す。残りは手作業で受けて、あとから足せば間に合います。