Why banks

What a bank gets out of it.

A payouts product your corporates will use, on your rails, without an engineering programme.

₹0 funds held

Funds never sit with OfferGrid.

OfferGrid carries the instruction layer. The bank carries the money. The two lines never cross.

The OfferGrid control plane

One payment operations layer between corporate instructions and bank rails.

Every instruction a corporate raises passes through the same five stages — whichever product it belongs to, and whichever rail it settles on.

See it work

One payout, start to finish.

Follow a single refund from the corporate’s instruction to a matched statement line, through every control on the way. Every value is simulated.

Before and after

What changes for the corporate — and for you.

Today the payout leaves the bank’s view the moment the file is uploaded and comes back as a statement line to be matched by hand.

More than a payout API

Reconciliation without spreadsheets.

A payout API tells you a request was accepted. Operations teams need to know the money landed, and to close the day. OfferGrid matches what you instructed against what the bank returned and what the statement shows, then raises what does not agree.

Security & compliance

Written for the outsourcing committee.

The control design, mapped to the RBI Master Direction on Outsourcing of IT Services, described as a design rather than a certification.

Implementation

Discovery to scale, in sequence.

Compliance review runs in parallel from the first week. Timing is set with the launch bank, not by us.

Platform roadmap · not live today

Expanding the control plane.

Three modules in development. None of them is available today and none forms part of a current engagement — they are here so a bank can see where the platform is going before it commits to the part that already works.

Questions banks ask

Frequently asked.

For banks

New fee income and deeper corporate relationships, without an engineering programme.

OfferGrid gives your transaction banking team a payouts product your corporates will adopt this quarter — running on your rails, under your brand, within your controls.

Why banks partner with OfferGrid

The opportunity, in your numbers

Model it for your book.

Payout volume your corporates currently route through third-party providers is volume that could settle on your rails and earn your fees. Put your own assumptions in; nothing is pre-filled.

Partnership models

Three ways to put it in front of your corporates.

Why OfferGrid

Build it, outsource it, or run it on your rails.

Three ways a bank can offer corporate payouts. Only one keeps the money, the relationship and the controls with the bank without an engineering programme.

Where the boundary sits

A modern payment operations product, without moving money outside your bank.

Your corporate raises the instruction. OfferGrid verifies, controls, routes, reconciles and resolves it. Your bank holds the account and executes the payment.

Division of responsibility

What we take off your plate. What stays with the bank.

Integration timeline

Discovery to scale.

The sequence an engagement follows. Timing is set with the launch bank, not by us — compliance review runs in parallel from the first week.

Your compliance team can start today. Your engineers can start next quarter.

Platform & API

An orchestration layer between client systems and the bank's payment APIs.

REST and file-based on the client side. CBS, payment gateway and UPI switch APIs — or H2H files — on the bank side. Reconciliation, audit and reporting in between.

Capabilities

Verify. Control. Route. Reconcile. Resolve.

The five stages every instruction passes through between a corporate system and a bank rail. Each one is a section below.

Architecture

Three tiers. One boundary that matters.

The stack

What happens inside the boundary.

The architecture above shows where OfferGrid sits. This is the order things happen in once an instruction arrives.

OfferGrid carries instructions and controls the workflow. The bank holds the account, holds the money and executes through its regulated payment rails. The intelligence layer at the top is roadmap; everything between it and the bank is described in the due-diligence pack.

In detail

The five stages, one at a time.

Platform roadmap · not live today

Expanding the control plane.

These modules are in development. Nothing here is available today, and nothing here is part of a current engagement or contract.

Where the platform actually is

What we are building first, and what follows it.

OfferGrid is pre-launch. The left column is the scope of the first release, being built with a launch bank; the right column is what the same control plane extends to afterwards. Nothing moves from right to left on this page until it has moved in the platform.

Sandbox credentials are issued in week one of discovery.

Agentic operations · platform roadmap

From payment APIs to payment operations agents.

AI that operates inside your payment controls.

Investigate, reconcile and prepare payment actions through natural language, while OfferGrid’s permissions, policies and approvals remain in control.

Roadmap module · not available today

How it fits together

