Skip to content
制作実績一覧
フィンテック / 決済Research

ZENITH — 決済オーケストレーション実験

ZENITH — Payment Orchestration Experiment

Stripe / PayPay / Komoju など複数PSPを抽象化する決済オーケストレーションレイヤのR&D。冗長化ルーティング、不正検知、3-D Secureハンドリングを統一APIで提供する。

2026 R&D 2026-03
#Payments#Orchestration#PCI DSS#Workflow#Fraud#3DS

ライブデモ

実際のアプリケーション画面のプレビュー

DEMO
app.zenith.jp/dashboard
+9.3%

¥8,432,100

本日の取引額

+14.1%

1,247

取引件数

+0.2%

98.7%

成功率

-3.1%

¥6,762

平均決済額

取引ボリューム

時間帯別決済件数

今日昨日
6時
8時
10時
12時
14時
16時
18時
20時
22時
0時

最近の取引

取引ID顧客金額決済方法ステータス時刻
TXN-8291株式会社テクノ¥128,000Stripe成功14:32
TXN-8290山田商事¥45,600PayPay成功14:28
TXN-8289佐藤リテール¥234,000Stripe処理中14:25
TXN-8288高橋デザイン¥18,900Komoju成功14:21
TXN-8287田中フーズ¥67,200PayPay失敗14:18
TXN-8286鈴木建設¥412,000Stripe成功14:15

決済方法内訳

1,247総取引
Stripe45% (¥3,794,445)
PayPay30% (¥2,529,630)
Komoju15% (¥1,264,815)
その他10% (¥843,210)

不正検知アラート

4件
92
異常な金額パターン

不明アカウント · 14:30

74
複数デバイスからのログイン

外部ユーザー#482 · 14:12

68
短時間での大量決済

テストアカウント · 13:55

45
地理的異常アクセス

渡辺商店 · 13:40

課題

複数PSPを直接扱うと、失敗時のフォールバック戦略、3DSチャレンジ、Webhook冪等性がサービスごとにバラけ、本業のビジネスロジックを侵食する。また不正検知モデルを自前で持つにはデータが不足することが多い。

ソリューション

PSPアダプタを「決済意図 → 認可 → キャプチャ → 返金」の統一ステートマシンで表現し、Temporalで永続化。ルーティングはコスト/成功率/地域を重み付きで評価。不正検知はルールエンジン + 小規模モデル (XGBoost) のハイブリッドで、解釈可能性を重視。PCI DSSスコープを最小化するため、カードデータは常にPSPのElementで扱う。

成果

  • 複数PSPを統一APIで扱いエッジ関数から呼び出し可能に
  • 擬似トラフィックで認可成功率を +4.1pt 改善
  • Webhook冪等性テストで二重計上をゼロ化
  • 不正検知ハイブリッドモデルでAUC 0.94
Key Metrics

Measured Impact

認可成功率改善

+4.1pt

Webhook二重計上

0件

不正検知 AUC

0.94

PCIスコープ

最小

Features

What it does

決済

統一API

複数PSPを単一インターフェースで扱い、切替コストを最小化。

ルーティング

コスト・成功率・地域に応じた重み付きPSP選択。

リスク

ハイブリッド不正検知

ルール + モデルで高精度かつ解釈可能なスコア。

3-D Secure

Challenge/Frictionlessの両フローを統一ハンドラで処理。

運用

冪等性

全書き込みに冪等キーを必須化し、Webhookの再送にも安全。

監査と再現

Temporalのイベント履歴から任意の決済を完全再現可能。

Architecture

System Layers

Layered architecture showing components, responsibilities, and data flow.

L1

Layer

API

gRPC内部APIと外部向けREST/GraphQLの二重化。

gRPCREST GatewayOpenAPI
L2

Layer

オーケストレーション

Temporalワークフローで決済ステートマシンを永続化。

TemporalSagasIdempotency Store
L3

Layer

PSPアダプタ

各PSPの差異を内部DSLに抽象化し、上位層からは統一表現で扱う。

StripePayPayKomojuAdyen
L4

Layer

リスク

ルール + モデルのハイブリッドで、解釈可能なリスクスコアを算出。

ルールエンジンXGBoostFeature Store
L5

Layer

セキュリティ

鍵はVault管理、カード情報はPSPのElementに限定し、PCI DSSスコープを最小化。

HashiCorp VaultKMS監査ログ
Development Process

How we built it

01

Discovery

想定顧客のPSP利用パターンを調査しルーティング要件を整理。

Deliverables

  • 要件ドキュメント
02

脅威モデル

STRIDEで脅威を洗い出し、対策をロードマップに落とし込む。

Deliverables

  • 脅威モデル文書
03

ドメインモデリング

決済ライフサイクルを統一ステートマシンに落とし込む。

Deliverables

  • ステートマシン図
04

Implementation

Temporalワークフロー中心に段階的にアダプタを追加。

Deliverables

  • アダプタパッケージ
05

QA

Webhookリプレイ・冪等性・Chaosテストを自動化。

Deliverables

  • 自動テスト
06

Red Team

外部ベンダによるレビューとペネトレーションテスト。

Deliverables

  • レッドチームレポート
07

Iteration

ルーティング重みとリスクモデルを継続改善。

Deliverables

  • 改善PR
Roadmap

Delivery Timeline

  • P0Done2026-03-06

    ドメインモデリング

    決済ライフサイクルを統一ステートマシンで表現。

  • P1Done2026-03-24

    PSPアダプタ

    Stripeアダプタを初期実装し、テスト環境で動作確認。

  • P2In Progress2026-04-16

    冗長ルーティング

    コスト/成功率/地域を重み付けしたPSPルータを開発中。

  • P3Planned2026-05

    不正検知

    ルール + XGBoostハイブリッドモデルを開発予定。

  • P4Planned2026-06

    セキュリティ監査

    外部セキュリティベンダによるコードレビュー+ペネトレーションテストを予定。

Team

Who built it

3engineers

Roles

  • バックエンド/決済
  • セキュリティ
  • ML/リスク
技術スタック

Tools & Platforms

Frontend

Next.js

Backend

GoStripe APIPayPay APIKomoju API

Data

PostgreSQLRedisKafka

Infrastructure

OpenTelemetryKubernetes

Other

gRPCTemporalXGBoostVault
Build with KGA

同様のプロジェクトをお考えですか?

お客様のビジネスに最適なソリューションをご提案いたします。

プロジェクトを相談する