{"id":28344,"date":"2026-11-06T17:33:08","date_gmt":"2026-11-06T12:03:08","guid":{"rendered":"https:\/\/razorpay.com\/blog\/?p=28344"},"modified":"2026-11-06T17:33:08","modified_gmt":"2026-11-06T12:03:08","slug":"payment-solutions-gig-platforms-india","status":"publish","type":"post","link":"https:\/\/razorpay.com\/blog\/payment-solutions-gig-platforms-india\/","title":{"rendered":"Payment Solutions for Gig Platforms in India: Instant Partner Payouts and Commission Splits"},"content":{"rendered":"<p>Payment solutions for gig platforms in India combine customer collections, commission allocation, partner disbursements and reconciliation. When a home-service job ends, the worker needs a clear earnings statement and bank credit, while the platform needs its commission recorded against the same booking.<\/p>\n<p>Manual spreadsheets and unclear payment statuses make that harder as volumes grow. The key question is how to collect a customer payment, retain the agreed commission and pay the worker without losing track of the funds. An instant payout and settlement of a customer collection are separate events, with different funding and timing requirements.<\/p>\n<p>This guide explains a Rs 1,000 commission example, two alternative funds flows and the controls needed for failures and refunds. Razorpay Payment Gateway supports collections, Route supports allocation among Linked Accounts, and RazorpayX supports payouts from an appropriately funded business account. Choose the combination that fits your approved business model and product eligibility.<\/p>\n<div class=\"key-takeaways\" style=\"background-color: #e8f1ff; border-left: 4px solid #2563eb; border-radius: 8px; padding: 24px; margin: 24px 0; color: #172b4d;\">\n<h2 style=\"margin-top: 0; margin-bottom: 16px; color: #123c7d;\">Key Takeaways<\/h2>\n<ul style=\"margin: 0; padding-left: 22px; line-height: 1.7;\">\n<li style=\"margin-bottom: 12px;\"><strong>Instant partner payouts in India:<\/strong> <a href=\"https:\/\/razorpay.com\/x\/payouts\/\">RazorpayX Payouts<\/a> lets gig platforms send available business funds to freelance workers and partners. IMPS and supported UPI configurations offer immediate, round-the-clock processing, subject to activation, sufficient balance, transaction limits and bank availability. Confirm the final payout status before showing a worker as paid.<\/li>\n<li style=\"margin-bottom: 12px;\"><strong>Commission splits for gig platforms:<\/strong> <a href=\"https:\/\/razorpay.com\/route\/\">Razorpay Route<\/a> supports splitting customer payments among multiple Linked Accounts. Your platform calculates the agreed commission and each partner&#8217;s share, then creates the relevant transfers. A split or transfer does not itself guarantee instant bank credit; Linked Account settlement follows its configured schedule.<\/li>\n<li style=\"margin-bottom: 12px;\"><strong>Customer collections and payout funding:<\/strong> <a href=\"https:\/\/razorpay.com\/payment-gateway\/\">Razorpay Payment Gateway<\/a> handles customer collections. An unsettled collection is not automatically available in a separate payout account. Choose Route settlement or a funded RazorpayX payout according to your approved business model, and prevent the same worker share from being paid twice.<\/li>\n<li style=\"margin-bottom: 12px;\"><strong>Partner onboarding:<\/strong> Route uses Linked Accounts; RazorpayX uses Contacts and Fund Accounts. These are different product records. Check eligibility, verification and account activation separately, and allow for the documented 24-hour cooling period before transfers to a new Route Linked Account.<\/li>\n<li style=\"margin-bottom: 12px;\"><strong>Payment control and reconciliation:<\/strong> Link each worker&#8217;s earnings obligation to its job, commission and transaction IDs. Handle pending, queued, processing and failed states explicitly. Account validation and an accepted API request do not guarantee that the beneficiary has received the money.<\/li>\n<li style=\"margin-bottom: 12px;\"><strong>Costs and refund recovery:<\/strong> Confirm collection, split-transfer and payout charges for your chosen flow. Plan customer refunds and recovery of worker earnings separately. Route reversals depend on the required balance and refund scenario; a completed worker bank payout should not be treated as automatically recoverable.<\/li>\n<\/ul>\n<\/div>\n<h2>What Payment Features Does an Indian Gig Platform Need?<\/h2>\n<p>An Indian gig platform needs a way to accept customer payments, calculate its commission, assign each worker&#8217;s earnings, send partner payments and reconcile the result. Payment splitting controls how a collection is allocated. A payout service moves available business funds to a worker&#8217;s beneficiary account. The required combination depends on the platform&#8217;s business model.<\/p>\n<h3>Customer Payments, Worker Earnings and Partner Disbursements<\/h3>\n<p>The customer&#8217;s payment and the platform&#8217;s obligation to pay a worker are two separate things. The customer pays for a service. The platform owes a worker an agreed share of that value, often after applying commission, incentives and deductions.<\/p>\n<p>Different business triggers produce that obligation. A delivery task creates a per-trip earning the moment the drop is confirmed. A home-service booking creates an obligation once the job is marked complete. A freelance milestone creates one when the client approves deliverables.<\/p>\n<p>This guide is written for the platform operator, not for a solo freelancer who only needs to accept client payments. It also keeps cross-border collections, international worker payments, payroll classification and worker-credit products outside its detailed scope.<\/p>\n<h3>Why a Checkout Gateway Alone May Not Answer the Whole Requirement<\/h3>\n<p>A checkout gateway accepts money from customers. It does not, by itself, hold beneficiary records for thousands of riders, apply your commission logic, enforce approval rules, confirm that disbursement funds are available or expose payout-level status handling.<\/p>\n<p>Those are the capabilities that turn a collection into a paid worker. Product selection should follow your approved funds flow rather than the other way around. Not every gig platform needs all three Razorpay products.<\/p>\n<blockquote><p><strong>DID YOU KNOW:<\/strong> Razorpay Route documentation describes one-to-many disbursements for marketplaces and platforms, where a single incoming payment is distributed to multiple recipients. You can review <a href=\"https:\/\/razorpay.com\/docs\/payments\/route\/?preferred-country=IN\">Route&#8217;s documented purpose and eligibility<\/a> before designing your flow.<\/p><\/blockquote>\n<h2>How Do Instant Partner Payouts Work in India?<\/h2>\n<p>RazorpayX partner payouts are funded from the business account used for disbursements. The platform adds funds, creates the worker&#8217;s Contact and Fund Account, and initiates the payout after its business checks. IMPS and supported UPI configurations offer immediate processing around the clock, subject to activation, available balance, limits and bank availability. Customer-collection settlement follows its own schedule.<\/p>\n<h3>Instant Payouts and Collection Settlements Have Different Timelines<\/h3>\n<p>RazorpayX debits the payout amount, fees and tax from the business account used for disbursements. A payout can therefore be initiated from available funds without treating an unsettled customer collection as immediately available cash. Route Linked Account settlements follow their configured schedule, so confirm that schedule separately.<\/p>\n<p>This has a direct working-capital consequence. If you promise same-day worker payments while related collections settle later, the platform is financing that gap from its own funds. That is a funding decision, not just a feature choice.<\/p>\n<p>Do not assume T+2 is a universal default. <a href=\"https:\/\/razorpay.com\/docs\/payments\/route\/schedule-settlement\">Route documentation<\/a> uses T+2 as an illustration: new Linked Accounts inherit the main account&#8217;s settlement schedule, and their schedule can equal or exceed the main account&#8217;s. Separately, <a href=\"https:\/\/razorpay.com\/docs\/x\/payouts\">RazorpayX payout documentation<\/a> states that the payout amount, fees and tax are deducted from the RazorpayX account balance. Plan these settlement and funding requirements separately.<\/p>\n<h3>UPI, IMPS, NEFT and RTGS for Partner Payments<\/h3>\n<p>These are documented product conditions checked on 6 November 2026, not universal limits for every Indian payment product. Confirm your enabled account type and partner bank before implementation.<\/p>\n<table>\n<thead>\n<tr>\n<th scope=\"col\">Mode<\/th>\n<th scope=\"col\">Useful role<\/th>\n<th scope=\"col\">Condition to explain<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>IMPS<\/td>\n<td>Prompt bank-account payouts, including small worker earnings<\/td>\n<td>RazorpayX documentation lists immediate, round-the-clock processing for bank-account payouts up to Rs 5 lakh per transaction. Confirm enabled account, bank availability and the final payout status.<\/td>\n<\/tr>\n<tr>\n<td>UPI<\/td>\n<td>Payouts to an eligible worker&#8217;s VPA<\/td>\n<td>For Current Accounts, documentation lists UPI-to-VPA payouts for RBL and Yes Bank accounts, below Rs 1 lakh per transaction, with immediate processing around the clock. Confirm current enablement and operational conditions.<\/td>\n<\/tr>\n<tr>\n<td>NEFT<\/td>\n<td>Bank-account transfers where the processing window fits the requirement<\/td>\n<td><a href=\"https:\/\/www.rbi.org.in\/Scripts\/FAQView.aspx?Id=60\" rel=\"nofollow noopener\" target=\"_blank\">NEFT operates around the clock at network level<\/a>. RazorpayX payout processing windows depend on the enabled bank and account configuration; confirm these before promising a worker-payment time.<\/td>\n<\/tr>\n<tr>\n<td>RTGS<\/td>\n<td>Larger-value consolidated transfers<\/td>\n<td>RazorpayX documentation describes payouts above Rs 2 lakh and bank-specific processing windows. Confirm the enabled configuration; this is usually unnecessary for a small individual gig payment.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Check the current <a href=\"https:\/\/razorpay.com\/docs\/x\/payouts\">RazorpayX payout modes and processing conditions<\/a> against your enabled account before choosing a rail.<\/p>\n<p>Rail choice matters more than it looks. IMPS remains the documented 24&#215;7 bank-account payout rail with the higher per-transaction ceiling, which is relevant for consolidated weekly or incentive payments that exceed the UPI limit.<\/p>\n<blockquote><p><strong>PRO-TIP:<\/strong> Design the worker&#8217;s payment screen around confirmed status updates. A request accepted for processing is not a promise that the worker&#8217;s bank has already received the funds.<\/p><\/blockquote>\n<h2>How Do Commission Splits Work for Gig Platforms?<\/h2>\n<p>Commission splitting allocates a customer&#8217;s payment between the platform and the people delivering the service. With Razorpay Route, a platform can configure transfers to Linked Accounts through orders, payments or direct transfers. Its application determines the relevant amounts and commission rules. Allocation and transfer processing must be distinguished from the Linked Account&#8217;s bank-settlement timing.<\/p>\n<h3>A Rs 1,000 Booking With a 15% Platform Commission<\/h3>\n<p>The figures below are assumed business amounts for illustration only. They are not Razorpay fees or a customer case study. The example deliberately excludes gateway charges, Route transfer fees, payout fees, GST, TDS and any applicable state welfare-related deductions.<\/p>\n<table>\n<thead>\n<tr>\n<th>Illustrative ledger entry<\/th>\n<th>Calculation<\/th>\n<th>Amount<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Customer payment collected<\/td>\n<td>Booking value<\/td>\n<td>Rs 1,000<\/td>\n<\/tr>\n<tr>\n<td>Platform commission<\/td>\n<td>15% of Rs 1,000<\/td>\n<td>Rs 150<\/td>\n<\/tr>\n<tr>\n<td>Worker earnings before fees\/tax<\/td>\n<td>Rs 1,000 less Rs 150<\/td>\n<td>Rs 850<\/td>\n<\/tr>\n<tr>\n<td>Total allocated<\/td>\n<td>Platform share plus worker share<\/td>\n<td>Rs 1,000<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>In a Route design, the platform retains its agreed share while the worker&#8217;s share is assigned to the appropriate Linked Account. The commission logic itself lives in your platform application. There is no universal no-code rules engine that decides your commercial terms for you.<\/p>\n<p>A second worker or service partner can receive an additional allocation where the approved flow supports it. Keep the sum of all allocations within the funds actually collected.<\/p>\n<p>Remember that transfer creation after payment capture and eventual bank settlement are separate stages. Creating the transfer records who is entitled to what. Settlement is when that entitlement reaches a bank account.<\/p>\n<h3>Per-Job, Multi-Partner and Milestone-Based Earnings<\/h3>\n<p>Per-job earnings are the simplest case: calculate the approved worker share once the task is marked complete and the payment is captured.<\/p>\n<p>Multi-partner bookings need separate calculations for each approved recipient, such as a technician and a supervising partner on the same service visit. Record each share against the same job ID.<\/p>\n<p>For milestone-based work, calculate the eligible share under the business agreement. Use supported settlement holds to defer settlement until the milestone is approved; release still follows the applicable settlement rules.<\/p>\n<p>A hold is not a universally available escrow service, and splitting a payment does not resolve the platform&#8217;s tax obligations.<\/p>\n<blockquote><p><strong>DID YOU KNOW:<\/strong> Settlement of a Route transfer can be put on hold indefinitely or until a specified timestamp, after which it settles according to the applicable account schedule. The <a href=\"https:\/\/razorpay.com\/docs\/api\/payments\/route\/modify-settlement-hold\/\">settlement hold documentation<\/a> gives a worked example. A hold is a timing control, not a guarantee of immediate withdrawal once it is released.<\/p><\/blockquote>\n<h2>How Razorpay Supports Collections, Splits and Partner Payouts<\/h2>\n<p>Razorpay offers separate capabilities for a gig platform&#8217;s money movement: Payment Gateway for customer collections, Route for allocating collections among Linked Accounts, and RazorpayX for disbursements from a funded business account. Confirm product eligibility and the intended flow before combining them, including who funds each payment and how duplicate disbursements are prevented.<\/p>\n<h3>Customer Collections With Razorpay Payment Gateway<\/h3>\n<p><a href=\"https:\/\/razorpay.com\/payment-gateway\/\">Razorpay Payment Gateway<\/a> handles the customer side of the transaction through supported methods including UPI, cards and netbanking.<\/p>\n<p>In a customer-funded payment flow, confirm the payment and capture state before allocating that collection. Reconcile unclear statuses before treating the funds as available. Business-funded worker earnings follow their own approval and funding checks.<\/p>\n<p>A confirmed customer payment is not the same as immediate cash availability in a separate payout account.<\/p>\n<h3>Commission Allocation With Razorpay Route<\/h3>\n<p><a href=\"https:\/\/razorpay.com\/route\/\">Razorpay Route<\/a> provides Linked Accounts, payment transfers, settlement holds, reversals and reconciliation reporting.<\/p>\n<p><strong>Flow A:<\/strong> customer collection, confirmed capture, approved commission calculation, Route allocation and transfer, then Linked Account settlement under its configured schedule.<\/p>\n<p>Eligibility comes first. <a href=\"https:\/\/razorpay.com\/docs\/payments\/route?preferred-country=IN\">Razorpay&#8217;s Route documentation<\/a> sets out turnover and payer-payee transparency requirements for product access. The party listed as a Linked Account must directly interface with customers to provide goods or services. Confirm that your proposed gig-platform use case meets the applicable requirements before designing transfers.<\/p>\n<p>Linked Account setup is also a prerequisite. Current documentation specifies a <a href=\"https:\/\/razorpay.com\/docs\/payments\/route\/transfer-funds-to-linked-accounts\/?preferred-country=IN\">24-hour cooling period for new Linked Accounts<\/a> before transfers can be initiated, which matters if you onboard partners daily.<\/p>\n<p>This route can pay the worker through Linked Account settlement. It does not necessarily need another payout for that same share.<\/p>\n<h3>Business-Funded Worker Payments With RazorpayX<\/h3>\n<p><a href=\"https:\/\/razorpay.com\/x\/payouts\/\">RazorpayX Payouts<\/a> uses Contact and Fund Account records, funded disbursements, bulk and API operations, and status notifications.<\/p>\n<p><strong>Flow B:<\/strong> record the worker&#8217;s approved earnings, confirm funds in the authorised business account, initiate the RazorpayX payout, then reconcile its status back to the earnings ledger.<\/p>\n<p>Route Linked Accounts and RazorpayX <a href=\"https:\/\/razorpay.com\/docs\/x\/contacts?preferred-country=IN\">Contacts<\/a> and <a href=\"https:\/\/razorpay.com\/docs\/x\/fund-accounts\/\">Fund Accounts<\/a> are different product entities with different onboarding behaviour. Do not treat Flow A followed by Flow B as a default sequence. A combined design needs product and compliance review plus an explicit funding and reconciliation plan.<\/p>\n<figure style=\"margin: 24px 0;\"><figcaption><strong>Two alternative funds flows for a gig platform<\/strong><\/figcaption><div style=\"border: 1px solid #cbd5e1; border-radius: 8px; padding: 16px; margin: 12px 0; background: #f8fafc;\">\n<p><strong>Flow A: Customer-funded allocation through Route<\/strong><\/p>\n<ol>\n<li>Confirm collection and payment capture.<\/li>\n<li>Calculate the platform commission and partner shares.<\/li>\n<li>Create the appropriate Route transfers to Linked Accounts.<\/li>\n<li>Reconcile Linked Account settlement under the configured schedule.<\/li>\n<\/ol>\n<\/div>\n<div style=\"border: 1px solid #cbd5e1; border-radius: 8px; padding: 16px; margin: 12px 0; background: #f8fafc;\">\n<p><strong>Flow B: Business-funded partner payout through RazorpayX<\/strong><\/p>\n<ol>\n<li>Approve the worker&#8217;s earnings obligation.<\/li>\n<li>Confirm available funds in the authorised business account.<\/li>\n<li>Initiate the RazorpayX payout to the worker&#8217;s Fund Account.<\/li>\n<li>Reconcile the payout status and confirmed beneficiary credit.<\/li>\n<\/ol>\n<\/div>\n<p><strong>These are alternative designs.<\/strong> Do not pay the same earnings through both flows. Any combined design needs an approved funding and reconciliation plan.<\/figure>\n<blockquote><p><strong>PRO-TIP:<\/strong> Use one internal earnings-obligation ID per payable worker share, and link the actual product transaction IDs to it. This is a recommended platform control, not a claim that the two products share one automatic ledger.<\/p><\/blockquote>\n<h2>Which Payment Flow Fits Your Gig Business Model?<\/h2>\n<p>Select a gig-platform payment flow according to how the worker earns money and how the platform funds that obligation. A customer-funded marketplace may need transaction-level allocation and settlement controls. A platform paying approved shifts, incentives or tasks from business funds may need a payout workflow. Some businesses need both, with an approved separation of obligations.<\/p>\n<h3>Delivery and Mobility Partner Payments<\/h3>\n<p>Earnings here are calculated per task or at end of shift, often with incentives layered on top. Available balance and clear payment status matter because volumes are high and individual amounts are small. The platform supplies the job-completion and earnings logic. A payout API does not independently validate that a delivery happened or a shift was worked.<\/p>\n<h3>Home Services and Freelance Marketplaces<\/h3>\n<p>These flows involve commission allocation, sometimes multiple service providers on one booking, and payment release after the agreed service or milestone. Keep direct provider settlement separate from business-funded payouts in your design documentation. Also keep domestic payout guidance separate from international client invoicing and overseas worker disbursement.<\/p>\n<h3>Staffing and Contractor Networks<\/h3>\n<p>Approved work records drive batch payments here, usually on a weekly or fortnightly cycle, with reconciliation needed at individual payment level rather than batch level. Independent-contractor earnings are not automatically employee payroll. Confirm classification and withholding treatment with your own advisors.<\/p>\n<h2>How to Set Up Partner Payments Without Losing Payment Control<\/h2>\n<p>Start with the platform&#8217;s approved funds flow, then complete business onboarding, create the appropriate recipient records, confirm funds and apply earnings rules. Test the full payment lifecycle, including errors, before going live. A successful account-validation result does not guarantee every future payout succeeds.<\/p>\n<ol>\n<li><strong>Define the obligation.<\/strong> Specify the customer payment, platform commission, worker share, payment trigger and the party responsible for refunds.<\/li>\n<li><strong>Approve the architecture.<\/strong> Confirm whether Route settlement, RazorpayX payouts or a reviewed combination fits the business model. Check eligibility and payer-payee requirements with the relevant team.<\/li>\n<li><strong>Complete business onboarding.<\/strong> Finish account activation, applicable KYC and product approvals. Do not assume Route and RazorpayX share identical access requirements.<\/li>\n<li><strong>Create recipient records.<\/strong> Use Route Linked Accounts for that flow, or RazorpayX Contacts and Fund Accounts for payouts. Allow for the documented Route cooling period where relevant.<\/li>\n<li><strong>Validate recipient details.<\/strong> Use the applicable <a href=\"https:\/\/razorpay.com\/x\/bank-account-verification\/\">bank-account and UPI verification capability<\/a>, confirming availability for your account type. Keep verification distinct from identity checks and activation, and do not promise workers a universal completion time.<\/li>\n<li><strong>Prepare funds and commission rules.<\/strong> Record the commission basis, rounding and allowed deductions. Confirm the payout account holds sufficient funds for the payout and applicable charges.<\/li>\n<li><strong>Implement safe payment handling.<\/strong> Keep secrets server-side, validate webhooks and use the required payout idempotency mechanism, which has been <a href=\"https:\/\/razorpay.com\/docs\/api\/x\/payouts\/\">mandatory for all payout requests since 15 March 2025<\/a>. Reuse the same key for retries of the same unresolved payout; do not create a second payment on a network timeout.<\/li>\n<li><strong>Test and reconcile.<\/strong> Test successful, pending, low-balance, rejected and failed cases, plus refund and recovery handling. Reconcile a small authorised pilot before scaling.<\/li>\n<\/ol>\n<p>Before launch, confirm current Route eligibility for your business, including the applicable financial-year turnover assessment and payer-payee declaration. Product approval applies to the proposed use case; do not assume every platform or recipient qualifies.<\/p>\n<h2>What Happens When a Worker Payout Fails or a Customer Requests a Refund?<\/h2>\n<p>Track payout status before deciding what to do next. A queued payout may need funding, a pending payout may need approval, and a processing payout may still be awaiting a bank result. Customer refunds and worker-payment recovery are separate operations. Route supports transfer reversals subject to available Linked Account balance; this does not mean every completed payout can be recalled.<\/p>\n<h3>Pending, Queued and Processing Are Different States<\/h3>\n<ul>\n<li><strong>Pending:<\/strong> an applicable approval workflow has not completed.<\/li>\n<li><strong>Queued:<\/strong> the relevant account lacks sufficient balance. Razorpay documents that <a href=\"https:\/\/razorpay.com\/docs\/x\/payouts\/queued?preferred-country=IN\">queued payouts are processed first-in-first-out<\/a>, attempting the next payout if one cannot be funded. Funding the account may allow processing.<\/li>\n<li><strong>Processing:<\/strong> wait for the documented terminal result and inspect the status details. Do not create a fresh payout simply because a request timed out.<\/li>\n<\/ul>\n<p>The payout lifecycle documentation notes that <a href=\"https:\/\/razorpay.com\/docs\/x\/payouts\/states-life-cycle\/\">IMPS and UPI payouts can remain in processing for up to T+3 working days<\/a> in cases such as deemed success or beneficiary bank issues. Treat this as exception handling, not the normal promise for every payment. Build your worker-facing labels accordingly, and follow the documented <a href=\"https:\/\/razorpay.com\/docs\/api\/x\/payout-idempotency\/\">idempotency requirements<\/a> for retries.<\/p>\n<h3>Refunds After Commission Allocation or Worker Payment<\/h3>\n<p>Three operations are commonly confused: reversing a Route transfer, refunding the customer and handling a RazorpayX payout-failure reversal. Keep them distinct in your ledger.<\/p>\n<p><a href=\"https:\/\/razorpay.com\/docs\/payments\/route\/reversal?preferred-country=IN\">Route transfer reversals<\/a> can apply after settlement when the required floating balance is available. The <a href=\"https:\/\/razorpay.com\/docs\/api\/payments\/route\/refund-payments-and-reverse-transfer\">refund and reverse-transfer API<\/a> supports automatic reversal with <code>reverse_all<\/code> for a full refund and for a partial refund involving a payment transferred to one Linked Account. For a partial refund involving multiple Linked Accounts, reverse the appropriate transfer separately. This distinction matters when a booking is allocated to several partners.<\/p>\n<p>If the required balance is unavailable, you need an agreed recovery or funding process. Do not promise automatic clawback from a worker&#8217;s bank account.<\/p>\n<blockquote><p><strong>DID YOU KNOW:<\/strong> Razorpay&#8217;s payout idempotency documentation warns that retrying an unresolved payout with a fresh key can create a duplicate. A network timeout needs status handling, not an assumption of failure.<\/p><\/blockquote>\n<h2>Gig Platform Payment Features and Cost Checklist<\/h2>\n<table>\n<thead>\n<tr>\n<th>Selection criterion<\/th>\n<th>What the platform should verify<\/th>\n<th>Useful proof to request<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Customer collections<\/td>\n<td>Supported methods and capture\/settlement behaviour<\/td>\n<td>Current product documentation and merchant terms<\/td>\n<\/tr>\n<tr>\n<td>Commission allocation<\/td>\n<td>Who calculates the split and which recipients can receive it<\/td>\n<td>Worked order example and approved funds flow<\/td>\n<\/tr>\n<tr>\n<td>Worker payout speed<\/td>\n<td>Enabled rail, account\/bank availability, limits and exceptional states<\/td>\n<td>Account-specific mode and TAT table plus test evidence<\/td>\n<\/tr>\n<tr>\n<td>Funding<\/td>\n<td>Source of payout funds and low-balance handling<\/td>\n<td>Approved funding plan and reconciled account balance<\/td>\n<\/tr>\n<tr>\n<td>Partner onboarding<\/td>\n<td>Product eligibility, recipient records, verification and cooling periods<\/td>\n<td>Current onboarding checklist<\/td>\n<\/tr>\n<tr>\n<td>Refunds and recovery<\/td>\n<td>Full and partial refunds, reversal balance and post-payment recovery<\/td>\n<td>Documented refund scenarios<\/td>\n<\/tr>\n<tr>\n<td>Reconciliation<\/td>\n<td>Job and earnings ID linked to collection, transfer, settlement or payout IDs<\/td>\n<td>Sample ledger and status report<\/td>\n<\/tr>\n<tr>\n<td>Charges<\/td>\n<td>Collection fee, split-transfer fee, payout fee, optional services and taxes<\/td>\n<td>Current contracted rate card with fee bases and conditions<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h3>Calculate Cost Per Completed Worker Payment<\/h3>\n<p>Request each applicable charge separately. Gateway pricing is not the payout rate card, and a collection fee, a transfer fee and a payout fee sit on three different transaction entities.<\/p>\n<p>Keep commercial charges distinct from the amount owed to the worker and from your own commission. A useful operational measure is the relevant period&#8217;s total applicable charges divided by completed worker payments. Show the inputs rather than quoting a made-up rupee figure.<\/p>\n<p>Lower fees alone do not establish suitability. Weigh failed and duplicate payments, reconciliation effort and working-capital needs alongside price.<\/p>\n<blockquote><p><strong>PRO-TIP:<\/strong> Ask for a worked quote covering one customer collection, its split transfers, one worker payment and a later partial refund. Confirm which charges apply in your chosen architecture instead of adding every possible product fee to every transaction.<\/p><\/blockquote>\n<h2>Frequently Asked Questions<\/h2>\n<h3>Which Razorpay products support gig-platform payouts and commission splits?<\/h3>\n<p>RazorpayX Payouts supports sending available business funds to gig workers and partners, while Razorpay Route supports commission allocation among Linked Accounts. Razorpay Payment Gateway handles customer collections. IMPS and supported UPI configurations offer round-the-clock payout processing, subject to account, bank and funding conditions. Choose the approved flow and confirm settlement schedules; do not pay the same earnings twice.<\/p>\n<h3>Can gig workers receive UPI or IMPS payouts on weekends?<\/h3>\n<p>RazorpayX documentation lists immediate, round-the-clock IMPS processing and UPI payouts for supported configurations. Availability depends on the enabled account, bank, transaction limits, funds and operational conditions. An accepted request is not a guarantee of immediate beneficiary credit, and exceptional transactions can remain in processing.<\/p>\n<h3>Is splitting a customer payment the same as paying the worker instantly?<\/h3>\n<p>Splitting allocates a payment among recipients. Bank settlement of a Route Linked Account follows the configured settlement schedule. A separate payout uses available funds in the account authorised for disbursements. A platform promising rapid worker payments must plan funding and status handling rather than assume a newly collected payment is instantly available.<\/p>\n<h3>Can one booking be divided among several freelance partners?<\/h3>\n<p>Razorpay Route supports splitting incoming funds among multiple Linked Accounts. The platform determines the agreed commission and recipient amounts, then creates the appropriate transfers. Linked-account creation, cooling periods, eligibility and settlement rules still apply. Make the total allocations and any deductions clear in the earnings ledger.<\/p>\n<h3>What happens if the customer asks for a refund after the worker has been paid?<\/h3>\n<p>Customer refunds and recovery of worker earnings require separate checks. Route&#8217;s <code>reverse_all<\/code> option supports full refunds and partial refunds involving one Linked Account, subject to balance requirements. For a partial refund involving multiple Linked Accounts, use the appropriate transfer reversal separately. Do not assume a completed worker bank payout can be recalled.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Payment solutions for gig platforms in India combine customer collections, commission allocation, partner disbursements and reconciliation. When a home-service job ends, the worker needs a clear earnings statement and bank credit, while the platform needs its commission recorded against the same booking. Manual spreadsheets and unclear payment statuses make that harder as volumes grow. The<\/p>\n","protected":false},"author":180,"featured_media":28353,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[906],"tags":[],"class_list":{"0":"post-28344","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-payment-gateway"},"_links":{"self":[{"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/posts\/28344","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/users\/180"}],"replies":[{"embeddable":true,"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/comments?post=28344"}],"version-history":[{"count":3,"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/posts\/28344\/revisions"}],"predecessor-version":[{"id":28349,"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/posts\/28344\/revisions\/28349"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/media\/28353"}],"wp:attachment":[{"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/media?parent=28344"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/categories?post=28344"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/tags?post=28344"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}