← library
Partner-gated
Payments / Super-app platform (India)·agent-generated · deepseek-v4.1-flash·checked 2026-10-28
difficulty
4/5

Paytm has no self-serve 'Sign in with Paytm' OAuth — user login exists only inside the Mini App platform (business KYC + partner approval), and the documented 'OAuth Token API' is a merchant server token, not user delegation.

First working connection
~3–8 hours once a client_id exists
Production / approved
Est. 2–6 weeks: merchant KYC + Mini App/credential approval, then review (approval waits inferred)
Composio managed OAuth
Bring your own app
Not in Composio's managed-OAuth list — you'll need your own OAuth app (or it isn't a Composio toolkit yet).
who does itagent 6you 2provider 0
evidencetested 14sourced 8inferred 15
◆ agent run7 pages read6/15 quotes verified verbatim61s$0.019deepseek-v4.1-flash

01Pick your path

Merchant OAuth Token (server-to-server)
when Your agent acts for your own Paytm merchant account (payments, refunds, settlements), not for end users.
→ You get an access token for your own merchant account to call payments/refund/settlement APIs. No user consent screen, no user identity — this is the 'OAuth' Paytm actually documents.
Mini App Login Flow (user-delegated)
when You need the Paytm user's identity and are willing to ship your app inside Paytm's Mini App Store.
→ paytmFetchAuthCode → getAccessToken → getUserInfo inside a Paytm Mini App; gives you the signed-in Paytm user's profile. Requires Mini App onboarding and a client_id issued by Paytm.
Standard 'Sign in with Paytm' on your own site
when You want an ordinary OIDC social login button on your own website.
→ Not offered self-serve. No developer console for OAuth client registration; you would have to negotiate directly with Paytm's partner/onboarding team.

02Time & effort

Hands-on work
2.6 h – 7.7 h
Waiting on others
8 days – 5 weeks
You're actually working
<1% of elapsed time
Phases
5
start↑ first working connection, then production pathproduction
  1. DEVPick the surface: merchant token vs Mini App login20–40 minutessourced[S4]Read the API reference sidebar: 'OAuth Token API' is under Payments; the login flow is under Mini Apps → Login Flow.
  2. DEVOpen a Paytm for Business / merchant account15–60 minutessourced[S1]Paytm claims 'create your account in under five minutes' and 'instant activation', but verification of business details can add days (inferred).
  3. PRODRequest Mini App access + client_id and redirect approvalwait 5–20 daysinferred[S7][probe]No source states an approval SLA; the probe shows keys are not self-serve.
  4. DEVWire login flow and token exchange2–6 hourstested[probe][S4]Authorize page and token endpoint confirmed to exist; request/response params are undocumented, expect trial-and-error with Paytm support.
  5. PRODMini App review and go-livewait 3–15 daysinferred[S7]Paytm advertises '2 developers can complete the integration in 2 Weeks' — that is build effort, not an approval SLA.
agent can do it you waiting on providerbar widths ∝ √time, so short tasks stay visible

03Steps

0/8 done

Get a working connection

  1. Confirm which 'OAuth' you needagentsourced ❝[S4]

    In the Paytm API reference, 'OAuth Token API' and 'Access Token API' live under Payments; the user-facing flow is Mini Apps → Login Flow (paytmFetchAuthCode, getAccessToken, getUserInfo). Write down which one your agent needs before touching code.

    “OAuth Token API * Native Fetch User PayMode Status API” — [S4] verified verbatim
    ↗ developer.paytm.com/docs/
  2. Open a Paytm for Business accountyousourced ❝[S1]

    Sign up as a merchant (company name, business type, live website). This account is the prerequisite for any Paytm-issued client_id; billing/settlement bank details are captured here.

    “Open a merchant account, accept digital payments and log in to manage settlements, QR codes and your Soundbox.” — [S1] verified verbatim
    ↗ dashboard.paytmpayments.com/login/
  3. Send the user through the discovered authorize endpointagenttested[probe]

    Point users at https://accounts.paytm.com/oauth-js-sdk/login/index.html?client_id=<yours>&response_type=code&redirect_uri=<https callback>. Note the probe: an invalid client_id still renders a login page with HTTP 200, so verify success by the presence of a code on your redirect, not by page load.

    ↗ accounts.paytm.com/oauth-js-sdk/login/index.html
  4. Exchange the code at the token endpointagenttested[probe]

    POST the returned code to the discovered token endpoint from your backend. The exact grant_type/client authentication/response shape is not published — log the raw response and confirm parameters with Paytm before you ship.

  5. Resolve the user profile and bind it to your sessionagentinferred[S4]

    Call getUserInfo (server-side, never in the browser) to fetch the minimum profile fields, map them to a local session, and store the Paytm user identifier as your external ID. Keep access tokens server-side only.

    ↗ developer.paytm.com/docs/

Make it production-ready

  1. Request Mini App platform access and a client_idyousourced ❝[S7]

    Use the Mini App Store 'Get Started' / 'API Documentation' entry points to request platform access, then send the credential request (see artifact) with your registered redirect URI, required user fields, and environment needs.

    “Integrate using open source technologies like HTML and Java script and reach out to 150 Million monthly active users on Paytm App.” — [S7] verified verbatim
    ↗ business.paytm.com/miniapps
  2. Harden, then submit for reviewagentinferred[S3][S7]

    Keep checksum/signing and API keys on the server (Paytm Checksum + server SDKs), add a fallback identity path for browsers where the Mini App webview is absent, and submit the Mini App for review.

  3. Send the credential + scope justification requestagentinferred[S1][S7]

    Send this to the onboarding contact listed on Paytm's merchant pages (onboarding.support@paytmpayments.com) or through the Mini App 'Get Started' flow. It gives the partner team the four things they will ask for: business identity, redirect URI, minimum data set, and token contract.

    ◆ prepared by agent · Draft request to Paytm partner/onboarding team
    Subject: Mini App login flow — client credentials and redirect URI request

Hello Paytm Mini Apps / Onboarding team,

We are building <product>, a <category> app, and want to use the Paytm Mini App Login Flow (paytmFetchAuthCode -> getAccessToken -> getUserInfo) to sign users in.

Business details
- Legal name / business type: <name>, <Private Limited | Proprietorship | Partnership/LLP | ...>
- Merchant account: <merchant ID / registered email at dashboard.paytmpayments.com>
- Live website: https://<yourdomain>

Technical ask
- Sandbox and production client_id for the Mini App login flow
- Registered redirect URI: https://<yourdomain>/auth/paytm/callback (HTTPS, single host)
- Requested user data: name, Paytm user ID, <phone only if required> — nothing beyond what we render
- Token endpoint behaviour at https://accounts.paytm.com/oauth/token: grant type, client authentication method, access/refresh token lifetimes

Compliance
- Data stored in <region>, deleted on account deletion; privacy policy: https://<yourdomain>/privacy
- Secrets held server-side only (Checksum / server SDK)

Questions
1. Which scopes or consent strings does the login flow expose? scopes_supported is empty on https://accounts.paytm.com/.well-known/openid-configuration.
2. Is the login flow usable outside the Paytm in-app webview?
3. What is the expected review turnaround for a new Mini App?

Thanks,
<name>, <role>

04Requirements, scopes & nuances

You'll need

  • ▸A Paytm for Business merchant account with completed KYC: company name, contact person, mobile, email, business type, and a live (or soon-live) website URL. inferred[S1]
  • ▸Mini App platform onboarding if you want user identity — the login flow ships only as part of the Mini App platform. sourced ❝[S7][S4]
  • ▸A client_id/credentials pair and at least one registered HTTPS redirect URI issued by Paytm; there is no self-serve registration page. inferred[probe]
  • ▸For merchant API calls: server-side signing (Paytm Checksum) and server SDKs (Java/Node/PHP/Python) — secrets must stay server-side. sourced ❝[S3]

Gotchas

  • !The 'OAuth Token API' in Paytm's API reference sits under Payments — it is a merchant server token, not user-delegated OAuth. Do not bill it to your planner as user sign-in. inferred[S4]
  • !The only user-facing login primitive Paytm documents is the Mini Apps Login Flow: paytmFetchAuthCode JS API → getAccessToken API → getUserInfo API, i.e. it runs inside the Mini App platform, not as a standalone OIDC provider. sourced ❝[S4]
  • !The discovery document at accounts.paytm.com advertises authorization_endpoint=https://accounts.paytm.com/oauth-js-sdk/login/index.html — a JS-SDK login page, an unusual authorize URL that will not behave like a standard /authorize redirect. tested[probe]
  • !scopes_supported is absent from the discovered metadata, so there is no published scope catalogue to pick a least-privilege subset from. tested[probe]
  • !Merchant onboarding is a KYC form, not a click-through: company name, contact person, mobile, email, whether your website is live, and business type (Private Ltd / Public Ltd / Proprietorship / Partnership-LLP / Trust / HUF / Unregistered). inferred[S1]
  • !Mini App login is delivered through the Paytm app webview, so it will not authenticate users on a plain web browser session; plan a fallback identity path for desktop/web. inferred[S7]
Scope / permissionTierNoteEvidence
Merchant access token (OAuth Token API)basicNot a user scope. Client-credential style token for your own merchant account; grants payment/refund/settlement operations you are already entitled to.inferred[S4]
getUserInfo (Mini App profile read)sensitiveThe closest thing to a scope: the Mini App getUserInfo API returns the signed-in user's details. Ask for only the fields you render.inferred[S4]
paytmFetchAuthCode / getAccessToken (login flow grant)gatedThe grant itself, not a named scope. scopes_supported was absent from the discovery document, so no least-privilege scope list can be chosen from public docs.tested[probe][S4]
Phone / Paytm user ID (if returned by getUserInfo)restrictedTreat as sensitive PII for Indian DPDP purposes; request only if your flow genuinely needs it, and document retention.inferred[S4]

05If you get blocked

✕The planner's 'OAuth support is unclear' is correct at the product level: Paytm publishes no third-party 'Sign in with Paytm' OAuth app console — developer.paytm.com only offers a merchant account 'Create Account' [S3].inferred[S3][S4]

→ Scope the project to what Paytm actually ships: (a) merchant-side OAuth Token API for your own account [S4]; (b) Mini App Login Flow inside Paytm's app [S4/S7]. There is no social-login product to enable.

✕No merchant/partner account = no client_id. Everything on accounts.paytm.com is keyed to an onboarded Paytm business.inferred[S1]

→ Sign up at https://business.paytm.com/ and complete the Payment Gateway form at https://dashboard.paytmpayments.com/login/ (company name, business type, live website). Write to onboarding.support@paytmpayments.com for status.

✕The authorize endpoint returns a 200 HTML login page even for client_id=probe_invalid_client, so you cannot debug a bad/absent client_id from the error surface.tested[probe]

→ Register the redirect URI with Paytm during onboarding and test only with the issued client_id; treat the HTML 200 as 'credentials required', not as a working authorize URL.

✕Standard discovery hosts are dead: auth.paytm.com and login.paytm.com both 'fetch failed' for /.well-known/openid-configuration and /.well-known/oauth-authorization-server.tested[probe]

→ Hardcode https://accounts.paytm.com/.well-known/openid-configuration or the endpoints it returns; do not build generic OIDC discovery against auth.paytm.com or login.paytm.com.

06Evidence: what was tested, sourced, and still uncertain

$ probes: live GETs with a dummy client_id, no credentials
✓ Discovery document (/.well-known/openid-configuration) → n/a
https://auth.paytm.com/.well-known/openid-configuration
unreachable: fetch failed
∴ auth.paytm.com does not answer discovery on either well-known path — do not target this host in code or config.
✓ Discovery document (/.well-known/oauth-authorization-server) → n/a
https://auth.paytm.com/.well-known/oauth-authorization-server
unreachable: fetch failed
✓ Discovery document (/.well-known/openid-configuration) → n/a
https://login.paytm.com/.well-known/openid-configuration
unreachable: fetch failed
✓ Discovery document (/.well-known/oauth-authorization-server) → n/a
https://login.paytm.com/.well-known/oauth-authorization-server
unreachable: fetch failed
∴ login.paytm.com does not answer discovery on either well-known path — do not target this host either.
✓ Discovery document (/.well-known/openid-configuration) → 200
https://accounts.paytm.com/.well-known/openid-configuration
issuer=https://accounts.paytm.com; authorization_endpoint=https://accounts.paytm.com/oauth-js-sdk/login/index.html; token_endpoint=https://accounts.paytm.com/oauth/token; scopes_supported=n/a
∴ The only live, standard-looking OIDC discovery document on Paytm. Use this one; it gives issuer, authorization_endpoint and token_endpoint.
✓ Authorize endpoint with a fake client_id → 200
https://accounts.paytm.com/oauth-js-sdk/login/index.html?client_id=probe_invalid_client&response_type=code&redirect_uri=https%3A%2F%2Fexample.com%2Fcallback
text/html — HTML/login page
∴ The advertised authorization_endpoint is a JS-SDK login HTML page ('oauth-js-sdk'), consistent with the Mini App in-app login flow rather than a general-purpose OAuth authorize screen.

Still uncertain

  • ? Token endpoint contract is unknown: grant_type, client authentication (secret vs PKCE), token lifetime and refresh behaviour are not in any fetched source and were not exercised beyond a discovery read.
  • ? No published scope catalogue — scopes_supported was empty in the discovery document, so scope names in this guide are inferred from the documented Mini App APIs (getUserInfo), not from a Paytm scope list.
  • ? Whether the Mini App login flow can be used by a third-party website/app outside the Paytm in-app webview is not stated in any source; the 'oauth-js-sdk' authorize path suggests it is webview-bound.
  • ? Approval durations for Mini App onboarding and for credential issuance are not published anywhere in these sources; all waits marked here are inferred.
  • ? The probe tested a single fake client_id and one redirect_uri; behaviour with a real (expired/revoked) client_id is unverified.
  • ? Sources are thin on OAuth specifics: business.paytm.com, paytm.com/oauth and paytm.com/partner-with-us are marketing pages, and developer.paytm.com is a docs index — no page describing a user-consent OAuth product was retrieved.
  • ? Generated automatically; no app was registered and no review was submitted.