은행 입출금 내역을 웹훅으로 실시간 받는 방법

은행 입출금 내역을 웹훅으로 받는다는 것은, 계좌에 입금이나 출금이 발생한 순간 그 거래 정보를 미리 등록해 둔 우리 서버로 곧바로 보내 주는 방식입니다. 새 거래가 있는지 확인하려고 우리 쪽에서 주기적으로 조회하는 폴링과 달리, 거래가 생긴 쪽이 먼저 알려 주기 때문에 받는 쪽은 도착한 데이터를 처리하기만 하면 됩니다. 페이액션은 계좌에 연결된 은행 입출금 통지를 실시간으로 받아 거래 내역을 분석·저장한 뒤, 그 결과를 웹훅으로 고객사 서버에 전송합니다.

이 글은 왜 계좌 데이터를 실시간으로 받는지, 웹훅이 폴링과 무엇이 다른지, 실제로 어디에 쓰이는지를 개념 중심으로 정리합니다. 요청 형식과 전송 항목, 응답 규격, 재전송 정책 같은 연동 스펙은 페이액션 개발자센터에 정리돼 있으니 구현 단계에서 그대로 참고하면 됩니다.

왜 폴링이 아니라 웹훅인가요?

계좌 거래를 우리 시스템에 반영하는 방법은 크게 둘입니다. 하나는 우리 서버가 일정 주기로 조회 API를 호출해 새 거래가 있는지 확인하는 폴링이고, 다른 하나는 거래가 생긴 순간 전송을 받는 웹훅입니다.

폴링의 한계는 구조에서 나옵니다. 조회 주기가 곧 지연의 하한이 되기 때문입니다. 주기가 길수록 그만큼 늦게 알게 되고, 주기를 짧게 줄이면 지연은 짧아지지만 대부분 ‘새 거래 없음’을 확인하는 빈 호출이 그만큼 늘어납니다. 반대로 거래가 몰리는 시간대에는 한 번에 여러 건이 딸려 와 처리도 함께 몰립니다. 결국 지연을 줄이려면 호출을 늘려야 하는 맞교환이 계속 따라붙습니다.

이벤트 기반 방식은 이 맞교환을 끊습니다. 보내는 쪽이 거래가 생긴 시점에 한 번 전송하므로 지연과 호출량이 서로 분리됩니다. 거래가 없으면 아무 통신도 일어나지 않고, 거래가 있으면 그 순간에만 데이터가 도착합니다.

다만 웹훅이 언제나 정답은 아닙니다. 하루 한 번 대사만 하면 되는 업무라면 폴링이 오히려 단순합니다. 웹훅은 받는 쪽 서버가 항상 응답할 수 있어야 하고, 전송이 실패했을 때를 대비한 재전송과 복구 수단이 함께 있어야 제 몫을 합니다. 지연에 민감한 업무일수록 웹훅이, 주기적인 정합성만 필요한 업무일수록 폴링이 어울린다고 보면 대체로 맞습니다.

페이액션이 거래를 실시간으로 감지하는 원리 자체가 궁금하다면 무통장입금 자동확인 스크래핑과 실시간 방식 비교에서 더 자세히 확인할 수 있습니다.

실시간 입출금 데이터는 어디에 쓰나요?

계좌 거래를 실시간으로 받아 두면, 그동안 ‘사람이 통장을 열어 보는 순간’에 묶여 있던 업무가 이벤트 단위로 풀립니다. 대표적인 쓰임새는 세 가지입니다.

• 정산·대사 자동화. 입금과 출금이 생길 때마다 내부 장부에 반영되므로, 화면을 열 때 조회하는 것이 아니라 늘 최신 상태로 유지됩니다. 월말에 몰아서 맞추던 대사를 상시 대사로 바꿀 수 있습니다.
• ERP·재무 시스템 연계. 거래를 발생하는 대로 받아 전표나 자금 관리 데이터로 흘려보낼 수 있습니다. 은행 화면과 내부 시스템을 사람이 오가며 옮겨 적던 구간이 사라집니다.
• 빠른 입금 확인이 필요한 모든 비즈니스. 쇼핑몰처럼 주문이 있는 곳은 물론, 강의·모임 신청폼, 공동구매, 회비처럼 주문 개념이 없는 곳까지 — 입금 이벤트를 받는 순간 결제 확정·안내 발송·명단 갱신 같은 뒷단 처리를 자동으로 이을 수 있습니다.

세 가지의 공통점은 돈이 움직였다는 사실 자체를 트리거로 쓴다는 점입니다. 쇼핑몰이든 서비스든 플랫폼이든, 빠른 입금 확인이 필요한 비즈니스라면 형태를 가리지 않고 같은 방식으로 붙일 수 있습니다.

페이액션은 입출금 데이터를 어떻게 보내나요?

