Building the Best In Class Partner Payout experience in the Gig Economy

By — Shubham Pandey (Engineer, Payouts & Accounting Team)

At Urban Company, we proudly believe that our partner payout experience is best in class in the Gig economy. Our Partners (our service professionals) receive their payments every second working day (on Monday, Wednesday and Friday). Moreover, the payout happens without fail before the end of day and never spills over to the next day. This minimizes anxiety in our partner community and ensures that our partners are never short of cash which is rightfully theirs.

In this blog we go through the flow and evolution of UrbanCompany’s payout systems and address some key enhancements and design choices which enable such an amazing partner experience.

Scale of Payouts

To appreciate why the above payout experience is not trivial, it is important to understand our scale.

• We do payouts every Monday, Wednesday and Friday
• In the 2 days between each payout, we process hundreds of thousands of service requests
• These requests and hence ultimately payouts are distributed across tens of thousands of partners
• These payouts need to happen to partners across multiple countries: India, Singapore, Dubai and Saudi Arabia

Flow

Let’s understand the systems and processes involved in the payout. The entire payout flow can be divided into the below three steps:

1. Transaction Creation

Settlement system listens to different payout related kafka events and then pulls the context from different microservices and computes the additions and deductions to be added for settlement.

2. Reconciliation​​

Each Mon-Wed-Fri, a workflow picks all the transactions for all partners in the time period and does a partner level reconciliation.

The steps involved in the reconciliation process are:

1. Aggregation: In this step we create a payout entity on a partner level which is an aggregation of all the individual additions (request payouts, incentives) and deductions (commission, taxes, credit recharges, etc.).
2. Validation: In this step we validate the sanctity of the data and whether from the payment gateway perspective, we’re supposed to receive all the money we’re paying out.

3. Settlement

Once the payout entities are created, a workflow picks all the payouts, does the pre-processing and starts the fund transfer process using the bank service.

Bottlenecks

This design choice of listening realtime to the stream of business events from UC and computing the additions and deductions real time (vs through batched crons) ensures that transactions are always available within settlement service for payouts whenever the payout had to happen.

However, the elaborate and extensive reconciliation, aggregation and eventual transfer with concurrency restrictions from our Banking partners meant that payouts did spillover to the next day impacting partner experience.

Goal

We set a goal to optimise the TAT to get 100% partners to receive payouts on the same day

Optimisations

Listing down the optimisations which gave us a lift of 5 hours for 99 percentile transfers while also achieving the goal of 100% same day payouts:

1. Auto validation: Earlier our finance team used to validate each payout by manually downloading PG reports and then comparing against the transaction ids of the payouts going out to do a money-in/money-out recon.

To automate the validation process we built a custom PG reports handler where we defined report schema against each payment gateway. The module read relevant emails from PGs, downloaded reports and parsed them to create transactions used for further validation. The output of this validation is a recon report which flags any request where there’s a discrepancy between money-in vs money-out. Doing this reduced the time taken for this process from 4 hours to 20 mins.

2. Automate pre-processing: We automated all business pre-processing like marking payouts with unapproved bank accounts on-hold, checking for duplicates, fraudulent activity flagging etc. These features reduced the time taken by this process from 2 hours to 30 mins.

3. Optimise payout status update process: Earlier we used to let the bank transfer process finish before we started the status check process via a workflow. The problem with the approach was that there was no time-based prioritisation of transfers to check the status for. We use to randomly batch transfers in an hourly workflow. When we dived deeper we realised that the efficacy of status checks increase when we ordered the transactions by the time since initiation of transfers. To enable this prioritisation we started initiating callbacks with 60 mins delay trigger which led to us successfully updating correct status of all bank transfers within the same day.

4. Automate Retrial: The retrial process was earlier manual. We had to wait for status checks to complete before Finance team would retry failures manually. We automated the retry mechanism by integrating the retry APIs of our banking partners to attempt retries as soon as we received a failure from the bank which resulted in 0 next-day retries and more accurate statuses of payouts in the system. This is how the new status update and retrial flow looks like:

Now the whole process is automated and needs zero manual intervention. Starting from additions and deduction transactions getting created, to payouts being created, to getting transferred, to getting retried in cases of failure.

Results

• Partners receiving payouts with a delay of 24 hours went from 2% to 0.
• 99% of partners started receiving payouts before 1 pm instead of 6 pm.
• Complete elimination of all manual processes.
• 40% reduction in payout delay related helpcenter contact rate.

Before

After

What’s next

As we write this blog, we continue to work on improving the process. The reader would’ve noticed how the recon and validation process is still latent. We believe we can bring this recon time down from 6 hours to 30 mins by working on concurrency and horizontal scaling. Post these changes we should be able to make our payouts reach the partners early morning while they embark to do the first job of the day on Urban Company.

The team behind partner payouts

Devanshi Bansal, Rishabh Aggarwal

About the Author

Shubham Pandey has been working in Urban Company for more than 6 years and has helped design and build most money related systems of UC starting from payouts and wallets, to taxation and accounting. In his free time you’ll find him reading books on his kindle or researching Web 3.0 technologies.

Sounds like fun?
If you enjoyed this blog post, please clap 👏(as many times as you like) and follow us (@UC Blogger). Help us build a community by sharing on your favourite social networks (Twitter, LinkedIn, Facebook, etc).

If you are interested in finding out about opportunities, visit us at http://careers.urbancompany.com