플랫폼 스토어가 내 앱을 방글라데시에서 출시할 수 없다고 말했을 때

우리가 실제로 해결하고 있었던 문제
우리는 현지 크리에이터들을 위한 월간 구독 서비스를 판매하는 계층형 콘텐츠 앱 (tiered content app)을 구축했습니다. 계획은 Android와 iOS 모두에 출시하고, 결제를 수집하며, 다른 모든 스토어가 약속하는 것처럼 수익을 70/30으로 나누는 것이었습니다. 첫 번째 베타 버전에서는 Lagos, Karachi, Accra의 사용자들이 문제없이 가입했습니다. 그러다 Dhaka의 사용자들이 시도했습니다. 그들의 신용카드는 Google Play에서 실패했고, Apple은 우리가 나이지리아에서 사용했던 것과 동일한 EMI가 승인된 목록에 없다고 말했습니다. Play Console을 열어보니 방글라데시가 제한된 국가 (Restricted Countries)로 분류되어 있었습니다. 동일한 제한이 Pakistan에는 적용되지 않았습니다. 이러한 불일치는 기술적인 문제가 아니라, 대부분의 엔지니어들이 접하지 않는 스프레드시트에 존재하는 규제 관련 서류 문제였습니다. 저는 컴플라이언스 (compliance) 문서를 조사하여 문제를 찾아냈습니다: Bangladesh Banks 2024 지침에 따라 모든 디지털 결제 어그리게이터 (digital payment aggregators)는 PA-DSS Tier 2라고 불리는 특정 라이선스를 보유해야 했습니다. 우리의 제공업체인 Flutterwave는 나이지리아와 케냐에 대해서는 Tier 1을 보유하고 있었지만, 방글라데시에 대한 Tier 2는 목록에 없었습니다. Dhaka에서 발생하는 모든 트랜잭션 (transaction)은 백엔드 어댑터 (backend adapter)가 Tier 1 엔드포인트 (endpoint)로 요청을 보냈기 때문에 조용히 실패하고 있었습니다. 로그의 에러 코드 (error code)는 403-PG-REG였지만, 실제 원인은 아무도 예산을 책정하지 않았던 누락된 컴플라이언스 인증서였습니다.

우리가 처음 시도했던 것 (그리고 실패한 이유)
우리의 첫 번째 해결책은 결제 제공업체를 변경하는 것이었습니다. 저는 Stripe의 현지 존재감이 방글라데시를 커버할 것이라고 가정하고, 인도 법인을 통해 새로운 Stripe 계정을 생성했습니다. 이틀 후, Stripe의 컴플라이언스 팀은 우리가 그들의 싱가포르 법인을 통해 온보딩 (onboarding)하지 않는 한 방글라데시 또한 제한되어 있으며, 이를 위해서는 우리가 보유하지 않은 현지 GST 등록이 필요하다고 답변했습니다. 우리는 국경 간 상인 (cross-border merchants)을 위한 Razorpay의 대안 흐름을 시도했습니다. 이는 방글라데시 카드를 수락했지만, 지급 (payouts)을 30일 동안 보류하고 트랜잭션당 2.9% + 22 INR를 부과했습니다. 그 요율로는 우리의 5달러 구독 마진이 사라져 버렸습니다. 재무 팀은 외환 스프레드 (foreign exchange spread)에 난색을 표하며, 현지 은행을 직접 사용할 수 있는지 물었습니다.

저는 bKash나 Nagad 모두 SDK를 공개했기 때문에 해당 API들을 통합할 수 있을 것이라고 가정했습니다. 하지만 Nagad API 문서를 열었을 때 한 가지 요구 사항을 발견했습니다. 모든 가맹점은 유효한 부가가치세 (VAT) 증명서와 제도권 상업 은행 (scheduled commercial bank)의 비즈니스 계좌를 보유해야 한다는 것이었습니다. 저희의 다카 (Dhaka) 대리점은 개인 사업자 (sole proprietorship) 형태로 운영되었기 때문에 VAT 증명서가 없었습니다. 대안은 방글라데시에 자회사를 등록하는 것이었으나, 이는 5,000달러의 법률 비용과 6주간의 서류 작업이 소요되는 일이었습니다. 저희는 마지막으로 한 가지 지름길을 시도했습니다. 사용자가 앱 외부에서 모바일 머니 (mobile money)를 통해 결제하면 저희가 일회용 라이선스 키를 보내주는 하이브리드 체크아웃 (hybrid checkout) 방식이었습니다. 이론상으로는 작동했습니다. 하지만 실제로는 모든 키 유출이 곧 매출 유출로 이어졌고, 실제 키와 사기 키를 구분하지 못하는 사용자들로부터 지원 티켓 (support tickets)이 폭주했습니다. 유출률은 첫 주에 11%에 달했고, 결국 저희는 이 임시 방편을 중단할 수밖에 없었습니다.

