はじめに：私たち決済代行は、キャッシュレス社会を支える「インフラ」である。

ネットショップで「購入する」ボタンを押してから、注文完了画面が出るまでの数秒間。その裏側では複数のシステムが通信し、クレジットカード、コンビニ決済、電子マネー、銀行振込、後払いなど、選ばれた支払い方法に応じた処理が行われ、その結果が記録されています。このとき、商品を販売する事業者と決済会社のあいだに立ち、取引をつなぐのが私たち決済代行です。

当たり前に使用しているネットショプ。止まれば買い物そのものができなくなる。
決済代行は、電気や水道のように、キャッシュレス社会を裏側で支える重要なインフラです。

この記事で使う言葉

決済の世界では似た言葉が混在しがちなので、最初に整理しておきましょう。

• 加盟店：決済会社と契約し、商品やサービスの代金を受け取る事業者。ECサイト（ネットショップ）、実店舗、サブスクリプション型のWebサービスなどが該当します。この記事では「お店」「ECサイト」もすべて加盟店と呼びます。
• 決済会社：カード会社、コンビニ収納の事業者、電子マネー事業者など、実際に決済を処理する会社。
• 決済代行：加盟店と決済会社のあいだに立ち、両者をつなぐ事業者・サービス。
• エンドユーザー：加盟店で買い物をする消費者。

決済代行の仕組み：3者の関係と決済の流れ

冒頭で紹介した加盟店・決済代行・決済会社の関係を図にすると、次のようになります。

加盟店がつなぐ先はオールインウォレットの1本だけで、その先の決済会社ごとの違いはオールインウォレットが吸収します。

クレジットカード決済を例に、エンドユーザーが「購入する」を押してからの流れを追ってみましょう。

1. エンドユーザーが加盟店のサイトで支払い方法を選び、購入操作を行う
2. 加盟店のシステムが、決済代行のシステムへ決済リクエストを送る
3. 決済代行のシステムが、リクエストを決済会社の仕様に合わせて変換し、送信する
4. 決済会社が与信（カードが使えるか、限度額は足りるか）などを判定し、結果を返す
5. 決済代行のシステムが結果を記録し、加盟店にわかりやすい形で返す
6. 加盟店のサイトに「注文完了」が表示される

文字にすると単純ですが、エンジニアの目で見るとポイントがいくつもあります。リクエストの変換、通信エラー時の扱い、結果の記録と通知。どれも「ほぼ動く」では許されない部分です。

「お金を扱う」とは、絶対に間違えられないということ

決済システムで扱うデータは、そのまま誰かのお金です。1件の二重決済、1円の金額ズレ、1つのステータスの取り違えが、加盟店の売上やエンドユーザーの信頼を直接損ないます。「たまに起きる不具合」が許されない世界です。

だからこそ、私たちは次のような考え方を大切にしています。

• 正常系より先に異常系を考える：タイムアウト、通信断、重複リクエスト、決済会社側の障害。うまくいかなかったときに何が起きるかを、設計の起点にします。
• 「わからない状態」を放置しない：結果が不明な取引は、照会して必ず確定した状態に収束させます。
• 後から必ず説明できるようにする：いつ、何が起き、どう処理されたかをログで追えることを、機能と同じ重さで扱います。
• 変更には慎重に、確認は重ねて：レビューとテストを重ね、リリースの影響範囲を事前に洗い出します。

派手さはなくても、一つひとつの判断を丁寧に積み重ねる。それが、お金の流れを預かるエンジニアの仕事です。具体的な技術課題は、後半で詳しく紹介します。

なぜ決済代行が必要なのか：加盟店が抱える3つの壁

もし決済代行がなければ、ECサイトを運営する事業者（加盟店）は、使いたい決済手段ごとに決済会社と個別に向き合う必要があります。そこには大きく3つの壁があります。

1. 開発コストの壁

クレジットカード、コンビニ決済、電子マネー、銀行振込、後払い。決済会社ごとに仕様は異なります。認証方式、リクエストの形式、エラーコードの体系、結果通知の受け取り方、テスト環境の用意のされ方まで、すべてがバラバラです。

決済手段を5つ導入したければ、5通りの接続を実装し、5通りのテストを行い、5通りの仕様変更を追い続けることになります。本業のサービス開発に充てたいエンジニアの時間が、決済の「配管工事」に吸われていきます。

2. 運用・管理の壁

