integrate-easypaisa

Easypaisa の統合

コピーした古いスニペットではなく、加盟店が現在承認を受けている統合ガイドに基づいて Easypaisa の決済を実装してください。Easypaisa のドキュメントや利用可能な決済モードは、加盟店との契約や環境によって異なる場合があります。

まず既存の統合を確認する

リポジトリを調べ、Easypaisa／Easypay のパッケージ、プラグイン、ゲートウェイクライアント、加盟店／ストア ID、ハッシュキーの設定、環境 URL、ホスト型チェックアウトフォーム、モバイルアカウントまたは OTC のフロー、戻り先／コールバック／ポストバックのルート、トランザクションステータスの検証、取消処理、注文フィールド、決済処理ジョブ、テスト、デプロイ用シークレットを確認してください。

• 統合が存在する場合は、実装しているガイド／バージョン、利用可能なモード、環境、署名／正規化ルール、エンドポイント、注文のライフサイクル、既知の障害を特定してください。認定済みの動作を維持しながら、段階的に修正してください。
• 統合が存在しない場合は、プロジェクトの既存スタックと加盟店の最新のオンボーディング／統合パックを使って設計してください。
• 認証情報の名前、リクエストフィールド、エンドポイント URL、ハッシュの順序、アルゴリズム、レスポンスコード、ステータス値、コールバックのルールを決して捏造したり、コピーしたりしないでください。それぞれを最新の加盟店向けドキュメントとテストベクターで確認してください。

商品と加盟店の利用資格を確認する

現在、Easypaisa の公式資料では、審査申請、書類提出、KYC／デューデリジェンス、統合を条件として、稼働中のウェブサイトまたはモバイルアプリを持つ事業者／法人向けにオンライン決済ゲートウェイの利用を案内しています。公開されている決済モードには、Easypaisa モバイルアカウントと OTC があります。WooCommerce、OpenCart、Magento、PrestaShop 用のプラグインも掲載されています。実際に利用できるモード、手数料、決済、上限、技術仕様については、加盟店契約で確認する必要があります。

オンライン決済ゲートウェイを、個人ウォレット送金、加盟店 QR／Till、決済リンク、一括支払い、銀行カードアクワイアラー、エスクロー、継続課金エンジンと混同しないでください。コーディングを始める前に、必要な Easypaisa 商品を確認してください。

ワークフロー

1. 最新の加盟店向け統合ガイド、サンドボックス／ステージングの詳細、承認済み決済モード、認証情報、テスト用アカウント／データ、署名の例、コールバックのルール、ステータス／取消 API、認定テストケース、決済条件、本番移行パックを入手します。
2. ガイド／API／プラグインの正確なバージョンを記録し、既存コードと比較します。
3. 決済を開始する前に、一意の加盟店注文／参照 ID を使って内部の保留中注文を作成します。
4. 商品、数量、金額、通貨、割引、配送、顧客の所有権をサーバー上で計算します。クライアントから送られた値を決済上の確定値として受け入れないでください。
5. ドキュメントで指定されたフィールド、順序、エンコーディング、アルゴリズムに厳密に従って、リクエストと完全性検証値を生成します。署名用シークレットはサーバー側に保管します。
6. 顧客は契約で定められたホスト型／ダイレクト／モバイルアカウント／OTC のフローにのみ誘導します。HTTPS の戻り先 URL とサーバー通知 URL を使用します。
7. ブラウザーからの戻りは、ユーザー体験のためだけに使用します。サーバーコールバック／ポストバックを検証して重複を排除し、結果が不明な場合は、承認済みのステータス確認手段または加盟店ポータルで確認します。
8. サーバー側の検証後にのみ、一度だけ履行処理を実行します。サポートと照合に備えて、トランザクション、注文、チャネル、ステータス、決済の各 ID を記録します。
9. 失敗、キャンセル、タイムアウト、重複、遅延コールバック、取消、対応している場合は返金、決済額の不一致に対する処理を実装します。
10. ステージング環境で承認済みのテストケースを実行し、本番モードに切り替える前に加盟店による認定／承認を完了します。

必須ルール

• 加盟店の認証情報やハッシュ／署名キーを、ブラウザーコード、モバイルアプリ、リポジトリ、ログ、スクリーンショット、エラーに決して公開しないでください。
• クエリパラメーター、成功ページ、クライアントの JSON、SMS、スクリーンショット、リダイレクトだけを根拠に、注文を支払い済みにしてはなりません。
• 正確な公式の正規化方式を使用してメッセージの整合性を検証してください。アプリケーションがダイジェストを比較する場合は、タイミングセーフな比較が必要です。
• 注文 ID と外部取引 ID の一意性を確保し、フルフィルメントを冪等にしてください。
• タイムアウトや応答の喪失は、検証が済むまでは失敗ではなく不明として扱ってください。
• 整数の最小通貨単位、またはガイドで指定された厳密な小数形式を使用してください。二進浮動小数点は決して使用しないでください。
• 課金／支払いの作成を安易に再試行しないでください。
• 明示的な承認なしに、実際の支払い、取消、返金、認証情報の変更を行わないでください。

参照先

• 注文状態、ホステッド／モバイルアカウント／OTC フロー、コールバック、検証、プラグイン、テストについては、references/integration-workflow.md を読んでください。
• 署名、シークレット、冪等性、照合、モニタリング、本番環境への展開を実装する前に、references/security-and-operations.md を読んでください。
• 日付付きの公式情報、現在公開されている主張、コミュニティの証拠、再検証が必要な詳細については、references/research-notes.md を読んでください。

検証と出力

関連するフォーマッター、静的解析／型チェック、テスト、ビルドを実行してください。Easypaisa が見つかったか、それともゼロから追加したか、使用した製品／モードとガイドのバージョン、実装したフロー、コールバック検証、冪等性、取引状態の復旧、照合、認定状況、残っている加盟店ポータルの設定を報告してください。公開情報の調査結果、加盟店提供の仕様、ステージング環境での証拠、実運用の承認は明確に区別してください。