Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →
Magento 2 and Adobe Commerce multi-vendor stores running Mirasvit or Webkul extensions with Razorpay Route or PayU SplitPay face a three-entity reconciliation chain — customer order, Magento sub-orders per vendor, and split payouts — and the gateway settlement report often loses the sub-order ID, forcing reconciliation to the parent order ID with per-vendor commission derived downstream.
Match gateway payout to Magento order via invoice entity, then unpack to sub-orders in multi-vendor setups via the parent order ID. Derive commission per vendor per contract tier (typically 8–20%), deduct MDR (1.75–2.5% cards, 0–0.4% UPI) and GST on MDR, apply TDS Section 194O at 1% on gross sale value where the store is an e-commerce operator, and reverse refunds against the original sale period.
Magento connector with invoice and sub-order extraction, vendor commission tiers, Razorpay Route or PayU SplitPay linked account mapping, TDS 194O rule per vendor annual threshold (₹5 lakh), GST TCS Section 52 where applicable, and refund reversal logic tied to credit memo entity.
A per-order, per-vendor reconciled settlement with MDR, commission, TDS 194O, and GST TCS all attributed correctly, GSTR-1 filing aligned to marketplace vs single-seller posture, and a vendor payable ledger that clears against each vendor's linked-account payout.
A Magento 2 store with Webkul multi-vendor extension processes 1,200 orders per month across 35 vendors, collecting payment through Razorpay Route. A single customer order containing items from three vendors generates one Razorpay transaction, one MDR deduction, and three vendor payouts at settlement. Reconciling this to Magento’s order and sub-order structure is not a single match — it is a chain of matches across three entities: customer order, Magento sub-orders, and vendor payouts. This article is for finance teams at Indian Magento and Adobe Commerce operators running either single-seller or multi-vendor configurations.
What Magento Payment Gateway Reconciliation Involves
Magento payment gateway reconciliation is the process of matching gateway settlement reports against Magento order data — invoice entities, sub-order entities in multi-vendor setups, and credit memos for refunds — while accounting for MDR, GST on MDR, and TDS Section 194O where applicable. The output is a per-order variance report that feeds both GSTR-1 (for the marketplace or single-seller GST filing) and the vendor payable ledger (for multi-vendor setups).
The India-specific context is that Magento’s out-of-the-box order structure was not designed for the TDS 194O and GST TCS Section 52 requirements that apply when the store operates as a marketplace. The reconciliation layer must derive these tax deductions from the order data before matching against the gateway report. For single-seller Magento stores, the task is simpler — MDR grossing and refund mapping — but still non-trivial at scale.
How Magento Payment Gateway Reconciliation Works
Matching Gateway Payout to Magento Orders
The starting point is the gateway settlement report from PayU, Razorpay, or Cashfree. Each payout batch lists individual transactions with gateway transaction ID, Magento order ID (passed through as merchant reference), amount, MDR deducted, and net payout. The reconciliation matches each transaction to Magento’s sales_order table by order ID, then validates the amount matches the invoice total. Variances in this layer are MDR rate mismatches, missing transactions (where the gateway reports a settlement but Magento has no corresponding order), and orphaned Magento orders (where Magento records a completed invoice but no gateway transaction exists).
Handling Multi-Vendor Splits with Razorpay Route or PayU SplitPay
For multi-vendor Magento stores, each customer order fans out into multiple sub-orders, one per vendor. Razorpay Route executes the split at settlement time by transferring each vendor’s net share to their linked account after deducting the marketplace commission and MDR. The reconciliation layer matches each split transfer to the corresponding Magento sub-order by vendor ID and sub-order reference, verifies the commission percentage applied matches the vendor’s contracted tier (typically 8 to 20 percent), and confirms TDS 194O was deducted where the vendor’s annual payout crosses the ₹5 lakh threshold.
Reconciling Refunds and Credit Memos
Magento refunds flow through the credit memo entity. When a customer refund is issued, Magento creates a credit memo, triggers the gateway’s refund API, and the gateway processes the refund in a subsequent settlement cycle — typically 3 to 7 business days later. The reconciliation step is to match each credit memo to the corresponding refund line in the gateway’s settlement report, verify the refunded amount equals the original invoice (or the partial refund amount), and book the revenue reversal in the period the refund was processed, not the period of the original sale.
Magento Gateway Integration Reference
| Gateway | Magento Module | Settlement Cycle | Marketplace Split Support |
|---|---|---|---|
| PayU | PayU Payment Gateway for Magento 2 | T+1 to T+2 | PayU SplitPay for multi-vendor |
| Razorpay | Razorpay Magento 2 Payment Gateway | T+1 UPI, T+2 cards | Razorpay Route for marketplace split |
| Cashfree | Cashfree Payments for Magento 2 | T+1 standard | Cashfree Easy Split for vendor payouts |
| CCAvenue | CCAvenue Magento 2 Extension | T+2 to T+3 | No native split — manual settlement |
India Compliance Angle: Section 194O and Section 52 on Marketplaces
When a Magento store operates as an e-commerce operator facilitating sales on behalf of third-party vendors, two tax obligations apply. Under TDS Section 194O of the Income Tax Act, the operator deducts 1% TDS on the gross sale value (excluding GST) of each vendor’s supplies once their annual payout through the platform crosses ₹5 lakh. The deduction applies to every payment thereafter and is reported in quarterly TDS returns (26Q). The vendor claims the 194O credit in Form 26AS.
Under GST Section 52, the same operator collects TCS at 1% on the net taxable value of supplies facilitated — 0.5% CGST + 0.5% SGST for intra-state, 1% IGST for inter-state. The operator files GSTR-8 by the 10th of the following month, which populates the vendor’s GSTR-2B with the TCS credit. A single vendor payout therefore triggers two distinct deductions reported through two different return filings.
Finance teams running payment gateway reconciliation on Magento multi-vendor stores need a matching engine that handles order fan-out (one customer order to many vendor sub-orders) natively — treating each sub-order as an independent reconciliation target with its own commission and TDS attribution. Reconciliation software India finance teams use that can ingest Razorpay Route split reports and Magento sub-order data in the same pipeline avoids the common Excel failure mode where multi-vendor reconciliation gets done only at the customer-order level and per-vendor variances go uncaught. The RBI Payment Aggregator guidelines govern the escrow structure under which Razorpay and PayU hold these customer funds before settlement.
The following questions address the reconciliation patterns Magento India operators encounter when running gateway-integrated checkout flows.