会社情報
採用情報
お問い合わせ
Article

決済システム開発事例：セキュアなオンライン決済で顧客の信頼感向上

高田晃太郎
決済システム開発事例：セキュアなオンライン決済で顧客の信頼感向上

オンライン決済の離脱は売上の直結損失であり、業界調査では不正関連のコストが決済額の数％規模に達するケースが報告されています¹²。加えて近年はSCA（Strong Customer Authentication：強固な認証）の義務化やチャージバック増加への対処が急務となり、単なるゲートウェイ接続だけでは顧客体験も信頼も守り切れません³。公開情報やカードネットワークのガイドラインを見ると、EMV 3-D Secure 2（以下3DS2）の適用は承認率の改善に寄与しうることが示唆され³、トークン化（カード番号を代替トークンに置き換えて保護）や適切な鍵管理はPCI DSS（Payment Card Industry Data Security Standard：カード会員データのセキュリティ基準）のスコープ縮小と運用コスト低減に結びつくという一般的な相関が語られています⁴。そこで本稿では、中規模ECを想定した決済システム刷新の一般化ケースを、設計思想から実装、パフォーマンス、運用の学びまで具体的に共有します。技術的には中級以上を想定しつつ、ROIの観点も併置し、現場で明日から使える粒度に落とし込みます。

事例の全体像と要件定義：スコープ縮小と承認率の両立

対象は、月間数十万トランザクション規模のECを想定します。課題は、モバイルでの途中離脱、SCA未対応エリアの承認率低下、チャージバック比率の高止まりでした。非機能要件としては可用性99.99%、チェックアウトのp95レイテンシ250ms以内、RTO 15分、RPO 0に近い設計を目標に据えます。方針としては、自社サーバでカード情報を扱わないことを明確化し、フロントはホスト型フィールドで完全トークン化、バックエンドはプロバイダ非依存のアブストラクション層で統一し、SCAは3DS2を優先して段階適用する設計を採ります³。これにより、一般にPCI DSSの自己問診はSAQ Aに近づけられ、監査・運用の負荷を抑えつつ、信頼性と承認率の両立が期待できます⁴。

アーキテクチャはBFF（Backend for Frontend）の背後に決済サービスを置き、外部プロバイダとの通信はキューイングとWebhookの二系統で冪等制御を徹底するのが定石です。勘定系は二重仕訳の簡易レジャーで内部整合性を確保し、鍵素材はKMSでEnvelope暗号（データ鍵をマスター鍵で保護する方式）、シークレットは専用ボルトに格納します。スタックの一例としては、Node.js 20とGo 1.22、PostgreSQL 15、Redis 7、Nginx、Kubernetesを採用し、運用自動化と可観測性を前提に構築します。

セキュリティ設計：PCI DSS、トークン化、鍵管理

カード情報はフロントのホスト型要素から直接プロバイダへ送信し、サーバはトークンのみを扱います。これによりデータ保護の主戦場はトークン、Webhookシークレット、内部レジャーに集約され、結果として監査対象の縮小が期待できます⁴。鍵管理はKMSでマスターキーを管理し、アプリ側でデータ鍵を都度生成してEnvelope暗号化を行います。監査証跡としては、すべての復号操作を監査ログに残し、アラートはSIEMへ転送するのが実務的です。

信頼性と整合性：冪等性、再実行、レジャー

決済の二重請求は顧客の信頼を損ねるため、リクエストとWebhookの両方向で冪等性（同じ要求を繰り返しても結果が変わらない性質）を実装します。クライアントからのリトライはIdempotency-Keyで抑止し⁵、サーバ側ではRedisの原子的オペレーションで初回処理のみを許容します。状態遷移はPending、Authorized、Captured、Failedに限定し、二重仕訳レジャーで金額の一貫性を検証します。Webhookは順序不定を前提に、バージョンとイベントIDでの重複排除を行い、決済サービスの内部イベントに正規化してから処理するのが安全です⁶。

