← library
Merchant OAuth only
Payments / payment gateway (merchant API)·agent-generated · deepseek-v4.1-flash·checked 2026-10-28
difficulty
4/5

PayU has OAuth only for merchant server-to-server calls (client_credentials) — no consent screen, no third-party app registration, no scopes — so 'act for your user' needs PayU's partner program (business vetting, weeks), and getting even the merchant credentials means company KYC and a signed contract.

First working connection
~1–2 hours once credentials exist
Production / approved
2–10 days merchant onboarding + contract, then live credentials
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 5you 3provider 0
evidencetested 3sourced 23inferred 12
◆ agent run14 pages read19/23 quotes verified verbatim88s$0.017deepseek-v4.1-flash

01Pick your path

Server-to-server (client_credentials)
when You are the merchant and your agent just needs to call PayU's payment APIs.
→ A Bearer token for your own merchant POS; you can create orders, but nothing acts 'as a PayU user'.
trusted_merchant grant
when Your own back end already owns the customer record and you pass extCustomerId yourself.
→ Token scoped to a fixed extCustomerId — models per-customer behaviour without any consent step from that customer.
partner grant + referral program
when You onboard other merchants onto PayU under a partner arrangement.
→ Firm-level authentication for referral partners after a form, commercial negotiation, contract and onboarding.
PayU India partner OAuth (co-branded onboarding)
when You operate in India and want co-branded merchant onboarding.
→ Docs pages exist for partner OAuth, but the fetched content was navigation only — treat as a phone-call-to-sales path, not a spec.

02Time & effort

Hands-on work
1.7 h – 4.5 h
Waiting on others
9 days – 7 weeks
You're actually working
<1% of elapsed time
Phases
7
start↑ first working connection, then production pathproduction
  1. DEVConfirm there is no user-delegated OAuth5–15 minutesinferredDiscovery URLs are HTML, and the authorize URL is a token endpoint. PayU is an acquirer/API, not an identity provider.
  2. DEVRegister merchant account + prepare documents30–60 minutessourced[S8][S1]Company/legal details and KYC documents are required; the developer must supply the legal identity and sign.
  3. PRODPayU verification and contract activationwait 2–10 daysinferred[S8][S1]Not stated in sources. Longer for cross-border entities; SMB 'simple onboarding' is only available in select markets.
  4. DEVPull client_id/client_secret from a POS5–15 minutessourced[S3]
  5. DEVImplement token + order calls against sandbox30–90 minutessourced[S3][S8]Curl-to-code is trivial; the redirect-handling quirk on the order response is the main time sink.
  6. PRODGo live: production account, notifyUrl, contract terms30–90 minutessourced[S8][S3]Sandbox and production are separate accounts, so live credentials are issued separately.
  7. PRODOnly if needed: partner program / partner OAuth applicationwait 1–6 weeksinferred[S12]S12 describes form → commercial terms → contract → onboarding with no published SLA; timing is a guess.
agent can do it you waiting on providerbar widths ∝ √time, so short tasks stay visible

03Steps

0/8 done

