決済ゲートウェイ
eSewa、Khalti、Stripe、PayPal、銀行のゲートウェイ。コールバック、検証、返金処理も含みます。
API連携 — ネパール
Soft Himalayaは、カトマンズから決済ゲートウェイ、CRM、ERP、配送業者、独自APIの接続を手がけています。ネパール、英国、オーストラリア、米国、カナダの企業と協働しています。

実運用のためのエンジニアリング
項目の所有、認証情報、リトライ、アラートは、システム間でデータが動き出す前に設計します。
連携の対象
連携の仕事の多くは特別なものではありません。顧客、注文、請求書とは何かについて2つのシステムを一致させ、片方が利用できないときの挙動を設計することです。
eSewa、Khalti、Stripe、PayPal、銀行のゲートウェイ。コールバック、検証、返金処理も含みます。
連絡先、商談、活動履歴を、Webサイトやフォームとチームが使うCRMの間で同期します。
請求書、在庫、仕訳データを、正としている会計システムやERPとやり取りします。
配送手配、ラベル発行、料金照会、追跡ステータスを、自社の画面に取り込みます。
各プロバイダ経由のトランザクションメッセージ。配信状況と再送の挙動も明示的に設計します。
自社プラットフォームと出品先マーケットプレイスの間で、商品、在庫、注文を同期します。
自社プロダクトやパートナー向けのAPIを、バージョン管理、認証、ドキュメントとあわせて構築します。
受信イベントを検証し、キューに入れて処理します。トラフィックが急増してもレコードを取りこぼしません。
古いシステムはデータベースへの直接アクセスを許すのではなく、定義したインターフェース経由で公開します。
なぜ重要か
何事もない日に2つのシステムをつなぐのは簡単です。費用を払う価値があるのは、プロバイダがタイムアウトし、項目を変更し、レート制限をかけ、同じイベントを二度送ってきたときの処理です。
スタッフがシステム間で注文を書き写す作業は遅く、数週間後の照合時に初めて表面化する不一致を生みます。
プロバイダには障害もメンテナンス時間もあります。キュー、リトライ、明確なフォールバックがあれば、相手側が復旧するまで自社側は動き続けられます。
タイムアウトは処理の失敗を意味しません。冪等キーと照合がなければ、再送は二重課金や二重出荷になります。
項目は非推奨になり、バージョンは終了します。連携には監視と担当者が必要で、一度作って祈るだけでは足りません。
進め方
期間はプロバイダのドキュメントの質、サンドボックスの有無、認証情報と承認がどれだけ早く得られるかによって変わります。多くの場合、この最後の点が一番時間のかかる部分です。
プロバイダのAPIドキュメントを読み、契約プランで実際に何ができるかを確認し、レート制限、サンドボックス、承認の手順を洗い出します。
システム間で項目を対応づけ、各レコードの正となる側を決め、実装前にインターフェースを文書化します。
プロバイダのテスト環境に対して構築します。認証情報は最初からコードベースの外に置きます。
タイムアウト、部分的な失敗、重複イベント、レート制限を意図して処理します。レコードを作成する箇所には冪等性を持たせます。
正常系だけでなく異常系も検証します。プロバイダの停止、不正な応答、再送されたWebhook、期限切れの認証情報などです。
ログ、アラート、対応手順書を用意した状態で本番稼働させます。顧客より先に貴社が障害に気づける状態にします。
連携の設計
処理したリクエスト数の架空のダッシュボードをお見せする代わりに、連携が安定するか、それとも継続的なサポート案件になるかを分ける判断を挙げます。
APIキー、OAuth、署名付きリクエストのいずれか。加えて認証情報をどう更新し、誰が保持するか。
各項目をどのシステムが所有し、レコードをどう突き合わせ、両側が同じレコードを更新したときにどうするか。
リトライ方針、バックオフ、デッドレターの扱い、そしてプロバイダが利用できない間に利用者に何を表示するか。
何を記録し、何がアラートを発生させ、連携が止まったときに誰が動くのか。
認証情報とプロバイダのアカウントは貴社名義で登録するため、アクセスが当社に依存することはありません。
ツール
技術構成は、つなぐシステムと、引き渡し後に貴社チームが保守できるかどうかに沿って選びます。
連携サービス、Webhook、APIレイヤー
既存のPHPアプリケーション内での連携
大量データの同期とバッチ処理
インターフェース設計、バージョン管理、ドキュメント
リトライ、バックオフ、急増時の処理
レコード保存、冪等キー、キャッシュ
セキュリティと信頼性
破られない連携は存在せず、セキュリティを保証すると謳う会社は誇張しています。私たちが約束できるのは、一貫して適用する実践と、連携が貴社のデータをどう扱うかの明確な説明です。
キーは環境変数かシークレットストアに置き、リポジトリには入れません。権限も連携に必要な最小限に絞ります。
通信はTLSで行い、受信するWebhookは署名がプロバイダのシークレットで検証できない限り拒否します。
プロバイダが公開している制限を守り、失敗しているエンドポイントを叩き続けるのではなく、指数バックオフとキューで処理します。
個人情報と決済情報は必要な箇所だけに記録し、不要な箇所では伏せ、保持期間は合意に従います。
お見積もり
費用はプロバイダのAPIの品質、関係するシステムの数、サンドボックスの有無、必要な照合ロジックの量によって変わります。お見積もりの前にドキュメントを確認します。
1つのプロバイダを1つのシステムに接続します。決済ゲートウェイ、配送業者、メッセージ配信サービスなどです。
2つ以上のシステムの整合を保ち、所有ルールと相互の照合を設計します。
パートナーや自社アプリケーションに公開するAPIを、バージョン管理とドキュメントとともに構築します。
質問
プロバイダ、期間、障害時の処理、そして費用の考え方について、よくいただく質問です。
2つのシステムをつなぎ、誰かが手入力し直すことなくデータをやり取りできるようにすることです。たとえば、WebサイトとCRM、ストアと配送業者、アプリケーションと決済ゲートウェイの連携です。作業の大部分は、各レコードをどのシステムが管理するか、一方が利用できないときにどうするかを決めることです。
協働にあたって
匿名のクライアントの声、稼働率の数値、検証できないリクエスト量のグラフは掲載しません。代わりに、私たちが自らに課している基準を示します。
項目、エンドポイント、エラーコード、リトライの挙動は書き出して引き渡します。開発者一人の頭の中に留めません。
プロバイダのアカウントは貴社名義で開設し、当社のアクセス権は範囲を限定し、いつでも削除できます。
正常系が動くことだけでなく、プロバイダが停止した場合やエラーを返した場合に何が起きるかもお見せします。
ソースコード、環境設定、よくある障害への対応手順書を、次にシステムを支える方へ引き渡します。
プロジェクトを始める
関係するシステム、お手元にあればプロバイダのAPIドキュメントのリンク、そして現在どの作業を手で行っているかをお送りください。確認したい点、ご提案する範囲、概算をお返しします。