여기서 화이트 라벨이 뜻하는 것
카드 프로그램을 처음부터 만들려면 발급사를 찾고, 그들의 보안·컴플라이언스 심사를 통과하고, 1센트까지 대사되는 원장을 구축하고, 인증을 연동하고, 첫 카드가 나가기 전에 컴플라이언스 인력을 갖춰야 합니다. 18개월이 보통의 일정이며, 그 대부분은 엔지니어링이 아닙니다.
화이트 라벨은 이 모든 것을 저희 것으로 물려받는다는 뜻입니다. 고객은 첫 화면부터 플라스틱 카드까지 귀사의 브랜드만 봅니다. 발급 계약, 컴플라이언스 프로그램, 원장과 대사는 저희가 운영하고 저희가 책임집니다.
포장만 바꾼 추천 제휴가 아닙니다. 고객은 귀사의 고객이고, 가격은 귀사가 정하며, 고객 관계도 귀사가 유지합니다. 바꿀 수 없는 것은 컴플라이언스 규칙뿐입니다. 이는 발급사와 법에서 나옵니다.
제공 내용
아래 항목은 모두 기본 포함이며, 모듈별로 값을 매기지 않습니다.
처음부터 끝까지 귀사의 브랜드
카드 디자인, 앱 또는 웹 인터페이스, 이메일, 도메인까지. 귀사가 원하지 않는 한 고객이 보는 어디에도 저희 이름은 나오지 않습니다.
가상 카드와 실물 카드 발급
귀사의 프로그램 아래 저희 발급 파트너를 통해 카드를 발급하고, Apple Pay와 Google Pay에 등록하며, 실물 카드가 필요한 곳에는 배송합니다.
인터페이스가 하는 모든 일에 대한 API
사용자 생성, 인증 실행, 카드 발급, 한도 설정, 정지, 원장 조회, 웹훅으로 거래 스트리밍. 대시보드에서 할 수 있는 일은 API로도 할 수 있습니다.
컴플라이언스 체계
신원 확인, 제재 대상 및 정치적 주요 인물 심사, 거래 모니터링, 그리고 이에 따르는 보고 의무까지 프로그램의 일부로 운영합니다.
원장과 대사
복식 부기로, 매일 발급사와 대사합니다. 카드 프로그램에서 제대로 만들기 가장 어려운 부분이며, 틀어지기 전까지는 아무도 보지 못하는 부분입니다.
2선 지원
귀사의 고객에게는 귀사의 팀이 답합니다. 귀사의 제품이 아니라 결제 인프라에 관한 질문이면 저희에게 넘어오고, 어깨를 으쓱하는 대신 답을 돌려드립니다.
역할 분담
아래의 역할 구분은 선호의 문제가 아닙니다. 규제상 인가를 누가 보유하는지에 따라 정해집니다.
| 귀사 | NELVOI | |
|---|---|---|
| 브랜드, 인터페이스, 고객 관계 | ✓ | — |
| 고객에게 적용하는 가격 | ✓ | — |
| 고객 유치와 1선 지원 | ✓ | — |
| 발급 계약과 카드 스킴 회원 자격 | — | ✓ |
| 신원 확인과 지속적 심사 | — | ✓ |
| 거래 모니터링과 규제 보고 | — | ✓ |
| 원장, 정산, 대사 | — | ✓ |
| 컴플라이언스 사유의 거절 또는 정지 결정 | — | ✓ |
마지막 행은 두 번 읽을 가치가 있습니다. 컴플라이언스 결정은 파트너에게 위임할 수 없으며, 이에 대한 통제권을 주겠다는 제공자는 첫 규제 심사도 버티지 못할 것을 말하고 있는 셈입니다.
첫 대화에서 첫 카드까지
낙관이 아니라 현실입니다. 6주 만에 출시되는 프로그램은 누군가 무언가를 건너뛴 프로그램입니다.
범위 설정
무엇을, 누구를 위해, 어느 시장에서, 어느 정도 규모로 만드는지 정합니다. 저희가 지원할 수 없는 부분은 이 단계에서 말씀드립니다. 그 답은 나중이라고 나아지지 않기 때문입니다.
상업 조건
초기 설정, 카드당 비용, 규모별 경제성을 문서로 정합니다. 공개 페이지에 가격 범위를 적지 않는 이유는 답이 정말로 거래량과 시장 구성에 달려 있어서이며, 정직할 만큼 넓은 범위는 쓸모가 없기 때문입니다.
프로그램 승인
발급 파트너가 귀사의 프로그램을 심사합니다. 사업 모델, 목표 시장, 컴플라이언스 체계, 재무 상태를 봅니다. 가장 오래 걸리는 단계이며 누구도 단축할 수 없습니다.
연동
이 단계 첫날에 샌드박스 자격 증명을 드립니다. 대부분의 팀은 2~4주 안에 핵심 흐름을 연동합니다. 가장 오래 걸리는 것은 보통 저희 API가 아니라 귀사의 온보딩 UX입니다.
출시
먼저 제한된 집단에, 그다음 더 넓게 엽니다. 첫날부터 모두에게 여는 프로그램은 실제 고객의 돈으로 예외 상황을 발견하게 됩니다.
비용 구조
세 가지 요소입니다. 제안서에서 발견하게 하느니 여기서 그 틀을 밝혀 두는 편이 낫습니다.
- 초기 설정 수수료 — 1회이며, 프로그램 승인, 구성, 연동 지원을 포함합니다
- 카드당 수수료 — 발급된 카드마다 한 번 청구하며, 가상 카드와 실물 카드의 가격이 다릅니다
- 거래 수익의 배분 — 규모에 따라 커지는 부분이며, 거래량이 실제로 숫자를 바꾸는 부분입니다
화이트 라벨에 관한 질문
예. 발급, 구독, 환전에 대해 고객에게 얼마를 받을지는 귀사가 정합니다. 프로그램을 재판매하지 않고 직접 운영하는 주된 이유 중 하나입니다. 할 수 없는 것은 카드 네트워크 규칙을 위반하는 방식의 과금입니다. 예를 들어 금지된 곳에서 추가 요금을 붙이는 것이 그렇습니다.
계약상으로도 실제로도 귀사의 고객입니다. 저희는 그들에게 마케팅하지 않고, 관계를 맺지 않으며, 귀사가 제휴 사실을 공개하기로 하지 않는 한 그들의 앱에 나타나지 않습니다. 일부 시장에서는 공개가 의무인데, 이 경우 귀사가 스스로 알아내도록 두지 않고 저희가 미리 알려 드립니다.
발급 파트너의 인가 범위와 귀사의 인허가에 달려 있으며, 범위 설정 단계에서 가장 먼저 확정하는 사항입니다. 이 질문에 “어디서나”라고 답하는 쪽은 진짜 제공자가 아니거나 자기 계약서를 읽지 않은 것입니다.
대개는 필요 없습니다. 프로그램이 발급사의 인가 아래 운영되기 때문입니다. 다만 카드 발급 외에 무엇을 하는지, 그리고 시장에 따라 다릅니다. 귀사의 모델에 라이선스가 필요하다면 초기 설정비를 받은 뒤가 아니라 범위 설정 단계에서 말씀드립니다.
웹훅을 갖춘 REST API이며, 샌드박스부터 시작합니다. 사용자 생성, 인증, 카드 발급, 제어 설정, 원장 조회, 이벤트 수신. 결제 API를 연동해 본 팀에게는 놀랄 것이 없고, 그렇지 않은 팀은 보통 저희가 아니라 온보딩 흐름에 시간을 씁니다.
정해진 종료 절차가 있습니다. 고객에게 통지하고, 카드는 갑자기 끄는 대신 일정에 따라 단계적으로 종료하며, 잔액은 반환합니다. 서면 종료 조항이 없는 계약은 인질극이며, 저희도 그런 계약에는 서명하지 않을 것입니다.
요구 사항 보내기
시장, 예상 거래량, 일정, 그리고 무엇을 만들려는지 알려 주십시오. 서면 제안서와 함께 귀사의 일정 안에서 무엇이 가능한지 솔직한 의견을 드리겠습니다.
- 지원할 수 없는 시장과 모델은 범위 설정 단계에서 말씀드립니다
- “가격 논의” 통화가 아니라 서면 상업 조건
- 프로그램 승인 즉시 샌드박스 접근 제공
