Stripeからfincodeへの乗り換えでかなり苦労した話 – 開発日記(99)

2024/05/15

Stripeからアカウント閉鎖のお知らせが来て不信感が募ったので、fincodeに乗り換えることにした話の続きです。

fincodeで決済連携を行うための調査を色々実施。

ユーザが支払いをするとき、自社サイトではなく「決済代行会社のサイトに用意されているページ」に飛ばして決済する、いわゆるリンク型決済を使いたい。（fincodeではリダイレクト型決済と呼ぶ）
しかもidea LaneはSaaS型なので継続課金でそれを使いたい。

ところが調査の結果、fincodeでは難しそうだった。

• 以下fincodeサポートに確認済み
  • リダイレクト型決済…サブスクリプションの申し込みを受けるには、カード登録におけるプラン情報の受け渡しができないため利用が難しい
  • コンポーネント型決済…レイアウトが不自然で、かつiframeのため外からCSSをいじることもできない（iframeの中身をいじろうとしても、ドメインが異なるためブロックされる）

上記のようなiframeの画面に対し、外側からhtmlやCSSをこねくり回して字をかぶせたりすることも考えたが、かえって手間がかかりそうだ。

SaaS型サービスの決済申し込みを受け付ける際、fincodeではリンク型もコンポーネント型も使えないとすると、決済代行会社ががホストするページを利用するのはもう断念するしかない。

つまり決済入力の画面と機能を自サイトで作るしかなさそうだ。

結局カード入力フォームを作ることになるのか……。
正直バカバカしいが、やむをえない。

fincodeがホストするページの処理を多く真似させてもらって、idea-laneドメイン内に決済ページを作成した。

慣れてない作業なので結構大変でした……。
（Stripeさえ安心して使えたらこんな無駄な苦労しなくて済むのに！ という心のぼやきがw）

画面だけは出来たので以降は動作の実装に取りかかる。

2024/05/16～17

fincode連携の実装

• カード入力画面の挙動の調整（バリデーションなど）
• トークン化の処理
• 入力された情報に対処するバックエンドの各処理
• バックエンドから返ってきた情報をカード入力画面やアプリ側でどう対処するか
• カード入力処理の前に行うfincode顧客情報の登録周り
• idea Lane上のプランの選択とカード入力画面への繊維・連携

など、全て実装しなければならないのでどうしても時間を取られる。

2024/05/18

今日はfincodeの顧客情報のチェック・登録周りなどを実装

• fincodeの顧客周りの仕様で気づいたこと
  • ある顧客IDで一度顧客を作ってしまうと、顧客を削除してもそのIDは再利用出来ないようだ。
    • fincodeの管理画面上、見た目は消えている。そしてAPIで確認しても「その顧客は居ません」となる。
    • それなのに同一IDで登録しようとするとエラーが発生。すごく使いづらい。
  • サポートに問い合わせたがそれが仕様とのこと。登録時に任意の顧客ID指定は可能だが、そのIDが本当に使えるかどうかを確認する手段は用意していないらしい
  • fincodeの顧客IDを自動発番にした場合、今度はidea Laneの会員IDをfincodeに持たせることが出来なくなってしまう。fincode側に任意の項目が何も無いため。とても不便
    • これもサポートに聞いたが、任意の情報は持てないそう。。。

ここまでfincode連携だけで相当の時間を消費しているが、上記のようにfincodeの機能不足と実装がしづらいと感じる仕様にたびたび遭遇して、気持ち的に辛くなってきた。

• たとえばAPIでカードのトークンを作る際、カードの番号がおかしくてもトークンが発行できてしまう。処理後のエラーもあらためて対応しなければならない。
• 細かなバリデーションやエラー対応、サブスクの状況確認など、何もかも作らないといけない。Webhookはあるが自分が期待したような挙動でないため、色々なチェックを手で組まないといけない。
• サブスク加入後の対応（状況確認・期限切れの対応・キャンセル対応・プラン変更・カード変更）も、画面から処理から全てこちらで用意しないといけない。

決済代行は他に3社具体的にチェックしていたが、いずれも実装が楽になるように色々考えられていた。fincodeもサブスクで無ければそこまで大変では無かったかもしれないのだが……。それにしても仕様的に微妙と思うところに色々出くわす。サポート側も回答はしてくれるが対応は何もしてくれない。

fincodeで作り込んでしまってきているので、今更他のものにスイッチするのもしんどい。が、もしこれが最初から分かっていたら選ばなかった。

コスト面を重視したとはいえ、手数料が同水準の会社は他にもある。日本企業という安心感を取ったのが一番の大きな理由だったのだが、結果として決済連携では想像以上の時間と労力を費やすことになってしまった。（あくまでも私の場合は、です）

2024/05/19～22

毎日、fincodeとの連携の実装に取り組む。

結構な時間を使い、正常系は動くようになってきた。が、まだまだ対応しなければならないところがたくさんある。

• fincodeの仕様で知ったこと
  • 決済登録APIで”item_code”:というのがあり、商品コードとして使いたいが挙動がおかしいのでサポートに聞いたら「現在閉塞しているパラメータです」とのこと。それならドキュメントにも掲載しないで欲しい…
  • 決済完了時のメール送信について、用意された機能が利用できないことが判明。fincodeのメール送信機能はリダイレクト型専用であり、それ以外（つまりJSやAPI経由の決済）では使えないとのこと。とすると、決済完了時に送られるメール送信も自前で実装しないとダメか…

ということでfincodeとのAPI連携に加えて、決済完了時のメール送信の実装もすることに。

メール送信はサーバ側で行うことになる。メールを送るプログラムをnode.jsで書いたことはこれまで無いが、nodemailerというモジュールを使って実装してみた。

文面をjs内にHTMLで書いて、Cloud FunctionsからSMTPサーバへ向けて送信する処理を書いたら無事に送れた。まだテストだけなのでこれからエラー処理やメール文面の改善やパラメータでの出し分けなど改善をしていく必要性がある。

うーん、決済連携ばかりに時間を取られ、idea Laneの本来の機能実装に使える時間が全く持て無くて、だいぶ辛くなってきた。

2024/05/23～28

引き続き毎日、fincodeとの連携の実装に取り組む。

• カード番号入力画面での全角文字入力対策など
• fincodeの決済は日本時間で処理するので、cloud functions側のタイムゾーン対応など
• 主にエラー時のメッセージやログの対応
• サーバサイド処理はfincodeの決済周りしか作っていないが、それでもだいぶロジックが複雑化してきたのリファクタも実施。6つのモジュールに分けた。
• サブスクリプションの更新・停止受付の実装
• 例外対応や処理の安定化

それにしてもあまりにも決済周り(というかfincode連携)で時間を取られてしまっている。

気分転換？を兼ねてアイディアの高さを変える機能の実装に着手。

実験段階でなので処理が甘いが、ドラッグでアイディアの高さを変えることができるようになった。

そしてここまで苦労したfincode連携は思わぬ結末を迎えることに……。

---

※開発日記は当時の記録をもとに作成し、必要に応じて加筆・補足しています

---