---
# System prepended metadata

title: クレジットカード処理の進め方
tags: [prismatix]

---

# クレジットカード処理の進め方

###### tags: `prismatix`

飯野さんとお話ししている中で、今後の要件整理を行いました。


### 決まったこと
- POROで作成・参照処理を書き直す
- 簗瀨は「ユーザーがパスワード変更時にprismatixのデータも変更され、次回ログイン時に新パスワードが適応されている」を進める
- 作成処理のリファクタが終わり次第、参照処理をそれにあわせて書き直す


### 目的：Pristmatix経由でクレジットカードリソースの操作を行えるようにする

#### すでに終わったもの
- クレジットカードの登録(Create)
    - 現状Serviceにまとめている

#### 着手中
- クレジットカードの読み出し(Read)

#### 今後
- 更新(Update)
- 削除(Delete)
- バリデーション

#### 保留
- リソースの操作はどこで行う？
  - Modelを作る？
  - Serviceにまとめる？

- CRUDの処理をすべてPOROにまとめる？

## 今後どうする？
#### パターン1
- クレジットカード作成の処理のみをPOROにまとめて、そこに参照、更新、削除、検証を追加していく

##### 懸念
- 簗瀨着手中のタスクが一度止まる
- 飯野さんが作成処理をリファクタする間、別のタスクをやる必要が出てくる

#### パターン2
- クレジットカード参照を一度PRに出して、作成・参照をリファクタしてPOROにまとめる。その後更新、削除、検証をまとめていく

##### 懸念
- 重複処理が発生する
- 参照処理をPOROに移し替える必要が出てくる

## PaymentInfoCode について
`PaymentInfo.payment_info_code` に `vt_order_id(order_id)` を入れてしまうのは良くない気がしてきました。

### 理由
- 本来、`PaymentInfo.payment_info_code` は prismatix の `PaymentInfo` リソースを特定できるためだけのIDであるべき
- duplex 側で `id` をログとして出力しているので、そこに `vt_order_id` を出力するのは良くない

### 改善案
- 当初予定していた `PaymentInfo.attributes` に `vt_order_id` を入れ、 `PaymentInfo.payment_info_code` には `SecureRandom` でユニークな値を入れる

### 懸念点
- attributes は何でも入れたり削除したりできるので値が存在しない！みたいなことにならないか。または、何を入力すればよいか分からない状況にならないか
  - `attributes` に `vt_order_id` 必須バリデーションをかけるにはどうすればよいか
    - `PaymentInfo` に `attributes.vt_order_id` にアクセスするようなメソッドを生やして `create` 時にバリデーションをかける？