← All case studiesCheckout.com / Dec 2025 - Jul 2026

Following SDK fixes across platform boundaries

Delivered React Native SDK work through its Android and iOS dependencies and used merchant-facing sample development to identify platform differences.

Senior Mobile Engineer · Parser contractor

Product context and challenge

As a Parser contractor on Checkout.com’s Android Payment Flow team, I worked on a public merchant sample and took responsibility for critical React Native SDK bugs and incomplete features.

Completing wrapper features required native releases first. Sample development also exposed differences in configuration, styling, and behavior between Android and iOS.

My scope and ownership

  • Fixed critical React Native SDK bugs and implemented required Android and iOS changes before completing the wrapper work for release.
  • Developed the public Android sample using the iOS sample as the agreed design reference.
  • Documented platform differences and created follow-up tasks.
  • Prioritized merchant-requested fixes, joined issue discussions, and onboarded a new iOS developer from Parser.
  • Owned co-branded card-scheme development with open display-priority requirements and took on Gradle configuration tooling for an internal sample.

Decisions and trade-offs

  • Native dependency changes had to be published before the React Native work could be completed. I followed the dependency chain across both native platforms.
  • Without a UX designer for the merchant sample, my engineering manager and I agreed to use the existing iOS sample as the Android reference.
  • Co-branded card presentation required an agreed business rule. Display priority remained an open requirement; this work is not presented as shipped payment-routing functionality.

Quality, validation, and delivery

  • Compared SDK configuration, styling, and behavior while building the sample and working across native platforms.
  • Recorded inconsistencies as follow-up tasks and used merchant discussions to understand and prioritize stability issues.
  • Kept internal configuration tooling separate from the public sample: the Gradle approach generated Android resources from multiple API-key sources.

Outcomes

  • The native dependency changes and completed React Native work were included in a release.
  • Platform differences were documented for follow-up. Publication of the public sample and resolution of every difference are not claimed.
  • Card-scheme and configuration-tooling work describe contributions in progress; their shipping and adoption outcomes are not established.

Supporting technologies

KotlinAndroid SDKSwiftiOS SDKReact NativeTypeScriptGradle