UXと承認率：3DS2、SCA、タイムアウト設計

3DS2はデバイス情報と行動シグナルに基づくリスクベース認証を提供し、チャレンジ不要のフリクションレス通過を拡大できます³。導入ではチャレンジの待ち時間を短縮するため、モバイルではWebViewではなく外部ブラウザにフォールバックし、戻りパスはディープリンクで回収します。ユーザーの操作が止まると離脱が起こるため、タイムアウトはUIで段階表示し、失敗時は保存済みカートに自動復帰させると顧客体験を損ねにくくなります。

実装ディテールとコード例：現場で使えるパターン

まずはチェックアウトAPIでの冪等性と3DS連携の基本形です。Expressを例に、Idempotency-Keyの検証とプロバイダ呼び出しのエラー処理を示します⁵。

import express from 'express';
import { v4 as uuidv4 } from 'uuid';
import type { Request, Response } from 'express';
import { createPayment, ProviderError } from './provider';
import { getOrSet, releaseKey } from './idempotencyStore';

const app = express();
app.use(express.json());

app.post('/checkout', async (req: Request, res: Response) => {
  const key = req.header('Idempotency-Key') || uuidv4();
  const lock = await getOrSet(key);
  if (!lock.acquired) return res.status(409).json({ error: 'In-progress' });
  try {
    const { amount, currency, token, customerId } = req.body;
    const payment = await createPayment({ amount, currency, token, customerId });
    return res.status(201).json({ payment });
  } catch (e) {
    if (e instanceof ProviderError && e.retryable) return res.status(202).json({ status: 'pending' });
    return res.status(502).json({ error: 'provider_failure' });
  } finally {
    await releaseKey(key);
  }
});

app.listen(3000);

次に、Redisで実装する冪等ロックです。SET NX EXを用いて初回のみ処理を許容し、プロセス障害時はTTLで解放します。

package idem

import (
  "context"
  "time"

  "github.com/redis/go-redis/v9"
)

type Store struct{ rdb *redis.Client }

type Lock struct{ Acquired bool }

func NewStore(rdb *redis.Client) *Store { return &Store{rdb} }

func (s *Store) GetOrSet(ctx context.Context, key string, ttl time.Duration) (*Lock, error) {
  ok, err := s.rdb.SetNX(ctx, "idem:"+key, "1", ttl).Result()
  if err != nil { return nil, err }
  return &Lock{Acquired: ok}, nil
}

func (s *Store) Release(ctx context.Context, key string) error {
  return s.rdb.Del(ctx, "idem:"+key).Err()
}

Webhookの署名検証とリプレイ対策です。タイムスタンプの許容窓を短く設定し、イベントIDで重複排除します⁶。

from flask import Flask, request, abort
import hmac, hashlib, time

app = Flask(__name__)
SECRET = b"webhook-secret"
WINDOW = 300  # 5 minutes

seen = set()

@app.post('/webhook')
def webhook():
    sig = request.headers.get('X-Signature')
    ts = int(request.headers.get('X-Timestamp', '0'))
    eid = request.headers.get('X-Event-Id')
    if abs(int(time.time()) - ts) > WINDOW:
        abort(408)
    body = request.get_data()
    mac = hmac.new(SECRET, f"{ts}.".encode() + body, hashlib.sha256).hexdigest()
    if not hmac.compare_digest(mac, sig or ''):
        abort(401)
    if eid in seen:
        return ("ok", 200)
    seen.add(eid)
    # process event safely
    return ("ok", 200)

フロントへの過負荷防止と不正トラフィック抑止として、Nginxでレート制御と接続再利用を有効化します。

http {
  limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;
  upstream api {
    server 127.0.0.1:3000;
    keepalive 64;
  }
  server {
    listen 443 ssl http2;
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
    add_header Content-Security-Policy "default-src 'none'; frame-ancestors 'none';";
    location /checkout {
      limit_req zone=perip burst=20 nodelay;
      proxy_http_version 1.1;
      proxy_set_header Connection "";
      proxy_pass http://api;
    }
  }
}

