後払い決済導入時システム開発の進め方

当コラムは、後払い決済（BtoC）導入時に導入する決済会社が決まった後、自社システムに搭載する際のAPI開発で気を付けたいことや上手な進め方を記載したものになります。当社を頼って頂いた複数の大手通販会社で採用された手法ですのできっとお役に立てると考えています。

上記図のように後払い決済導入を検討している推進者は、後払い決済会社選定後にシステム開発要件定義を行う事になります。
とは言っても通常は、決済会社のエンジニアと開発担当エンジニアで話が進んでいきます。
このフェーズになると後払い決済導入プロジェクトは、推進者の手を離れてホッと一息できるタイミングです。

ですが、実は、ここでエンジニアに丸投げしてしまうと「ローンチに間に合わない・ローンチできても思っていたより使いづらい」ということがよく発生します。

最悪、開発に手が掛かりすぎて終わらず次の重要な開発が始まってしまい結局後回しになってしまうこともあります。

それもそのはず、開発エンジニアの決済に関する経験値といえば普通は「クレジットカード決済」です。
つまりエンジニアの頭の中は「クレジットカード決済脳」です。

ですが、後払い決済はクレジットカード決済と動き方や性質が全然違います。
エンジニアの「後払い決済は、クレジットカード決済と似たようなもんでしょ？」という間違った認識で工数見積を行い、開発をスタートしてしまうと上記のような開発が終わらない・出来上がったけど運用しづらい事態が発生します。※経験上、開発期間として1.5～2.5ヶ月かかるケースが多いです。（勿論何人で開発を行うのかによるとは思いますが）

自社スクラッチできるシステムを有している推進者や開発エンジニアの方は是非参考にしてください。

さて本題に入る前に改めて当コラムが役に立つ前提の確認を行いましょう。

■前提の確認

1. 当コラムで有効な決済は「請求書による後払い決済」です。
   具体的に言うとPaidyとatoneを除いた「請求書による後払い決済」（NP後払い、後払いドットコムなど）です。（atoneは請求書による後払いという側面もありますが…）
   感覚的な伝え方で恐縮ですが、Paidyとatoneの開発は、「請求書による後払い決済」の工数の半分から1/3程度です。
2. ASPカートではなく自社で開発できる環境が必要。
   スクラッチできるシステムで唯一ECCUBEは除外。理由はモジュールを利用した方が簡単だからです。
3. 当コラムは標準的なAPI項目とAPI名で話を進めます。
   「請求書による後払い決済」と言ってもたくさんの会社があります。
   当然ですが各社仕様もAPI名も用意してあるAPI数も違います。ですのでほとんどの決済会社で存在するAPIとわかりやすいAPI名で進めていきます。詳しくは決済会社の仕様書で確認してください。
4. 請求書別送を前提としています。（請求書同梱は各社運用手順が違い分岐がややこしいので当コラムでは割愛）
   ですが、開発するAPIはほとんど変わらないので参考文献としては有効です。

逆説的ですが、当コラムはサブスクストアやMakeshopのようなASPカートを使っていたり、楽天・ヤフー・Amazonのようなモール店のみで販売している場合は役に立ちません。

では、さっそくはじめていきましょう！！

まずは、上記のような後払い決済の流れを簡単にした図をエンジニアに見せて、おおまかな流れと下記の注意点を説明します。

1. 保証型後払い決済の保証になるタイミングは商品がお客さまの手元に到着した時点
   もうちょっと言うと、到着しても返品となり、商品が手元に返ってきたら保証対象ではないよ！ということ。
   （ダウンロードコンテンツでなければ購入した時ではないし出荷した時でもないよ！ということ）
2. 後払い決済は、他の決済（クレカ・代引き・前払い・キャリア）と動きが全然違う。
   →上記1を踏まえ、他決済と決定的に違う要素として「発送伝票番号登録」という動きがあるということ。