흐름은 세 단계입니다. 먼저 입금이나 출금이 발생하는 즉시 해당 은행이 보내는 입출금 통지를 페이액션이 받습니다. 받은 통지를 분석해 거래 내역으로 정리·저장하고, 저장된 거래를 등록해 둔 주소로 웹훅으로 전송합니다. 계좌 로그인 정보나 별도 앱 설치 없이, 은행이 이미 제공하는 통지를 출발점으로 삼는 구조입니다.

수신 범위는 필요한 만큼만 켜면 됩니다. 입금과 출금을 각각 받을 수 있고, 연동한 계좌가 여러 개라면 계좌별로 켜고 끌 수 있어 원하는 계좌의 원하는 거래만 골라 받을 수 있습니다. 입금과 출금을 한 주소로 모아 받을지, 서로 다른 주소로 나눠 받을지도 선택할 수 있습니다.

운영에 필요한 장치도 함께 제공합니다. 전송이 실패하면 자동으로 다시 보내고, 마지막까지 실패하면 알림 메일이 발송됩니다. 대시보드에서 웹훅 발송 내역을 조회해 성공·실패를 확인하고, 필요하면 특정 건을 수동으로 재전송할 수도 있습니다. 수신 서버에 일시적인 장애가 있었더라도 정상화한 뒤 다시 받아 채울 수 있다는 뜻입니다. 재전송 간격과 횟수, 로그 조회 조건 같은 세부 기준은 개발자센터에 정리돼 있습니다.

입출금 데이터 수신은 이용 중인 플랜에 따라 사용 여부와 이용할 수 있는 계좌 수가 달라집니다. 어떤 상황에 잘 맞는지와 도입 조건은 입출금 데이터 수신 서비스 소개에서 확인할 수 있습니다.

연동하려면 무엇을 해야 하나요?

연동은 페이액션 대시보드에서 순서대로 진행됩니다. 크게 네 단계입니다.

1. 상점 등록 — 운영 중인 쇼핑몰·서비스 정보를 등록합니다.
2. 계좌 연동 — 입출금을 받을 은행 계좌를 연결하고, 안내에 따라 해당 은행의 입출금 통지 서비스를 신청합니다. 이 통지가 실시간 수신의 출발점입니다.
3. API·웹훅 설정 — API키를 만들고 입출금 데이터를 받을 웹훅 주소를 등록합니다.
4. 수신 개발 — 개발자센터 문서에 맞춰 수신 서버를 구현합니다. 도착한 데이터는 저장하고 응답을 먼저 돌려준 뒤 무거운 처리는 뒤로 넘기고, 같은 거래가 다시 와도 한 번만 처리되게(멱등) 해 두면 안정적으로 돌아갑니다.

쇼핑몰·서비스처럼 주문이 있는 비즈니스라면 ‘1초 자동 입금확인’을 함께 쓸 수 있습니다. 주문을 등록해 두면 페이액션이 입금과 주문을 자동으로 매칭해 결제완료 처리와 안내까지 이어 주는 방식입니다. 입출금 이벤트를 그대로 받는 데이터 수신과 목적에 따라 골라 쓰거나 함께 쓰면 됩니다. 항목 형태와 응답 방법 같은 상세 스펙은 페이액션 개발자센터에서 확인할 수 있습니다.

핵심 정리

• 입출금 웹훅은 계좌에 입금·출금이 생긴 순간 등록해 둔 주소로 거래 정보를 보내 주는 방식입니다. 조회 주기를 기다리거나 빈 조회를 반복할 필요가 없습니다.
• 폴링은 조회 주기가 곧 지연이고 지연을 줄이려면 호출을 늘려야 하지만, 이벤트 기반 전송은 지연과 호출량이 분리됩니다. 다만 하루 한 번 대사면 충분한 업무라면 폴링도 여전히 합리적입니다.
• 활용처는 정산·대사 자동화, ERP·재무 시스템 연계, 그리고 주문 개념이 없는 신청·공동구매 같은 입금 처리까지 이어집니다.
• 페이액션은 은행 입출금 통지를 실시간으로 받아 분석·저장한 뒤 웹훅으로 전송하며, 입금·출금과 계좌 단위로 수신을 고를 수 있고 재전송·알림·발송 내역 조회·수동 재전송 같은 운영 장치를 함께 제공합니다.
• 연동은 상점 등록 → 계좌 연동 → API·웹훅 설정 → 수신 개발 순서로 진행하며, 주문이 있는 비즈니스는 1초 자동 입금확인을 함께 쓸 수 있습니다. 상세 스펙은 개발자센터에서 확인합니다.

주문 등록 없이 계좌 입출금 이벤트를 그대로 받아 보세요. 동작 방식과 도입 조건은 입출금 데이터 수신 서비스 소개에서, 상세 스펙은 페이액션 개발자센터에서 바로 확인하고 연동을 시작할 수 있습니다.