Stripe決済機能、怒涛の3本勝負

はじめに

今年決済を伴う新規サービスの開発、運用を行う過程でStripeを初めて使用し、
怒涛の勢いで決済機能の開発を行ったので今年の振り返りも兼ねて記事にしたいと思います。

私は都内でフリーランスのエンジニアをしています。
プロフィールはこちら。

インフラ構成

使用技術

使用した技術は下記になります。

• フロントエンド
  • vercel
• バックエンド
  • TypeScript、express
• インフラ
  • ECS、Fargate
  • Amazon Aurora
  • ElastiCache(Redis)
  • AWSSQS

構成図(簡易版)

クレジットカード決済

Stripe自体が初めての使用だったので苦労した記憶があります。
ConnectAccountへの分配報酬を考慮したPaymentIntentの作成方法。決済確定から注文処理までの一連のフローを初期段階で構築できたので後続の決済機能の基盤を作ることができたがかなりの収穫でした。Stripeはテストカードが豊富なので失敗ケースや3DSカードまで幅広く行うことができました。

決済フローイメージ(正常系のみ)

銀行振込決済

注文処理の基盤はできていたので比較的に実装は入りやすかったですが、
バーチャル口座の理解と金額によって自動消し込みで実行されるwebhhookイベントの網羅に苦戦した覚えがあります。
バーチャル口座は事前に顧客毎に割り振られるものなので顧客によっては事前に全額払っている場合や、一部のみ入金してくるパターンなどを考慮するの実装のポイントでした。

決済フローイメージ(正常系のみ)

定期購読決済(サブスク)

定期購読が今ままでの決済方法の中で一番難易度が高かったです。
定期購読の場合、定期購読(subscription)、請求書(Invoice)、注文(PaymentetIntent)のステータスを管理する必要があり仕様との整合性を合わせるのがかなり難しく感じました。
なので正常系、異常系を網羅して実装するのがかなりのポイントでした。

決済フローイメージ(正常系のみ)

最後に

Stripeは高機能かつドキュメントが豊富なので各種ビジネスフローに合わせやすく、決済サービスとしてとても優れていると感じました。
定期購読では先の日付のテストも行う必要があるのですがTestClockというものがあり顧客の時間を未来に擬似的に動かすこともできイベントを発生させることができるのでとても重宝しました。
反面、機能が多いかつプロパティも多い分どれを選択する必要があるのかを見極めるのが導入のポイントだと感じました。

ネイティブアプリ以外での決済機能は初めでしたが、1年間で実装してリリースまで持っていけたことはかなり自信になりました。この記事でStripeを導入するハードルが少しでも低くなれば幸いです。