決済ステータス定義の最適解

ネットスーパーシステムの決済ステータス表現 (状態遷移) は複雑だ。 その理由は要求要件が多いことに起因しているが、多いことが悪いのではなく、それに応えなければシステムとして真の価値を発揮できないからで。逆に問題解決できなければ、著しく利便性を落としてしまうので、必須要件という位置付けにある。 前提文脈を汲み取りづらいモデリングなので、問題解決例を示すのはあまり見かけないが、自分が考えた決済ステータス定義の答えを示す。 この内容は過去にブログや登壇で話した内容の延長でもあるので、過去の内容も参考にすると良いかもしれません。 「E-Groceryにおけるカード決済処理の難しさと設計戦略」 「ネットスーパーの買い物体験を支える工夫と決済機能実現の過程」 前提条件 注文から支払い完了まで時間差がある注文後に注文内容の変更ができる品切れが発生するケースがある販売員が注文内容を変更できる0円での支払

[BOOOOOOOON]

https://global.alipay.com/docs/ac/cashierpay/payment_status_desc とか https://docs.stripe.com/payments/payment-intents/verifying-status?locale=ja-JP とか https://documentation.paysimple.com/reference/payment-statuses とか先行の決済事業者の仕組みを理解したほうがいい

[psne]

状態の名前からオーソリのキャンセル等の文脈が消えてるので混乱するやつ

[shag]

こういうのってそもそも決済と請求と督促が分かれてないのかな？

[daishi_n]

RDBMSのトランザクションでは足りず別途実装か何かしらのソフトウェアが必要なのでつらみあるよね。コミットしたデータに自分でロールバック処理書くとか賽の河原だよ

[kazkun]

なんか、状態がcanceledなのにそこからcancelという遷移があったりしてネーミングが気持ち悪い。多分色々と行間が省略されてるからだとは思うけど。

[pmint]

ネットスーパーの販売員ってなんだ、というか何屋なんだ。"与信枠を…圧迫しない"…とか意味不明すぎる。"カード決済以外…が選択される場合がある"…のにカード以外unsupportedなのは草。この図だとcancelled無駄だろ…

[matarillo]

世のモデリング例って、「きれいなモデル」のことが多いので、複雑だったり泥臭かったりする定義は参考になる。／stripeなどのAPIももちろん参考になるけど、API応答は内部状態を生でさらすとは限らない気がする

[toaruR]

返金系も（´－｀）と、領収書の最適解が知りたい

[Eiichiro]

つらみしか感じない。自分ならfinとそれ以外は別カラムに分けるかなぁ。遷移履歴は別テーブルでログとして残すと思う。決済金額変更がフローに、なさそうなのが救いっぽい？

[Shinwiki]

先にデータの持ち方じゃん？

[nemoba]

注文変更をキャンセル&&alt注文作成にすると状態として一気に減らせられる。まあ、集計時に気を遣うけど

[hiroomi]

ネットスーパーシステムの決済ステータス表現 (状態遷移)

[roshi]

やはりこういう時のステータス名って事実たがら過去形にした方がいいんだろうか。事実なのは自明だから現在形で書きたくなるけどイベント名とステータス名で書き分けられるメリットもあって悩ましい。

[masa8aurum]

“名前付けは微妙なので参考にされないほうが良いと思います” / 泥臭い例

[prograti]

返金はアナログな対応なのかな？与信枠が減ったままになっちゃうけど