스테이징 환경에서는 결제 테스트가 통과되었습니다. 그러다 화요일에 PhonePe가 SDK 업데이트를 배포했고, 삼성 기기에서 UPI 인텐트 딥 링크(UPI intent deep link)가 실행되지 않기 시작했으며, 수요일 결제 시도 중 12%가 아무런 오류 메시지 없이 실패했습니다. 결제는 이루어지지 않았고, 주문도 생성되지 않았습니다. 사용자는 멈춰버린 화면을 보았고 앱을 삭제했습니다.

결제 테스트는 모바일 QA(Quality Assurance) 영역 중 가장 리스크가 크고 유지보수 비용이 많이 드는 분야입니다. 또한, 결제 흐름이 서드파티 SDK(third-party SDKs), 외부 앱 실행, OS 레벨의 인텐트(intents), 그리고 예고 없이 혹은 사용자의 개입 없이 변경되는 제공업체별 UI에 의존하기 때문에 대부분의 팀이 자동화 커버리지를 가장 적게 확보하는 영역이기도 합니다.

이 가이드는 실제로 스프린트(sprint)를 거치며 생존할 수 있는 결제 테스트를 구축하는 방법을 다룹니다. 구체적으로 무엇이 고장 나는지, 왜 전통적인 자동화가 결제 흐름에서 어려움을 겪는지, 각 레이어에서 무엇을 테스트해야 하는지, 그리고 Vision AI가 사용자가 실제로 보는 결제 경험을 어떻게 검증하는지를 설명합니다.

결제 흐름 테스트에 대한 심층적인 분석은 [Why Checkout Flows Break More Than Anything Else]를 참조하세요. 배달 앱 전체 체크리스트는 30 Test Cases from Order to Doorstep.를 참조하세요.

핵심 요약 (Key Takeaways)

• 결제 흐름 테스트 (Payment flow testing)는 모바일 QA에서 유지보수 비용이 가장 높은 영역입니다. 이는 귀사의 릴리스 주기와 무관하게 독립적으로 업데이트되는 제3자 SDK (Razorpay, Juspay, Google Pay, PhonePe 등)에 의존하기 때문이며, 귀사의 코드에 아무런 변경이 없더라도 테스트가 깨질 수 있습니다.
• 인도의 결제 환경은 15~20개 이상의 결제 경로를 테스트할 것을 요구합니다: UPI (5개 이상의 앱), 카드 (Visa, Mastercard, RuPay), 인터넷 뱅킹 (50개 이상의 은행), 지갑 (Paytm, Amazon Pay, Mobikwik), 현금 결제 (COD), 플랫폼 크레딧, 할부 (EMI), 그리고 분할 결제 (split payments).
• UPI는 테스트 시 실패 가능성이 가장 높은 결제 방식입니다. 앱의 경계를 넘나들기 때문입니다 (귀사의 앱 → OS 인텐트 (intent) → UPI 앱 → 콜백 (callback)). 또한, OS 레벨의 앱 선택기 (app selector)는 Appium의 엘리먼트 트리 (element tree)에서 보이지 않습니다.
• 4단계 테스트 전략: API 레벨의 결제 로직 (모든 PR) → Vision AI를 통한 시각적 흐름 검증 (모든 빌드) → 제공업체 샌드박스 (sandbox) 통합 (매주) → 엣지 케이스 (edge case) 및 네트워크 회복탄력성 (릴리스 전).
• Vision AI (Drizz)는 결제 흐름을 시각적으로 검증하므로, 결제 제공업체의 SDK가 업데이트되어도 테스트가 깨지지 않습니다. 어떤 SDK 버전이 렌더링하든 카드 번호 필드는 여전히 카드 번호 필드처럼 보이기 때문입니다.
• 812개의 결제 수단을 가진 프로덕션 앱은 4060개의 결제 전용 테스트 케이스가 필요합니다. 셀렉터 (selector) 기반 도구를 사용할 경우, 스프린트당 1015시간의 유지보수가 필요하지만, Vision AI를 사용하면 12시간이면 충분합니다.

결제 흐름 테스트를 어렵게 만드는 요인은 무엇인가?

결제 흐름 테스트는 귀사의 앱과 귀사가 제어할 수 없는 외부 시스템 사이의 경계를 넘나들기 때문에 독보적으로 어렵습니다. 다섯 가지 구조적 요인이 결제 테스트를 신뢰성 있게 자동화하기 가장 어려운 영역으로 만듭니다:

1. 제3자 SDK 의존성 (Third-Party SDK Dependency)