接続した後も大変です。売上の確認、取消や返金の処理、障害時の調査。決済会社ごとに管理画面が分かれていれば、担当者は複数の画面を行き来しながら突き合わせ作業をすることになります。「この注文の決済は今どうなっているのか」に答えるだけで、何分もかかってしまうのです。

3. セキュリティとコンプライアンスの壁

カード情報を扱う決済には、PCI DSSをはじめとする厳格なセキュリティ基準があります。日本では割賦販売法の改正により、加盟店にもカード情報の適切な管理が求められるようになりました。自社だけで一から対応しようとすると、専門知識と大きなコストが必要です。

なお、オールインウォレット自体はカード情報を保持しない設計です。カード情報の処理は、オールインウォレットの先にある、PCI DSSに準拠した決済会社側のシステムが担います。加盟店はこうした仕組みを利用することで、カード情報の取り扱いを専門のシステムに任せることができます。

決済代行は、これらの壁を加盟店の代わりに引き受ける存在です。言い換えれば、決済の複雑さを吸収し、シンプルなインターフェースとして提供することが、私たちの価値の核になります。

オールインウォレットとは：「1回つなげば、全部使える」決済モジュール

オールインウォレットは、クレジットカード決済・コンビニ決済・電子マネー決済などの導入を希望する事業者と、各決済会社のシステムをつなぎ、多彩な決済を一括で管理できるサービスです。

ポイントは、オールインウォレットがすでに各決済システムと接続済みであることです。加盟店はオールインウォレットとさえつなげば、さまざまな決済手段を使えるようになります。決済ごとのシステム構築が不要になり、開発コストを大きく抑えられます。

提供価値を整理すると、次のとおりです。

契約面にも特徴があります。加盟店審査や加盟店契約は原則として各決済会社と直接結び、イーウォレットとは決済モジュールの使用契約を結ぶ形です。売上も原則として各決済会社から加盟店へ直接入金されます（一部、弊社との契約・弊社からの振込となる決済もあります）。

つまりオールインウォレットは、決済の「情報」の流れを正しく、安全に、確実につなぐことに責任を持つシステムです。エンジニアにとっては、ここが一番の腕の見せどころになります。

開発の裏側：決済システムならではの5つの技術課題

「複数の仕様をラップするだけ」に見えて、決済システムの開発には、Webサービス一般とは少し違う緊張感があります。扱うのが「お金」である以上、バグの影響は直接、加盟店とその先のエンドユーザーの財布に及ぶからです。ここでは、私たちが日々向き合っている代表的な課題を紹介します。

1. 異なる決済仕様を、ひとつのモデルに抽象化する

クレジットカードは「与信→売上確定」の2段階、コンビニ決済は「受付番号の発行→店頭での支払い→入金通知」という非同期の流れ。電子マネーや後払いにも、それぞれ独自のライフサイクルがあります。

これらを加盟店から見て一貫したインターフェースで扱えるようにするには、決済の状態をどうモデル化するかが鍵です。共通化しすぎると個別の決済手段の特性が失われ、個別化しすぎると加盟店にとっての使いやすさが損なわれる。この抽象化の線引きこそ、設計者の腕が問われるところです。新しい決済手段を追加するときも、既存の加盟店に影響を与えずに拡張できる構造が求められます。

2. トランザクションの状態管理と整合性

決済には「途中で止まる」可能性が常にあります。決済会社へのリクエストがタイムアウトしたとき、その決済は成功したのか、失敗したのか。ネットワークの向こう側の状態は、こちらからは即座にはわかりません。

そのため、状態遷移を厳密に定義し、不明な状態を検知したら照会して正しい状態に収束させる仕組みが必要です。トランザクションログは、障害調査や問い合わせ対応の生命線でもあります。「いつ、誰が、何をリクエストし、どんな結果が返ったか」を後から正確に追える設計が欠かせません。

3. 冪等性：二重決済を絶対に起こさない

ユーザーがボタンを連打した、通信が不安定でリトライが走った。そんなときに同じ決済が2回実行されてしまえば、加盟店の信用問題に直結します。

リクエストの一意性をどう担保するか、リトライ時に前回の結果をどう返すか。**冪等性（idempotency）**の設計は、決済システムで最も基本的で、最も手を抜けない部分です。

4. セキュリティ：守るべき情報を、持たない・漏らさない

カード情報や個人情報を扱う以上、セキュリティは機能要件と同じ重みを持ちます。その前提として、オールインウォレットはカード情報を保持しない設計を採っています。カード情報の処理は、PCI DSSに準拠した決済会社側のシステムが担います。「持たなくていい情報は持たない」ことが、最も確実な防御だからです。