内部レジャーは二重仕訳で整合性を担保します。オーソリとキャプチャの分離、取消や払い戻しの逆仕訳を容易にします。

CREATE TABLE ledger_entries (
  id BIGSERIAL PRIMARY KEY,
  txn_id UUID NOT NULL,
  account TEXT NOT NULL,
  amount_cents BIGINT NOT NULL,
  currency CHAR(3) NOT NULL,
  direction TEXT CHECK (direction IN ('debit','credit')),
  created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);
-- invariant: SUM(debit) == SUM(credit) per txn_id
CREATE UNIQUE INDEX ON ledger_entries(txn_id, account, direction);

シークレットの保護にはEnvelope暗号を用います。KMSでデータ鍵をラップし、復号イベントは監査対象にします。

import { KMSClient, EncryptCommand, DecryptCommand } from '@aws-sdk/client-kms';
const kms = new KMSClient({});

export async function seal(plaintext: Buffer, keyId: string) {
  const enc = await kms.send(new EncryptCommand({ KeyId: keyId, Plaintext: plaintext }));
  return Buffer.from(enc.CiphertextBlob as Uint8Array);
}

export async function open(ciphertext: Buffer) {
  const dec = await kms.send(new DecryptCommand({ CiphertextBlob: ciphertext }));
  return Buffer.from(dec.Plaintext as Uint8Array);
}

可観測性はSLO（Service Level Objective）を守る生命線です。OpenTelemetryでトレースを付与し、外部プロバイダの待ち時間を可視化します。

import { trace, context } from '@opentelemetry/api';
const tracer = trace.getTracer('payment');

export async function capture(id: string) {
  return await tracer.startActiveSpan('capture', async (span) => {
    span.setAttribute('payment.id', id);
    try {
      const res = await callProviderCapture(id);
      span.setAttribute('provider.latency_ms', res.latency);
      return res;
    } catch (e) {
      span.recordException(e as Error);
      span.setStatus({ code: 2, message: 'provider error' });
      throw e;
    } finally {
      span.end();
    }
  });
}

パフォーマンス最適化と計測の考え方：p95短縮の要因

刷新前のチェックアウトAPIでは、p95が数百ms台で頭打ちになることがよくあります。HTTP/2とKeep-Aliveの徹底、プロバイダSDKのコネクションプール化、Webhookを同期照合しないフローへの変更などを組み合わせると、p95を200ms前後まで短縮できるケースが一般に見られます。スループットについても、同様の最適化で千rps級まで線形に伸び、CPU使用率の閾値を超えずにSLOを維持しやすくなります。なお、これらは本番に近いステージングでの負荷試験に基づく参考例であり、実運用では日中帯の変動に応じて±10〜20%程度の揺らぎが見込まれます。

承認率は、3DS2のリスクベース通過やSCAの適切な適用により、主要地域で数ポイント改善するケースが報告されています³。チャージバック率も、ルールベースの前処理や3DSの免責適用と組み合わせることで大幅に低減することがあり、返金オペレーションの手作業削減につながる場合があります。コスト面では、PCI DSSのスコープ縮小により監査・ペネトレーションテストの対象が限定され、年次コストの削減が期待でき、導入後のROI可視化にも寄与します⁴。

ボトルネック解析では、外部プロバイダへのネットワーク遅延が支配的になることが多く、リトライ戦略の見直しが奏功します。トランジェントなエラーには指数バックオフで再試行し、恒久的失敗は即座にフォールバックパスへ分岐します。これによりタイムアウトによるUIの固着を防ぎ、ユーザーの待ち時間の体感を抑えやすくなります。

ビジネス価値と運用の学び：信頼は設計から生まれる

