간편 결제 시스템 동기, 비동기 | CallBackURL Webhook

간편 결제 시스템 비교 - 동기 VS 비동기

온라인 쇼핑이나 음식 배달 등의 주문을 하다 보면, 간편 결제 시스템이 얼마나 중요한지 절실히 느끼게 돼요. 보통은 카드나 계좌 연결을 통해 빠르게 결제가 되는데, 간혹 결제 과정이 길어지고 그것도 몇 번이나 재시도를 해야 했던 경험이 다들 한 번씩은 있으실 거 같아요. 그래서 안정적이고 효율적인 결제 시스템이 얼마나 중요한가 깨닫게 되죠. 결제 시스템이 좀 불안정하면 사용자에게 얼마나 치명적일 수 있는지, 이번 포스팅에서 간편 결제 CallBackURL, Webhook 기능과 데이터 통신 방식 기술을 살펴볼게요.

왜 결제 과정에서 문제가 생기는 걸까?

 가장 큰 이유는 서버에서 데이터를 처리하는 방식 때문이라고 할 수 있어요. 간편결제는 동기통신 방식을 사용할 때가 많은데, 이게 서버 입장에서 데이터를 일일이 처리하면서 응답할 때까지 기다려야 하는 거라 통신 지연이 쉽게 생기거든요. HttpTimeOut 오류도 여기서 주로 발생하는 거라 데이터가 올바르게 통신되지 않았다는 결론으로 이어져요. 더군다나 사용자가 많아지는 피크 타임엔 시스템의 처리 속도가 훨씬 느릴 수밖에 없어요. 반면 비동기통신 방식은 요청을 받고 바로 처리를 시작해서 다음 요청으로 넘어갈 수 있고 각 요청에 대한 처리 결과를 CallBackURL 통해 전달하곤 해요.

더 나은 결제시스템을 위해 Webhook 통한 데이터 처리

 솔직히 사용자 입장에선 결제 과정이 매끄럽게 잘 되기만 바랄 뿐, 이게 동기든 비동기든 딱히 신경 쓰지는 않잖아요? 하지만 개발자나 책임자라면 시스템 설계 방식부터 데이터 처리량까지 다 고려해야 하죠. Webhook 방식이 제공하는 특장점을 살펴보면 기존 방식과는 차별화된 면이 있어요. 간단히 말하면 특정 이벤트가 발생했을 때 필요한 정보를 바로 알려주는 자동화된 알림 시스템이라 생각하면 돼요. 동기 통신처럼 응답을 기다리는 불필요한 시간 낭비를 줄이고, 비동기 처리의 강점도 살리니까 속도가 빠르고 안정적이에요. 놓치기 쉬운 서버 상태나 결제 결과 등을 CallBackURL로 즉각적으로 업데이트해 주니까 사용자가 따로 확인하지 않아도 완료 여부를 알 수 있죠.


 결국 우리는 빠르고 안전한 결제 경험을 원할 수밖에 없어요. CallBackURL Webhook처럼 신뢰할 수 있는 시스템은 그런 의미에서 성공적인 해결책이 될 수 있어요. 물론 초기 도입에는 약간의 기술적 장벽이 있을 수도 있지만, 한 번 익숙해지고 익히게 되면 더 이상 뒤돌아보지 않게 될 거예요. 시스템의 안정성과 응답 속도가 최우선 순위라면, 이 방식의 가치에 쉽게 공감할 수 있을 거예요.

 

CallBackURL

• 사용자가 온라인 쇼핑몰(웹/앱)에서 결제를 시도해요
• 쇼핑몰의 프론트/백엔드 서버는 결제 요청을 *PAY사(PG/VAN사)*에 전달해요
• Pay사 결제 서버는 결제를 처리한 후, 쇼핑몰이 사전에 등록해둔 CallBackUrl로 결제 결과를 비동기 전송해요. (POST)
• 쇼핑몰의 서버는 이 요청을 받아서 주문 상태를 업데이트하거나, 내부 처리 해요

 

사용자 결제 요청
     ↓
