Click Create Application under Created Applications.
Provide the following details and click Save.
Name: The application name provided here is displayed on the Razorpay authorisation interface.
Website: Enter the URL of the application's website.
Logo: Upload a square image for application logo. If logo is absent, a default logo is used.
The following fields are displayed after the application is created, for development and production clients. These are read-only:
Client ID: Publicly exposed identifier of the client which is generated uniquely. It helps identify your application on Razorpay.
Client Secret: Privately shared string between the application and Razorpay. Do not expose the client secret publicly. It helps to authenticate the identity of the application on server-to-server API calls.
Redirect URIs: A whitelisted set of URIs defined during creation. Production clients can only use secure HTTPS URIs to prevent man-in-the-middle attacks. You can define multiple redirect URIs.
Edit the Redirect URIs for your clients if needed.
To connect to a sub-merchant's Razorpay account, the application redirects the user to a Razorpay-hosted webpage. The user can approve or deny the authorisation request on this page.
Define the following query parameters in the URL. All parameters are mandatory unless specified as optional:
client_id
string The unique client identifier.
response_type
string Specifies that the application is requesting an authorisation code grant. Possible value is code.
redirect_uri
string Callback URL used by Razorpay to redirect after the user approves or denies the authorisation request. The client should whitelist the redirect_uri.
scope
string Defines what access your application is requesting from the user. You can request multiple scopes by separating with a space. Possible values:
read_only: Provides read access to all resources. All GET API requests.
read_write: Provides read and write access to all resources on the API.
state
string A random string generated by your service. This parameter helps prevent cross-site request forgery (CSRF) attacks. State validation has to be implemented by your application and should work as described below:
Your application should generate a unique random string and save it in the database.
Send the random string to Razorpay in the authorisation request in the state parameter.
Razorpay sends back the same state value as query params on your redirect URI.
In your backend, you validate that the state value stored in your database matches the one you received for the client_id and the user that initiated the authorisation.
The server responds with the following parameters:
token_type
string Defines the type of access token. Possible value is Bearer.
expires_in
integer Integer representing the TTL of the access token in seconds.
access_token
string A private key used to access sub-merchant resources on Razorpay. Used for server-to-server calls only.
public_token
string A public key is used only for public routes such as Checkout or Payments.
refresh_token
string Used to refresh the access token when it expires.
razorpay_account_id
string Identifies the sub-merchant ID who granted the authorisation.
Store the access_token received above on your server. Using this token, you can access the sub-merchant's data on Razorpay APIs based on the level of access granted.
Using the public_token for authorisation can secure a public-facing implementation such as Razorpay Checkout. In such cases, the public_token can replace the key_id field as shown below:
You can use refresh tokens to generate a new access token. If your access token expires, you will receive a 4XX response from the API. You can make a request using your refresh token to generate a new (access_token and refresh_token) pair.
Refer to the following API request on how to request a new token:
POST
https://auth.razorpay.com/token
Watch Out!
You should make this request from the application's backend server only.
After you obtain an access token, you can use it to access the sub-merchant's data on Razorpay APIs. The access is controlled based on the scope requested for and granted by the user during the authorisation process.
Sub-merchants can revoke access to your application from their Razorpay Dashboard at any time. Once revoked, your application will no longer have the capability to perform any operations on the sub-merchant account.
We recommend subscribing to the account.app.authorization_revoked webhook event. This ensures that you receive real-time notifications whenever a sub-merchant revokes access to your connected application.