Get a working connection

  1. Verify what 'OAuth' means at PayU before writing codeagentinferred

    Run the two well-known GETs and inspect Content-Type. text/html + 200 means 'no metadata', not 'supported'. Then note that GETting the authorize URL yields 401 JSON — it is a token endpoint.

    ↗ secure.payu.com/.well-known/openid-configuration
  2. Choose the grant type that matches the jobagentsourced ❝[S3]

    PayU documents exactly three grant types: client_credentials (standard), trusted_merchant (per logged-in user via fixed extCustomerId), partner (firm-level, referral program). None is an authorization-code flow an end user approves.

    “PayU offers three different grant types for OAuth tokens.” — [S3] verified verbatim
    ↗ developers.payu.com/europe/docs/payment-flows/auth-and-order/
  3. Register the merchant account (legal identity required)yousourced ❝[S8]

    Follow the registration section: production and sandbox are separate accounts and are not interconnected, so register the sandbox account first to unblock coding. Prepare company/KYC documents; the developer must do this personally.

    “The Production and Sandbox environments are entirely separate and are not interconnected in any way.” — [S8] verified verbatim
    ↗ developers.payu.com/europe/docs/get-started/set-up-account/
  4. Copy client_id and client_secret from a POSyousourced ❝[S3]

    client_id and client_secret live in any point of sale (POS) in PayU's management panel. The agent can draft the config plumbing; only the developer can read the secret out of the panel.

    “To generate an OAuth token, you will need client_id and client_secret, which can be found in any of your points of sale (POS), in your management panel.” — [S3] verified verbatim
    ↗ developers.payu.com/europe/docs/get-started/set-up-account/
  5. Implement the token callagentsourced ❝[S3]

    POST form-encoded; the Content-Type header is mandatory or you get 401. Cache the returned access_token (expires_in ~43199s) server-side and never expose the client_secret to a browser or to an agent runtime.

    “Without the Content-Type: application/x-www-form-urlencoded header, the authentication request will return error 401.” — [S3] verified verbatim
    ◆ prepared by agent · client_credentials token request (sandbox host: secure.snd.payu.com)
    curl -X POST https://secure.payu.com/pl/standard/user/oauth/authorize \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=client_credentials" \
  -d "client_id=$PAYU_CLIENT_ID" \
  -d "client_secret=$PAYU_CLIENT_SECRET"
  6. Create an order with the Bearer tokenagentsourced ❝[S3]

    Send OrderCreateRequest with 'Authorization: Bearer <token>'. Prices are in the lowest currency unit (grosz), except HUF which is multiplied by 100. Keep extOrderId unique per POS.

    “Specify prices using the lowest currency unit.” — [S3] verified verbatim
    ↗ developers.payu.com/europe/docs/payment-flows/auth-and-order/
  7. Disable redirect following and parse 302/JSON correctlyagentsourced ❝[S3]

    A successful order create may come back as HTTP 200 + HTML or 302 to redirectUri. Turn off automatic redirects in your HTTP client, or you will report failures on successful payments.

    “If the response to the payment creation request is returned with an HTTP 200 status and in HTML format, make sure that the tool used to communicate with PayU has automatic redirect handling disabled.” — [S3] verified verbatim

Make it production-ready

  1. Escalate if you actually need firm/user-level accessyousourced ❝[S12][S4][S5]

    If the product genuinely needs per-user delegated access, apply to the partner program (form → commercial terms → contract → unique registration link). For India, the partner OAuth / co-branded onboarding docs exist but the fetched pages contained only navigation, so ask sales directly.

    “Signing the contract and generating a unique registration link for customers.” — [S12] verified verbatim
    ↗ corporate.payu.com/partners/

04Requirements, scopes & nuances

You'll need

  • ▸A registered PayU merchant account (production and sandbox are separate accounts) with the documents PayU requires at registration — the developer must supply these. sourced ❝[S8]
  • ▸client_id and client_secret, available from any point of sale (POS) in the management panel. sourced ❝[S3]
  • ▸A server-side HTTP client that can POST application/x-www-form-urlencoded and disable automatic redirect following. sourced ❝[S3]
  • ▸A publicly reachable HTTPS notifyUrl to receive order notifications. inferred[S3]
  • ▸For firm-level/referral access: a signed partner agreement plus a generated registration link — commercial negotiation, not self-serve. sourced ❝[S12]

Gotchas

  • !Both OAuth discovery URLs answer 200 with text/html — PayU's website catch-all, not OIDC metadata. Do not wire an OIDC client to them. inferred
  • !/pl/standard/user/oauth/authorize with query params and a fake client_id returns 401 JSON mentioning an error — it behaves like a token endpoint, not a browser authorize/consent page. inferred
  • !The token request must be a POST with Content-Type: application/x-www-form-urlencoded; without that header PayU returns error 401. sourced ❝[S3]
  • !The access token expires in 43,199 seconds (~12h) and is used as 'Authorization: Bearer <token>' on /api/v2_1/orders — cache and refresh it rather than fetching per request. sourced ❝[S3]
  • !Production and Sandbox are entirely separate and not interconnected — you must create and register two accounts. sourced ❝[S8]
  • !The Orders endpoint can answer with HTTP 200 + HTML or 302 to redirectUri; disable automatic redirect following in your HTTP client or you lose the JSON order status. sourced ❝[S3]
Scope / permissionTierNoteEvidence
client_credentialsbasicStandard integration; token represents your merchant account. Narrowest option and the only one you need for pure payment API calls.sourced ❝[S3]
trusted_merchantsensitiveAuthenticates requests for logged-in shop/application users via a fixed extCustomerId — still uses your client_secret, so there is no user-facing consent.sourced ❝[S3]
partnergatedFirm-entity-level authentication for merchants in the referral program; requires the partner arrangement, so it is effectively gated.sourced ❝[S3][S12]
PayU India partner OAuth (co-branded onboarding)gatedDocumented as partner OAuth/co-branded onboarding for PayU India; community docs also describe a Smart Send / Zoho Marketplace app install path.inferred[S4][S5][S11]
OIDC scopes (openid, profile, etc.)gatedNot available. No scope list, consent screen, or discovery metadata exists for third-party apps.inferred