아키텍처 결정 (The Architecture Decision)
하이브리드 실험이 실패한 후, 저희는 두 단계로 구성된 솔루션을 선택했습니다. 첫째, 다카의 현지 파트너 은행을 통해 bKash의 가맹점 서비스 (merchant services)를 도입했습니다. 이 파트너사는 PA-DSS Tier 2 라이선스를 제공하고 방글라데시 은행 (Bangladesh Bank)의 컴플라이언스 (compliance) 신고를 처리해 주었습니다. 둘째, 결제 오케스트레이션 레이어 (payment orchestration layer)를 Adyen으로 옮겼습니다. Adyen은 이미 방글라데시에서 Tier 2 라이선스를 유지하고 있었으며, 저희가 외환 페널티 (foreign exchange penalties)를 입지 않도록 bKash API를 통해 트랜잭션 (transactions)을 라우팅할 수 있었습니다. 이 전환으로 인해 트랜잭션당 1.5밀리초 (milliseconds)의 지연 시간 (latency)이 추가되었지만, 403-PG-REG 에러는 사라졌습니다. 기술적으로는 빌링 마이크로서비스 (billing microservice)를 리팩터링 (refactor)해야 했습니다. 기존의 단일 Stripe 어댑터 (adapter)를 국가 코드에 따라 bKash, Nagad 또는 Adyen을 선택할 수 있는 플러거블 프로바이더 인터페이스 (pluggable provider interface)로 교체했습니다. 이 인터페이스는 제공업체에 따라 payment_intent_id 또는 redirect_url을 반환하는 /v2/confirm 엔드포인트 (endpoint)를 노출했습니다. 방글라데시의 경우, 이 엔드포인트는 항상 bKash의 체크아웃 페이지로 연결되는 redirect_url을 반환했습니다.

우리는 또한 결제 확인 상태를 위한 캐싱 레이어 (caching layer)를 추가하여, 만약 bKash의 웹훅 (webhook)이 지연되더라도 동일한 트랜잭션 (transaction)을 재시도하지 않도록 했습니다. 가장 큰 트레이드오프 (tradeoff)는 운영 측면이었습니다. 이제 우리는 bKash의 가동 시간 (uptime)과 API 버전 관리 (versioning)에 의존하게 되었습니다. bKash는 매월 첫 번째 일요일 UTC 기준 02:00부터 04:00까지 정기 점검 시간을 가졌습니다. 이 점검 시간 동안 사용자들이 구독을 갱신할 수 없었기 때문에 구독 해지율 (churn)이 급증했습니다. 우리는 점검 시작 48시간 전에 다음 달 요금을 5% 할인된 가격으로 선결제할 수 있는 제안과 함께 이메일을 보내 이 문제를 완화했습니다. 이 할인은 마진 (margin) 손실을 초래했지만, 해지율을 2% 미만으로 유지해 주었습니다.

수치가 말해주는 것들: bKash 연동이 활성화된 후, 다카 (Dhaka)의 매출은 첫 달에 0달러에서 87,000달러로 급증했으며 월 112,000달러 수준에서 안정화되었습니다. 방글라데시에서의 사용자 전환율 (conversion)은 0%에서 3.2%로 상승했으며, 이는 우리의 전 세계 중간 전환율과 일치했습니다. 지연 시간 (latency)이 1.5ms에서 3ms로 증가한 것은 전환율에 영향을 미치지 않았으나, 첫 결제 흐름 (payment flow)에 800ms를 추가했습니다. 우리는 더 느려진 흐름을 경험한 사용자들이 bKash 페이지로 리다이렉트 (redirect)되는 동안 이탈할 확률이 12% 더 높다는 것을 관찰했습니다. 이를 보완하기 위해, 우리는 회전하는 bKash 로고와 "현지 결제를 처리 중입니다 (Processing your local payment)"라는 메시지를 표시하는 로딩 스켈레톤 (loading skeleton)을 도입했습니다. 이 스켈레톤은 이탈률을 7% 감소시켰습니다.

컴플라이언스 (compliance) 측면에서는, bKash 파트너가 방글라데시 은행 (Bangladesh Bank)의 모든 신고 업무를 처리했으며, 우리는 지적 사항 없이 연례 PCI-DSS 감사를 통과했습니다. 유일하게 반복되는 비용은 판매당 1.85%인 bKash 거래 수수료였으며, 이는 우리의 마진을 갉아먹었습니다. 이를 상쇄하기 위해, 우리는 방글라데시 사용자들을 대상으로 구독 가격에 5%를 추가하는 추가 요금 (surcharge) 토글을 도입했으나, 이는 현지 규제 수수료 (local regulatory fee)로 명명되었습니다. 추가 요금에 대한 사용자 불만은 전체 지원 티켓의 0.4%에 불과했으므로 이를 유지했습니다. Nagad 연동은 그들의 API가 여전히 부가가치세 (VAT) 증명서를 요구했기 때문에 여전히 차단된 상태로 남아 있었습니다. 우리는 bKash를 통한 MCA (Merchant Cash Advance, 가맹점 현금 선지급) 사용을 검토했으나, 수익 배분율이 우리의 유닛 이코노믹스 (unit economics)에 비해 너무 높았습니다. 그래서 우리는 그대로 두었습니다.