전형적인 인도 모바일 앱은 3~5개의 결제 SDK를 통합하여 사용합니다: 결제 게이트웨이(Payment Gateway)로서의 Razorpay 또는 Juspay, UPI를 위한 Google Pay / PhonePe / Paytm, 그리고 개별 카드 네트워크 프로세서가 그것입니다. 각 SDK는 고유의 릴리스 주기(Release Cycle), 고유의 UI 컴포넌트(UI Components), 그리고 고유의 파괴적 변경 사항(Breaking Changes)을 가지고 있습니다. Razorpay가 SDK 버전 4.2.1을 배포하면, 여러분의 코드가 단 한 줄도 바뀌지 않았음에도 체크아웃 화면이 다르게 렌더링되거나, 타임아웃(Timeout)이 다르게 발생하거나, 다른 콜백(Callback) 형식을 반환할 수 있습니다.

여러분의 테스트 스위트(Test Suite)는 이러한 SDK 업데이트가 언제 배포되는지 전혀 알 수 없습니다. 그 첫 번째 징후는 월요일 아침에 발생하는 테스트 실패입니다.

2. OS 레벨의 인텐트(Intent) 및 딥 링크(Deep Link)의 취약성

Android에서의 UPI 결제는 인텐트(Intent)를 통해 작동합니다: 앱이 인텐트를 발생시키면, OS가 UPI 앱 목록을 제시하고, 사용자가 하나(Google Pay, PhonePe, Paytm)를 선택하면, 선택된 앱이 트랜잭션(Transaction)을 처리하고 결과를 여러분의 앱으로 반환합니다. 이 체인의 각 단계에서 문제가 발생할 수 있습니다:

• 인텐트 형식(Android가 UPI 앱을 실행하기 위해 사용하는 기술적 지침)이 Android 버전 간에 변경됨
• Samsung의 One UI가 순정(Stock) Android와 다르게 인텐트 해석(Intent Resolution)을 처리함
• 일부 UPI 앱이 적절한 성공/실패 콜백(Callback)을 반환하지 않음
• UPI 앱 선택자 대화 상자(App Selector Dialog)는 앱의 엘리먼트 트리(Element Tree)에서 보이지 않는 OS 레벨의 컴포넌트임

Appium은 인텐트를 발생시킬 수는 있습니다. 하지만 OS 레벨의 앱 선택자나 UPI 앱 자체의 UI와 안정적으로 상호작용할 수는 없습니다. 그것들은 여러분의 앱 프로세스 및 엘리먼트 트리 밖에 있기 때문입니다.

3. 결제 상태의 복잡성

결제 흐름은 성공 상태보다 더 많은 실패 상태를 가집니다:

• 결제가 시작되었으나 완료되지 않음 (사용자가 이탈함)
• 결제 처리 중 (여러분의 앱과 제공업체 사이에서 중간 상태에 머물러 있음)
• 결제는 성공했으나 콜백을 받지 못함 (돈은 차감되었으나 주문은 생성되지 않음)
• 재시도가 가능한 결제 실패
• 재시도가 불가능한 결제 실패 (카드 차단, 잔액 부족)
• 재시도 시 결제는 성공했으나 첫 번째 시도도 성공함 (이중 결제)
• 부분 결제 완료 (지갑 잔액은 차감되었으나 UPI 부분은 실패함)

각 상태는 에러 메시지, 재시도 버튼, 환불 알림, 상태 표시기 등 특정 UI 처리를 필요로 합니다. 모든 상태를 테스트하려면 제공업체(provider)의 응답을 모킹(mocking)해야 하며, 이는 테스트가 제공업체의 실제 동작과 일치하는 모킹의 정확도에 의존함을 의미합니다.

4. 인도의 결제 수단 다양성

인도 시장은 거의 다른 어떤 지역보다 더 많은 결제 조합을 가지고 있습니다:

• UPI (Google Pay, PhonePe, Paytm, BHIM, WhatsApp Pay): 각각 고유한 앱, UI, 콜백(callback) 동작을 가짐
• 신용/직불 카드 (Credit/Debit Cards) (Visa, Mastercard, RuPay): Razorpay, Juspay를 통하거나 직접 연동
• 인터넷 뱅킹 (Net Banking) (50개 이상의 은행, 각기 다른 로그인 흐름 보유)
• 지갑 (Wallets) (Paytm Wallet, Amazon Pay, Mobikwik, Freecharge)
• 착불 결제 (Cash on Delivery) (쿠폰 및 최소 주문 규칙과 상호작용하는 토글 로직)
• 플랫폼 크레딧/코인 (Platform Credits/Coins) (잔액 계산이 필요한 부분 결제)
• EMI (자격 확인이 포함된 카드 기반 할부 옵션)
• 분할 결제 (Split Payments) (지갑 잔액 + 나머지 금액에 대한 UPI 결제)

"결제가 작동한다"를 테스트한다는 것은 각각 고유한 실패 모드를 가진 15~20개 이상의 결제 경로를 테스트한다는 것을 의미합니다.

5. 제공업체별 요소 ID(Element IDs)의 예고 없는 변경