そのうえで、通信の暗号化、アクセス制御、ログに機微情報を残さない工夫、脆弱性への継続的な対応を積み重ねています。イーウォレットはプライバシーマークを取得しており、情報を扱う企業としての責任を開発の現場でも徹底しています。

5. 可用性：止まらないことが最大の機能

決済が止まれば、加盟店の売上が止まります。セールやキャンペーンの日にアクセスが集中しても、安定して処理し続けなければなりません。さらに、接続先の決済会社側で障害が起きたときに、それを素早く検知し、影響範囲を切り分けて加盟店に正しく伝えることも求められます。自分たちのシステムだけでなく、つながっている先の状態まで含めて面倒を見るのが、決済システムの宿命です。

コントロールパネル：バラバラの決済を「ひとつの画面」に

オールインウォレットのもうひとつの柱が、加盟店向けのコントロールパネル（管理画面）です。決済種別にかかわらず、各決済の進行状況、決済額、過去の取引をまとめて確認できます。

管理画面というと地味に聞こえるかもしれませんが、実は設計の難しさが詰まった領域です。

• 異なるデータを、同じ物差しで見せる：決済手段ごとにステータスの意味や粒度が違うものを、加盟店の担当者が直感的に理解できる形に揃える必要があります。
• 大量のトランザクションを素早く検索する：取引件数が増えても、注文番号や日付、決済種別でストレスなく絞り込めることが求められます。データ構造やインデックス設計の良し悪しが、そのまま使い勝手に表れます。
• 権限と監査：誰がどの操作をしたのかを記録し、必要な人が必要な情報だけにアクセスできるようにする。お金を扱う画面ならではの要件です。
• 現場の業務フローに寄り添う：問い合わせ対応や経理の締め作業など、加盟店の担当者が実際にどう使うかを想像しながら、画面や機能を改善していきます。

決済処理の堅牢さと、管理画面側の使いやすさ。この両方がそろって初めて「決済をまとめて任せられる」サービスになります。バックエンドからフロントエンドまで、一気通貫でプロダクトに関われるのもこの領域の魅力です。

決済の領域で働く面白さ

「正しさ」にこだわれる環境

多くのWebサービスでは、スピード重視で「まず出して、あとで直す」判断が求められる場面もあります。一方、決済では1円のズレも許されません。状態遷移、例外処理、境界値、リトライ。エンジニアが本来大切にしたい「正しく動くこと」に、正面から向き合える仕事です。

社会インフラを支える手応え

自分の書いたコードの先で、毎日たくさんの買い物や支払いが行われています。目立つことは少なくても、止まれば誰もが困る。そんなインフラを支えている実感は、この仕事ならではのやりがいです。

20年以上の知見と、変わり続ける決済の世界

イーウォレットは2004年から決済に携わってきました。長く運用されてきたシステムには、障害や仕様変更を乗り越えてきた知見が詰まっています。同時に、キャッシュレス化の進展で決済手段は今も増え続けています。積み上げてきた土台を守りながら、新しい決済を取り込んでいく。安定と変化の両方を扱えるのが、この領域の奥深さです。

こんな方と一緒に働きたい

次のような経験や志向をお持ちの方は、きっと力を発揮していただけます。

• Webアプリケーションやバックエンドの開発・運用経験がある方
• 外部システムとの連携や、非同期処理・状態管理を伴うシステムを設計した経験がある方
• データベース設計やパフォーマンスチューニングに関心がある方
• 「動けばいい」ではなく、障害時の振る舞いや運用まで考えて設計したい方
• セキュリティや品質への意識が高く、それをチームに広げていきたい方

決済システムの開発経験は必須ではありません。ドメイン知識は入社後に身につけられます。それよりも、複雑なものを丁寧に理解・分解し、「考える力」に自信がある方を歓迎します。

おわりに

決済代行とは、加盟店と決済会社のあいだに立ち、決済の複雑さを引き受けてシンプルな形で提供する仕事です。その中核にあるのは、異なる仕様の抽象化、トランザクションの整合性、冪等性、セキュリティ、可用性といった、エンジニアリングの本質的なテーマです。

オールインウォレットは、こうした課題に向き合いながら、加盟店が本業に集中できる環境をつくるためのシステムです。「お金が流れる道」を、より速く、より安全に、より使いやすく。その道づくりに、あなたの経験を活かしてみませんか。

少しでも興味を持っていただけたら、カジュアルな面談も大歓迎です！