決済

ステータス、定期的なステータス協議および調整

銀行の結論が得られるまで、バックエンドから決済状態を確認してください。 callback、 SCA からの戻り、ウィジェットの閉鎖は財務確認とはみなされません。

バックエンドからのクエリ

: "${WR_API_KEY:?Defina WR_API_KEY en el entorno seguro de su backend}"

curl --request POST 'https://api.wealthreader.com/payments/?action=status' \
  --header 'Content-Type: application/json' \
  --header "X-API-Key: ${WR_API_KEY}" \
  --data '{
    "payment_intent_id": "11111111-1111-4111-8111-111111111111",
    "refresh": true
  }'

refresh はオプションであり、デフォルトで true です。 Wealth Reader 外部クエリは意図によって制限されます。バックエンドにもバックオフを適用し、結果が曖昧な限りは別の意図を作成しないでください。

三つの異なる次元

フィールド	コアバリュー	答えるもの
`state`	`ready`、 `authorization_required`、 `processing`、 `reconciliation_required`、端末	耐久性のあるフロー状態。
`interaction_status`	`not_started`、 `authorization_required`、 `processing`、 `completed`、 `finished`	技術的なやり取りが終わったのか、続くのか。
`payment_status`	`not_initiated`、 `pending`、 `unknown`、 `settled`、 `rejected`、 `cancelled`、 `expired`、 `failed`	正常化された財務結果。

唯一の肯定的な確認は payment_status: settledであり、これは資金決済完了を明示する銀行の状態から導かれます。技術的な結果 DONE、 interaction_status: completed 、 payment_status: pending は資金決済の完了を意味することはありません。

曖昧な結果

スタート後に認識されないネットワークの切断、タイムアウト、または応答は、 reconciliation_required の意図を変え、 payment_status: unknownを露出させます。スタートは自動的に繰り返されません。

現在のプロバイダーは、応答が失われたイニシエーションを再構築するクエリを提供していません。その状態クエリは、同じイニシエーションによって返される不透明なコンテキストを必要とします。したがって、そのケースは手動で照合する必要があります。自動状態の定期的なクエリや callbackIDの検索では取得できません。

その場合:

冪等性キーと識別子を保持し、
他の意図を作成したり、再び許可したりしない;
Wealth Readerの認証済みステータスを確認し、安全な照合リファレンスを保持してください。
技術サポートに連絡してください; automatic_recovery が false中はステータス確認を続けないでください。

手動で照合が必要な意図の場合、サーバー間クエリには以下が含まれます:

{
  "payment_status": "unknown",
  "reconciliation_required": true,
  "reconciliation": {
    "automatic_recovery": false,
    "reference": "wrp_recon_0123456789abcdef0123",
    "request_id": "11111111-1111-4111-8111-111111111111",
    "correlation_id": "22222222-2222-4222-8222-222222222222",
    "reason": "initiation_rejected"
  }
}

これらの識別子は機密情報を除去したサポート用参照です。ウィジェットに提供されるものではなく、顧客がプロバイダーの内部状態を問い合わせたり再構築したりすることはできません。

reason は Wealth Readerコードであり、サプライヤーのテキストではありません。 initiation_rejected はサプライヤーが開始の明確な拒否で応答したことを示します。 initiation_response_unavailable、認識可能な回答がなかったことを示します。いずれの場合も開始通知はすでに送信されているため、繰り返されません:参照を保持し、技術サポートに連絡してください。

コールバックとリプレイ

返還 SCA は排他的な支払い callback に到達します。 Wealth Reader 相関を検証し、銀行のパラメータをそのまま提供者に転送します(予期せぬ名前は記録され、すでに許可された返還は拒否されません)、戻りのリクエストは一度だけ処理され、暗号化されたセンシティブ状態を保持します。繰り返しは HTTP 409のみ応答します。それは本文内の内部コードに依存しません。

認証には複数のリダイレクトが必要になることがあります。検証された各 REDIRECT は同じ SCA ウィンドウ内で続き、新しい callbackチェックポイントを開きます。新しいイニシエーションは作成しません。結果 DECOUPLED は意図を保持し、ウィジェットがステータスを問い合わせるための意図を processing 保持します。明示的な RETRY は、すでに準備済みの完了のみを繰り返し、待ち時間と試行回数に制限があります。 ERROR、 PASSWORD、 MORE_INFO、 SELECT_OPTION、未知の結果やそれらの制限の尽きは照合が必要な状態になり、新しいイニシエーションにはなりません。

マーチャントはその callbackを公開したり処理したりする必要はありません。このリリースはマーチャントにウェブフックを送信しません。公開された決済確認の仕組みはサーバー間の状態を定期的に問い合わせるものです。

ウィジェットの閉じる

flow_closed は、目に見えるやり取りが終了したことを伝えます。フロントエンドはモーダルを閉じることができますが、そのイベントに対して「支払済み」と表示されてはなりません。バックエンドは決済確認や照合の責任を保持します。

次のステップ

リストを完成させるセキュリティとテスト.

最終更新 2026-09-10