결제 제공업체가 SDK를 업데이트하면 결제 UI 내부의 요소 ID(element IDs)가 변경됩니다. 버전 4.1에서 resource-id="rzp_card_number"를 사용하던 Razorpay 체크아웃 시트가 버전 4.2에서는 resource-id="card_number_input"을 사용할 수 있습니다. Razorpay 요소를 타겟팅하던 귀하의 Appium 테스트는 귀하가 아무것도 변경하지 않았음에도 깨지게 됩니다.

이것이 결제 테스트의 독특한 유지보수 부담입니다. 타인의 코드 변경으로 인해 귀하의 테스트가 깨지는 것입니다.

결제 테스트에서 구체적으로 무엇이 깨지는가?

인도에서 매일 수백만 건의 거래를 처리하는 모바일 앱들의 패턴을 바탕으로 분석하면 다음과 같습니다:

UPI 실패 (가장 흔한 사례)

• Intent 미실행 (Intent not launching): UPI 앱 선택기가 나타나지 않거나, Google Pay가 설치된 기기임에도 "설치된 UPI 앱이 없습니다"라는 메시지가 표시됨.
• 앱별 실패 (App-specific failures): 동일한 기기, 동일한 금액, 동일한 가맹점에서 Google Pay를 통한 결제는 성공하지만 PhonePe를 통한 결제는 실패함.
• 콜백 미수신 (Callback not received): UPI 앱에서 금액이 차감되고 성공 메시지가 표시되었으나, 귀하의 앱은 콜백 (Callback)을 받지 못함. 사용자는 멈춰있는 "처리 중 (Processing)" 화면을 보게 됨.
• 타임아웃 처리 (Timeout handling): 사용자가 UPI 앱을 열고 3분 동안 주의가 분산되어 트랜잭션이 타임아웃 (Timeout) 되었으나, 귀하의 앱에 타임아웃 메시지가 표시되지 않음.
• Collect vs Pay 흐름 혼동 (Collect vs Pay flow confusion): 일부 통합 방식은 Collect 요청 (가맹점이 시작)을 사용하고, 다른 방식은 Pay 흐름 (사용자가 시작)을 사용함. UI 흐름이 다르기 때문에 한쪽을 위해 작성된 테스트가 다른 쪽에서는 작동하지 않음.

카드 결제 실패 (Card Payment Failures)

• 3D Secure 리다이렉트 오류 (3D Secure redirect breaking): 결제 게이트웨이 (Payment Gateway)의 웹뷰 (WebView) 내에서 은행의 OTP/인증 페이지 로딩에 실패함.
• 저장된 카드 토큰 만료 (Saved card tokens expiring): 저장된 카드 자격 증명을 사용하는 테스트가 토큰이 만료되거나 카드가 재발급될 때 실패함.
• RuPay 전용 흐름 (RuPay-specific flows): RuPay 카드는 Visa/Mastercard와 다른 프로세서를 통해 라우팅되며, UI와 타임아웃 동작 방식이 다름.

지갑 및 분할 결제 실패 (Wallet and Split Payment Failures)

• 부분 결제 상태 손상 (Partial payment state corruption): 지갑 잔액은 성공적으로 차감되었으나, 나머지 금액에 대한 UPI 부분이 실패함. 결과적으로 총액이 맞지 않게 됨. 지갑 부분에 대한 환불이 자동으로 트리거되지 않음.
• 지갑 잔액 표시 오류 (Wallet balance display stale): 캐시된 지갑 잔액은 500으로 표시되지만 실제 잔액은 200임. 사용자가 지갑을 선택하면 잔액 부족으로 결제가 실패하지만, UI에는 충분한 잔액이 있는 것으로 표시됨.
• 플랫폼 크레딧 + 쿠폰 상호작용 (Platform credits + coupon interaction): 100 크레딧 플랫폼 할인과 20% 쿠폰이 함께 적용될 때, 쿠폰이 크레딧 적용 전 혹은 후에 적용되는가? 빌드 (Build)마다 이 계산 방식이 다름.

COD 전용 실패 (COD-Specific Failures)

• COD 가용성 로직 (COD availability logic): COD는 1,500 미만의 주문에 대해 사용 가능하지만, 그 임계값(threshold)은 도시마다 다릅니다. Delhi(1,500 제한)를 기준으로 작성된 테스트는 tier-3 도시(500 제한)에서 실패합니다.
• COD + 쿠폰 상호작용 (COD + coupon interaction): COD와 함께 무료 배송 쿠폰이 적용될 때, 배송비가 COD 금액에 다시 추가되는지 아니면 흡수되는지 확인해야 합니다.
• COD 토글 상태 (COD toggle state): 사용자가 COD를 선택했다가 UPI로 전환한 후, 다시 COD로 전환했을 때 주문 총액이 동일해야 합니다. 때때로 그렇지 않은 경우가 발생합니다.

