You are on page 1of 8
INTEGRATING PAYMENTS or seca Sse Sonny nonce WITH REACT NATIVE ON ‘cert=senevosscwe ny APP (BLACK) ENGINEERING cogu hari s © ayer ‘Aekcossng te Goat an Cre Gap oy lay Nagel HOW WE BUILT A CUSTOM CHECKOUT EXPERIENCE ON TOP OF OUR PAYMENT PARTNER SDK, COMPLETELY IN REACT NATIVE. A‘ Cleat we build our apps using teacl=native (a cross-platform app development framework) and Con the same tine, we have built cur mutual fund app, Black The app primarily has two modules ITR and Mutual Funds purchase. On the mutual fund's side, although we support gor AMCs, our Payment experience was not great, so we decided to improve the checkout and payment experience for our users. We already had checkout and payment flow on our app, but we were comaletely relying on our external payment partner. The probiem with this approach was that we were not in control of UI/UX for eg, default payment options, previously saved information, color scheme, error handling ete. ‘The High level requirements are mentioned below, 2. Display and handle multiple Payment modes (UPI/Net Banking/Pay later) 2. Have configurable error handling without App release or Codio-Push 3. Handle downtimes of Banks, UPI handles, and UPIapps 4 Error reporting and alerts from app to our internal channels 5, Hanale payments from multiple bank accounts of users to adhere to TPVIa compliance requirement for mutual fund apps) 6, Seamlessly add a new mode of payment without having to modify much of previous code, Subscibe a 18 UI/UX \With the design team coming up with the UX, it was time for engineering to kick off the work. Before directly diving into the Code, States, and Hooks, let's have a look at the design prototypes, © wr ‘The screen primarily ists various payment modes, and on selecting a particular mode the actions and details of that mode are shown by expanding the component, sort ofa drop-down experience. ‘There is also a popup to select a bank account against each payment methad and Finally. an error sereen needs to be configured based on various error codes. CODE DESIGN AND ARCHITECTURE Lets go through the various methods and approaches used, to achieve the design and simultaneously meet the initial guidelines that were laid out. the following sections. COMPONENTIZATION As we all know componentization is one of the basic principles of gat. which makes it one of the proferred frameworks for front-end design. So the first task here would be to divide the whole page into small components that can act independently So at first sight we would roughly componentize the page as, + Component for each payment method (UPI app, UPI collect, and Netbanking) + Bank popup component + Suggestion input component (for UPI collection) But the problem wit the approach certain parts of code geiting repeated, 's thal. in each payment method component there would be + Header part and bank component + Logie to expand and shrink the method's contents <€ Choose payment mode Investment Amount 5,000 © uPipayment @ icici 4567 v Please use the same verified bank for the payment. Google Pay PhonePe BHIM PhonePe Proceed to payment. ©. Enter UPIID O Net banking O Pay later with mandate We can think of putting the header Ul as a separate component and including itn each method's component, uymentmahad components ented wit by ss vow BBut stil. the logic of expanding/shrink will be duplicated in each component which will be not a good scalable solution, React native allows us to pass components as children, hence we can use this approach So the entire payment componer into parent and child components, can be decoupled The parent component will take care of expanding, shrinking, bank account selection and each chile component will take care only of the particular payment method's UI, validation methods, etc. Hence the final code looks as follows, sss connec hated wh by chu ewe By this approach we have decoupled the logie and UI, hence in the future adding a new method ‘would be very much simple — add a new component for payment and wrap it up with this parent, component. FEW MORE DE-COUPLING \We are relying on our payment partners currently for fetching the UPI apps installed on the user's device. Hence in the UPI app section, the UPI app list has also been decoupled and designed as a separate component. which fetches and displays the list of UPI apps. By this approach, in future. If ‘any changes occur in the payment partner's SDK, the change would be required only in this component and the core payment component would be unaffected. This UPI apps component also encapsulates the logic of preferential sorting where few apps are shown on preference. LIFTING THE ‘STATE’ UP AND USE OF CONTEXT API React recommends lifting the state up to a common ancestor so that various components can share the common data. Here also on the payments page, we have lots of states and data that ‘manage various UI components, For ag, selected payment mathod, selected bank account, UPI suggestions, downtime data, last successful payment data, ete. Passing these values to individual components would become unmanageable and willincrease the code lines on the parent page. To overcome this we would be using the context API provided by react-native that allows to share common data across components. ‘nesocheteawih W by cd eww stsuecesfulPayent tsugestons| sll =| =e ool ‘eatsosad th by itd oo By this approach, each component will de-structure and take the required information internally and there would be no dependency on the parent page to pass the required props for components individually. The function of the payments page will only be to intate the transaction on the payment partners. side, based on the selected payment method, and handle success and error cases, ERROR HANDLING A laid out initially we wanted to have a configurable error handling experience, without app release or code-push. To achieve this we have hasted a configuration file in our internal system to configure the error experience against each error code from SDK Let's see the structure of JSON to have a better understanding, sonore Pot awe ‘ > » mo» ae << > srrcomgieon torah @ by un veo ‘As we can see against each code, there are flelds that describe the error message to be shown ‘along with but page with the message * Your bank accounts are invalid." message and 2 buttons which take the sero add bank and profile pages respectively, mn labels andl actions. For eg: (or bank_account_snvalid code the user would see a But fetching this file inapp and finding the error codes and info would be an inefficient way of doing things. Here we have leveraged our GraphQL server infra to do this piece of work. Every time: there is an error from SDK. the app queries out the Graph@L server for the action, the server in turn responds only with the piece of JSON against the error scenario. ERROR REPORTING By the above approach, we were also able lo handle error reporting to our internal channels, Once the app reports an error to the Graph server, the server pushes some severe error scenarios ‘along with user and session info, to aur internal channels for manual intervention. This etror reporting. without GraphOl. server, would have been a dificult task. The errors are alse logged and kept for future reference or . 718 BENEFITS ‘This coding approach has helped us alot in testing the release of the payment as we could test the individual components thoroughly and release it bug-tree. The approach also made sure that there were no severe hiccups faced while scaling up our new payments page to our entire user base. Later when we added a new custom payment option of Pay Later” nol even a single existing code ‘was touched to accommodate the new method. TAKING IT TO NEXT LEVEL 7 We are constantly in touch with our other payme to arrive ata solution where this page can be scaled to support payments through other partners as woll, ‘Adding a configuration against each payment method and each bank for enabling and disabling the method, as it has come to our notice some of the banks do net support the compliance (verification of user identity) against certain methods. capaho s Y ‘ BRIDGING PROFITABILITY AND WORKING CAPITAL NEEDS WITH “ee DYNAMIC DISCOUNTING THE ERA OF ALTERNATIVE LENDING Lean aLoc © 2023, fo

You might also like