Three layers, and only one of them touches money.

BotPay brings agentic intelligence to OfferGrid’s payment operations infrastructure. OfferGrid remains the control plane. The bank remains the regulated entity.

The agent calls the same OfferGrid APIs a person or a corporate system calls, and is subject to the same policy, approval and audit path.

The control path

AI that operates inside your payment controls.

The agent does not receive unrestricted control over money. Every action it takes travels the same route as any other instruction.

A worked example

What the operator says, and what actually happens.

The conversation on the left is the whole of the operator’s experience. The column on the right is the path every requested action still has to travel.

What it looks like in use

Four operations an agent could take off a team’s morning.

Illustrative interactions against the capabilities described on the platform page. Shown to explain the model, not as a product demo.

Governance

Policies, continuity and incident response.

For corporates

Your bank account becomes your payout engine.

Refunds, cashback, publisher and creator payments raised from your own systems, approved by your own people, and paid from your own account at your bank — with the reconciliation done before your finance team opens the statement.

What you get

The payout desk your finance team wishes it had.

Every control your bank expects, applied automatically, from the account you already hold.

How you get it

Through your bank.

OfferGrid is offered by banks to their corporate customers — under the bank’s brand, or behind the bank’s existing corporate portal. Your money never leaves your bank.

OfferGrid is pre-launch and is being built with a launch bank partner. If your bank is not yet offering it, tell us which bank you use and we will route the conversation.

Developers

Boring in the right ways.

One REST API for payments, batches, beneficiaries, verification, approvals, reconciliation and exceptions. Idempotent writes, signed webhooks, problem-detail errors, and three status fields that never lie to you.

Contract defined in the OpenAPI 3.1 draft · reference docs, SDKs and changelog ship with the first release

Authentication

OAuth 2.0 client credentials, scoped.

System clients authenticate with a client-credentials grant; mTLS is available for bank-side integrations. Every token carries only the scopes it needs.

POST https://auth.offergrid.in/oauth2/token
grant_type=client_credentials&scope=payments.create%20payments.read

Authorization: Bearer <access_token>
Idempotency-Key: rf-88213-2026-09-04     # required on every write
If-Match: "3"                              # optimistic concurrency on state changes

Idempotency & retries

Retry as often as you like. You get one payout.

Every write carries an Idempotency-Key. A replay returns the original result with Idempotency-Replayed: true and never creates a second payment. State-changing calls take an If-Match ETag, so two operators cannot approve past each other.

HTTP/1.1 202 Accepted
ETag: "1"
Idempotency-Replayed: false

{
  "id": "po_01J6XQ4R8N",
  "client_reference": "RF-88213",
  "amount": { "value_minor": 249900, "currency": "INR" },
  "control_status": "APPROVAL_PENDING",
  "execution_status": "NOT_STARTED",
  "reconciliation_status": "NOT_REQUIRED",
  "version": 1
}

Status model

Three orthogonal states, not one overloaded string.

A payment has a control state, an execution state and a reconciliation state. They advance independently, so “approved but the bank has not answered” and “paid but not yet on a statement” are first-class, not guesses.

SUBMISSION_UNCERTAIN is deliberate: when the bank has not confirmed receipt, the platform never reroutes or resubmits on its own.

API surface

Twenty-four operations.

Grouped by the stage they serve. Cursor pagination on every list; RFC 7807 problem details with a request_id on every error.

Webhooks & files

Every status transition, signed. Every file, checksummed.

About OfferGrid

We make bank rails programmable for offer-linked payments — so banks, not intermediaries, own the flow.

Refunds, cashback, publisher and creator payments create recurring operational complexity for banks and their corporate customers. Much of that volume runs through intermediaries that sit between the bank and its own corporate customer. OfferGrid exists to move that volume back onto bank rails, with the controls a bank expects.

Working with a bank's partnerships or compliance team? Start here.

Offer refunds as a bank product to your merchant and e-commerce corporates.

Give your consumer-brand corporates a campaign payouts product on your rails.

Bring ad-network and marketplace corporates' publisher runs onto your rails.

A creator payments product for your brand and agency corporates, on your rails.