3. 決済のステータスに「後払い決済」（後払いでも可）を新設して欲しい
   審査結果というステータスがあるのであれば「OK」「NG」「与信中（保留、入金待ちでも可）」を作って欲しいとお願いをします。
   →決済と審査結果が分かれてないのであれば、「後払い決済OK、後払い決済NG、後払い決済与信中」の3つのステータスを作って欲しい

ここまででエンジニアの後払い決済の理解度（5%）←たった5%ですが飛ばしちゃダメです。

次に、具体的にどんなAPI項目があるのか？をみてもらいます。
具体的には下記のようなAPIの仕様がわかる資料を用意します。
とその前に、資料を作る為に決済会社のAPI仕様書を取得する必要がありますが、決済会社の担当に依頼すればすぐもらえますので早速依頼してください。
どうぞ安心してください。仕様書と言ってもBtoCの後払い決済のAPI仕様書を読み解くのは難しくありません。
システムにとんと疎くても全然いけます。だまされたと思って一度仕様書を（腰を据えて）読んでみてください。
筆者は、エンジニアでも何でもないですが割とすぐ理解できました。
さて、資料についてですが当社は左からAPI名、開発有無、目的、具体的な情報例、備考の順で記載します。

API名：取引情報登録（POST）

目的：購入者の利用審査を決済会社が行う為
具体的に必要な情報：決済会社から提供される御社のユニークID、注文番号、日付、購入者の①ユニークID②氏名③郵便番号④住所⑤電話番号⑦メールアドレス⑧請求額合計⑦注文情報(商品名/点数/詳細金額など) 配送先が購入者と違う所謂ギフト利用の場合①氏名②住所③電話番号　等
※リアルタイム与信採用時は与信結果がレスポンスされます。
注意点：取引情報登録でレスポンスを受け取れなかった用に再送を設定する場合、「購入者の①ユニークID」が同番号の場合、決済会社の与信サーバー が弾いてくれるか登録できるのかを掴んでおいた方がいいです。弾いてくれる場合は再送で問題ありませんが、登録できてしまう場合は再送だと重複登録となるので避けた方がよい為です。

API名：与信結果返信（GET）

目的：利用審査OK/NG等を判定する行為
具体的に取得できる情報：①与信OK　②与信NG　③与信中

API名：発送伝票番号登録（POST）

目的：決済会社が請求書発行業務に入る（＋商品着荷確認作業に入る）
具体的に必要な情報：運送会社（※）、伝票番号
※運送会社は決済会社によって「ヤマト運輸→01、佐川急便→02…というように番号を振られているのでその番号を記載」

発送伝票番号登録を行う事により、決済会社は送り状番号で商品到着確認を行い、到着したものを保証対象としていきます。
つまり、発送伝票番号登録を行わないと、請求書も送られませんし、当然保証対象とならず御社に代金が入金されません。

API名：取引情報修正（POST）

目的：上記の「取引情報登録API」で登録した内容の修正を行う
具体的に必要な情報：決済会社から提供される御社のユニークID、購入者のユニークIDを指定し修正したい項目と内容を記載
注意点：「氏名・住所の変更」または「請求額が上がる」場合は再与信となり再与信の結果、審査結果がNGになることがある。
発送伝票番号登録後は取引情報の変更はできない。
（ただし請求書の送り先を変更したい場合のみ可能だがAPIは存在せず決済会社の管理画面での対応となる。）

API名：取引キャンセル（POST）

目的：キャンセル・返品時に上記「取引情報登録」の取消しを行う
具体的に必要な情報：決済会社から提供される御社のユニークID、購入者のユニークIDを指定する
注意点：キャンセルAPIを叩くタイミングは返品商品が到着してから。
また購入者が支払いをしてしまった場合はキャンセルが出来ない為エラーとなるので管理システムに注意喚起が必要

余白に開発出来ないことを記載

下の余白にAPIが存在しないため開発できないことも記載しておくと気が利いていると言えます。具体的には、下記のようなことです。ただ、何度も言いますが実行可能なAPIを保持している決済会社もありますので詳細は各決済会社の仕様書を確認してください。

