直接API
DEUNAサーバーAPIを使用して、商人が独自の支払い体験を構築します。
このページで
Direct API を使用する場合、チームがチェックアウトインターフェースを所有し、信頼できる商社バックエンドから DEUNA を呼び出すことが想定されます。 クライアントが支払い手段を収集またはトークン化し、バックエンドが支払いを生成し、両方のレイヤーが最終的な支払い状態に至るまでの、顧客が必要とするすべての操作を処理します。
統合手順に従う#
1. merchant と環境の設定#
決済リクエストを作成する前に：
- 完了 アカウントのセットアップ および、サンドボックス環境用の認証情報を取得します。
- 読み取り 認証とAPIキー これにより、公開クライアントの認証情報、プライベートバックエンドの認証情報、およびオプションの顧客IDを分離できます。
- 少なくとも1つの有効な決済接続とルーティング戦略を設定します。 プロバイダー機能 を使用して、国、方法、通貨、およびサポートされているオペレーションを確認し、次に 決済戦略.
- 共有環境およびネットワーク要件を適用してください。 API統合の基本.
- サポートされている方法を使用する Postmanコレクション クライアントを実装する前に、サンドボックスリクエストを検査する場合に使用します。
サンドボックスと本番環境では、異なる基本URL、認証情報、プロバイダ接続、および決済データを使用します。 環境間でリソースを混在させないでください。
2. 安全に決済情報を収集する#
商人はDirect APIインターフェースを所有していますが、カードデータの取り扱いには、PCI DSSの要件が適用されます。
- クライアントが、バックエンドで生のカード情報を処理する必要がない場合、サポートされている方法を使用してください。 カードトークン化フロー および、生成された決済方法のトークンをバックエンドに送信します。
- 設定された不正検知プロバイダーがブラウザまたはデバイスのデータが必要な場合、 直接APIによるデバイスフィンガープリントフロー.
- ウォレットや代替決済方法については、まず プロバイダー機能を開始し、必要な接続ガイドを参照してください。
payment_source,specific_fields, リダイレクト、QRコード、バウチャー、またはコールバックの動作。 - 既存の注文トークンが存在する場合、バックエンドは設定済みのものを取得できます。 支払い方法 処理の前に。
3. 支払いを作成および処理する#
新しい統合は、以下の手順から開始してください。 POST /v2/merchants/orders/purchase. 2つの有効なリクエストモデルをサポートしています:
| モデル | 使用するタイミング | ドキュメント |
|---|---|---|
| インライン注文 · 推奨 | 注文を作成し、1回の Purchase V2 リクエストで決済処理を行う。 | 決済リクエスト契約 および 業界標準の例を実装 |
| 既存の注文トークン · 任意 | 別のチャネルや体験で決済が必要な場合にのみ、注文を作成する。 order_token 決済処理の前に。 | 注文を作成、次に 既存の注文の処理 |
以下の サンドボックスでの支払いクイックスタート 最も簡潔なバックエンドフローを実現するために。 エンドポイント: カタログ これは、公開されている操作とそのサポートされている呼び出し元に関する公式な情報です。
サポートされている支払い変更のリクエストごとに、安定した X-Idempotency-Key バックエンドで。不確実な試行時に、同じキーと完全に同一の本文を再利用します。完全な ガイドライン：冪等なリクエストの処理, その保持期間と競合解決方法を含む。
4. レスポンスの処理と顧客の行動#
HTTP 2xx レスポンスは、APIリクエストが受け入れられたか処理されたことを意味します。しかし、それだけでは、実際に資金が移動したことを証明するものではありません。 order.payment.data.status および、返された次のアクションを確認してください。
選択したメソッドに合ったライフサイクルを選択してください：
ブラウザのリターンURL、SDKコールバック、またはプロバイダのリダイレクトを決済の証明として使用しないでください。決済が保留中、処理中、審査中、または顧客の対応を待っている間は、決済をブロックしてください。
5. 非同期結果の確認#
設定する 注文および決済ステータスのウェブフック 商社および環境向け。署名の検証、繰り返し注文の冪等な処理、および実行前に遅いビジネスロジックの実行を確認します。
同期的な応答が失われた場合、または通知が遅延した場合、以下の手順で元の注文を取得します。 GET /merchants/orders/{order_token}取得した支払い状況を、履行または、大幅に変更する前の試行前に、確認します。
ネットワークタイムアウトの場合、以下の手順に従ってください。 クライアントのタイムアウト管理クライアントのタイムアウトは、決済が失敗したことを意味しません。
6. 決済後の操作の実装#
選択した接続と現在の決済状態でサポートされている操作のみを公開します。
高度な操作に関する詳細については、 複数の部分的な決済, 複数の部分的な払い戻し, および 非同期払い戻し.
本番環境での準備確認リスト#
- 秘密鍵は、保護されたバックエンド構成にのみ保存され、ログからは削除されます。
- サンドボックスと本番環境の認証情報、基本URL、接続、およびデータは分離されています。
- すべてのアクセス可能な 支払いステータス および、必要な顧客側の操作が実行されます。
- バックエンドは、注文識別子、リクエストボディ、および冪等性キーを保持し、復旧のために使用します。
- Webhook の署名、重複配信、遅延配信、および順序外の更新がテストされます。
- クライアントのタイムアウト動作は、合意されたものに従います。 タイムアウトと調整モデル.
-
429およびプラットフォームエラーに関するガイダンス レート制限に関する推奨 と エラー参照. - キャプチャ、無効化、返金機能は、接続と現在の状態がサポートしている場合にのみ表示されます。
- 成功、拒否、3DS、保留、タイムアウト、再試行、およびプロバイダエラーのシナリオは、本番環境での使用前に検証されます。