Developer quickstart

Choose the capabilities you need before applying for a client. Platform sign-in alone does not require a merchant. Creating and paying orders for users requires a client bound to your own active merchant.

1. Choose a flow

Goal	Client and flow	Scopes
User sign-in	Public or confidential client, Authorization Code + PKCE	`openid profile`
Server-side store and product synchronization	Confidential client, Client Credentials	`merchant.profile.read products.read`
Collect payment for your own business orders	Merchant-bound confidential client, Client Credentials	`merchant_payments.create merchant_payments.read`
Users purchase through your application	User authorization with a merchant binding	Product, order and payment scopes as needed

Browser, desktop and mobile applications cannot hide a fixed Secret and should use a public client. Applications with a secure backend can use a confidential client. See Clients and secrets.

2. Apply and prepare configuration

After receiving a developer invitation, submit your application name, description, homepage, client type, redirect URIs and scopes. Once approved, check the Developer Center. For a confidential client, use the available rotation action to generate and save a Secret.

Prepare:

Name	Purpose
`AUTHORIZATION_ENDPOINT`	Full authorization page URL assigned to this client
`API_BASE_URL`	Assigned business API base URL, including its path prefix
`TOKEN_ENDPOINT`	Full assigned token endpoint
`USERINFO_ENDPOINT`	Full assigned userinfo endpoint
`CLIENT_ID`	Approved client identifier
`REDIRECT_URI`	Registered callback address you control
`CLIENT_SECRET`	Confidential clients only; store on the server

Obtain these service URLs from Developer Center → Application configuration → Service URLs after approval. Addresses are assigned per client. Preserve the complete base path and use the supplied OAuth endpoints without deriving them from another address. Keep URLs in application configuration and update them when the platform notifies you of a change. Documentation and callback URLs are not service endpoints.

For external-order collection, follow General merchant collection directly: obtain a server token, discover channels, create with an idempotency key and optional return_url, then reconcile confirmed payment. Buyer OAuth identity authorization is not a prerequisite; TDC still requires TDCloud sign-in at checkout.

3. Establish identity authorization first

Follow Authorization Code and PKCE. A Node.js backend can generate the parameters as follows:


import { randomBytes, createHash } from 'node:crypto'
 
const codeVerifier = randomBytes(32).toString('base64url')
const codeChallenge = createHash('sha256')
  .update(codeVerifier)
  .digest('base64url')
const state = randomBytes(32).toString('base64url')
const nonce = randomBytes(32).toString('base64url')

Generate fresh values for each attempt and bind the verifier, state and nonce to its initiating session. This example generates parameters only; it does not implement session storage or callback handling. The PKCE standard is RFC 7636 .

After obtaining tokens, call GET /oauth/userinfo and use sub to link the local account. Decoding a JWT is not verification. Do not use an ID Token as the OpenAPI Bearer Token.

4. Add products and orders

After verifying sign-in, implement the product, order and payment flow. Follow data formats for amounts and troubleshooting for failures.

Check your integration

Use your own test accounts to verify consent and denial, invalid state, expired authorization codes, refresh-token rotation and minimum scopes. Commerce also requires checking actual orders, payment, delivery and merchant revenue; verify the complete purchase flow after obtaining a token.