Android Platform Lead, PayPal Here POS

PayPal Here is PayPal's hardware-anchored point of sale. As the Android Platform Lead I owned the Android application's health for a platform with 600K+ total users globally and 200K+ active on Android across multiple countries — the kind of product where a regression doesn't just inconvenience users, it stops cashflow for real merchants taking real card payments.

Architecture decisions, A/B testing, sprint planning, code reviews. Cross-platform alignment with the iOS Tech Lead, the Backend services Lead, and the Product Owner — daily, not as a one-time sync — so the course of action benefitted all three platforms. Mentoring on the Android contributors. And defining the global standard for POS hardware integration inside PayPal — what "supported reader" meant, what every supported terminal had to expose, and how new hardware partners came on board.

The piece I'm most proud of from this period is the Verifone terminal integration. Verifone terminals talk to the host over Bluetooth or IP; the protocol is EMVco-spec; the activation flow has to branch on the card type the reader sees and route the payment data to the back-office service. Adding Verifone support meant building the BT/IP transport in the SDK, implementing EMVco data exchange, and wiring it through to the activation and settlement flows on the back-office side.

What started as Verifone-specific became the global standard for POS hardware integration inside PayPal. I defined what "supported reader" meant — the contract every terminal had to expose, the lifecycle hooks each one had to honor, the data shape that survived on its way back to the back-office. The standard let new hardware partners plug in against the contract without re-architecting the core, which is what "scaling hardware support" actually means in practice. That standard outlived the specific Verifone work.

Coroutines, StateFlow / SharedFlow, MVI for the screens, Jetpack Compose where Compose was ready, View where View was still the right call. MVI was deliberate for POS: the screens mediate high-stakes payment flows, and any state-drift between the UI, the reader, and the back-office service surfaces as a failed transaction or a hardware desync. Strict single-source state discipline keeps the merchant out of a bad spot at the counter. Gradle custom plugins for the build-time concerns the platform inherited from being multi-product. Retrofit / OkHttp on the network side. Nothing exotic — durable choices for a product that ships every two weeks for years.

PayPal Here ships on Android, iOS, and a back-office desktop console. Platform parity is a daily discipline, not a one-time alignment exercise — I drove the iOS conversation often enough that I ended up effectively defining iOS expectations as well as the Android ones. The course of action for all three platforms went through a 60+ engineer organization across Android, iOS, and Backend, and holding it coherent meant putting decisions in writing, surfacing tradeoffs early, and not letting platforms drift. When platforms drift it's because someone let them; the job is to not let them.