WebMoneyがつらい
私はWebMoneyを個人顧客として使ったことはありません.
決済手段として導入しようとしていてとにかく仕様が地獄.
怒りのあまり文章が整ってないですし順序も支離滅裂です.
私の怒りを整理するために書いているのであまり参考にはならないかもしれません.
仕様書が簡単にアクセスできる場所にない
「問い合わせ」をしないと仕様書が見れません.
普通にweb上にパブリックに公開していません.
我々の場合, 詳細な仕様書が来たのは契約後でした.
なので私は契約する前にWebMoneyの仕様書を確認することが出来なかったので, 契約することを止められませんでした.
仕様書がPDF
WebなんだからHTMLで提供してほしい.
コピーも難しいしコード例もとても見づらい.
動作確認環境が古すぎる
Linux glibc2 (kernel 2.4/2.6)になっております.
CGIの設置を要求してくる
今時本物のCGIです.
FastCGIとかですらありません.
ApacheかIISでしか動かないことになります. これは公式確認環境です.
これが私の環境では地獄を生み出しました.
しかもCGIの上にネイティブELFファイルです.
元々CGIで組み合わせが困難な上にネイティブELF, なので解析による書かれていない仕様の把握が困難です.
こちら側で通信をコントロールできない
APIを使うという時にこちら側で通信を完全にコントロールすることが出来ずに, 決済が完了しようとする時に相手のサーバがこちらのサーバに通信を送ってきます.
しかもそれらの仕様が一切書かれていません. メソッドがPOSTであるということすら仕様書のPDFに書かれていません.
開発用モードがない
開発環境では開発モードで動かして, それからAPIキーを本番用にしたいですよね. 無いです.
一応テスト用プリペイド番号は存在しますが, 提供側が開発者モードにする方法は存在しません.
ローカルでテストできない
前述のように向こうから通信を送ってきてそれを受け取るサーバが必要なのでローカル環境で開発できません.
何かしらのサーバ上で動かす必要があります.
少しコードを変えるたびにサーバにデプロイして手動テストが必要になります. 地獄.
通知用モジュールがHTTPでアクセスしてくる
80番ポート固定です. うっかりHSTS導入も出来ない.
設定ファイルなどの文字コードがShift_JISかEUC-JP
正気か? しかも環境によって異なるので一定しない.
改行コードが(LF または CRLF)と書いてる
どっちだよ.
設定ファイルが謎フォーマット
PARAM.TXTという設定ファイルのフォーマットが謎. CSVと書いていますが, カンマの後に値を省略してたりするので私の知ってるCSVですらない. XMLが嫌でJSONが良いとかが贅沢な悩みだとわかりました.
もちろん文字コードはShift_JISなどですし改行コードは定まっていません.
命名にセンスがない
謎の略語が多すぎる.
引数の制限が厳しすぎる
商品名にまともに記号が使えないとか, 半角カナが使えないとか, スペースの際にエスケープが必要だとか, それらの形式がまとまった形で仕様書として書かれていないのはまあ良いとします. 諦めて使わないので.
発注コードの仕様が許せない,
「任意にご指定いただける」と書かれているくせに,
+-=._@[]
以外の記号が使えないとか,
128文字までしか使えないとか,
何処が任意やねん.
任意って言葉の意味がわからない.
JSONもXMLも使えないおかげでこれ用の専用エンコードを開発してしまいました.
日時の形式が意味不明な上にタイムゾーンが定まってない
YYYYMMDDhhmmss
はないでしょ.
ISO 8601準拠にしてとまでは言いませんが,
何かで区切るとかしないんですか.
そして仕様書の何処を見てもタイムゾーンが規定されていないため, エスパーする必要があります. 未だにタイムゾーンがなんなのかはわかりません.
決済完了すると1つのCSVファイルにデータを追記する
もうCSVは諦めるとして, ファイルにデータを追記するのは完全に地獄. 追加されるたびにデータを全探索して現在RDBに入っている値かどうか確かめてマージする必要があって, 数が増えたら破綻するんじゃないですかこれ?
決まった連番を作るとか, ファイルを分けるとかしてくれれば少しはマシだったんですが…
JSONでないのでBoolを表現するのに0
と1
を使っているあたりも細かな地獄を表現しています.
カレントディレクトリの仕様を書いていない
カレントディレクトリを実行ファイルと同じ場所に設定しないと全てのモジュールは動かないのですがそういうこと書いてない.
エラーが意味不明
エラーが短すぎる上にソースコードも開示されてないので何が原因なのか即座にわかりません.
独自のエラーファイルを見ても意味不明なので, ユーザ側が見れるweb側のエラー表示は全く参考になりません.
別オリジンからPOSTでHTTPリクエストしてくる
別オリジンからPOSTはないでしょ. こっちはCORSの根本的対策としてミドルウェアレベルでトークンなしのPOSTを全面禁止してたんですよ. この事情でセキュリティを緩めざるを得なかったのは屈辱でした.
最終的にエラーメッセージを出さずに沈黙し始めた
もう嫌になってきました.