Juspay reports FY26 growth as payment orchestration expands internationally

The announced development

Juspay reported on 9 October 2026 that revenue for the financial year ended 31 March 2026 reached ₹664 crore, compared with ₹514 crore in the preceding year. The company described the increase as 30 percent and highlighted international business across several regions. It also reported adjusted EBITDA of ₹33 crore, excluding employee stock option costs.

These are company reported figures, with the adjustment explicitly relevant to interpretation. They describe Juspay's business performance rather than the expected results of an individual merchant integration. For merchants, the announcement offers a timely reason to examine the operational and commercial case for payment orchestration: the software layer used to coordinate payment providers and related services.

Merchant analysis: start with a specific constraint

Orchestration is most useful to evaluate against a concrete payment problem. A merchant may struggle to launch a local method, reconcile several provider reports or manage failures across existing integrations. Those are different problems and may call for different capabilities. A general desire to improve payments is too broad to guide a procurement decision or establish whether the project succeeded.

Write down the current constraint in observable terms. For example, finance might spend several days matching deposits, while engineering might need a long release cycle to change routing. Establish the baseline before evaluating a new platform. Otherwise, improvements elsewhere in the business can be attributed to the integration even when the original problem remains unresolved.

A merchant with modest volume and one suitable provider may have a different business case from a company operating across many markets. More connections also create responsibilities: configuration, monitoring, commercial agreements and incident handling. The aim should be a payment operation the business can manage reliably, not the largest possible collection of provider logos or routing options.

Routing decisions need comparable evidence

A routing rule can affect approval rates, costs and customer experience at the same time. Merchants should ask how performance comparisons account for country, issuer, payment method and transaction characteristics. Sending easier transactions to one provider and difficult transactions to another can make an unadjusted approval comparison misleading. Decisions should reflect sufficiently comparable groups and a meaningful observation period.

Successful authorisations are only one part of the outcome. A route that appears attractive initially may create more refunds, disputes or reconciliation work. Finance and risk teams should help define the metrics, including net revenue and operational cost. A change should not be declared successful merely because the checkout reports more approvals before downstream outcomes are understood.

Routing also needs a clear authority model. Decide who can change rules, what review is required and how a previous configuration is restored. Store a record of changes with the reason and expected result. When performance shifts, that history helps distinguish a provider incident from an internal experiment. It also prevents several teams from making conflicting adjustments at the same time.

Resilience depends on more than another connection

A second provider may improve available options, but it does not automatically provide a safe fallback for every transaction. A merchant should understand whether the original attempt failed conclusively or remains unresolved before making another request. Retrying an uncertain payment can create duplicate charges or orders. Reliable status handling matters as much as the existence of an alternative route.

Test outage scenarios with the platform and providers. Include delayed responses, missing notifications and a successful payment whose confirmation arrives after a timeout. The merchant needs a consistent order record and a clear process for customer support. A technical failover that increases uncertainty at the help desk is not a complete resilience solution.

Some dependencies may remain shared across otherwise separate providers. A merchant should map important infrastructure and operational dependencies rather than assuming complete independence. Ask what the platform itself requires to remain available and how incidents are communicated. The evaluation should include access to transaction information during an interruption, because finance and support still need to resolve customer questions when normal workflows are impaired.

Token and data portability affect future choices

An orchestration decision can influence how difficult it becomes to change providers later. Merchants should ask where payment credentials are stored, which tokens can be used with which connections and what an authorised migration would involve. These questions should be answered contractually and technically before the integration becomes central to the business. Portability should not be inferred from the word orchestration.

Data access is equally important. A merchant needs enough detail to reconcile transactions, investigate failures and meet its operational obligations. Ask about export formats, identifiers and access after a contract ends. A visually appealing dashboard is useful, but it should not be the only way the business can obtain its own relevant transaction records.

Security responsibilities need explicit allocation. Identify which party handles sensitive information and which controls remain with the merchant. Adding an intermediary does not erase the need for appropriate access management and secure integration practices. Teams should understand their own responsibilities without assuming that a provider's general security statement covers every part of the merchant environment.

Commercial scope should match the implementation

The full cost of orchestration includes more than a platform subscription or transaction fee. Engineering effort, provider contracts, testing, ongoing monitoring and support processes all matter. Merchants should prepare a realistic estimate of both initial work and continuing ownership. Savings that depend on features not included in the proposed agreement should not be counted as secured benefits.

Implementation scope should be phased. A first stage might standardise reporting for existing connections, while a later stage introduces a carefully measured routing change. Phasing can make the source of any improvement easier to identify. It also reduces the risk of simultaneously changing checkout behaviour, reconciliation and provider relationships without knowing which change caused a problem.

Assign acceptance criteria to each stage. Engineering can verify technical behaviour, finance can reconcile sample settlements and support can resolve test incidents. Commercial teams should confirm that the contracted capabilities match what was demonstrated. A project is ready for expansion when these functions agree it works, not simply when an integration checklist has been completed.

Merchants should investigate how provider specific capabilities are represented in a common interface. A standardised request can simplify engineering, but it may also hide differences in capture windows, refund behaviour or available reporting fields. Ask the implementation team to document those differences and show where staff can see them. A finance user should not need to infer an important restriction from an unexplained error code. The same scrutiny applies when a new connector is introduced: advertised availability should be followed by testing against the functions the merchant actually uses. Keep a small set of realistic transaction examples as an acceptance pack, including the unusual cases that previously required manual intervention. Reusing that pack across provider changes creates a consistent basis for comparison and helps prevent a migration from quietly removing functionality that another department depends on during its normal work. Document exceptions before approving wider deployment.