각 계층에서 무엇을 테스트해야 하는가?

계층 1: API 레벨 결제 로직 (Layer 1: API-Level Payment Logic) (모든 PR에서 실행)

UI를 건드리지 않고 결제 계산, 쿠폰 상호작용 및 상태 관리(state management)를 테스트합니다:

• 다양한 품목 조합에 따른 주문 총액 계산
• 쿠폰 할인 적용의 정확성 (정액, 백분율, 한도 적용)
• 거리 및 시간에 따른 배송비 계산
• 할증 가격(Surge pricing) 적용 및 총액 반영 여부
• 지갑 잔액(Wallet balance) 차감 및 잔액 계산
• 각 상태(성공, 실패, 대기, 타임아웃)에 대한 결제 콜백(Payment callback) 처리
• 부분 결제 실패 시 환불 트리거(Refund trigger) 로직
• 도시 및 주문 금액별 COD 가용성 규칙

도구 (Tools): Postman, RestAssured, API 클라이언트를 포함한 pytest.

계층 2: 시각적 결제 흐름 테스트 (Layer 2: Visual Payment Flow Testing) (모든 빌드에서 실행)

각 결제 수단 진행 중에 사용자가 실제로 보는 내용을 검증합니다:

결제 수단으로 UPI 선택

• UPI 앱 선택기 또는 UPI ID 입력창이 나타나는지 확인
• 최소 하나 이상의 UPI 앱 옵션이 보이는지 확인

결제 수단으로 신용/직불 카드(Credit/Debit Card) 선택

• 카드 번호 입력 필드가 나타나는지 확인
• 만료일 및 CVV 필드가 보이는지 확인
• 정확한 금액과 함께 "결제(Pay)" 버튼이 표시되는지 확인

현금 결제(Cash on Delivery) 선택

• 주문 총액이 업데이트되는지 확인 (결제 처리 수수료 없음)

• "주문하기(Place Order)" 탭

• 주문 확인 화면에 결제 수단이 COD로 표시되는지 확인

• "지갑 잔액 사용(Use Wallet Balance)" 토글 활성화

• 지갑 잔액이 총액에서 차감되었는지 확인

• 남은 금액이 표시되는지 확인

• 남은 금액에 대해 UPI 선택

• 결제 완료

• 분할 결제 요약과 함께 주문이 확인되었는지 확인

도구: Drizz (Vision AI) 테스트는 실행 중인 결제 SDK 버전이나 제공업체가 사용하는 요소 ID(element IDs)에 관계없이 시각적 결제 흐름을 검증합니다.

레이어 3: 결제 제공업체 통합 테스트 (주간 실행)

각 결제 제공업체의 테스트/샌드박스 (test/sandbox) 자격 증명을 사용하여 다음을 수행합니다:

• 각 UPI 앱(Google Pay, PhonePe, Paytm)을 통한 전체 트랜잭션 완료
• 3D Secure OTP를 사용한 카드 트랜잭션 완료
• 최소 2개 이상의 은행을 통한 인터넷 뱅킹 (net banking) 트랜잭션 완료
• 타임아웃 (timeout) 동작 테스트 (제공업체 타임아웃을 기다린 후, 앱이 이를 적절히 처리하는지 확인)
• 실패 시나리오 테스트 (잔액 부족, 거절, 네트워크 오류)

도구: 제공업체 샌드박스 환경 + 시각적 흐름 검증을 위한 Drizz.

레이어 4: 엣지 케이스(Edge Case) 및 회귀 테스트 (릴리스 전 실행)

• "주문하기(Place Order)"를 더블 탭하여 주문이 중복 생성되지 않는지 확인
• 결제 처리 중 네트워크 단절 시 우아한 복구 (graceful recovery) 확인
• UPI 결제 중 앱이 백그라운드로 전환될 때, 복귀 후 콜백 (callback)이 여전히 수신되는지 확인
• 결제는 성공했으나 앱이 충돌(crash)한 경우, 재실행 시 주문 상태 확인
• 결제 실패 후 재시도 시 금액이 정확한지 확인 (중복되지 않았는지 확인)

도구: 수동 테스트 + 네트워크 시뮬레이션 (Charles Proxy) + 시각적 상태 검증을 위한 Vision AI.

Vision AI가 결제 테스트를 어떻게 변화시키는가?

Drizz는 Vision AI 기반의 모바일 테스트 플랫폼으로, 제3자 결제 SDK 내부의 요소 ID를 쿼리하는 대신 사용자와 동일하게 렌더링된 화면을 바라봄으로써 결제 흐름을 검증합니다. 결제 테스트에서의 핵심적인 이점은 타인의 SDK가 업데이트되더라도 귀하의 테스트가 깨지지 않는다는 것입니다.