Lessons from Native WeChatPay & Alipay SDK Integration
Sujal Vijayvargiya
SDE-1
Each Asian payment wallet has unique lifecycle semantics that break generic adapter patterns. Here's what I learned integrating WeChatPay, Alipay, and FPS Intent natively on Android and iOS at Juspay.
Why Not WebViews
Singapore and Hong Kong payment regulations require native app-to-app handoff for wallet payments — webview redirects fail authentication checks and are rejected outright by WeChatPay and Alipay in these markets.
Native SDK integration was not optional. It was the only compliant path.
Each SDK Has Its Own Lifecycle
WeChatPay on Android uses Activity result codes for confirmation. Alipay uses a callback-based model with a different result encoding scheme. FPS Intent resolves asynchronously via deep link re-entry after the banking app completes the transfer.
Building a single 'wallet adapter' that abstracts these differences sounds elegant but quickly falls apart. The lifecycle semantics differ enough that per-SDK state handling was the correct architecture.
Testing Across Markets
Test environments for WeChatPay and Alipay require region-specific sandbox credentials and device locales. Our CI pipeline had to be extended with market-specific test profiles to catch locale-sensitive edge cases before production deployment.
— END OF TRANSMISSION —
RETURN TO BLOG