우리가 실제로 해결하려 했던 문제
우리는 전 세계 어디에서나 누구에게든 온라인 강의를 판매할 수 있는 이커머스 (e-commerce) 플랫폼을 구축하려고 했습니다. 꽤 간단해 보이지 않나요? 하지만 현실은 많은 아프리카 국가들이 내부 은행 정책, 자금 세탁 방지법 (anti-money laundering laws), 그리고 기타 규제 장벽으로 인해 PayPal이나 Stripe 같은 서비스를 사용하는 데 차단되어 있다는 점입니다. 이는 제가 "플랫폼 제한 (platform restriction)"이라고 부르는 전형적인 사례로, 결제 처리업체 (payment processor)가 사용자의 개인적인 의도와 상관없이 내부 정책에 따라 특정 국가에 대한 접근을 제한하는 경우를 말합니다.

우리가 처음 시도했던 것 (그리고 실패한 이유)
우리의 초기 솔루션은 제한된 국가에서도 결제를 "해제"할 수 있다고 약속하는 Stripe Connect와 같은 결제 게이트웨이 애그리게이터 (payment gateway aggregator)를 사용하는 것이었습니다. 우리는 단순히 다른 게이트웨이를 통해 결제를 "라우팅 (route)"함으로써 제한을 우회할 수 있다고 생각했습니다. 하지만 결과적으로 이 접근 방식에는 중대한 결함이 있었습니다. 바로 지연 시간 (latency)을 유발하고 결제 실패 위험을 높인다는 점이었습니다. 결제가 실패했을 때 우리 시스템은 일반적인 오류 메시지만을 보냈고, 이는 좋지 않은 사용자 경험 (user experience)을 초래했습니다.

아키텍처 결정 (The Architecture Decision)
우리는 결국 애그리게이터 방식을 포기하고, 나이지리아에서 직접 결제를 수락할 수 있는 다른 결제 처리업체를 선택해야 했습니다. 시행착오 끝에 우리는 거래 실패율이 매우 낮고 더 세밀한 오류 처리 (error handling)를 제공하는 PayStack이라는 작은 결제 처리업체를 결정했습니다. 또한 PayStack의 특정 오류 코드 (error codes)를 처리하기 위해 우리 시스템에 맞춤형 오류 처리 로직을 구축해야 했으며, 이 과정에서 더 자세한 정보를 얻기 위해 그들의 지원 팀과 협상해야 했습니다.

수치가 말해주는 것
나이지리아에서 PayStack을 도입한 후, 첫 달 만에 해당 국가에서의 강의 판매량이 30% 증가했습니다. 더 중요한 것은, 애그리게이터 방식을 사용할 때 3%였던 시스템 오류율이 0.2%로 감소했다는 점입니다.

고객들 또한 만족했습니다. 더 이상 일반적인 오류 메시지를 보지 않아도 되었고, 훨씬 더 빠르게 거래를 완료할 수 있었습니다. PayStack의 강력한 API (Application Programming Interface)와 더 나은 고객 지원이 우리 성공의 핵심이었습니다.

다르게 행동했을 점: 만약 제가 이 과정을 다시 한다면, 처음부터 더 많은 현지 결제 처리업체 (Payment Processors)와의 통합을 우선순위에 두었을 것입니다. 우리는 우리의 독특한 상황을 고려하지 않는 글로벌 결제 처리업체들을 억지로 맞추려 하느라 너무 많은 시간을 허비했습니다. 또한 현지 결제 처리업체들과 관계를 구축하고, 그들의 오류 코드 (Error Codes) 및 지연 시간 (Latency) 특성에 대한 더 상세한 정보를 얻는 데 더 많은 시간을 투자했을 것입니다.