링크 결제를 우리 서비스에 자동으로 심으려면 어떻게 해야 할까?

링크 결제는 지난 몇 년간 빠르게 성장한 결제 방식 중 하나입니다. 견적·청구·맞춤 상품을 판매하던 비즈니스에서 시작해, 매칭 플랫폼·SaaS·B2B 솔루션처럼 거래가 실시간으로 일어나는 서비스까지 — 결제 링크 한 줄이 별도의 결제 페이지를 만드는 일을 대체했습니다.

이제 질문은 "링크를 어떻게 만들고 보낼 것인가"가 아니라, "어디서 만들고 어디에 기록할 것인가"로 옮겨가고 있습니다.

어드민에서 사람이 직접 링크를 만들어 보내는 방식은 거래가 일정 규모를 넘는 순간 한계를 드러냅니다. 금액을 잘못 입력해 환불·재발급을 처리하는 시간이 늘고, 만료 시각을 빼먹은 링크가 외부에 살아남아 의도치 않은 결제로 이어지는 일이 누적됩니다.

무엇보다 결제 내역과 자사 비즈니스 데이터가 분리되어 따로 관리되는 구조가 매일 운영팀의 시간을 갉아먹습니다. 어느 매칭에서 결제가 발생했는지, 어느 청구서가 미수금인지를 사람이 매일 엑셀로 맞춰야 합니다.

자사 서비스 안에 결제·금융이 임베드되는 시장이 빠르게 커지고 있으며, 미국 B2B 결제만 봐도 2026년까지 약 2.6조 달러, 현재의 약 3배 규모로 성장할 것으로 전망되고 있습니다(Bain & Company × Bain Capital, 2022).

결제가 별도의 작업이 아니라 서비스 흐름 안에서 자동으로 처리되는 이벤트로 자리를 옮기고 있다는 신호입니다. 링크 결제도 같은 흐름 위에 있습니다. 이 글은 개발 리소스를 갖춘 팀이 포트원 링크페이 API로 링크 결제를 자사 서비스 안에 심는 방법을 다룹니다.

운영자가 어드민에 들어가 금액을 입력하고 링크를 복사해 카카오톡으로 보내는 기존의 링크 결제는 두 가지 문제를 만듭니다 — 결제를 생성하는 타이밍이 실시간이 아니고, 어떤 매칭에서 결제가 일어났는지 추적이 끊깁니다.

만약 시스템 안에서 특정 이벤트 발생시 자동으로 결제 URL이 생성되어 알림톡으로 발송된다면 어떨까요?

버티컬 SaaS와 매칭 플랫폼을 예시로 들어보겠습니다. 고객이 강사를 예약하거나, 디자이너 매칭이 확정되거나, 인테리어 견적이 승인되는 순간이 결제 트리거가 될 수 있습니다.

이런 흐름은 어떻게 시스템에 심을 수 있을까요?

매칭 확정 이벤트가 발생하면 서버에서 API를 호출해 그 매칭에 맞는 금액·상품명·만료시각이 박힌 결제 링크를 즉시 생성하고, 응답으로 받은 단축 URL을 알림톡·SMS·이메일 채널로 자동 전송합니다.

여기서 중요한 건 merchant_uid와 custom_data 두 필드입니다. 매칭 ID·예약 번호·계약 ID를 merchant_uid에, 매칭의 부가 정보를 custom_data에 담아두면, 결제 완료 시 웹훅으로 같이 돌아옵니다. 결제와 자사 비즈니스 데이터가 같은 키로 묶이는 구조가 됩니다.

운영 효과는 명확합니다. 매칭 → 결제 → 서비스 활성화까지 사람이 일일이 손대야 하던 반복 작업이 사라지고, 결제 실패·만료·재시도가 모두 자사 DB에 기록되어 분석이 가능해집니다.

매월 1일에 청구서 200장이 동시에 나가는 회사라면, 결제 링크는 이제 일괄 처리 단위로 다뤄야 합니다.

