FRONT에서의 결제 + 결제 정보 저장

 

현재까지 수 없이 고민한 내용은,

결제를 어떻게 진행 할 것인가 였다.

 

모든 결제를 BACKEND단에서 진행하자니, 많은 정책상의 문제.

그리고 또 결제가 정상적으로 진행 되었는지 사용자에게 친화적이지 않다는 문제가 있었다.

 

그렇다고 FRONTEND단에서만 사용하자니, 금액에 대한 관리가 우리 서버에서 전혀 진행할 수 없는 형태가 된다. 

 

POINT만을 사용하는 결제는, 결제의 기본이 남에게 확인을 받아야한다는 것을 고려했을때,  결제가 아닐 수 도 있다. 

 

현재 그러므로 회의끝에 내린 결론은

웹하드처럼, 포인트를 구매해서(FRONT단에서) 이 포인트로 상품을 사자! 

 

이를 위해 , 기존에 PURCHASEJSV2로 두었던 JS단에서 가장 먼저 구매 내역을 저장하게 하였다 .

 

@Table(name = "Payment")
@Entity
@Data
@NoArgsConstructor
@AllArgsConstructor
public class Payment {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    Integer PaymentIndex;

    @Column(name = "PaymentID")
    String PaymentID ; //결제 id

    @Column(name = "status")
    String status;

    @Column(name = "paytime")
    Timestamp paytime ;
    //결제 시간

    @Column(name = "ordername")
    String ordername ;
    //product의 pname이 될것

    @Column(name = "totalamount")
    int totalamount ;


    public Payment(String paymentID, String status, Timestamp paytime, String ordername, int totalamount) {
        this.PaymentID = paymentID;
        this.status = status;
        this.paytime = paytime;
        this.ordername = ordername;
        this.totalamount = totalamount;
    }
}

 

자동 생성에 대한 문제가 있었다. 

자동생성하는 INDEX(실제 INDEX는 아니라고 볼 수 있을것 같지만) 라는 PK를, 

JAP REPOSITORY에서 SAVE를 활용할때 반드시 객체에 있어야 하는것이 아닌가 하는

모순에 빠졌었다.

 

허나 이전 프로젝트 내용이 기억이 났고, SQL에선 AUTO INCREMENT로. 

생성자는 이가 없어도 되는 생성자를 생성하였다. 

 

DB에 삽입하였다.

 

현재까지 완료된 구조를 파악해보면

 

1. 프론트단에서 금액 결제를 요청한다

2. 그 금액만큼 결제를 진행한다

3. 결제 금액을 확인하여 , 이가 옳게 되면 결제정보를 저장한다

4. 그 이후,(순서는 3번과 변경가능) 상품의 갯수를 줄인다

5. 받은 응답을 다시 제출한다. 

 

 

--구현해야 할 것 --

 

1. 가장 급한것은, 지금 토큰이 거의 15분마다 만료된다. 매 거래시마다 TOKEN을 발급받는 LOGIC이 필요할 것 같다

2. SERVICE단과의 분할이 필요하다. 

3. 결제가 정상적이지 않을때 취소하는 루틴이 필요하다. (MOCK이나 JUNIT의 기능을 활용하여 , 잘못된 응답을 보내보자)

4. 그 이후에, USER 정보를 전 결제 과정에 추가해야 될 것 같다.

5. 큰 관점에서의 문제인데, MSA구조로 옮길때 분할을 어떻게 진행해야할지 고민이 필요하다.