メインコンテンツまでスキップ
Markdownをコピー

スクラッチ開発向け決済ガイド

自社開発で決済システムを構築・統合する事業者様向けに、
設計から本番運用までの実装パターン・注意点を体系的に整理します。

1. 実現できること

スクラッチ開発では、当サービスのAPI仕様に準拠することで以下が実現できます。

高度なワークフロー制御
発送時課金などの複雑なビジネスロジックに対応し、発送・在庫・会計システムとの統合が可能です。

独自の UI/UX 実装
決済フロー全体を自社で制御でき、ブランドに沿ったユーザー体験を実現できます。

イベント駆動型システム
Webhook通知により決済完了・キャンセル・入金をリアルタイムで捕捉し、スケーラブルなアーキテクチャが構築できます。

多様な課金方式への対応
随時決済、継続決済、後払いなど複数の課金パターンを同一システムで実装できます。

2. 選ぶべきサービス構成

製品タイプ

  • Entry:ゲスト購入のみのケース
  • Standard:会員登録機能を持つサイト向け
    • カード情報を保存して2回目以降の購入を簡単にします
  • Advanced:クレジットカード決済で洗替を利用する場合

接続方式の選択

要件に応じてOpenAPIタイプまたはリンクタイプ Plusを選択します。
接続方式により利用可能な決済手段や開発工数が異なります。

OpenAPIタイプ と リンクタイプ Plus の違い

OpenAPIタイプ(API型)

  • 決済フローを完全に制御でき、独自のUI/UXを自由に実装可能
  • 発送時課金などの複雑なワークフロー対応
  • 自社システムとの深い連携が可能

リンクタイプ Plus(リンク型)

  • お客様を当サービスが提供する決済画面に誘導する画面遷移型の接続方式
  • 決済画面を当サービスが提供するためセキュリティリスクが少ない
  • 決済画面の開発不要・短期間で導入可能

詳細は接続方式から探すを参照してください。

3. 実装上の必須チェックリスト

スクラッチ開発で本番環境に移行する前に、以下の項目を段階的に確認してください。

接続設定の確認

項目確認内容
本番環境の認証情報本番用のショップID・ショップパスワード、APIキーが正しく設定されているか
エンドポイント設定接続先URLがテスト環境から本番環境に切り替わっているか
SSL/TLS設定SSL証明書の検証が有効になっているか
認証・認可処理トークン管理・失効時の再取得メカニズムが実装されているか

決済処理フローの実装確認

項目確認内容
正常系フロー正常な決済フローが最後まで完了するか、テスト環境で検証済みか
二重決済防止同じ取引が複数回実行されるのを防ぐ仕組みが実装されているか
キャンセル・返品処理キャンセルと返品が正常に動作することをテスト環境で検証済みか

Webhook実装(非同期通知)

項目確認内容
受信プログラムの実装決済完了・キャンセル・入金等のイベント通知を受け取るプログラムが実装されているか
署名検証Webhookの改ざん検知・送信元確認の仕組みが実装されているか
冪等性の保証同じ通知を複数回受け取っても処理が重複しない仕組みが実装されているか
再送メカニズムWebhook受信失敗時の再送に対応できるか(HTTP 200番台の返却)
通知先URL設定本番環境用の通知先URLに変更されているか

セキュリティ実装

項目確認内容
機密情報の保護ソースコードにテスト認証情報・APIキーが含まれていないか
ログ出力管理ログにカード番号等の機密情報が出力されていないか
入力値検証ユーザー入力に対する検証・サニタイズが実装されているか
暗号化通信APIエンドポイントへの通信がHTTPSで暗号化されているか
IP制限必要に応じてIP制限が設定されているか

テスト環境での検証

項目確認内容
接続テストテスト環境との接続が正常に確立されているか
全パターンのテスト正常系・エラー系・エッジケースすべてをテスト環境で検証済みか
E2Eテストエンドツーエンドのフローが自動化されているか、手動テスト手順書があるか
性能テストレスポンス時間・スループットが要件を満たすか(ただし負荷テストはテスト環境では禁止)

運用準備

項目確認内容
監視・ロギング決済トランザクション・エラーログが適切に記録される仕組みができているか
アラート設定異常検知・障害通知の仕組みが整備されているか
運用手順書日次・月次の売上確認、障害対応、データ確認の手順が整備されているか
緊急連絡体制障害発生時の連絡先・対応フローが定義されているか
重要

Webhookは決済完了、キャンセル、入金等の重要なイベント通知です。
以下の3点なしに本番運用に入ることは禁止されています:

  1. 署名検証 - Webhookの送信元・改ざんの確認
  2. 冪等性の保証 - 同じ通知を複数回受け取ても処理が重複しない
  3. 再送メカニズム - 受信失敗時に当サービスが自動的に再送できるよう対応

詳細は結果通知(Webhook)を参照してください。

LLMですか?llms.txtllms-apis.txtに各ページの概要とリンクをまとめています。回答生成に活用してください。