• 請求書再発行（請求書を紛失したので再送してほしい。引越しをしたので新住所に送ってほしいなど）
• 与信完了通知先（担当者メール先）の変更
• 御社の電話番号や責任者（担当者）情報の変更

ここまででエンジニアの後払い決済の理解度（15%）

エンジニアの方に後払い決済の略図を見て後払い決済をぼんやり理解してもらい、API名の資料で使用するAPIについてなんとなく理解をしてもらいましたので、次のステップとして詳しく後払い決済がシステム的にどのように進んでいくのか？を理解してもらいます。ここが終わればエンジニアの方の理解度は一気に70%くらいまで上がります。

続いて用意するのは、下記のようなお客さまが購入してから支払いが完了するまでの流れが確認できる図です。

少し図↓について説明をすると後払い決済では一般的となったリアルタイム与信を採用した時のシステム的な動きです。
時系列は上から下、スタートは左上でお客さまが御社サイトで商品を購入し「後払い決済」を選択したところから始まります。
左側がお客様、中央が自社システム、右側が決済会社のシステムを表しています。
矢印の各色は下記を示しています。
緑色の矢印は運用の流れ
赤色の矢印は開発が必要な個所
青色の矢印はお客さまに向けて開発した方がよい箇所

個人的には先程のAPI名の資料を隣において見比べながら話を進めていくとより理解してくれる気がします。

矢印①API名：取引情報登録（POST）

システムのフロント（カゴ）と決済会社の与信サーバーをを取引情報登録APIで連携します。
（後述の一部返品の対応時に詳細記載しますが、カゴ部分だけでなくバックヤードでも取引情報登録APIができる開発をしてもらいます。）
リアルタイム与信の場合、数秒以内に与信結果がキックバックされます。

与信結果は【与信OK、与信NG、与信中】の3つ。
それぞれの与信結果に連動する開発内容は下記。
与信OK→ご注文ありがとうございました画面＋サンクスメールを送る
与信中→ご注文ありがとうございました画面＋サンクスメールを送る（与信OKとほぼ一緒）
与信NG→審査NGの画面を出し別決済に誘導画面

与信中というのは、決済会社の与信システムが与信結果を瞬時に出せないご注文で、審査が完了するまでに5分～120分程度の時間が掛かります。
大別すると下記2パターンがあります。

1. 電話番号の桁数が足りない、住所に番地以下の記載がないなど
   →どちらかというと情報不備に属する


2. 郵便番号と住所がかけ離れている、電話番号が不通、与信データベースに存在する情報と相違しているなど
   →システムで瞬時に判断できないのでオペレータ（人）が情報を集めて判断する

開発者目線で言うとは「与信中」が厄介なので与信中を与信NGにしてしまう企業もありますが、 結果として与信NGが増えてしますので例外はあれど愚策です。
期待値的に与信中の6割以上は審査OKになるので、良策としてはご注文ありがとうございました画面とサンクスメールに 「※ただし決済会社の審査NGとなった場合は別のお支払い方法をお願いすることがございます。」などと注意書きをつけるのがよいです。

与信中を与信NGにするやり方は、決済会社側でNG判定にしてもらうやりかたと 与信中でキックバックされたら返す刀でキャンセルAPIを用いてキャンセルしてしまうやり方があります。

念のため記載すると与信中を与信NGにしてしまうのがなぜ愚策かというと、お客さまの不信を買ってしまうからです。
補足：リアルタイム与信については下記コラムで詳しく書いてありますので興味ある方はご覧ください。 https://atobarai-hikaku.com/archives/20190219/

矢印③API名：与信結果返信（GET）

与信結果が「与信中」のものは、与信結果が変更になりそうなタイミングで与信結果を取得しにいく必要があります。
2021年2月時点で与信結果返信APIはイベント発生システムやWebhookのようなシステムはBtoCの後払い決済にはないのでバッチ処理が最適です。
バッチ処理の間隔は、経験的には15分おきか30分おきが多いですが、決済会社の仕様にも影響されますので決済会社と相談してきめてください。

