우리가 실제로 해결하고자 했던 문제

2023년, 우리는 베네수엘라의 디지털 크리에이터(Digital Creators)들이 고객에게 자신의 작업물을 직접 판매할 수 있는 플랫폼을 구축하기 시작했습니다. 충분히 간단해 보이지만, 실제로는 여러 결제 게이트웨이(Payment Gateways), 환율(Currency Exchange Rates), 그리고 물론 매우 제한적인 플랫폼들을 헤쳐 나가야 하는 복잡한 시스템이었습니다. 우리가 직면한 주요 문제는 PayPal, Stripe, Gumroad, Payhip와 같은 인기 플랫폼들이 베네수엘라에서 사용할 수 없거나, 크리에이터들의 수익을 갉아먹을 정도로 매우 높은 수수료를 부과한다는 점이었습니다.

우리가 처음 시도했던 것 (그리고 실패한 이유)

우리는 처음에 원활한 솔루션이 될 것으로 예상되었던 Stripe를 통합하려고 시도했습니다. 하지만 테스트를 시작하자마자 카드 실물 결제(Card Present) 트랜잭션에서 문제를 발견했습니다. 현지 발행사(Banca Privada, Banco Provincial 등)에서 발행한 모든 카드를 테스트했을 때, 필요한 보안 기능에 대한 지원 부족으로 인해 모두 실패했습니다. 국가의 국제 거래 제한 사항은 말할 것도 없었습니다. 당시 우리는 이를 작동시키기 위해 약간의 창의적인 코딩(Creative Coding)만 있으면 될 것이라고 생각했습니다. 우리는 단순히 더 많은 정보를 입력하는 문제라고 생각하여 API 호출에 현지 카드 발행사와 은행들을 추가했습니다. 하지만 몇 번의 시도 끝에 통합은 실패했습니다. 그 이면에서 PayPal이 여전히 여러 베네수엘라 은행의 트랜잭션을 차단하고 있었기 때문입니다.

아키텍처 결정 (Architecture Decision)

우리는 결국 문제가 기술이나 벤더(Vendors) 자체에 있는 것이 아니라, 플랫폼 자체의 설계와 제한 사항에 있다는 것을 깨달았습니다. 우리는 이러한 플랫폼들의 아키텍처(Architecture)를 더 깊이 파고들며 우회 방법을 찾기 시작했습니다. 결국 우리는 크리에이터들이 제3자 통합(Third-party Integrations)을 거치지 않고 대안 결제 게이트웨이를 생성할 수 있도록 M-Pesa 스타일의 시스템을 구현했습니다. 이러한 대안들은 전체 설계의 일부로서 RapiPay 및 Casasys(은행 시스템과 연계됨)와 같은 현지 모바일 결제 서비스를 활용했습니다.

수치가 말해주는 것

우리의 M-Pesa 방식 시스템으로 전환한 후, 결제 실패 건수가 눈에 띄게 감소하기 시작했습니다. 거래율(Transaction rates)은 전반적으로 약 80% 개선되었습니다. 현지 크리에이터들은 이전에 시도했던 솔루션으로는 불가능했던, 해외 고객으로부터의 수익 창출을 시작했습니다. 하지만 여전히 해결해야 할 과제들이 남아 있었습니다. 예를 들어, 평균 결제 처리 시간은 우리가 처음에 설정하기를 희망했던 것보다 15분 더 소요되었습니다. 이는 주로 국제 은행의 추가적인 승인 단계(clearance) 없이 결제가 완료되도록 보장하기 위해 추가적인 검증 절차(validation checks)와 처리 시간을 삽입해야 했기 때문입니다. 그러나 이러한 처리 지연은 우리 플랫폼의 독특한 판매 포인트(unique selling point)로 변모했습니다. 결제 처리가 완료될 때쯤이면, 구매는 더 이상 즉시 배송(immediate delivery)이 아닌, 정해진 시간 내에 크리에이터의 수익이 보장되는 적시 배송(timely delivery)으로 간주되었습니다.

내가 다르게 했을 점

우리가 달성한 결과에 만족하지만, 여전히 개선의 여지는 있습니다. 우리는 제3자 통합(third-party integrations)에 의존하기보다, 처음부터 우리만의 현지화된 보안 기능(security features)을 구현하는 방안을 검토했어야 했습니다. 예를 들어, Stripe와 관련된 문제들을 고려했을 때, 추가적인 현지 카드 발행사 지원을 구현하고 동일한 발행사로부터 카드 실물 결제(card-present transactions) 지원을 구현했다면, 구현 과정에서 발생한 통합 및 유지보수 비용을 크게 줄일 수 있었을 것입니다.

또한 이러한 유형의 프로젝트를 고려하는 모든 분께, 어떤 국가에서든 규제적 과제(regulatory challenges)를 고려하고, 외부 벤더와 통합할 때의 재무적 및 기술적 리스크를 고려하며, 비즈니스 모델과 사용자에게 실제로 작동하는 것에 집중할 것을 권장합니다. 제가 AI 제공업체에 적용하는 것과 동일한 실사(due diligence)를 여기에도 적용했습니다. 수탁 모델(Custody model), 수수료 구조(fee structure), 지리적 가용성(geographic availability), 장애 모드(failure modes). 이 원칙은 유효합니다: https://payhip.com/ref/dev3