QR決済アプリの新規構築
店舗でQRコードを使って決済する簡単決済アプリの、中核となる決済フローを作りました。ユーザーはこのアプリでプリペイド式の決済手段を発行してもらい、加盟店のQRコードで支払い、ポイントやクーポンも同じアプリで使います。プロトタイプ段階で一度止まったプロジェクトを、決済機能を中心に簡素化して出し直す仕事でした。決済アプリでは、同じ要求が二度送られたり、失敗した決済が成功のように見えたりすれば、すぐにお金の問題になります。作業はQRスキャン、決済要求、サーバー応答の解釈、完了・失敗の表示まで続く決済フローと、その例外処理の全体にわたります。
QRスキャンから決済完了まで途切れない一つの流れ
QR決済アプリの決済は、コードをスキャンし、決済を要求し、サーバー応答を受けて完了か失敗を示す順で進みます。この順序を一つの流れにまとめ、ユーザーがいまどの段階にいるかを画面で分かるようにしました。決済が進行中なのか終わったのか、ユーザーが迷わないことを画面構成の基準にしました。

重複・遅延・取消を先に考えた決済要求
決済要求には正常な応答だけが返ってくるわけではありません。同じ要求が二度送られる場合、失敗応答、ネットワーク遅延、決済の途中でユーザーが取り消す場合を、決済フローと一緒に設計しました。決済要求と結果確認の過程で、要求・応答・画面の状態が互いにずれないよう合わせ、ユーザーに誤った決済状態が見えないようにしました。

形式の異なるサーバー応答をアプリの状態に移す解釈ルール
決済サーバーは、よく使われるデータ形式とは異なる独特な形式で応答を返していました。この応答を読み込む処理を作り、応答のケースごとにアプリがどの状態へ移るべきかを結び付けました。正常な決済だけでなく、エラーコード、欠けた項目、形式の崩れた応答でも、アプリが止まらず決められた画面へ進むようにしました。

二つのプラットフォームが同じ決済基準に従うようにした協業
同じ決済サービスのもう一方のプラットフォームのアプリは、別の開発者が担当しました。決済ロジックとサーバー応答の処理方針をその開発者に説明し、実装を手伝いました。プラットフォームが違っても決済ポリシーと例外処理の基準が同じでなければ、同じ決済がアプリによって違う結果に見えてしまいます。

この仕事のポイント
QRスキャンから決済完了・失敗の表示までつながる決済フロー
重複要求・失敗応答・ネットワーク遅延・ユーザーの取消に備えた例外処理
形式が独特なサーバー応答の解釈と、エラーコード・欠落項目の処理
インサイト
GA4 client_storage: 'none'은 정말 쿠키를 막을까?
두 달 전 이 블로그에 「GA4 쿠키 없이 쓰기」라는 글을 썼습니다. clientstorage: 'none' 으로 쿠키 저장을 끄고, 자체 분석이 쓰던 익명 ID 를 clientid 로 넘기면 쿠키 0개로 GA4 를 쓸 수 있다는 내…
GA4 Measurement Protocol: gtag.js 없이 서버에서 이벤트 보내기
랜딩 페이지의 전송량을 파일 단위로 쪼개 보다가, 가장 큰 파일이 우리 코드가 아니라는 것을 알았습니다. Google Analytics 의 gtag.js 였고, 방문 한 번에 176KB 를 받고 있었습니다. 페이지 전체가 1,094K…
중소 제조업 AI 도입 순서: DX를 먼저 끝내야 할까?
공장을 가진 중소·중견 제조기업 16만여 곳 가운데 스마트공장을 도입한 곳은 19.5%입니다. 회사가 작을수록 이 비율은 더 떨어집니다. 중소벤처기업부가 2025년 4월에 낸 제1차 스마트제조혁신 실태조사 결과입니다. 그림: 기업 규…
Next.js loading.tsx와 404: 버튼이 화면보다 먼저 살아나게 하기
관리 화면 왼쪽 위에 사이드바를 접고 펴는 ☰ 버튼이 있습니다. 폭 하나 바꾸는 버튼인데, 대시보드에서 누르면 2초 넘게 아무 반응이 없었습니다. 레이아웃만 바꾸는 일이 왜 이렇게 오래 걸리는지부터 들여다봤습니다. Next.js 16…



