Paid（ペイド）の導入方法とは？注意点など実装例をもとに解説します。

COLUMN コラム詳細

本記事ではBtoB後払い/企業間決済・請求代行の導入を検討をされている企業様に向けて、企業間決済・請求代行を導入するメリットや、代表的な請求代行サービスの「Paid（ペイド）」( https://paid.jp/ )を用いて導入を行う場合の実装例や注意点などを詳しく解説します。

本記事を読んでいただくことで、BtoB後払い/企業間決済・請求代行の導入に関する知見を深めることができます。ぜひ、参考にしていただけると幸いです。

自社サービスに導入をご検討中でしたら当社にて導入のための開発を行わせていただくことが可能です。

お気軽に下記のお問い合わせ窓口からお問い合わせください。

無料でPaidの導入・開発について相談する

Paid（ペイド）を導入するメリット

BtoB後払い/企業間決済・請求代行を導入する一番のメリットは、請求関連の業務効率を向上させ、キャッシュフローを安定させることです。

同時に取引先との金銭面でのトラブルが減少するため、取引先と長期的にわたる良い関係を築くことができます。

1. 業務効率の向上

決済・請求の自動化により、取引先への連絡漏れや行き違いといった人的ミスを回避できるため、正確な請求処理が可能になります。

さらに、催促業務や入金確認などの細かい業務も代行してもらうことができます。

2. キャッシュフローの安定

もし、取引先が倒産などで支払不能となった場合でも、入金保証付きのサービスを利用することによって、取引先の未入金が発生しても御社の資金繰りに影響が及ばずにキャッシュフローが安定します。

与信審査業務なども代行してくれるため、新規取引先との取引の開始リスクを軽減することも可能です。

Paid（ペイド）を導入する際の注意点と実装例

ここからは、「Paid（ペイド）」を導入した場合の実装部分に焦点を当てた解説となります。

基本的なWebサービスの決済フローと「Paid（ペイド）」を導入した場合の決済フローを図示します。
その上で、部分的に実装例を解説します。
※図は簡略化している部分がございます。

1. 基本的な自社サービスの決済までのフロー

以下の図で示すような、「商品画面」「確認画面」「決済画面」があり、このような処理を行うと想定しています。

2. 「Paid（ペイド）」を導入した場合の決済フロー

API通信が所々に増え、結構複雑になりましたね。

まずは、「Paid（ペイド）」のアカウント連携と新規作成周りです。

これに加え、新規アカウント登録で与信処理が実行される場合の分岐でのバッチ処理などが入ります。

2-1 アカウント連携周り

「Paid（ペイド）」は40万社以上がアカウントを保有しており、ユーザー本人がアカウント連携を行うだけで、すぐにPaid決済を利用することができます。

アカウント連携を行うことにより今後の決済フローがシンプルになるため顧客にとって決済までのUXが向上します。

既存の「Paid（ペイド）」ユーザーが御社サービスを利用することを想定して、アカウント連携を行う導線を設置することが必須になると思います。

アカウントの新規開設の場合は「与信審査」が入ります。

基本的に即時〜30分程度かかるため、ここの時間差をどうするかが重要なポイントになります。

一度連携すると、2回目決済からは自社サービス会員と「Paid（ペイド）」アカウントが紐づいており、与信審査が通っている状態になります。

このため、考慮する点としましては、限度額オーバーや取引停止などになります。

アカウント開設は、自社システム上にフォームを構築します。

フォーム自体は、決済画面に埋め込みやモーダル(ポップアップ)で表示するなど自社サービスの既存のUIを念頭に置いて決定されると良いでしょう。

アカウント開設に必要な項目は、

本社情報(法人名・住所・代表者・電話番号)
担当者情報(担当者氏名・電話番号・メールアドレス)
送り先情報・支払い方法・締日

などがあります(項目は最新のドキュメントに準拠してください)。

与信審査上、入力につきましては必須項目が多くなっております。

このため、既存の顧客情報をデフォルトで埋め込んだり(プリセットしたり)、入力エラーなどによって顧客が離脱しない工夫などが必要になります。

2-2 決済までのフローについて

ここでは、「受注可否チェックAPI」と「受注登録API」でさまざまな情報を送信する必要があります。

この辺りの処理で止まってしまうと、ユーザーの離脱につながってしまいます。

このため、APIの返り値やステータスの変換・ハンドリングや万が一の時のエラーハンドリングをして、「何が原因でエラーだったのか」をわかりやすくユーザーに伝えられるようすると良いでしょう。

PHPであればEnumを使いこのように書くと見やすいかもしれません。

<?php

enum ApiErrorCode: string
{
    case CE_0014 = 'CE-0014';
    case E21 = 'E21';
    
    // エラーメッセージに変換する関数
    public function getErrorMessage(): string
    {
        return match($this) {
            self::CE_0014 => 'エラー内容書く',
            self::E21 => 'エラー内容書く',
        };
    }
}

// APIエラーコードをエラーメッセージに変換する関数
function getErrorMessageFromCode(string $code): string
{
    // 指定したエラーコードをEnumで扱えるかチェック
    try {
        $errorCode = ApiErrorCode::from($code);
        return $errorCode->getErrorMessage();
    } catch (ValueError $e) {
        return '原因不明のエラーです。お問い合わせください';
    }
}

// 使用例 paidAPIClientは適当
$response = $paidAPIClient->post();
//色々入る
return getErrorMessageFromCode($response->getErrorCode());

2-3 与信審査のバッチについて

与信審査が完了するまで30分程度かかる場合があります。

リアルタイムで審査許可されない場合のことを考え実装しなければなりません。

そのため裏でバッチを動かしたり、決済イベントをフックして実行する必要があります。

// paid連携のアカウントを全て取得
$accounts = $this->getPaidAccounts();
// 送信に必要なmember_idだけを取り出す
$accountIds = $this->filterId($accounts);

// APIの仕様上10,000件が上限なので分割する
$chunkedAccountIds = array_chunk($accountIds, 10000);

foreach($chunkedAccountIds as $chunkIds){
	// APIで顧客ステータスを取得
	$response = $this->paidAPIClient->checkStatus($chunkIds)
	
	foreach($response->getData() as $data){
		// それぞれのステータスに応じてDBに保存する
		PaidAccount::updateStatus($data);
		// ビジネスロジックを継続
		// 審査失敗パターン
		// 審査完了パターン
		// 審査完了・取引不可パターン
		// 利用不可パターン
	}
}

まとめ

この記事を通して、請求代行サービスの「Paid（ペイド）」の実装フローやコードのサンプルを解説してきましたが、自社サービスに組み込もうと思うと与信審査関係や離脱を防ぐUXなど検討や対応する内容が多岐にわたります。

このため、実装の工数は多くなる傾向にあり、費用が上がってしまいますが、それを上回るメリットがあるかと思います。

もし、仕様等にご不明点、または、導入に関する御見積のご相談等ございましたら、お気軽に以下のリンクからお問い合わせください。

無料でPaidの導入・開発について相談する

※「Paid（ペイド）」のAPIのバージョンアップなどによって、本記事での解説時点(2024年11月時点)の仕様と異なる場合がございます。最新の仕様に沿って導入いただければと思います。

コラム一覧に戻る

Paid（ペイド）の導入方法とは？注意点など実装例をもとに解説します。