05If you get blocked

✕There is no third-party app registration, consent screen, or scope model anywhere in the sources — so you cannot ask a PayU user to 'Connect PayU' and get a delegated token.inferred[S3]

→ Keep PayU credentials server-side and treat PayU as a merchant/payment API, not as an identity provider for your users. If per-user delegation is a hard requirement, ask PayU partner sales whether any consent-based flow exists for your market.

✕Credentials only exist after merchant onboarding (registration, documents, contract) — this is a business-vetting gate, not a self-serve API key page.sourced ❝[S8][S1]

→ Budget the KYC/contract step as a real project task: company documents, sign-up form, contract signature, then credentials. Sandbox needs its own separate registration, so start it first.

✕Both /.well-known documents return HTTP 200 with text/html, so an agent that trusts status codes will 'discover' a non-existent OIDC provider and generate broken config.inferred[S3]

→ Reject these in your discovery/auto-config code; hardcode PayU's documented token URL from the developer guide instead.

✕The token endpoint returns 401 with a JSON error body that the probe could not fully read, so debugging a bad request is guesswork unless you log the raw body.inferred[S3]

→ Send Content-Type: application/x-www-form-urlencoded exactly; validate response is JSON with access_token before parsing.

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

$ probes: live GETs with a dummy client_id, no credentials
✓ Discovery document (/.well-known/openid-configuration) → 200
https://secure.payu.com/.well-known/openid-configuration
non-JSON (text/html; charset=UTF-8)
∴ HTTP 200 but text/html: this is the marketing site's catch-all, not OpenID metadata. Auto-configuring a client from it will silently produce garbage.
✓ Discovery document (/.well-known/oauth-authorization-server) → 200
https://secure.payu.com/.well-known/oauth-authorization-server
non-JSON (text/html; charset=UTF-8)
∴ Same result — no RFC 8414 authorization-server metadata is published. Do not claim PayU 'supports OIDC discovery'.
✓ Authorize endpoint with a fake client_id → 401
https://secure.payu.com/pl/standard/user/oauth/authorize?client_id=probe_invalid_client&response_type=code&redirect_uri=https%3A%2F%2Fexample.com%2Fcallback
application/json;charset=UTF-8 — body mentions "error"
∴ 401 JSON with an error field for a GET with query params: this endpoint expects a POSTed form-encoded client_id/client_secret (a token endpoint), not a browser consent redirect.

Sources read

  1. [S1] Financial Services for Emerging Markets | PayU Global official
  2. [S2] PayU S.A. third-party
  3. [S3] Authorize and Order | PayU Europe Developer Guide official
  4. [S4] Partner OAuth Integration official
  5. [S5] Enable Co-Branded Onboarding (OAuth) for Partners official
  6. [S6] Integration Overview | PayU Europe Developer Guide official
  7. [S7] PayU Europe Developer Guide official
  8. [S8] Setting up Your Account | PayU Europe Developer Guide official
  9. [S9] Manage User and Permissions official
  10. [S10] Get Client ID and Secret from Dashboard official
  11. [S11] Install PayU app on Zoho Marketplace official
  12. [S12] Partners for Advanced Global Fintech | PayU Global official
  13. [S13] Initiate POS Payment Transaction API official
  14. [S14] FAQs - Partner Integration official
  15. [composio] Composio — Managed OAuth apps directory official
  16. [probe] Live HTTP probes run by the agent (dummy client_id, no credentials) probe

Still uncertain

  • ? Evidence is thin: the planner's 'OAuth = yes' is not supported. No source shows an authorization-code/consent flow for third-party apps; the only real OAuth is merchant authentication.
  • ? S4 and S5 (PayU India 'Partner OAuth Integration' and 'Enable Co-Branded Onboarding (OAuth)') were fetched as navigation/menu text only — the actual requirements, endpoints and approval process are unknown.
  • ? No source states onboarding/approval duration; the 2–10 day and 1–6 week estimates are inferred.
  • ? The 401 error body from the probe was only described as mentioning 'error' — the actual error code/message is unverified.
  • ? Whether PayU India and PayU Europe have materially different partner-OAuth programs could not be confirmed from the fetched content.
  • ? No pricing, rate or contract terms appear in any source.
  • ? Generated automatically; no app was registered and no review was submitted.