Markdownをコピー
スクラッチ開発向け決済ガイド
自社開発で決済システムを構築・統合する事業者様向けに、
設計から本番運用までの実装パターン・注意点を体系的に整理します。
1. 実現できること
スクラッチ開発では、当サービスのAPI仕様に準拠することで以下が実現できます。
高度なワークフロー制御
発送時課金などの複雑なビジネスロジックに対応し、発送・在庫・会計システムとの統合が可能です。
独自の UI/UX 実装
決済フロー全体を自社で制御でき、ブランドに沿ったユーザー体験を実現できます。
イベント駆動型システム
Webhook通知により決済完了・キャンセル・入金をリアルタイムで捕捉し、スケーラブルなアーキテクチャが構築できます。
多様な課金方式への対応
随時決済、継続決済、後払いなど複数の課金パターンを同一システムで実装できます。
2. 選ぶべきサービス構成
製品タイプ
接続方式の選択
要件に応じて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点なしに本番運用に入ることは禁止されています:
- 署名検証 - Webhookの送信元・改ざんの確認
- 冪等性の保証 - 同じ通知を複数回受け取ても処理が重複しない
- 再送メカニズム - 受信失敗時に当サービスが自動的に再送できるよう対応
詳細は結果通知(Webhook)を参照してください。