Technology service provider

Technology forpayments thatstay under control.

Nikspay is a Technology Service Provider for payment operations. It brings payins, payouts, settlements, reviews, and evidence into one bank-ready operating layer.

See the platform
Nikspay governed payment pathA merchant payin passes validation, eligible MID routing, payment result, settlement, signed webhook delivery, and an attached audit evidence trail.NIKSPAY · CONTROLLED PAYMENT PATHLIVE VIEWMove across the payment path

One service layer. Every payment operation in view.

Nikspay keeps request intake, policy checks, routing decisions, manual approvals, ledger movements, settlement work, and case evidence connected. Operators can see what happened, why it happened, and what needs to happen next.

What it is
Payment technology and operating controls in one service layer.
Who it serves
Banks, regulated partners, merchants, and their operating teams.
How it connects
Versioned APIs, scoped access, signed events, and explicit approvals.
Where trust lives
In limits, ledgers, review queues, evidence, and named accountability.

One controlled path

From request to settlement, decisions stay visible.

Eligibility is resolved before weightage. If a route falls outside its amount, count, status, or balance rules, the request is redistributed only across eligible live routes.

01

Intent

Capture the request with merchant, amount, purpose, and destination context.

02

Validate

Apply access, amount, velocity, balance, and policy checks before movement.

03

Decide

Choose an eligible route only after its limits and live status are confirmed.

04

Review

Hold sensitive operations for approval with the full decision context attached.

05

Settle

Complete the approved workflow and keep balances connected to the source event.

06

Evidence

Record the actor, reason, before state, after state, and exact time.

Append-only ledgerSigned deliveryApproval gatesConfigurable limitsAudit context
Routing example · INR

Limits decide eligibility before weights decide frequency.

A payment always goes to one MID. For ₹300, the 60-weight MID is outside its range, so the eligible 40-weight MID receives the full selection share. At ₹700, both MIDs qualify and retain their 60/40 distribution.

MID eligibility before weightageFor an INR 300 request, MID A is outside its minimum and MID B receives the full eligible routing share. For an INR 700 request, both MIDs are eligible and their routing weights remain 60 and 40.Eligibility first. Weightage second.ROUTING POLICYSCENARIO 01₹300 requestMerchant requestPayin · INR 300AMOUNT CHECKPer MIDMID A · weight 60Range ₹500–₹1,000INELIGIBLEMID B · weight 40Range ₹100–₹1,000ELIGIBLEELIGIBLE POOLMID B · 100%routing selection shareSCENARIO 02₹700 requestBoth amount ranges passMID A · eligible₹500–₹1,00060%MID B · eligible₹100–₹1,00040%routing distributionA transaction is routed to one eligible MID. Weightage controls selection frequency; it does not split the payment.

The operating surface around every movement.

Each domain has a clear boundary, its own controls, and the context required to move work forward safely.

01PayinsView domain

Track incoming payment requests with adapter eligibility, merchant access, amount limits, success amount limits, and transaction-count limits visible before a route is chosen.

Eligibility before weight
Control areas
  • MID access
  • Amount range
  • Success limits
02PayoutsView domain

Create and monitor payout requests with beneficiary context, bank-account and UPI velocity limits, delivery status, and a complete operating trail.

Destination-aware controls
Control areas
  • Beneficiary checks
  • Daily limits
  • Delivery status
03SettlementsView domain

Request settlements by enabled type, keep manual settlement available where policy allows it, and alert the right operators when action is required.

Enabled types only
Control areas
  • Settlement type
  • Approval state
  • Operator alerts
04DisputesView domain

Manage chargebacks and complaints with merchant-visible updates, admin-only notes, screenshots, PDFs, ownership, and a chronological comment trail.

One accountable case file
Control areas
  • Case owner
  • Comment trail
  • Evidence files
05Fund controlsView domain

Move funds across governed payin, payout, bank-account, and external destinations with balance validation, an operator reason, and durable evidence.

Reason before movement
Control areas
  • Balance check
  • Approval gate
  • Audit evidence
Linked audit evidenceA payment operations audit timeline with a selected limit change and its actor, reason, before value, after value, timestamp, and attachments shown in a details drawer.Platform activityEvery operating event stays attached to its context.ACTORACTIONEVENTAyesha Khan09:42:11 ISTLOGINSuccessful sign-inAyesha Khan09:46:03 ISTVIEWOpened MID routingAyesha Khan09:48:27 ISTCHANGEUpdated amount limitRohan Mehta09:49:18 ISTAPPROVEApproved policy changeEVENT DETAILS · AUD-10389MID amount limit changedACTORAyesha Khan · Super adminREASONApproved capacity increaseBEFORE₹1,000AFTER₹2,500EVIDENCEapproval.pdfpolicy.pngRECORDED12 Aug 2026 · 09:48:27 ISTsha256 · 4fd8…9a21 · immutable eventSIGN-INS · VIEWS · CHANGES · APPROVALS · COMMENTS · ATTACHMENTS
Evidence remains attached to the operation it explains.

Every decision leaves evidence.

Super admins can inspect sign-ins, navigation, approvals, comments, and data changes across staff and merchant activity. Sensitive actions keep the decision context beside the result.

ActorActionReasonBeforeAfterTime
Named identityExact operationRequired contextPreserved stateRecorded statePrecise timestamp

Platform-wide activity

See when people signed in, where they worked, and what they changed.

Case evidence

Keep screenshots, PDFs, admin notes, and merchant updates in sequence.

Controlled access

Pair roles, login throttling, device limits, and reset protection.

In governance, clarity is evidence.

Nikspay payment API integrationA merchant request enters the Nikspay API, passes authentication, validation, limits, and eligible MID routing, then produces a payment response, signed webhook, settlement record, reconciliation status, and audit event.VERSIONED PAYMENT INTEGRATIONPOST /v1/payinsmerchant_order_idORD-1048amount700.00currencyINRcallback_urlhttps://…MERCHANT APPNIKSPAY SERVICE LAYER01AuthenticateScoped credential02ValidateSchema + intent03Apply controlsLimits + access04Select eligible MIDStatus + weightcorrelation_id · req_01HZX… · idempotentPAYMENT RESPONSE · 201statusacceptedpayment_idpay_7K29…routeeligible_midnext_actionawait_resultSIGNED WEBHOOKVerified deliveryTRACEABLESETTLEMENTLinked balance eventTRACEABLERECONCILIATIONExpected vs receivedTRACEABLEAUDIT EVENTActor + decision + timeTRACEABLEBank-specific connectivity is added against approved partner specifications, tests, controls, and certificates.

Built to integrate

Stable contracts. Governed change.

Use versioned APIs and signed webhooks for merchant-facing workflows. Add bank-specific connectivity only against approved partner specifications, security controls, conformance tests, and certificates.

Request surface
Versioned and validated
Credentials
Scoped and protected
Event delivery
Signed and traceable
Operational change
Approved and audited
Read API docs

Give every payment a governed next step.

Start with the Nikspay merchant workspace and bring finance, risk, operations, and engineering into the same clear operating view.

Nikspay | Technology for payments under control