Integrations

Connect Payments Without Multiplying Complexity

Integration is not only an API call. The useful blueprint covers the payment surface, provider path, transaction state, webhooks, finance systems, support tooling, and failure handling.

Request a gateway plan

Choose the interface that fits the product.

One deployment may combine more than one pattern. The final design depends on control, security scope, product experience, and delivery capacity.

Fastest surface

Hosted checkout

A gateway-hosted page can reduce frontend scope while preserving agreed brand elements.

Embedded experience

Web and mobile SDKs

Place payment components inside your product while keeping sensitive data paths appropriately constrained.

Maximum control

Server-to-server API

Own more of the payment experience and backend orchestration, with a correspondingly larger security and test surface.

Low-code collection

Links and QR flows

Support controlled payment journeys where a full commerce integration is not the right starting point.

The integration contract

Every payment state needs an owner.

Requests, callbacks, timeouts, duplicates, reversals, refunds, and reconciliation events should have explicit behavior across systems.

POST /payments
{
  "merchant_reference": "order_...",
  "amount": { "value": "...", "currency": "INR" },
  "method_context": "upi_or_card",
  "return_url": "https://your-domain.example/return"
}

What an INR deployment looks like

None of this is a permanent catalogue. Routes are enabled per approved project, each has its own transaction floor and ceiling, and any of them can be paused — which is why the live method list is something your checkout reads rather than something you draw once.

UPI intentUPI QRUPI linkPaytmPhonePeIMPSLive limits per routeSeparate payout flow

Next step

Apply this page to your actual payment model.

Send enough context to identify the right questions, dependencies, and commercial path.