+------------------+            +--------------------+            +------------------------------+
|   사용자 (고객)   | ───────▶   |   Pay사 결제 서버    | ───────▶   |  쇼핑몰 callback URL 서버   |
+------------------+   쇼핑몰 결제요청   +--------------------+   결제결과 POST 전송   +------------------------------+
                              (예: shop.com)                   (예: https://partner.com/pay/callback)

결제가 일어나고, 해당 결제 사이트로 CallBackUrl 전송 프름인데 이때, callbackURL의 개념은 비동기통신 방식이죠.

이에 반해, Http Connection Timeout 등의 타임아웃 응답은 동기 통신 방식으로, 응답이 올 때까지 대기해요.

 

* Callback URL , HTTP Connection Timeout 비교

분류	Callback URL	HTTP Connection Timeout
동기/비동기	비동기	동기
설명	서버가 처리 결과를 나중에 따로 알려주는 방식	요청 → 응답까지 기다리는 시간 제한
예시	결제 결과, 인증 토큰 발급 결과 통보	일반적인 REST API 호출 응답 대기
비유	택배를 주문하고, 배송이 완료되면 문자로 "도착" 통보	전화 걸었는데 상대방이 일정 시간 내 응답하지 않으면 끊김

 

고객이 온라인에서 물건을 결제

1. 동기 요청과 응답 (HTTP + timeout 적용)

• 쇼핑몰 → Pay API 서버

POST https://api.shop.com/v1/payment
{
  "amount": 5000,
  "orderId": "A12345",
  "callbackUrl": "https://partner.com/pay/callback"
}

 

• 이 요청은 동기 방식으로 Pay 서버는 요청을 받고, 일정 시간(timeout) 내에 승인 여부(결제 준비 상태)를 즉시 응답

HTTP 200 OK
{
  "paymentId": "cust12789",
  "paymentStatus": "000",
  ...
}

 

2. 비동기 결과 통보 (Callback URL)

• 고객이 실제 결제 페이지에서 카드/계좌로 결제를 완료 (페이사 외부 UI에서 진행)
• 결제 성공/실패 여부는 실시간으로 확인할 수 없으므로,  Pay 서버는 결제 완료되면 쇼핑몰 CallBackUrl로 비동기 POST 전송

POST https://partner.com/pay/callback
{
  "orderId": "20250719A12345",
  "paymentId": "cus123xyz789",
  "paymentStatus": "SUCCESS",
  "paidAt": "2025-07-19T11:45:00+09:00"
}

쇼핑몰 서버는 이 콜백을 받아 DB에 결제 완료로 기록하거나, 주문 상태를 업데이트, 이 단계는 비동기로 고객사 서버는 콜백을 받을 준비만 하고, Pay 사 쪽에서 결제가 끝난 시점에 따로 통보하게 돼요.

[고객 결제 요청] 
   
   └─▶ 쇼핑몰 서버 ──(동기 HTTP 요청)──▶ Pay 사 서버   ←── (15초 timeout 적용)
                                   │
                            결제 완료 시점 (몇 초~분 후)
                                   │
                   Pay 사 서버 ──(비동기 POST)──▶ 쇼핑몰 CallBackUrl

즉시 피드백 (요청에 대한 결과) 제공할 수 있다는 장점이 동기 연동에 있지만, Callback URL에는 인증 토큰, 시그니처(header 기반) 등을 넣어 위·변조 방지해 보안 안정성이 높아요.
다만, Callback 수신 실패 시 재시도 정책 사전에 협의가 필요해요. (3회, 5분 간격 등의 기준)

 

 결제 과정에서 사용자들이 겪는 어려움은 결코 사소한 문제가 아니에요. 만족스러운 결제 시스템은 결국 사용자 경험을 더 나은 방향으로 이끌 수 있을 뿐만 아니라, 서비스의 신뢰성도 높여주니 회사 입장에서도 높은 우선순위를 차지하게 되죠. 안정적인 간편 결제 시스템 안에서 효율적인 데이터 처리는 고민할수록 더욱 발전할 수 있다고 단언할 수 있을 거 같아요:)