また「与信中」→「与信NG」（情報不備含む）は、お客様に別決済で購入お願いします。または正しい情報で再注文お願いします。
というメールを送る仕組みを設計してもらえると運用がとても楽になります。

矢印⑥API名：発送伝票番号登録（POST）

発送伝票番号登録APIはタイムリーに行う必要はない為、商品発送後にバッチ処理していくケースが多いです。

注意点としては下記が挙げられます。

• 決済会社のメンテナンス時間をさける
• トラフィックが混みあうと決済会社のサーバーがダウンするので、間隔は1秒以上あける
• 0時までに完了できる時間帯から開始する
• 超巨大企業は、バッチ処理だと終わらないので別の方法を模索する

決済会社のメンテナンスは定期的に行われますが、時間帯はほぼ固定されています。
メンテナンスは数時間かかり、メンテナンス中はシステムダウンしているのと同義です。

メンテナンスがある時間帯は避ける、また19時台と23時台はトラフィックが混みあうなど決済会社によって傾向があるのでその時間も避ける事が得策です。
1日の出荷件数が数万件に及ぶ場合はバッチ処理だとおわらないので、別の方法を決済会社と模索しましょう。
また締め時間がだいたい0時なので0時までに完了できる時間帯から開始してください。

注意点：リアルタイム与信を採用しなかった場合の対処法
取引情報登録APIでリアルタイム与信を採用しなかった場合は、与信結果がキックバックされませんので、 与信結果返信APIをバッチ処理で取得していく形を取ります。
各後払い決済会社は記載してあるAPI以外にも便利なAPIが存在します。列挙して開発可否を決定してください。

ここまででエンジニアの後払い決済の理解度（70%）

ここまで来たらおおよその後払い決済のシステム開発に必要な要素は掴んでもらうことができています。
ここでもう一押し、イレギュラーな事態にも対応できるような工夫を開発してもらいましょう。

イレギュラーな対応とは「全部返品・一部返品」です。


通常、全部返品や一部返品は、該当商品の返品を受取後に代替商品を発送して終了です。後払い決済もこの流れは変わりません。
ただ、代替商品の在庫がなかったり再送を拒まれた場合は下記の運用が必要となります。

後払い決済における返品後の返金作業についての基本的な考え方

保証型後払い決済は、お客さまの支払い状況は通販事業者にわからない設計になっています。
ですが、お客さまがお支払いをしていないのに返金してしまってはおおごとになりますので下記を把握しておく必要があります。

御社がキャンセル→お客さまが誤って支払い　の順で発生した場合
お客さまへの返金対応は「決済会社」がします。

お客さまがお支払い→御社がキャンセル　の順で発生した場合
お客さまへの返金対応は「御社」です。お金は、お客様→決済会社→御社→お客さまという順で流れます。

※全部返品且つお客さまが商品代金未払いの場合の対応図↓（←ほとんどはこの場合）

上記図は、発送情報登録を行った後（つまり決済会社が請求書発行作業を行った後）からの動きを表しています。

前回の図と同様に時系列は上から下。左のブロックはお客さま、中央のブロックが御社、右のブロックは決済会社を示しています。
緑色の矢印は運用の流れ
茶色の矢印は決済会社とやり取りが発生する箇所
赤色の矢印は開発した方がよい箇所

時系列的にお客さまから返品したい連絡があり、代替商品の用意ができない（または代替商品発送を拒否された場合） 場合は、決済会社にお客さまの支払い状況を確認します。
この確認の仕方は決済会社によって千差万別です。

請求書は既に決済会社からお客さまに向けて送られてしまっている場合が多いので、御社からお客さまに対し
「お手元に届く、又は届いているお支払い用紙は破棄をお願いします。」と依頼しておきます。

ややこしい話ですが、万が一、御社がキャンセルした後にお客さまが支払ってしまった場合は、 決済会社がお客さまと連絡を取って返金処理を行ってくれます。（後払い決済はキャンセルした請求書を「支払い不可」にはすることはできず、キャンセル後も支払えてしまいます。）
ほとんど発生しませんが、お客さまから誤って支払ってしまったと連絡が入った際は決済会社から連絡がいきますとお伝えしてください。

