メインコンテンツへスキップ
すべてのシステムが正常に動作しています変更履歴v1
ログイン
DEUNA API

Referencia de API

各統合フローに対して、適切な DEUNA API、認証モデル、および呼び出し元を選択してください。

最終更新日 October 2, 2026Postman コレクション
このページで

DEUNA は、加盟店バックエンド、顧客アプリケーション、パートナー、プロバイダーコールバック向けの公開 API を提供します。リソース名だけでなく呼び出し元から確認してください。対応する認証モデルは API サーフェスごとに異なります。内部の Admin API と管理 API は意図的に除外されています。

以下の 完全なエンドポイントカタログ 構成された API Gateway の操作を、意図するユーザー、所有サービス、認証、またはヘッダーに基づいて検索します。

注文ペイロードの例QSR、航空会社、映画館、銀行、および小売の完全なリクエストをコピーします。エンドポイントカタログ呼び出し元、サービス、認証、またはパスによって、すべての公開操作を見つけます。注文の支払い処理完全な支払い契約とインタラクティブなリクエストパネルを確認します。

基本 URL#

開発中は、サンドボックスの基本 URL を使用してください。 導入資格情報を受け取り、認証プロセスを完了したら、本番環境に切り替えてください。

サンドボックス
https://api.sandbox.deuna.io
本番環境
https://api.deuna.io

API を選択する#

表面意図する呼び出し元認証これを使用してください
商社バックエンド · サーバー間信頼できる商社インフラプライベートAPIキーを X-Api-Key; X-Store-Code および、必要な場合にアイデンポテンツヘッダーを送信注文、購入、決済、払い戻し、キャンセル、同意、および運用関連のデータ
顧客アプリケーション · ユーザーからサーバーへの通信商社ウェブまたはモバイルアプリケーションが顧客を代理公開アプリケーションコンテキストとユーザー Authorization: Bearer … ログイン後、プライベートキーを埋め込まないログイン、プロフィール、住所、保存されたカード、および顧客によるウォレット連携
ネットワークまたはパートナー側のバックエンド承認されたネットワークまたはプラットフォームとの統合パートナーの認証情報と、オンボーディング時に定義されたテナント/ネットワークコンテキストネットワーク範囲の注文、設定、およびレポート
プロバイダからのコールバック · プロバイダからDEUNAへの通信決済、不正検知、ウォレット、またはプラットフォームプロバイダープロバイダ固有のコールバック契約; ゲートウェイは、所有サービスにコールバックヘッダーを転送し、共有の認証検証器を宣言しない非同期のステータス通知; 商社システムはこれらのルートを呼び出すべきではない

認証#

商社側のバックエンド

プライベートAPIキーを X-Api-Key、ベアラーヘッダーではなく送信。信頼できるサーバーインフラストラクチャに保持。

サーバーからサーバーへのリクエストヘッダーHTTP
X-Api-Key: YOUR_PRIVATE_API_KEY
X-Store-Code: STORE_CODE
X-Idempotency-Key: order_1042-attempt_1
Content-Type: application/json

認証された顧客

ユーザーアクセストークンをベアラーヘッダーに送信。一部の注文およびウォレット関連の操作では、商社アプリケーションキーまたはストアコンテキストも必要となる。 エンドポイント: カタログ 各ルートにおける認証および転送ヘッダーを表示します。

クライアントからサーバーへのリクエストヘッダーHTTP
Authorization: Bearer USER_ACCESS_TOKEN
X-Api-Key: APPLICATION_API_KEY
X-Store-Code: STORE_CODE
Content-Type: application/json

パートナー

パートナーの認証情報とネットワークコンテキストは、オンボーディング時に提供されます。チェックアウト用のプライベート API キーをパートナー認証情報として使用しないでください。

詳細は 認証 認証情報、トークンの有効期限、およびローテーションの管理

商社のバックエンド操作#

POST
/merchants/orders
注文を作成し、注文トークンを取得する
GET
/merchants/orders/{order_token}
現在の注文と支払い状況を取得する
GET
/merchants/orders/{order_token}/payments-methods
注文で使用可能な支払い方法を取得する
POST
/v2/merchants/orders/purchase
注文の支払い処理
POST
/v2/merchants/orders/{order_token}/capture
承認された決済を実行
POST
/v2/merchants/orders/{order_token}/refund
完全または部分的な返金を生成
POST
/merchants/orders/{order_token}/consent
ウォレットの同意を作成
GET
/merchants/orders/{order_token}/consent
ウォレットの同意状態を読み取る

顧客アプリケーションの操作#

POST
/users/request-code
一時的なログインコードをリクエストする
POST
/users/login
OTPをユーザートークンと交換する
GET
/users/me
認証されたユーザーのプロファイルを読み取る
GET
/payments-cards/users/{user_id}/cards
認証されたユーザーの保存されたカードを一覧表示する
DELETE
/users/payment-methods/{payment_method_id}/tokens/{payment_method}
保存されたウォレットアカウントと再利用可能な同意を削除する

プロバイダーからのコールバック#

プロバイダーのコールバックルートは、完全なインベントリの一部であり、チームは所有者を特定し、誤って呼び出すことを防ぐことができます。これらは商社のウェブフックではありません。DEUNAのイベントを独自のバックエンドで受信するには、注文のウェブフックURLを設定し、次の手順に従ってください。 Webhooks.

レスポンスとエラー#

2xxリクエストは成功しました。
4xx認証、権限、状態、またはリクエストデータが変更されている必要があります。返されたエラーコードを確認してください。
5xxDEUNAまたはプロバイダーが失敗しました。オペレーションがidempotentな場合にのみ、同じidempotencyキーを使用して再試行してください。

完全なリストは、[参照]で確認できます。 エラーコード.

パスのバージョン管理#

各パスをそのまま公開されているものとして使用してください。API Gatewayは、内部のプレフィックスなしで、標準的なルートを頻繁に公開します。 /api/v1 バージョンセグメント（例： /v2 は、カタログに表示されている公開ルートの一部である場合にのみ含まれます。 互換性を維持した変更は、次のリストに記載されています。 Changelog.