B2B 에이전트 지갑
입금 승인과 완전한 원장을 갖춘 B2B 에이전트 지갑
각 에이전트는 플랫폼의 선불 잔액 범위에서 판매합니다. 에이전트가 입금을 요청하고 승인하면, 예약마다 지갑에서 차감되며 원장 기록은 발생 원인까지 추적할 수 있습니다.
- 에이전트별 잔액
- 승인제 입금
- 입출금 원장
- 다중 통화 잔액
지갑의 작동 방식
후불 신용 한도가 아닌 선불 잔액
에이전트 신용 한도를 찾는 여행사는 대개 리스크를 관리하고 싶어 합니다. PHPTRAVELS는 선불 여행사 지갑으로 이를 해결합니다. 리스크는 승인한 입금액만큼이고, 잔액은 누군가 입력한 숫자가 아니라 원장 기록의 합계이며, 월말 정산은 논쟁이 아니라 보고서가 됩니다.
- 에이전트가 B2B 포털에서 금액, 통화, 결제 수단, 참조 번호와 함께 입금을 요청
- 관리자 화면에서 승인 또는 거절하며, 결정 전에는 잔액에 반영되지 않음
- 승인된 입금은 입금 통화로 에이전트 원장에 대변 기록
- 에이전트의 모든 예약은 잔액에서 차변으로 기록
- 원장의 각 행은 이를 만든 입금 또는 예약으로 추적 가능
- 금액
- 5,000.00
- 통화
- USD
- 결제 수단
- 계좌 이체
- 거래 참조 번호
- TRX-20481
관리자 승인
모든 입금은 당신의 결정을 기다립니다
대기, 승인, 거절된 입금을 한 목록에서 확인하고, 은행과 대조할 금액, 결제 수단, 참조 번호도 함께 봅니다.
- Skyline Travel LLC계좌 이체 · 참조 TRX-20481US$5,000
- Al Noor Tours현금 입금 · 참조 CSH-7713US$2,500
- Blue Coast Holidays계좌 이체 · 참조 TRX-20455US$1,200
에이전트별 잔액
각 에이전트 계정에는 자체 지갑이 있으며, 잔액은 수기 수정이 아니라 원장 기록으로 계산됩니다.
승인 워크플로
입금은 대기 상태로 들어오며 관리자가 승인한 뒤에만 지갑에 반영됩니다.
결제 수단과 참조 번호
모든 입금에 에이전트의 결제 방식과 거래 참조 번호가 기록되어 은행 거래 내역과 대조할 수 있습니다.
입출금 원장
각 기록에는 금액, 통화, 적요, 일시가 저장됩니다.
모든 통화의 잔액
입금과 원장 기록이 각자의 통화를 가지므로 시장이 다른 에이전트도 편한 방식으로 정산합니다.
거절 기록 보존
거절된 입금은 잔액을 바꾸지 않으며 기록은 감사용으로 남습니다.
자금 흐름
돈이 실제로 움직이는 방식
여섯 단계, 그리고 모든 단계에 정산에 쓸 수 있는 기록이 남습니다.
요청
에이전트가 포털에서 금액, 통화, 결제 수단을 보냅니다.
검토
재무팀이 참조 번호를 은행과 대조하고 승인 또는 거절합니다.
대변 기록
승인된 금액이 에이전트 원장에 대변으로 기록됩니다.
예약
에이전트가 예약한 항공, 호텔, 투어가 잔액에서 차감됩니다.
추가 충전
잔액이 부족해지면 에이전트가 다음 입금을 요청합니다.
정산
각 행은 이를 만든 입금 또는 예약으로 추적됩니다.
적용 위치
에이전트 포털, 관리자, 예약 엔진에 하나의 지갑
지갑은 추가 기능이 아니라 플랫폼의 일부이므로 잔액이 예약과 함께 움직입니다.
에이전트 포털
에이전트는 B2B 포털에서 입금을 요청하고 지갑으로 예약 대금을 결제합니다.
관리자 백오피스
재무 담당자가 입금을 승인하고 에이전트별 원장을 한 줄씩 검토합니다.
예약 엔진
자체 재고와 연결된 공급업체의 예약이 모두 같은 잔액에서 차감됩니다.
백오피스
에이전트 재무도 같은 관리자 화면에서
지갑은 모든 상품에 대해 이미 관리하는 에이전트 계정, 요금, 보고서 옆에 있습니다.
에이전트 계정
개별 로그인과 B2B 포털 접근 권한을 가진 에이전트 계정을 만들고 관리합니다.
입금 대기열
금액, 통화, 결제 수단, 참조 번호가 표시된 대기 입금을 바로 승인하거나 거절합니다.
에이전트 원장
에이전트별 입출금을 적요와 일시와 함께, 마이너스 잔액까지 기록합니다.
B2B 요금과 마크업
항공, 호텔, 투어 등에서 에이전트 전용 요금, 마크업, 수수료를 설정합니다.
다중 통화
에이전트 시장의 통화로 요금을 표시하고 입금을 받습니다.
보고서와 내보내기
예약, 매출, 에이전트 원장을 월말 정산용으로 바로 사용합니다.
비교
선불 에이전트 지갑과 후불 신용의 차이
B2B 에이전트 신용 한도를 찾을 때는 대개 두 가지 모델 중 하나를 의미합니다. 둘의 차이와 각 모델에서 소프트웨어가 하는 일입니다.
| 항목 | 후불 신용 조건 | PHPTRAVELS |
|---|---|---|
| 돈이 들어오는 시점 | 후불 신용 조건예약 후, 합의한 조건에 따라 | PHPTRAVELS예약 전, 승인된 입금으로 |
| 리스크 | 후불 신용 조건에이전트가 예약하고 아직 지불하지 않은 전액 | PHPTRAVELS승인한 입금액이 상한 |
| 회수 | 후불 신용 조건자체 계약에 따른 청구와 독촉 | PHPTRAVELS불필요, 잔액이 미리 충전됨 |
| 무엇이 이를 강제하나 | 후불 신용 조건에이전트와의 상업 계약 | PHPTRAVELS지갑: 승인된 잔액 안에서만 예약 |
| 정산 | 후불 신용 조건사후에 결제와 청구서를 맞춤 | PHPTRAVELS원장의 각 행이 입금 또는 예약과 연결 |
활용 사례
에이전트 지갑을 쓰는 곳
콘솔리데이터와 도매업체
예약 전에 잔액을 충전하는 하위 에이전트에게 항공권과 호텔을 판매합니다.
DMC와 투어 운영사
해외 파트너 여행사로부터 각자의 통화로 선불 잔액을 받습니다.
B2B 에이전트 네트워크
모든 에이전트가 지갑으로 정산하는 화이트라벨 에이전트 포털을 운영합니다.
PHPTRAVELS를 선택하는 이유
자금 규칙을 자체 코드로
소스 코드 포함
상용 라이선스로 자체 호스팅하므로 개발자가 지갑과 승인 흐름을 확장할 수 있습니다.
데이터는 자체 서버에
에이전트 원장과 입금 기록은 자체 데이터베이스에 남습니다.
24개 언어
에이전트 포털과 관리자 화면을 각 시장의 언어로, 오른쪽에서 왼쪽으로 쓰는 언어도 지원합니다.
B2C와 B2B
공개 사이트와 에이전트 포털을 하나의 설치로 운영합니다.
각 에이전트의 잔액은 입출금 원장으로 관리됩니다. 에이전트가 입금을 요청하고 승인되면 잔액이 늘어나며, 예약할 때마다 차변이 기록됩니다. 잔액은 이 기록의 합계이므로 항상 그 뒤의 거래와 일치합니다.
플랫폼은 후불 신용 상한이 아니라 선불 지갑으로 에이전트와 정산합니다. 에이전트는 승인된 잔액 안에서 판매하고 부족해지면 충전하므로 리스크가 제한됩니다. 신뢰할 수 있는 에이전트에게 후불 조건을 주는 것은 자체 계약에 따른 상업적 합의이며, 원장은 그 결과 잔액을 마이너스까지 포함해 기록합니다.
에이전트가 포털에서 금액, 통화, 결제 수단과 함께 입금을 요청하면 관리자 화면에 대기 상태로 들어옵니다. 승인 전에는 반영되지 않으며, 거절된 입금은 잔액을 그대로 두고 기록만 남깁니다.
네. 원장 기록과 입금은 각자의 통화를 가지므로 시장이 다른 에이전트도 편한 통화로 정산할 수 있습니다.
다시 충전합니다. 예약은 승인된 잔액에서 결제되므로 에이전트가 동의하지 않은 채무를 몰래 쌓을 수 없으며, 이것이 여행사가 사후 청구보다 선불을 택하는 주된 이유입니다.
네. 모든 입출금은 금액, 통화, 적요, 일시와 함께 저장되고, 입금에는 결제 수단, 참조 번호, 승인 상태가 남아 있어 이의가 있는 행도 이를 만든 예약이나 입금까지 추적할 수 있습니다.