商品発送前にも購入キャンセルはあると思いますので、キャンセルAPIを開発してもらう必要があります。
当然ですが商品発送後は、キャンセルを行うのは返品商品が届いてからです。これ鉄則です。

※全部返品且つお客さまが商品代金を払ってしまっていた場合の対応図↓

ほとんど発生しないですが、商品不備が発覚しキャンセルを行う前にお客さまがお支払いをしてしまうことがあります。
例えば、商品を買ったのが奥様で返品している最中に、ご主人が届いた請求書をみて良かれと思い払ってしまったなどです。

その場合、キャンセルAPIを叩いてもキャンセルできません。
後払い決済の仕様上お客さまがお支払いをしてしまうとキャンセルができない為です。
（すごく細かい話ですが、後払い決済会社もお客さまが支払ったことを知るにはタイムラグがありますので、今さっき支払った！という場合はキャンセルできます。）
どちらにせよキャンセルを行うのは返品商品が届いてからです。

キャンセルAPIを叩いてリクエストが不可だった場合、お客さまがお支払いしてしまっていますので返金は御社が対応しなければいけません。
社内担当者に上記のアナウンスが流れるようにシステムを作ってもらえると親切な設計だと言えます

※一部返品の場合の対応図↓

複数の商品を購入し、その一部のみ返品となった場合は、上記図の流れになります。

簡単に言うと下記流れです。
該当の注文をキャンセル→正しい金額で再注文（取引情報登録API）→与信OKで返却→発送伝票番号登録API→正しい金額の請求書発行

先に出てきた「取引情報修正API」は、発送伝票番号登録後は機能しませんので一度注文をなかったこと（キャンセル）し、 取引情報登録APIで再度審査をかける必要があります。よって、一部返品を想定し取引情報登録APIはバックヤードシステムから 意図的にできるような設計も作成してもらう必要があります。

例外をお伝えするとGMO後払いの「減額修正API」やNP後払いの「出荷報告済キャンセル取引再登録API」が存在し且つ開発を行えば流れは変わります。
減額修正API・出荷報告済キャンセル取引再登録API→正しい金額の請求書発行
※詳しくは、 GMO後払いの中の人にインタビューしましたをご覧ください。

お気づきの通り、キャンセル→再登録を行うと与信結果が変わる可能性が超低確率ですがあります。つまり与信NGになるということです。
万が一起きた場合、決済会社に事情を説明すれば特例として与信結果をOKにしてもらえる確率は高いですが、単純に手間です。 （一度ついた与信結果は上記のような特例を除いて依頼しても変更を受け付けてくれませんし、できません。当たり前ですが。）

減額修正APIや出荷報告済キャンセル取引再登録APIを用いれば与信結果を維持したまま金額の修正が可能になります。このAPIの便利さがわかりますね。


ここまででエンジニアの後払い決済の理解度（85%）

さて、当コラムはここで終了です。どうでしょうか？お役に立てたでしょうか？

ここから先、理解度を100％に近づけるには、各決済会社のAPIの仕様や与信サーバーのクセによって異なります。
またシステムエラーのリカバリー策（リトライ設計）をどうするのか？も論点になります。

ですが、当コラムを元に進めていけばエンジニアの方の理解度は85%くらいまで持っていくことができますので開発工数を正確に見積もることが可能となります。

さて、これで後払い決済導入推進者はエンジニアとシステム設計について協議し工数などの見積作業に入ることができました。
ほっと一息付けたと思ったら、すぐさま次の難関が…。
ほぼ100%の確率でカスタマーセンター担当者からお客さまからの問い合わせ時のQA表（よくある質問集）を作って欲しいというオーダーが飛んできます。そんなの作れませんね(笑)。

ご安心ください。次回のコラムでは過去に当社で様々な通販大手企業で採用されている（一般的な）QA表を公開します。
お楽しみに。