This is an English translation of the original Japanese article.
STORES Payment is our service that enables businesses to easily introduce cashless payments to their stores. This article shares the efforts we make in how we develop our Android app and help business owners with STORES Payment—a payment service that requires a high level of reliability.
Under our mission statement “Just for Fun,” hey, Inc. supports the development of a dedication-, passion-, and joy-driven economy. We offer a platform called “STORES Platform” to help businesses digitize their services by, for example, creating online stores and providing POS cash register systems, cashless payment systems, and online booking systems.
This article highlights one of our services called STORES Payment, with which business owners can easily adopt cashless payment systems into their shops. We hope you get some idea of the creative efforts we make in developing our Android app and supporting business owners through a payment service, which requires a high level of reliability.
About STORES Payment
A cashless payment service for retailers (business owners), STORES Payment enables people to pay with their credit cards, e-money, or QR codes and offers a mobile app that everybody can use easily, anytime and anywhere—be it indoors or outdoors—as long as there’s internet connection.
We also offer STORES Payment SDK, featuring app-equivalent payment functionalities. By integrating SDK into the app, vendors can smoothly introduce cashless payment functionalities into the app.
Being a payment service means stability is key for the app. But smooth user experience is another aspect we equally highlight in the development process. Improving our app based on the Voice of the Customer (VOC)—which we will discuss later—is another development effort characteristic of hey, aiming for further streamlining business owners’ workflow.
The architecture of and technologies used in the Android app
This section introduces the architecture of and technologies used in the STORES Payment Android app.
Architecture
Despite some exceptions—such as payment functionalities involving complex state management processes—overall, we have stuck to the design explained by Android Developer’s Guide to App Architecture.
But a key difference is that we added UseCases. The data layer uses the Repository pattern to hide API communication, persistence and other processes while passing obtained data to the UI layer via each UseCase. Although the UI layer manages the UI state with ViewModel and updates View, the app does not use DataBinding.
Source: Guide to App Architecture
Technologies used in STORES Payment
Our app uses Retrofit for API communication and Room of Android Architecture Components (AAC) for data persistence. Inter-layer connection has thus far been achieved by RxJava, but we are gradually transitioning to Kotlin Coroutines. We use AAC’s ViewModel and LiveData for the UI layer, and Dagger for the Dependency Injection library, respectively.
The app’s technical characteristic is its Bluetooth-enabled data transfer between card reader terminals and printers. Communication processing with terminals partly shares our in-house C++ implemented library with iOS apps.
STORES Payment (formerly Coiney) is a relatively long-standing app that’s been around since 2013. This means the system has some design-related challenges. Particularly significant is the app’s use of Broadcast for inter-layer exchange in some processes. This design has been in place since the app was first implemented, but we are currently considering changing it to Kotlin Coroutines Flow.
The app currently uses roughly 50% Kotlin and 50% Java, but Kotlin’s ratio is increasing.
With CI tools Bitrise and Danger, we have built our CI/CD environment for linting in response to pull requests and for internally distributing the app with Firebase App Distribution.
These warnings are posted as comments apart from linting
Introducing our example of development
To offer you a snapshot of how we typically develop our products, this section introduces the process through which we implemented a functionality called “payment details.”
The CS team catches business owners’ requests
Through daily and direct interactions with business owners (customers), our Customer Success (CS) team members accumulate identified problems and requests from business owners. This is in turn reflected in elaborate presentation materials to inform other hey members how solving the issues would offer business owners a more convenient user experience.
List of requests, managed by CS team
Improvement plan proposed based on business owners’ requests
Consulting with all development team members
All development team members—the product manager (PM), designer, back-end engineer, iOS engineer, Android engineer, and quality assurance (QA) engineer—discuss together to translate the CS team’s presentation into implemented features of the app.
First, the PM compiles key elements and, in response, the designer draws up a draft plan. Then, based on the draft plan, people from each of the development team’s job functions gather to talk about the feasibility and pros and cons of implementing the features.
Materials used when members discuss which feature to implement
Through this discussion, for “payment details” the development team decided to list detailed information after considering that:
- the CS team requested to add a link to online payment details
- previously the app showed a simple list of minimum necessary information
- from the business owners’ standpoint, the app currently does not provide minimum necessary information
Implementation
Now we move on to the implementation step. Challenges and questions that need to be resolved arise when you actually start working, whatever development endeavor you may be involved with. To quickly solve such hurdles upon facing them, members at hey communicate smoothly and cross-functionally.
Question from Android engineer to designer
Question from iOS engineer to front-end engineer
Once we solve challenges, eliminate questions, and finish implementation, we create a pull request on GitHub for review. Features implemented through a general review process are merged into the product code.
QA and release
As we mentioned earlier, there’s a QA engineer on the STORES Payment team who takes part from the feature requirement consulting phase and ensures that the app—containing the feature to be released—is of proper quality.
We design QA test cases by analyzing the to-be-released functionality. This analysis and the designed test cases are both reviewed by the mobile engineer and QA engineer.
Having the QA engineer is reassuring enough for our development process. But we can further raise this level of reassurance with the mobile engineer also participating from the analysis and design phases. STORES Payment involves monetary exchange, so we use as many sets of eyes available to make checks and in turn prevent major issues.
The app—after having its quality guaranteed through these processes—then is delivered to business owners through the Google Play store or the App Store to support their businesses.
Difficulty in payment services and efforts made for onboarding
Payment processes involve a lot of technical terms. To the uninitiated, hey’s internal conversations may be difficult to understand.
This section shares how we deal with payment domain knowledge revolving around STORES Payment, and the steps we take for onboarding.
Familiarizing with knowledge on payment
As we mentioned, credit card payment entails a great deal of specialized terminology and its standard specification contains an immense amount of information. There’s even another separate specification for card reader terminals too, to which mobile engineers frequently refer.
We developed an internal document for information often referenced in the development process, in turn bettering accessibility to necessary information. As shared and general knowledge of payment, our development team also offers a glossary document—open to non-development team members—that explains various payment-related terms.
For projects involving payment, we make various efforts to increase opportunities for new hires to get exposed to domain knowledge. Examples of such steps include in-team meetings for sharing information or workshops held across teams.
Onboarding articles
The STORES Payment development team hopes that new members show their value by getting used to the team’s environment as soon as possible. There’s high awareness of onboarding across the company, and diverse documents and systems are available on onboarding.
For example, for new members, hey develops dedicated onboarding articles. The articles have links to information necessary for development, such as how to make an account for tools that members would use or code repository links; they serve as a hub from which members can access various kinds of information.
Article for Yamamoto, one of the authors of this DroidKaigi article
We link the onboarding article to some of the payment-related documents mentioned earlier and ask new members to read them soon after joining hey. We hope that getting a general idea of payment terms and specifications will prove beneficial when the new hires face a challenge down the road.
Efforts made for smooth entry into Android app development
On an Android app development front, we offer abundant documents about architecture and some special implementation processes, set aside time to examine app design from a broader perspective through peer reviews with existing members, and provide an environment where members can engage in pair programming or consult about implementation without any hesitation.
We also arrange some time for daily one-on-one interactions between the team leader and new members for a month after the member joins hey. This is not only for members to discuss challenges or problems but is also intended for them to communicate each day through small talk and other exchanges.
In conclusion
This article introduced to you STORES Payment by showing the current situation and an example of functionality development surrounding our Android app. More areas need to be improved to render STORES Payment a better product, such as:
- eliminating Broadcast-based implementation
- introducing Jetpack Compose
- working to enhance quality and development speed by, among other efforts, automating UI tests
To speedily deal with these topics and deliver our app to business owners, we need more members. If you are interested, we encourage you to apply.
About the authors
Naoto Uwaseki/@nseki
I joined Coiney about three years ago, but the company morphed into hey before I knew it. I’m usually listening to music on my headphones while writing code or reading a specification (in English) with an intense expression on my face. At the moment, Uwaseki is studying Haskell on the side.
Kei Yamamoto/@day_craft
I am an Android app engineer living with my wife, two sons, and a cat. I joined a small-sized IT firm straight out of university but eventually left because despite my hope to become a programmer, I could only receive jobs as a tester. While living off my savings, I learned Android app development skills on my own and joined hey after working at another company. A current challenge I’m facing is how to make time to study while bringing up my children.