B2B 솔루션 기업의 청구 흐름은 SaaS와 다릅니다. 거래처별로 금액이 다르고, 결제 기한도 다르고, 무엇보다 미수금이 발생했을 때의 후속 처리(독촉·연장·취소) 가 운영의 핵심입니다. 사람이 한 건씩 만들어 보내는 방식으로는 매월 마감일이 되면 운영팀의 다른 업무가 미뤄집니다.

그럼 이 청구·미수금 흐름을 코드 단에서 어떻게 처리할 수 있을까요?

포트원 링크페이 API는 이 일괄 처리에 두 가지 핵심 옵션을 제공합니다.

첫째, expired_at입니다. 거래처마다 결제 기한이 다르더라도 청구일 + 영업일 N일을 계산해 만료 시각을 각기 다르게 박아 발송할 수 있습니다. 만료 시점이 데이터로 남기 때문에 "언제까지 결제되어야 하고, 언제부터 미수금으로 잡힐지"가 예측 가능한 숫자로 바뀝니다.

둘째, 결제 URL 비활성화 API입니다. 이미 발송한 결제 링크라도 응답으로 받은 단축 URL의 식별자를 PUT 요청으로 호출하면 즉시 비활성화됩니다. 거래처가 계약을 변경하거나 청구 금액에 오류가 발견됐을 때 새 링크를 발송하기 전에 이전 링크를 끊을 수 있어, 잘못된 금액으로 결제되는 사고를 막을 수 있습니다.

미수금 회수도 같은 흐름 위에서 자동화됩니다. 만료 시각이 지난 거래처를 자사 DB에서 추출해 새 expired_at을 박은 결제 링크를 일괄 재발송하면, 사람이 엑셀과 메일을 오가는 작업이 사라집니다. 수납 예측이 운영 지표가 되고, 미수금이 더 이상 월말 이벤트가 아닌 상태가 됩니다.

결제가 기능으로 머무는 회사와, 결제가 인프라가 된 회사의 차이는 운영 시간이 아니라 의사결정 속도에서 드러납니다.

기능 단계의 결제는 매번 사람이 만들어 보내는 작업물입니다. 거래가 늘어날수록 사람을 늘려야 하고, 채널이 늘어날수록 엑셀이 늘어납니다. 결제 데이터가 자사 시스템 바깥에 흩어져 있어서, 결제 데이터를 근거로 한 의사결정이 어려워집니다

인프라 단계의 결제는 다릅니다. 매칭이 성사되면 결제 링크가 생성되고, 결제가 완료되면 서비스가 활성화되고, 만료된 미수금은 다시 발송됩니다. 그 모든 과정이 자사 DB에 기록되어 코호트·LTV·미수금 회수율 같은 숫자가 운영 지표로 살아납니다. 사람이 늘어나는 대신 거래량이 늘어나도 운영 비용이 비례해서 늘지 않는 구조가 만들어집니다.

가능합니다. API 응답으로 받은 단축 URL의 마지막 식별자(예: 4bdf239e)를 https://api.iamport.co/api/supplements/v1/link/payment/{식별자} 경로에 PUT으로 호출하면 즉시 비활성화됩니다(포트원 개발자센터, 2025). 청구 금액 오류, 계약 변경, 잘못된 거래처 발송 등의 상황에서 재발송 전에 이전 링크를 끊을 수 있어 결제 사고를 막는 핵심 옵션입니다.

결제 URL API로 진행된 결제는 오직 웹훅으로만 결제 결과를 수신받을 수 있습니다. 웹훅은 결제가 성공한 경우에만 발송되기 때문에, 승인된 결과만 받아도 운영에 문제가 없는 서비스에 한해 해당 API를 이용하시기 바랍니다.

링크페이 API 내재화는 이 전환을 위한 첫 단추입니다. 결제는 더 이상 백오피스의 작업이 아닙니다.

거래량이 늘어나도 운영 시간이 비례해서 늘지 않는 구조 — 그게 다음 단계 비즈니스의 인프라입니다.