W35 - New Understanding of Standardization

Some new insights on standardization. Standardization work aims to eliminate differences across systems, reduce the complexity of the domain, and make systems more predictable.

Recently I worked with WeChat on switching payment channels, which involved changes to a third-party payment provider. During the integration, we made some business adaptations and checkout compatibility adjustments for the MMP scenario. From a front-end engineering perspective, we introduced a differentiated MMP implementation into the system. The immediate consequence was that the code became harder to maintain, and the checkout behavior under MMP became less predictable for external parties, leaving pitfalls for both the business and our team — we even had a related incident.

This exposed that our level of standardization is insufficient. If we describe the checkout service flow in three stages — payment invocation, payment selection and charge, and post-payment processing — the middle stage, payment selection and charge, happens inside Titans and has been unified across clients. There is little business differentiation there: although the content is extensive, it is predictable and less error-prone. The issues now occur at both ends: payment invocation and post-payment processing. Those ends should eliminate client differences; stacks like MMP, MRN, and Flutter should behave consistently in invocation and post-payment handling to reduce the complexity of client-specific checkout adaptation. So we need to find a good solution that "pinches both ends."

There are two types of checkout SDKs for businesses to choose from: a JS SDK and a Native SDK. I used to think the Native SDK merely shortened the payment invocation path and improved the checkout invocation experience. It actually does more: the Native SDK acts as an intermediary layer. By localizing invocation and post-payment logic, it provides a standard payment bridge to all tech stacks, effectively smoothing out client differences. In practice it reduces the core service's domain complexity, lowers the chance of mistakes, and decreases incidents. This is something the JS SDK struggles to replace.