PG 정산 수수료를 건별로 추적해 순수익 계산 정확도 향상

PG 정산 수수료(pg_fee_amount) 추적 — 결제대행사 플랫폼 0.1% DB 설정 기반

PG 정산 수수료(pg_fee_amount) 추적 — 결제대행사 플랫폼 0.1% DB 설정 기반 기능을 구현했음.

배경

결제대행사 수수료를 별도로 추적하지 않으면 실제 순수익 계산이 어려움. 수수료를 DB에서 관리하면 요율 변경 시 소급 계산도 가능함.

구현 방식

결제 완료 시 수수료 금액을 별도 필드에 저장하고, 수수료율은 DB 설정값을 참조하도록 했음.

코드 예시

// 결제 완료 시 수수료 계산
public void onPaymentCompleted(Payment payment) {
    PgConfig pgConfig = pgConfigRepo.findByPayMethod(payment.getPayMethod());
    long pgFee = (long) Math.floor(payment.getAmount() * pgConfig.getFeeRate());

    payment.setPgFeeAmount(pgFee);
    paymentRepo.save(payment);

    log.info("결제대행 수수료 추적: paymentId={}, fee={}", payment.getId(), pgFee);
}

검토 포인트

수수료율은 계약에 따라 등급별로 다를 수 있음. 단일 설정값 대신 요율 테이블로 관리하면 등급별 적용이 가능해짐.

정리

결제대행 수수료가 건별로 추적되어 정확한 순수익 계산이 가능해졌음.

DB 설계 고려사항

이번 작업에서 DB 쿼리를 작성하면서 몇 가지를 점검했음.

인덱스 활용: WHERE 조건에 사용하는 컬럼에 인덱스가 있는지 확인했음. 특히 status, created_at 같은 자주 필터링하는 컬럼은 복합 인덱스를 고려했음.

-- 인덱스 설계 예시
CREATE INDEX idx_status_created ON 내부테이블 (status, created_at DESC);
-- status 필터링 후 최신순 정렬이 많을 때 유효

소프트 삭제: 데이터를 물리적으로 삭제하지 않고 deleted_at 컬럼으로 논리 삭제하는 패턴을 유지했음. 이력 추적이 필요한 데이터는 지우면 안 됨.

페이징: 대량 데이터 조회 시 LIMIT/OFFSET 방식이 현재 규모에서는 충분했음. 데이터가 많아지면 커서 기반 페이징으로 전환을 고려해야 함.

다음