The Create Recurring Application Charge API is used to create a recurring charge for an application. This API is essential for developers implementing subscription-based billing workflows for their apps, allowing businesses to manage recurring charges with specific terms and limits.
This API is especially useful for:
Setting up recurring billing for application usage.
Defining usage-based billing terms and limits.
Managing application subscription charges with trial periods and specific conditions.
The unique ID of the recurring application charge.
372269663945671159
application_id
string
The unique ID of the application.
s1deCNxrkHePw03HD2bZ.xfwJAqe07nznt
name
string
The name of the recurring application charge.
test
price
string
The price of the recurring application charge.
10.0
capped_amount
string
The limit a customer can be charged for usage based billing. If this property is provided, then you must also provide the terms property. See usage charges for more information.
100.0
terms
string
The terms and conditions of usage based billing charges. Must be present in order to create usage charges, for example when the capped_amount property is provided. Presented to the merchant when they approve an app's usage charges.
terms
return_url
string
The redirect URL after payment.
https://shoplazza.com
confirm_url
string
The URL to confirm the recurring application charge.
https://test-shoplazza.stg.myshoplaza.com
status
string
The status of the recurring application charge (e.g., pending, active).
pending
test
boolean
Whether this is a test charge.
false
trial_days
int32
The trial period in days.
7
trial_ends_on
string
The end date of the trial period.
null
billing_on
string
The billing start date.
null
cancelled_on
string
The date the charge was cancelled.
null
cancel_sub_on
string
The subscription cancellation date, if applicable.
null
created_at
string
The creation timestamp of the recurring application charge.
2024-04-23T06:26:45Z
updated_at
string
The last updated timestamp of the recurring application charge.
2024-04-23T06:26:45Z
Error Response
Error responses in the API can be represented using two different fields: errors and error. Both fields provide details about issues encountered during request processing. Below is an explanation of the fields with their respective examples and descriptions.
Field
Type
Example
Description
errors
Array
[ "file number error"]
A list of errors encountered during the request processing.
Field
Type
Example
Description
error
String
"page not found"
Indicates an error encountered during the process
Error Detail
Status Code
Message
Possible Reason
Example Response
400
Bad Request
Invalid input format or request structure (e.g., missing required fields or incorrect data types).
Bad Request
Unauthorized
The request is missing valid authentication credentials or the credentials provided are invalid.
Unauthorized
422
Unprocessable Entity
The return_url field is missing in the API request body.
ReturnUrl is required
The return_url field is present but contains an invalid or improperly formatted URL
ReturnUrl must be a valid URL
There is a mismatch between the charge type specified in the application plan configuration and the charge type being created. T
“The chargetype configuration in the plan does not match with the listing, please check”
API Structure Overview
Language
Credentials
Header
URL
Click Try It! to start a request and see the response here!