セキュリティとUXの両立はトレードオフに見えますが、実際には整合性の高い設計が顧客の信頼を底上げします。冪等性は二重請求の不安を消し⁵、3DS2は不正と争うための共通言語になります³。結果としてサポート工数の抑制やCSATの向上、チャネル横断のLTV伸長に寄与しうる。経営的には、コンプライアンスコストの見通しが立つことで新規市場への展開計画が立てやすくなります。

移行戦略では、現行プロバイダと新プロバイダの並行稼働を通じてダークローンチとシャドートラフィックでの実測を重ねるのが有効です。フェイルセーフとして新系統がエラー閾値を超えた場合は自動で旧系統へ切り戻す仕組みを用意し、可逆なデプロイのみ実施します。計画外障害時の連絡経路や一時金額の過不足の社内フローも先に定義し、インシデント発生時に担当者が迷わないようにしておきます。

最後に、チーム運営の視点です。決済は横断領域のため、アプリ、SRE、セキュリティ、CS、法務を含む週次のリスクレビューを継続し、SLOのエラーバジェット消費と不正トレンドを同じテーブルで議論します。数値を共通言語にすることで、主観的な議論を避け、投資配分の意思決定が迅速になります。

移行の落とし穴を避けるために

アカウントアップデータやネットワークトークン導入は承認率の底上げに効きますが、カードライフサイクルの自動更新が前提になるため、サブスクリプション課金の設計とセットで検討すべきです。また、複数通貨・税計算・払い戻し規則は国別に異なり、チャージバック防御の条件も地域差があるため、決済ドメインのユビキタス言語をチーム内に育てておくことが後戻りを減らします。

まとめ：信頼を積み上げる決済の作り方

ここで示した設計指針は、トークン化と3DS2でセキュリティを高め、冪等性とレジャーで整合性を守り、可観測性でSLOを維持するという一貫した方針が、承認率の改善とチャージバック低減に結びつきうることを示しています。顧客は「支払えること」だけでなく「安心して支払えること」を評価します。だからこそ、設計の最初から信頼を組み込むことが重要です。

あなたのシステムで今日見直せるのは何か、Idempotency-Keyの実装か⁵、Webhook署名の検証か⁶、それとも3DS2の適用範囲か³。一つでも前進すれば、ユーザー体験は確実に良くなります。次のスプリントでは、ここで示したコード片をたたき台に、計測と改善のサイクルを回してみてください。信頼は日々の小さな積み重ねから生まれ、やがて確かな競争力になります。

参考文献

  1. Statista. E-commerce fraud - statistics & facts. https://www.statista.com/topics/9240/e-commerce-fraud/#:~:text=In%20the%20past%20decade%2C%20the,online%20shoppers%20and%20merchants%20alike
  2. Mastercard B2B. Ecommerce fraud trends and statistics merchants need to know in 2024. https://b2b.mastercard.com/news-and-insights/blog/ecommerce-fraud-trends-and-statistics-merchants-need-to-know-in-2024#:~:text=With%20particularly%20impressive%20ecommerce%20growth,East%20Asia%20on%20this%20measure
  3. Mastercard Payment Gateway. EMV 3-D Secure (3DS) and PSD2 SCA. https://www.mastercard.com/gateway/payment-solutions/secure-payments/emv3ds.html#:~:text=The%20PSD2%20legislation%20implemented%20in,factors%20for%20a%20successful%20transaction
  4. TokenEx. PCI Descoping: The Ultimate Guide to PCI Compliance. https://www.tokenex.com/blog/dp-pci-descoping-the-ultimate-guide-to-pci-compliance/#:~:text=PCI%20Descoping%20Example%3A%20Cloud
  5. Stripe Docs. Idempotent requests. https://docs.stripe.com/api/idempotent_requests#:~:text=The%20API%20supports%20idempotency%20for,or%20performing%20the%20update%20twice
  6. Brandfetch Docs. Webhooks best practices. https://docs.brandfetch.com/docs/webhooks/best-practices#:~:text=Webhook%20endpoints%20might%20occasionally%20receive,event%20payload%20includes%20an%20event